bugfix #896

bugfix:
md-input padding does not affect underline #896

I signed it!

Could you add a case like this to the demo so we can easily see it in different browsers? We use the demo extensively internally (at least until we have screenshot tests).

I don't got your point. You want me to put it to material2/src/demo-app/ for example?

I want you to a seciton in the input demo with padding (and maybe large borders).

@hansl is this still relevant?

Hard to say.  I'll check the bug tomorrow.

Hi @maciejsobala,
Changing the position of the underline will affect the md-hint, which now is misaligned. This PR is not the proper solution.


Annoying buffer right shift when beautifying with ST3 panes

So, this is more of an annoyance, but frequently when working with side by side panes and beautification is triggered, it'll shift the window to the right automatically.  Maybe there's a way to keep the window pinned left.

Seems like even after the command resets the viewport, there are instances where ST3 will try to shift the viewport right again.  Keeping an eye on this.


fix: make update proposal for onchain spaces functional agian

Summary
Closes: https://github.com/snapshot-labs/workflow/issues/247
Fixes following bugs:

Empty body (or other fields) won't cause editor to crash when triggering update proposal).
Using correct method on mana for updating proposal.
EthSig on starknet uses correct call format.
VP is not refreshed for editor when coming from pending proposal.

How to test

Create proposal on Starknet space (make sure to have delay to allow updating).
Try updating it.
It works.

Correct, fixed!


Cardinality of assigner in PIXm Query Params Out

Section Number https://profiles.ihe.net/ITI/PIXm/StructureDefinition-IHE.PIXm.Query.Parameters.Out.html
Issue In a PIXm Query  query response assigner in targetIdentifier should have cardinality 0..1
Proposed Change
See link above for Out parameters on the query.
Somewhere in the IG I read (I think) that in the query response, assigner is optional, but if it is sent, you shall send name.    If so, then change cardinality for assigner to 0..1 in the StructureDefinition
Priority:

Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

assigner is 0..1 but it is not listed in the differential (but the snapshot has 0..1), but i think we can adjust it, that is also shown in the differential.


Add the ability to name sourceSets in localMods

With the current design of forge loom, projects spanning multiple source sets cannot be loaded if they include a class from a non-main source set. (This is probably due to the way ExplodedDirectoryLocator works but I haven't checked)
This PR basically add something equivalent to ForgeGradle's mods:
mods {
	modname {
		source sourceSets.main
		source sourceSets.api
	}
}

would become
forgeLocalMods.clear()
localMods {
	named("modname", sourceSets.main, sourceSets.api)
}

I haven't found a simple way to get rid of forgeLocalMods.clear() and keep backwards compatibility.

Is there actually a reason to include a custom name for the sourceset?

Ah I see what you mean now, I would make it with closutes tho, thanks, will take a look

As far as I'm aware custom names aren't strictly necessary, but every sourceSet for the same mod should have the same name, this was just done quickly because I had issues and that was the first thing I though about. As for using closure, I'll see what I can do, but I'm not really familiar with them.

It's fine, I can do it if you don't

Yeah, sorry I'm lost on this one.

 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.


Add hidden visibility to protobuf build when we do custom protobuf

(continuation of #2306 )

This is now rolled into https://github.com/caffe2/caffe2/pull/2384


Bug: Tag Color Inconsistency

Description
The tags assigned to file in the file explorer exhibit inconsistent color coding. While the majority of tags are correctly color-coded, some entries deviate from the expected color scheme, creating confusion in categorization.
Steps To Reproduce

In "Details" view.
Click sort by tags. (on 2 or more tags, i tested 3 tags)

Files Version
<IP_ADDRESS>
Windows Version
10.0.22631.4602
User ID
639bed26-a7ce-4c31-97c1-4b31282bc40e
Log File
debug.log

Thanks for the report, This has already been fixed and will be available in the next update


verify transition sequence

In ad hoc testing I saw what I think were some extraneous entry/exits higher up the state tree than necessary.  I need to come back with a specific test case for this.  It is possible that I introduced this error with PR #1,
See https://en.wikipedia.org/wiki/UML_state_machine#Transition_execution_sequence for a description of how transitions are supposed to work according to the UML spec.

Confirmed incorrect behavior with unit test in commit 534dd9f


findfont: Font family 'Arial' not found.

After training a very simple XGBoost-model on toy data, I tried visualizing it. The visualization works, but before it appears, I get dozens if not hundreds of the same prompt: "findfont: Font family 'Arial' not found."
How do I get rid of this or suppress it?
I'm working in a jupyter notebook on Ubuntu 22.04.1. I do not have root access and can't install anything but python packages.
Sample code:
bst =      xgb.train(param,
dtrain,
num_round=2,
evals=evallist,
early_stopping_rounds=early_stopping_rounds,
verbose_eval=10)
viz_model = dtreeviz.model(bst,
X_train,
y_train,
tree_index=0,
feature_names=list(data.columns))
viz_model.view()
It really isn't all that involved ....

hi. yeah, annoying. trying setting fontname arg in view

@dalefi you can also suppress these warnings with:
import logging
logging.getLogger('matplotlib.font_manager').setLevel(level=logging.CRITICAL)

See here on Stack Overflow for more.
@parrt should we add this to dtreeviz for other users? Probably not, as importing dtreeviz would affect another package, matplotlib, in an unexpected way.

Thanks @mepland !  Very useful. I need this in a tutorial I just wrote...

Thanks @mepland  ! That worked.
@parrt I tried setting some other popular fontnames in view and all got me the same error (with that fontname instead of Arial of course).

I had the same problem. I had to ask matplotlib for the list of fonts that it new for the particular notebook. Jupiter seems to know a lot but colab does not.

Oh, I'm not working with colab, only on a GPU-server that I don't have access to. Should be a normal jupyter notebook on an Ubuntu machine.

https://github.com/ranaroussi/quantstats/issues/203#issuecomment-2419372779


feat: remove unnecessary 'tryParse' on parseDouble

There is some issue while calling parseDouble like this: https://github.com/dnfield/vector_graphics/issues/209
I suggest a fix to change the return of parseDouble to always double.tryParse so that it will return null instead of throwing an error if it parses an invalid String

Hi there, The Flutter team is now maintaining these packages in the flutter/packages repository at packages/vector_graphics and packages/vector_graphics_compiler. We'd appreciate it if you could direct this PR to those locations instead. Thanks!


Update Ixia for client api

Make use of go client API for IxiaTG CRD instead of REST API.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 25 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.4%) to 58.371%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

topo/node/ixia/ixia.go
0
25
0.0%

Files with Coverage Reduction
New Missed Lines
%

topo/node/ixia/ixia.go
1
9.96%

Totals

Change from base Build<PHONE_NUMBER>:
0.4%

Covered Lines:
2329

Relevant Lines:
3990

💛  - Coveralls

/gcbrun

We had a breakage in the presubmit (that was fixed but is not included on this branch). Can you cherrypick that change or resync and merge it in? https://github.com/openconfig/kne/commit/6a700bf042c3c461b5997e69ed91af2af32244d7
sorry about that

I have resynced and merged.

Resolved the go.sum conflict.

there are still merge conflicts unfortunately

okay I merged the other PR, ready to run the presubmit on this as well after the merge conflicts are resolved

/gcbrun


nbgitpuller hangs while syncing git repo

Starting from http://gallery.pangeo.io/repos/cgentemann/pangeo_ccmp/01_example-CCMP-notebook.html
I opened this binder link: https://binder.pangeo.io/v2/gh/pangeo-gallery/default-binder/master/?urlpath=git-pull?repo=https://github.com/cgentemann/pangeo_ccmp%26amp%3Burlpath=lab/tree/pangeo_ccmp/01_example-CCMP-notebook.ipynb%3Fautodecode
The binder loaded up okay, but then got stuck on this url
https://hub.binder.pangeo.io/user/pangeo-gallery-default-binder-qst1k5p6/git-pull?repo=https://github.com/cgentemann/pangeo_ccmp&urlpath=lab/tree/pangeo_ccmp/01_example-CCMP-notebook.ipynb?autodecode
With this status

The "click to see more details" button had no information.
It has been like that for 10 minutes.
I tried the same nbgitpuller link in https://staging.us-central1-b.gcp.pangeo.io/ and it worked fine.

The pinned nbgitpuller looks pretty old: https://github.com/pangeo-data/pangeo-docker-images/blob/2eef21daa9d399e41cbc276cd43622f5264ebb1f/base-notebook/conda-linux-64.lock#L185.
That apparently comes from the pin all the way in https://github.com/conda-forge/pangeo-notebook-feedstock/blob/84482c763e2034e76e6911e123a8b312a22ce7dd/recipe/meta.yaml#L19. I'd recommend bumping that (and maybe figuring out why it's not being auto-bumped)

Thanks a lot for the tip Tom! Is it safe to just manually bump that up to a newer version, or could I create an incompatibility problem that way? What would you recommend I try?

Confirming that upgrading nbgitpuller works in docker!
docker run -it --rm --volume `pwd`:/pangeo-forge -p 8888:8888 pangeo/pangeo-notebook:latest /bin/bash -c "mamba install --yes -n notebook -c conda-forge rise ipytree nbgitpuller==1.0.2; jupyter lab --ip <IP_ADDRESS> /pangeo-forge"

Manually bumping for now seems OK to me. Actually https://github.com/conda-forge/pangeo-notebook-feedstock/pull/84 is open with a bump, so maybe we just merge that?

https://github.com/conda-forge/pangeo-notebook-feedstock/pull/84 is merged now. I think that a bot will update the environment files here soon.

Amazing Tom, thanks so much!
While I've got you here, can I get you to review https://github.com/conda-forge/pangeo-notebook-feedstock/pull/86? (All related to the same project.) I don't want to break anything.

Not sure if this is still relevant since we've removed the pangeo binder links a few months ago already (https://github.com/pangeo-data/pangeo-docker-images/issues/459). Either way, nbgitpuller is at version 1.2.0, so I'll assume this is 'fixed' and close this.


Add log point on middle clicking gutter

Fix #204009

Thoughts @connor4312? What bugs me is that I always still have to move my hands to the keyboard after this anyway, so I wonder how much it speeds things up. And there's no way for anybody to discover this.

I always set logpoints via the context menu in the gutter, so there would be a marginal benefit for me, at least until I set up a keybinding for that command 😛
I'm not opposed to this, but there's no reason logpoint is special: the type of breakpoint should probably be configurable via a setting if we go this route.

the type of breakpoint should probably be configurable via a setting if we go this route

Agreed. I will proceed to add configuration for this.

This seems decent to me, what do you think @roblourens?

I don't have a mouse at the moment, so I can't properly test it. But I like the setting in principal, this is fine with me.


Request: Prevent rotation

Hi again!
Would be nice to set a return false; on the start function event to stop rotation if a condition is met. I'm trying to do it now, but it doesn't stop rotating the element. It just prevents the custom function execution, but not the rotation (like with jQuery UI resizable).
Thanks in advance.
Best regards,
Daglimioux.

Duplicate of another bug, which is now fixed.


loki.source.kubernetes_events: use last observed time as timestamp instead of creation time

Request
loki.source.kubernetes_events uses eventTime as timestamp. There should be an option to use series.lastObservedTime as timestamp.
Use case
In the current situation old events that are still firing can be rejected by Loki, which has a maximum age. It seem impossible at the moment to use series.lastObservedTime as timestamp since it is not included in the log message.
I also think this should be the default. It makes more sense to use lastObservedTime, so current events are at the top and no events are missing.
The following type of grafana agent error messages might be found:
ts=2024-03-21T11:13:26.025307679Z level=error msg="final error sending batch" component=loki.write.logs_service component=client host=loki-gateway status=400 tenant="" error="server returned HTTP status 400 Bad Request (400): entry for stream 'REDACTED' has timestamp too old: 2024-02-22T20:22:11Z, oldest acceptable timestamp is: 2024-03-14T11:13:26Z"

@hainenber I'm not sure I understand your remark. The latest time in the event is series.lastObservedTime. eventTime is when the event was created and can be a long time ago. When converting events to log messages I think it makes more sense to use series.lastObservedTime. This would prevent that old event logs become invisible in a monitoring tool like Grafana or that they will be pruned though they are still firing. It also means that a single event will create multiple log messages, which some users might not desire.


Incorrect Movement imports

When I upload this HDC file the game changes the movement from 4 running and swimming and 0 leaping 10/6/1 accordingly.

https://cdn.discordapp.com/attachments/770825017729482772/1144901800491749466/Grey_Ooze_MONSTER.hdc


#28 added logbook and loggin every request on TRACE

fixes #28

:+1:

[Current coverage][cc-pull] is 100%

Merging [#29][cc-pull] into [master][cc-base-branch] will not change coverage

@@           master   #29   diff @@
===================================
  Files          12    12
  Lines          97    97
  Methods         0     0
  Messages        0     0
  Branches        1     1
===================================
  Hits           97    97
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last updated by [049c163...02510fa][cc-compare]
[cc-base-branch]: https://codecov.io/gh/zalando-stups/log-sink/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/zalando-stups/log-sink/compare/049c163d37adfef5681e5adfdc5ac07ce3b2778b...02510fa747321e9142b17b6c775fdc383309a659
[cc-pull]: https://codecov.io/gh/zalando-stups/log-sink/pull/29?src=pr

👍


Feature proposal - parsing price in e-commerce webpage

One good functionnality was to allow parse price in e-commerce webpage.
If a price is found in the webpage, given, the price and the devise.

You can use the extend option to extract additional information from pages, as follows:

in a call to the parse() method:

Mercury.parse(
  url,
  {
    extend: {
      last_edited: { selectors: ['#last-edited'] }
    }
  }
)

on the command line:

mercury-parser https://www.nytimes.com/interactive/2019/03/11/magazine/regina-hall-movies-black-audience.html \
  --extend kicker=.kicker \
  --extend credits=.rad-article-credits \
  --extend-list captions=.rad-caption-text

in a custom extractor:

export const ExampleExtractorWithExtend = {
    ...

    extend: {
      categories: {
        selectors: ['.post-taglist a'],
        allowMultiple: true,
      }
    },

    ...

Thanks, but it's can be good to have a generic functionnality ?


Todo: Cliptok DM response when users reply to their punishment DMs

https://discord.com/channels/150662382874525696/780516096335282206/1074470744421048330


Missing Isotopes/Isotope Data

Hello. I've found this package rather useful but have encountered an issue with the nuclide data being incomplete or unexpectedly missing. When adding certain isotopes and metastable states to an inventory, I will get the following message.
[isotope]  is not a valid nuclide in icrp107_ame2020_nubase2020 decay dataset.
Upon checking the icrp107 report I can see that these isotopes are supposed to be present. V49 and V52 for example.
I am currently running radioactivedecay under Python 3.8 on Windows 10 with Radioactivedecay version 0.4.8 and installed via pip.
Any help would be appreciated, thank you.

Hi @JWingUtk
This is strange. Also running Python 3.8 on Windows 10 with Radioactivedecay version 0.4.8 installed via pip, those isotopes work fine for me.
The only thing I can think of is the nuclide string is case sensitive, so this works ("V49"):
>>> import radioactivedecay as rd
>>> rd.Inventory({"V49": 1.0})
Inventory activities (Bq): {'V-49': 1.0}, decay dataset: icrp107_ame2020_nubase2020

but this doesn't ("v49"):
>>> rd.Inventory({"v49": 1.0})
Inventory activities (Bq): {'V-49': 1.0}, decay dataset: icrp107_ame2020_nubase2020
....
ValueError: v49 is not a valid nuclide in icrp107_ame2020_nubase2020 decay dataset.

If this isn't your issue, can you please paste the command and full error Traceback you are finding?

It's been puzzling me for a bit. Case sensitivity is not the cause of my error. Below is the traceback I get trying to run my waste classification script.

@JWingUtk
Thanks! I think the issue is there is a white-space character at the end of your nuclide input string, i.e. it is "V49 " not "V49". This reproduces the same error on my machine:
>>> rd.InventoryHP({'V49 ': 1.0}, 'Bq')
...
ValueError: V49  is not a valid nuclide in icrp107_ame2020_nubase2020 decay dataset.

This is a bug - the package really should be able to cope with leading or trailing white-spaces in nuclide names like this. It should also be able to cope with case sensitivity issues like in my last message, i.e. accept "V49" or "v49".
The fixes for these issues are quite simple & would be great first issues. I noticed you recently joined GitHub - if you are interested in Python & contributing to open source software, I'd be happy to help mentor you on how to fix problems like this via the Pull Request system? If not, no worries, I'll work on a fix tomorrow.
In the meantime you should be able to fix the problem locally in your script by striping out the white-space characters from your nuclide strings. You can do this using a Dictionary comprehension on your Hp_inv_t0 dictionary like so before supplying it to the InventoryHP constructor:
Hp_inv_t0 = {nuc.strip(): act for nuc, act in Hp_inv_t0.items()}

Let me know what you think!

I'll patch it up on my end for now, but I am absolutely interested in contributing and being mentored on fixing problems via the pull request system. I feel pretty bad about not noticing the blank space at all, lost many hours to troubleshooting before submitting the issue here haha.

@JWingUtk That's great. Please drop me an email at alex.malins at DELETETHISgmail.com then we can get you up an running!

@alexmalins I believe I sent an email to the correct address. Let me know if you don't see anything!

Thanks got it!

PR #72 & release v0.4.11 solve this issue

Hey @GallegoSav - this issue is similar to this one: #80
The problem is one of naming: we should better describe the default dataset as just ICRP-107. Only the radionuclides in that dataset are included. Nubase2020 was just use to supplement atomic mass data that wasn't in ICRP-107. So all the nuclides in nubase2020 that don't also exist in ICRP-107 are not included in this package currently, sorry 😢


Cannot connect to redis://localhost:6379/0: Error 99 connecting to localhost:6379

superagi-backend-1          | ERROR:    Application startup failed. Exiting.
superagi-celery-1           | [2023-06-30 10:54:39,863: ERROR/MainProcess] consumer: Cannot connect to redis://localhost:6379/0: Error 99 connecting to localhost:6379. Cannot assign requested address..

Can you share some more detailed logs? Also, is the issue persisting?

Sorry iv moved on and tried again with latest version !

Sorry iv moved on and tried again with latterst version


deduce article title from url if it is empty

Try to deduce title from url only if the parsed title is empty. This happens with some blogs which don't populate the title properly.
This patch uses the already existing function make_title, although it is improved to not include .html or .htm at the end of the title.

Coverage decreased (-0.03%) to 32.394% when pulling f33f44d85e3625f9456a4905c9b39647756a0340 on p1er:title-from-url into 310d1adccf0ba47241b2896956090b2a226893f0 on akrennmair:master.

Coverage increased (+0.01%) to 32.434% when pulling e25e6817e9dd2ba67b7273cdc2f86d0049437358 on p1er:title-from-url into 310d1adccf0ba47241b2896956090b2a226893f0 on akrennmair:master.

Coverage increased (+0.01%) to 32.434% when pulling e25e6817e9dd2ba67b7273cdc2f86d0049437358 on p1er:title-from-url into 310d1adccf0ba47241b2896956090b2a226893f0 on akrennmair:master.

Coverage increased (+0.01%) to 32.434% when pulling e25e6817e9dd2ba67b7273cdc2f86d0049437358 on p1er:title-from-url into 310d1adccf0ba47241b2896956090b2a226893f0 on akrennmair:master.

Looks great, but a test for rss_parser will be nice, too—after all, that's what you wanted to change in the first place; changes to make_title are incidental.

@p1er, will you finish this, or should I take over? (I'll credit you in the Changelog either way.)

Okay, I'm taking over this.

Thank you for your work, @p1er!


AFrame: Ensure the support for handedness:none controllers

Some hardware has a single controller I think this should work but won't be cleaned up correctly.

Fixed


Add system/metadata table

Background
Currently Pinot doesn't have a way to store system metadata (other than looking through the logs)
This makes it super hard to debug, for example when I debug with @dongxiaoman in issue #7612 . It is super hard to figure out exactly which segment causes the AIOOB exception other than doing a log search.
Pitch
I was wondering if we can create some sort of system logging mechanism such as: https://dev.mysql.com/doc/refman/5.7/en/server-logs.html.
Draft Design Ideas
comparing with the mysql server logs. we can start with several subcategory of system metadata tables such as

server error logs ( indexed by server ID / segment ID ?)
query logs (controller / broker / server, indexed by requestID ?)
minion task logs (taskID?)

I am not sure if it is a good idea to add another step to write to a system metadata table in broker/server/controller/minion, especially if it potentially delays the query response time or minion task runtime. I was wondering if we can create a pinot-metadata SPI similar to pinot-metrics SPI so that we can easily plug in different metadata store backends and metadata writer (agent-based, direct push, JDBC, ... )
Thoughts?

Have you considered adding an interface to publishing such metadata to a stream? You can then consume it in Pinot and get analytics on it.

Have you considered adding an interface to publishing such metadata to a stream? You can then consume it in Pinot and get analytics on it.

this sounds like a great idea. in fact I was thinking about making the collect(metadata) as a stream interface or something similar to real-time segment upload logic.
The main idea for this SPI is to

create a separate user-facing API to log "important" logs that are different from the normal info/warn/error
enforce some type of schema on the log itself instead of a generic JSON blob
separate the "collect" and the "flush".

I was not my intention to limit the interface to publish to disk/database but not a stream.

Have you gone through https://docs.pinot.apache.org/developers/developers-and-contributors/contribution-guidelines ?
I would like to see a detailed design doc on what problem is being solved, and what areas are covered (more than logs? Any link with metrics? etc.) Overall, my understanding is that you are trying to ease Pinot operation. Please correct me if I am wrong.
thanks.

sounds good. I will create one. thanks for the pointer and the review in advance.

Have you gone through https://docs.pinot.apache.org/developers/developers-and-contributors/contribution-guidelines ?
I would like to see a detailed design doc on what problem is being solved, and what areas are covered (more than logs? Any link with metrics? etc.) Overall, my understanding is that you are trying to ease Pinot operation. Please correct me if I am wrong.
thanks.

sounds good. I will create one. thanks for the pointer and the review in advance.

Thank you, I can review the design doc. Please be sure to include what kiind of events you want to capture, and how it is going to help in operation. We have been thinking about this problem now, and would really like to have some long-term (months/years) data and trends captured. As examples:

controllers emit some table characteristics (number of segments, avg/min/max/median segment size, etc.)
minions emit some events for each segment they process (table name, segmentname, num records remved, etc.)
merger emits some number of segments processed
Brokers emit the RequestStatistics (or a part of it)
Multi-tenant realtime installations can benefit from knowing the "load" on each realtime server over time (how many segments are being handled, overall consumption rates, query rates, etc.) A rebalance command can analyze past trends to try to rebalance correctly, for example


Add LICENSE preface to the top of each code document

From Canada-Through-Time created by willtheorangeguy: willtheorangeguy/Canada-Through-Time#14
From Snoopy-Landing-Page created by willtheorangeguy: willtheorangeguy/Snoopy-Landing-Page#10
From PyWorkout created by willtheorangeguy: willtheorangeguy/PyWorkout#16
Add a license preface to the top of each code document. This can be from a personal license, or like something that the GNU GPL v3 has:
        How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

  To do so, attach the following notices to the program.  It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.

Also add information on how to contact you by electronic and paper mail.

  If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License.  Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".

  You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<https://www.gnu.org/licenses/>.

  The GNU General Public License does not permit incorporating your program
into proprietary programs.  If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library.  If this is what you want to do, use the GNU Lesser General
Public License instead of this License.  But first, please read
<https://www.gnu.org/licenses/why-not-lgpl.html>.

Not necessary for this website project.


fix problem where option input is not tag

Description
When the user selects an option for which WordPress version, to use in a new environment, if they select one of the stapled images, it tries to use that entire text as the option for the image, so the .lando.yml file looks like this:
  wordpress:
    type: compose
    services:
      image: ghcr.io/automattic/vip-container-images/wordpress:5.7   →  5.7.5
      command: sh -c "rsync -a /wp/ /shared/; chown www-data -R /shared; sleep infinity"
      volumes:
        - ./wordpress:/shared
        - type: volume
          source: scripts
          target: /scripts
          volume:
            nocopy: true

And that obviously will not work :-)
This change extracts the actual image tag from that string, and it throws a fatal error if it cannot.
Steps to Test

Check out PR.
Run npm run build
Run ./dist/bin/vip-dev-env-create.js --slug=test
Select WordPress Version:5.7   →  5.7.5
Finish the create sequence.
Run ./dist/bin/vip-dev-env-start.js --slug=test
Verify the WordPress 5.7 image gets pulled successfully.

wrong branch


Plan for core::future

Currently the traits within embedded-hal make use of the nb crate's flavour of async IO, however, core::future and core::task have recently been standardised and I believe are slated for inclusion in Rust 1.38. As such I was wondering whether migration towards using them would be something the maintainers of this project would be open to?
In particular use of  core::task::Waker opens up the possibility for HAL crates to use interrupts to signal when they are ready to make progress, avoiding the busy waiting that appears to be largely unavoidable with the current interface.
I'm aware that I'm not the first person to wonder this, see here, but I couldn't find an issue discussing it. The closest I could find was on the nb crate itself here.
If there is interest in this course of action I'm happy to look into writing a PoC, but I'm acutely aware there is, understandably, some caution around making breaking changes to the traits - see here.

So I'll caveat all the below with the fact I'm relatively new to rust and so what I say may be incorrect, but following further experimentation I do not believe it is yet possible for embedded_hal to make use of core::future and related types.
This is not to say that these types can't be used in embedded, far from it - it would be clunky but it is perfectly possible to use them in an embedded context, however, the specific constraints imposed by the design of embedded_hal, namely its use of traits and non static lifetimes, make this at least beyond my capabilities.
The easiest way to justify this, is to explain what I did, the problems I faced and how I bodged around them.
My first step was to build an "executor" that can run futures in an embedded environment. I don't believe it is possible to implement something like the executors in the standard library as the spawn interface seems to require dynamic memory allocation. However, it is relatively straightforward to write methods that can drive a core::future or an array of &mut core::future to completion, using a combination of the stateless wakers I describe in the linked issue, and core::future::LocalFutureObj. Implementations of the familiar block!, etc... macros can then be written using these methods.
Next I extended the traits within embedded_hal to use associated types to represent the future return types. I then tried to implement these traits within stm32f4xx_hal, however, immediately ran into an issue when the future needs to borrow a reference to the underlying peripheral for the lifetime of the future. Currently generic associated types are not close to stable, and so I bodged around this by making each of the embedded_hal traits generic over a lifetime parameter, and using this to parameterise the future associated type. The default blocking implementations required some HRTB magic to work, but I managed to make it work.
At this point I had a working stm32f4xx_hal and thought I was in the home stretch, however, I quickly discovered that trying to compose these futures was immensely fiddly. Not only does the somewhat hacky approximation to a generic associated type work against you, but I ended up having to use unsafe in order to preserve both the returned future and the peripheral it was borrowing across a Poll::Pending return. This is exactly what generators were created for, however, there is currently no way to resume them with an argument - in this case a core::task::Context. The current async implementation temporarily hacks around this using thread local storage, and this is why it isn't supported on embedded.
It was at this point that I threw in the towel, I realised I was trying to bodge together something that was complicated enough to have warranted inclusion in the language itself. Ultimately for embedded_hal to be able to use the new API it at a minimum needs generic associated types and the ability to resume generators with an argument. In practice these two features are likely to coincide with embedded async and async functions in traits, at which point the implementation becomes relatively trivial.
I will leave this issue open, but I won't be working on it further unless something changes.

@tustvold Thank you for looking into this, and for writing this extensive report!
I'd like to add my own experience to this bit:

immediately ran into an issue when the future needs to borrow a reference to the underlying peripheral for the lifetime of the future

If I had done this investigation, I would have stopped right here, unless I'd found an alternative to the borrowing. Experience has shown that this kind of borrowing is problematic in practice.
In the past, I've implemented my own future-like API (really basic, no thought spent on composing etc.) for the DW1000 driver. A call to send/receive on the main DW1000 struct would return a TxFuture/RxFuture, which was just another struct that borrowed the main struct and could be used to set up interrupts, poll the current status etc. This approach worked well enough for my examples, but experience with a non-trivial application showed that it didn't work beyond that.
The problem starts when you want to build an abstraction that requires the DW1000 struct to live as a field in another struct. If that encapsulating struct is supposed to fully manage the driver, that means it needs to store TxFuture/RxFuture too. Thanks to the lifetime, this turns into a self-referential struct, which doesn't work.
Maybe some language wizard will weigh in here and explain how that's all easy to solve using Pin or something, but my solution was to remove the futures, and instead add a type state parameter to DW1000. So DW1000 becomes DW1000<Ready>, TxFuture becomes DW1000<Sending> and RxFuture becomes DW1000<Receiving>. send/receive consume the DW1000<Ready> and return the DW1000<Sending>/DW1000<Receiving> respectively. The Sending/Receiving states provide their own methods to move back to Ready. No borrowing necessary.
For the simple examples this doesn't change much, except that they need an additional variable for sending/receiving, and need to assign the driver back to the original variable after completion. The complex application should be able to encapsulate the driver struct in an enum, with one variant for each of the states. Here's what the API looks like today: https://github.com/braun-embedded/rust-dw1000/blob/ceca46f9657fa09cba32b52b3a872b7a7108613e/src/hl.rs
(note: something there is not quite right yet; most testing was successful, but some of my examples stopped working for yet unknown reasons)
@tustvold Do you think this approach could help with a futures-based API? On first glance, it looks like we could get the original struct back from the future via Self::Output, but I haven't tried that.

If I had done this investigation, I would have stopped right here, unless I'd found an alternative to the borrowing. Experience has shown that this kind of borrowing is problematic in practice.

Yeah... I lack the experience with Rust to make those sorts of judgement calls :p That being said it did work quite well until I tried to wrap it with an impl.

If that encapsulating struct is supposed to fully manage the driver, that means it needs to store TxFuture/RxFuture too. Thanks to the lifetime, this turns into a self-referential struct, which doesn't work.

This is the exact issue that resulted in me throwing in the towel. You can work around it with Pin, as I did, but it is incredibly fiddly and I'm not totally sure what I've written is safe. Generators and by extension async solve this, but at the moment don't support embedded nor interfaces.

The Sending/Receiving states provide their own methods to move back to Ready. No borrowing necessary.

This is possible but unless I'm missing something doesn't compose well. Say for example you wanted to wrap the DW1000 driver a TDOA abstraction, or wanted to share its SPI bus with another component, neither of these would be trivially possible.
I think an approach similar to the one described here where the peripheral is moved into the future and returned on completion might work. I'll have a play around this evening after work and report back.

@tustvold

Yeah... I lack the experience with Rust to make those sorts of judgement calls :p That being said it did work quite well until I tried to wrap it with a trait.

That's why I'm here: To share the insights gained from my years-long (and ongoing) series of mistakes :-)

This is possible but unless I'm missing something doesn't compose well. Say for example you wanted to wrap the DW1000 driver in a TDOA abstraction, or wanted to share its SPI bus with another component, neither of these would be trivially possible.

I don't see how wrapping the driver in an abstraction is a problem, as that's the exact use case that this design is supposed to enable. But good point about sharing the SPI bus, I hadn't really considered that.
I guess one could create a representation of the shared bus that can move with the driver, similar to Sender/Receiver in std-land, but that would require fiddling with static's behind the scenes. Might be doable, but is also off-topic for this issue.
Lots of stuff to figure out in this space :-)

I think an approach similar to the one described here where the peripheral is moved into the future and returned on completion might work. I'll have a play around this evening after work and report back.

Yeah, that looks kind of what I had in mind. Looking forward to see what you come up with!

So one potential downside of moving the peripheral into the futures is that even the blocking APIs and usages can't borrow the values. The result is
let val = block!(serial.read());

Becomes
let (serial, val) = block!(serial.read());

It's also worth considering that whilst most HAL types should be lightweight to move, this isn't necessarily a guarantee. Nothing immediately springs to mind as an obvious use case for data storage within the peripheral, as opposed to the returned future, but I'm sure there must be a valid use case...

Would it be possible to provide multiple methods, one that borrows, one that moves? Maybe in such a case the Future implementation could be generic over what it takes/returns, or different Future implementations could be generated via a macro.
Not sure if any of that is practical. Just throwing out ideas.

@tustvold excellent writeup, thanks for exploring this!
i've been writing a bunch of non-embedded futures code recently and, as interesting as the concept is, i don't think they're a good option for embedded. it's possible that the ergonomics will improve significantly in the future, but, at this point in time there are a bunch of issues and hidden complexities that ime make complex applications with futures in rust vastly more difficult than just writing naturally async systems.
your writeup covers most of the embedded issues, the dynamic allocation and ergonomic pains that can only be solved with gratuitous use of Arc and Box are significant, but the major problem i have is that they're super contagious. once you have any component that uses futures, any code that would consume that (efficiently) is also forced to be asynchronous. maybe this can all be implemented in an opt-in way, but, i would be cautious of imposing this on hal users.

So one potential downside of moving the peripheral into the futures is that even the blocking APIs and usages can't borrow the values. The result is

there are a couple of examples of move-into-future in tokio and it seems the only way to ergonomically use them is to immediately wrap them with mpsc::channels so you can store and move references around. i think this has the same composability issues as type-state based futures.

It's also worth considering that whilst most HAL types should be lightweight to move, this isn't necessarily a guarantee

as above, if the hal is futures-based the consumers will be pushed to be to, and drivers with buffers etc. are often not lightweight. it might be possible to work around this with 'static buffers and things, but, it seems like it would introduce some complexity.

and instead add a type state parameter to DW1000

@hannobraun i have also been exploring the... limits ... of type-state programming with radio devices, for configuration rather than operating state. thanks for sharing your example ^_^
i had a very brief look at futures for the same send -> poll_send -> done pattern, but, couldn't conceptualise how they would interact with external interrupts or polling delays in a useful / simple / predictable way.

as above, if the hal is futures-based the consumers will be pushed to be to, and drivers with buffers etc. are often not lightweight. it might be possible to work around this with 'static buffers and things, but, it seems like it would introduce some complexity.

My thinking was that such buffers and other related state would likely be stored within the future object as opposed to the peripheral itself, but I agree that there is almost certainly some use case that would result in a chunky peripheral that is costly to move.

make complex applications with futures in rust vastly more difficult than just writing naturally async systems.

I can't agree with this more, it currently suffers from the same problem as C++ libraries like Boost.Asio - fantastically powerful but mind bending to use in practice. First-class language support to make this less painful is pretty much a necessity.

but the major problem i have is that they're super contagious.

And not only this but they don't really result in an abstraction that is particularly compelling - it is more restrictive and harder to reason about than the current API and the signature feature of interrupts isn't prevented by the current API, it is just out of scope and left to the HAL to handle. It's trying to provide a middle ground between bare-metal and an RTOS and I'm not really sure that's a good idea.
It's also worth considering that changes to embedded_hal are likely to be incredibly complicated and given the fact that native async will eventually make its way to embedded and traits, we'd likely end up suffering this pain twice.

@tustvold @ryankurte
Thanks for the additional info. Sounds like futures aren't a good option then, at least for now.
You talked about "naturally async" and "native async". As someone who's been following the async story from afar, what would that involve? async/await? Generators? Something else?

given the fact that native async will eventually make its way to embedded and traits

Any idea what that would look like? Maybe any articles I could read?

You talked about "naturally async" and "native async". As someone who's been following the async story from afar, what would that involve? async/await? Generators? Something else?

by "naturally async" i just mean code that is inherently non-blocking, the standard start_transmit()/check_transmit() or poll() paradigm that we've been writing forever, with internal state and without the addition of futures and generators.
i'm not sure what @tustvold means here by "native async", i guess the finalisation of async support (and custom generators etc. to support other uses of them) in rustc?

@ryankurte I indeed meant the stabilization of async support in rustc, with both embedded support and the ability to use them in traits.

cc new RFC for this: #172

I think y'all are ahead of me on this, but, had a bash at implementing futures over natually async traits, was okay except for futures traits not yet being available, TLS not being available on embedded platforms, and generators using std::boxed::Box. I also haven't worked out how to usefully integrate wakers (without just waking every time).

now that embedded-hal-async exists, I think this can be closed.


[5Dim Vehicles] Air Plane Speed issue

I think there is a problem with the Airplane's top speed. It moves at the same rate as the APC which is far slower than the vanilla car. One would expect an aircraft to have a top speed exceeding that of the trains.

Yes, the vehicles module need a total rework, but actually i have no time for it

Actually i was playing around in the lua a quick dirty fix is to just drop a  from the plane's weight from 35000 to 3500 this gives it a good speed

It is fixed in next release, thanks you ^^


Can I use this gem for front-end password strength check?

I saw zxcvbn js code in this gem, is it possible to leverage them for front-end password strength check? Then I won't be worry about the front-end zxcvbn version doesn't match back-end one.

@calfzhou I think you can by making API call to server side


User management

Any update in user management  first time runs fine  but second time  update gives a timeout error

solved ..


Possible improvement of mktemp error message

mktemp requires three 'X' in the pattern argument. In the case where the XXX is missing and the tmpdir option is provided, the uutils-coreutils mktemp error message is a bit cryptic. This error message is better in the GNU version and could be improved in my opinion:
coreutils$ ./target/release/coreutils mktemp --tmpdir foobar
mktemp: failed to create file via template 'foobar/tmp.XXXXXXXXXX': No such file or directory
GNU version:
$ mktemp --tmpdir foobar
mktemp: too few X's in template ‘foobar’

Note that for the version without tmpdir, the error messages are the same in both versions:
GNU version:
coreutils$ mktemp foobar
mktemp: too few X's in template ‘foobar’

$ ./target/release/coreutils mktemp foobar
mktemp: too few X's in template 'foobar'

That sounds like a good improvement indeed. Would you like to try to fix it?

That sounds like a good improvement indeed. Would you like to try to fix it?

I don't think I'll have time in the coming weeks (maybe later), so if someone wants to work on that feel free to.

Im working on this. Dont have too much time available, but should be coming soon :)

Fixed in https://github.com/uutils/coreutils/pull/4342


#150776 breaks building utsushi package

Describe the bug
The change introduced in #150776 breaks building utsushi package (on my system)
Steps To Reproduce
Steps to reproduce the behavior:
Add package like this:
{
    hardware.sane.enable = true;
    hardware.sane.extraBackends = with pkgs; [
      epkowa
      utsushi
    ];
    services.udev.packages = [ pkgs.utsushi ];
}

Results in an error during the build:
Output of `nix log /nix/store/dn3nfllgnfh8sn90vxds9vh7j756s541-imagescan-3.65.0.drv`
 @nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/3nj9xsc03aqdrfkgbn448y3x2j91lmag-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/ndpg46zh2wf7hxp820rwjv7w4ib0h83h-iscan-3.63.0-autoconf-2.70.patch?id=4fe8a9e6c60f9163cadad830ba4935c069c67b10
patching file configure.ac
applying patch /nix/store/8bpsxnwlghzq8ww11c6lyd33wmnjrmi7-iscan-3.61.0-imagemagick-7.patch?id=985c92af4730d864e86fa87746185b0246e9db93
patching file filters/doc-locate.cpp
@nix { "action": "setPhase", "phase": "autoreconfPhase" }
autoreconfPhase
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: running: autopoint --force
Copying file upstream/aclocal/codeset.m4
Copying file upstream/aclocal/extern-inline.m4
Copying file upstream/aclocal/fcntl-o.m4
Copying file upstream/aclocal/glibc2.m4
Copying file upstream/aclocal/glibc21.m4
Copying file upstream/aclocal/intdiv0.m4
Copying file upstream/aclocal/intl.m4
Copying file upstream/aclocal/intldir.m4
Copying file upstream/aclocal/intmax.m4
Copying file upstream/aclocal/inttypes-pri.m4
Copying file upstream/aclocal/inttypes_h.m4
Copying file upstream/aclocal/lcmessage.m4
Copying file upstream/aclocal/lock.m4
Copying file upstream/aclocal/longlong.m4
Copying file upstream/aclocal/printf-posix.m4
Copying file upstream/aclocal/size_max.m4
Copying file upstream/aclocal/stdint_h.m4
Copying file upstream/aclocal/threadlib.m4
Copying file upstream/aclocal/uintmax_t.m4
Copying file upstream/aclocal/visibility.m4
Copying file upstream/aclocal/wchar_t.m4
Copying file upstream/aclocal/wint_t.m4
Copying file upstream/aclocal/xsize.m4
Copying file po/Makevars.template
autoreconf: running: aclocal --force -I upstream/aclocal
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force --ltdl
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'upstream'.
libtoolize: copying file 'upstream/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'upstream/aclocal'.
libtoolize: copying file 'upstream/aclocal/libtool.m4'
libtoolize: copying file 'upstream/aclocal/ltargz.m4'
libtoolize: copying file 'upstream/aclocal/ltdl.m4'
libtoolize: copying file 'upstream/aclocal/ltoptions.m4'
libtoolize: copying file 'upstream/aclocal/ltsugar.m4'
libtoolize: copying file 'upstream/aclocal/ltversion.m4'
libtoolize: copying file 'upstream/aclocal/lt~obsolete.m4'
libtoolize: putting libltdl files in LT_CONFIG_LTDL_DIR, 'upstream/ltdl'.
libtoolize: copying file 'upstream/ltdl/COPYING.LIB'
libtoolize: creating file 'upstream/ltdl/Makefile.am'
libtoolize: copying file 'upstream/ltdl/README'
libtoolize: creating file 'upstream/ltdl/Makefile.in'
libtoolize: copying file 'upstream/ltdl/libltdl/lt__alloc.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt__argz_.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt__dirent.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt__glibc.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt__private.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt__strl.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt_dlloader.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt_error.h'
libtoolize: copying file 'upstream/ltdl/libltdl/lt_system.h'
libtoolize: copying file 'upstream/ltdl/libltdl/slist.h'
libtoolize: copying file 'upstream/ltdl/loaders/dld_link.c'
libtoolize: copying file 'upstream/ltdl/loaders/dlopen.c'
libtoolize: copying file 'upstream/ltdl/loaders/dyld.c'
libtoolize: copying file 'upstream/ltdl/loaders/load_add_on.c'
libtoolize: copying file 'upstream/ltdl/loaders/loadlibrary.c'
libtoolize: copying file 'upstream/ltdl/loaders/preopen.c'
libtoolize: copying file 'upstream/ltdl/loaders/shl_load.c'
libtoolize: copying file 'upstream/ltdl/lt__alloc.c'
libtoolize: copying file 'upstream/ltdl/lt__argz.c'
libtoolize: copying file 'upstream/ltdl/lt__dirent.c'
libtoolize: copying file 'upstream/ltdl/lt__strl.c'
libtoolize: copying file 'upstream/ltdl/lt_dlloader.c'
libtoolize: copying file 'upstream/ltdl/lt_error.c'
libtoolize: copying file 'upstream/ltdl/ltdl.c'
libtoolize: copying file 'upstream/ltdl/ltdl.h'
libtoolize: copying file 'upstream/ltdl/slist.c'
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force -I upstream/aclocal
autoreconf: running: /nix/store/khilbv2w0ixj55clcpsjzpaq0l1bhh2j-autoconf-2.71/bin/autoconf --force
autoreconf: running: /nix/store/khilbv2w0ixj55clcpsjzpaq0l1bhh2j-autoconf-2.71/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:208: installing 'upstream/compile'
configure.ac:204: installing 'upstream/missing'
connexions/Makefile.am: installing 'upstream/depcomp'
autoreconf: Leaving directory '.'
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
fixing libtool script ./upstream/ltmain.sh
fixing libtool script ./upstream/boost/tools/build/v2/engine/boehm_gc/ltmain.sh
configure flags: --disable-static --disable-dependency-tracking --prefix=/nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0 --with-boost-libdir=/nix/store/ryqkcl29gbspipvl8gdan8gkrq356xyk-boost-1.77.0/lib --with-sane-confdir=/nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0/etc/sane.d --with-udev-confdir=/nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0/etc/udev --with-gtkmm --with-jpeg --with-magick --with-magick-pp --with-sane --with-tiff
checking for a BSD-compatible install... /nix/store/abc8hz0v47jzsf048j1qx7m94bxfhpl7-coreutils-9.0/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /nix/store/abc8hz0v47jzsf048j1qx7m94bxfhpl7-coreutils-9.0/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '1000' is supported by ustar format... yes
checking whether GID '100' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... none
checking for gcc option to support OpenMP... -fopenmp
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... none
checking standard compliance level of g++... 201402L
checking the archiver (ar) interface... ar
checking pkg-config is at least version 0.9.0... yes
checking for a sed that does not truncate output... /nix/store/aw3vgxn4fdrjqgmc94fr582hjhr2z3p3-gnused-4.8/bin/sed
checking whether NLS is requested... yes
checking for msgfmt... /nix/store/shv8hvhagfzpw7sm9a0qaxxgdvvngnzp-gettext-0.21/bin/msgfmt
checking for gmsgfmt... /nix/store/shv8hvhagfzpw7sm9a0qaxxgdvvngnzp-gettext-0.21/bin/msgfmt
checking for xgettext... /nix/store/shv8hvhagfzpw7sm9a0qaxxgdvvngnzp-gettext-0.21/bin/xgettext
checking for msgmerge... /nix/store/shv8hvhagfzpw7sm9a0qaxxgdvvngnzp-gettext-0.21/bin/msgmerge
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by gcc... ld
checking if the linker (ld) is GNU ld... yes
checking for shared library run path origin... done
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /nix/store/rvdb7057bmg3rasbqq8lzl10dffy3p31-gnugrep-3.7/bin/grep
checking for egrep... /nix/store/rvdb7057bmg3rasbqq8lzl10dffy3p31-gnugrep-3.7/bin/grep -E
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /nix/store/aw3vgxn4fdrjqgmc94fr582hjhr2z3p3-gnused-4.8/bin/sed
checking for fgrep... /nix/store/rvdb7057bmg3rasbqq8lzl10dffy3p31-gnugrep-3.7/bin/grep -F
checking for ld used by gcc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... nm
checking the name lister (nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... (cached) pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse nm output from gcc object... ok
checking for sysroot... no
checking for a working dd... /nix/store/abc8hz0v47jzsf048j1qx7m94bxfhpl7-coreutils-9.0/bin/dd
checking how to truncate binary pipes... /nix/store/abc8hz0v47jzsf048j1qx7m94bxfhpl7-coreutils-9.0/bin/dd bs=4096 count=1
./configure: line 11993: /usr/bin/file: No such file or directory
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... yes
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... ld
checking if the linker (ld) is GNU ld... yes
checking whether the g++ linker (ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for gcc options needed to detect all undeclared functions... none needed
checking what extension is used for runtime loadable modules... .so
checking what variable specifies run-time module search path... LD_LIBRARY_PATH
checking for the default library search path... /lib /usr/lib
checking for library containing dlopen... -ldl
checking for dlerror... yes
checking for shl_load... (cached) no
checking for shl_load in -ldld... (cached) no
checking for dld_link in -ldld... no
checking for _ prefix in compiled symbols... no
checking whether deplibs are loaded by dlopen... yes
checking for argz.h... yes
checking for error_t... yes
checking for argz_add... yes
checking for argz_append... yes
checking for argz_count... yes
checking for argz_create_sep... yes
checking for argz_insert... yes
checking for argz_next... yes
checking for argz_stringify... yes
checking if argz actually works... yes
checking whether libtool supports -dlopen/-dlpreopen... yes
checking for ltdl.h... yes
checking whether lt_dlinterface_register is declared... yes
checking for lt_dladvise_preload in -lltdl... yes
checking where to find libltdl headers...
checking where to find libltdl library... -lltdl
checking for unistd.h... (cached) yes
checking for dl.h... no
checking for sys/dl.h... no
checking for dld.h... no
checking for mach-o/dyld.h... no
checking for dirent.h... yes
checking for closedir... yes
checking for opendir... yes
checking for readdir... yes
checking for strlcat... no
checking for strlcpy... no
checking for boostlib >= 1.49.0... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem... yes
checking whether the Boost::IOStreams library is available... yes
checking for exit in -lboost_iostreams... yes
checking whether the Boost::Program_Options library is available... yes
checking for exit in -lboost_program_options... yes
checking whether the Boost::Unit_Test_Framework library is available... yes
checking for doxygen... no
checking for perl... no
checking for dot... no
checking for pdflatex... no
checking for LIBUDEV... yes
checking for LIBUSB... yes
checking for LIBMAGICK_PP... no
checking for LIBMAGICK_PP... yes
checking for gm... no
checking for convert... convert
checking for LIBGTKMM... yes
checking for sane/sane.h... yes
checking SANE version... 1.0.32
checking where SANE backends are installed... /nix/store/9rz898v8nrnyz2z2als2sbfpvr3gywk4-sane-backends-1.0.32/lib/sane
checking where SANE configuration is kept... /nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0/etc/sane.d
checking for /nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0/etc/sane.d/dll.conf... yes
checking what udev configuration directory to use... /nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0/etc/udev
checking for /nix/store/5k24i0bqgcaylfyvq34amgjh7nvj4nmn-imagescan-3.65.0/etc/udev/rules.d... yes
checking for uncrustify... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for C/C++ restrict keyword... __restrict__
checking size of unsigned long long... 8
checking for __attribute__... yes
checking for nanosleep... yes
checking for poll... yes
checking for sleep... yes
checking for usleep... yes
checking for sqrt in -lm... yes
checking for jpeg_start_compress in -ljpeg... yes
checking for TIFFOpen in -ltiff... yes
checking for magic_open in -lmagic... no
checking for libusb_error_name in -lusb-1.0... yes
checking for libusb_get_port_number in -lusb-1.0... yes
checking for sigaction... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating connexions/Makefile
config.status: creating doc/Makefile
config.status: creating doc/tests/Makefile
config.status: creating drivers/Makefile
config.status: creating drivers/esci/Makefile
config.status: creating drivers/esci/tests/Makefile
config.status: creating filters/Makefile
config.status: creating filters/tests/Makefile
config.status: creating gtkmm/Makefile
config.status: creating gtkmm/about.xml
config.status: creating lib/Makefile
config.status: creating lib/tests/Makefile
config.status: creating sane/Makefile
config.status: creating sane/tests/Makefile
config.status: creating src/Makefile
config.status: creating src/tests/Makefile
config.status: creating tests/Makefile
config.status: creating po/Makefile.in
config.status: creating upstream/ltdl/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing libtool commands
@nix { "action": "setPhase", "phase": "buildPhase" }
building
build flags: -j8 -l8 SHELL=/nix/store/iqprjr5k5385bhf1dzj07zwd5p43py1n-bash-5.1-p12/bin/bash
make  all-recursive
make[1]: Entering directory '/build/source'
Making all in .
make[2]: Entering directory '/build/source'
make[2]: Leaving directory '/build/source'
Making all in lib
make[2]: Entering directory '/build/source/lib'
Making all in .
make[3]: Entering directory '/build/source/lib'
  CXX      connexion.lo
  CXX      device-info.lo
  CXX      exception.lo
  CXX      log.lo
  CXX      monitor.lo
  CXX      run-time.lo
  CXX      scanner.lo
  CXX      octet.lo
  CXX      context.lo
  CXX      iobase.lo
  CXX      device.lo
  CXX      filter.lo
  CXX      buffer.lo
monitor.cpp: In member function 'std::string utsushi::monitor::default_device() const':
monitor.cpp:79:56: error: '_1' was not declared in this scope
   79 |                   bind (&scanner::info::is_driver_set, _1));
      |                                                        ^~
monitor.cpp:79:56: note: suggested alternatives:
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
In file included from include/boost/system/detail/error_category.hpp:17,
                 from include/boost/system/error_category.hpp:10,
                 from include/boost/filesystem/path_traits.hpp:14,
                 from include/boost/filesystem/path.hpp:21,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
/nix/store/v819nrv8d33ns36gm4v9vqydq1v95axi-gcc-10.3.0/include/c++/10.3.0/functional:221:34: note:   'std::placeholders::_1'
  221 |     extern const _Placeholder<1> _1;
      |                                  ^~
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
In file included from include/boost/bind/bind.hpp:2336,
                 from include/boost/signals2/slot.hpp:15,
                 from include/boost/signals2/connection.hpp:25,
                 from ../utsushi/signal.hpp:28,
                 from ../utsushi/device.hpp:29,
                 from ../utsushi/scanner.hpp:27,
                 from ../utsushi/monitor.hpp:31,
                 from monitor.cpp:41:
include/boost/bind/placeholders.hpp:58:38: note:   'boost::placeholders::_1'
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
monitor.cpp: In function 'bool utsushi::is_all_device_connected(const container_type&, const id_list&)':
monitor.cpp:524:27: error: '_1' was not declared in this scope
  524 |                           _1, id->first, id->second));
      |                           ^~
monitor.cpp:524:27: note: suggested alternatives:
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
In file included from include/boost/system/detail/error_category.hpp:17,
                 from include/boost/system/error_category.hpp:10,
                 from include/boost/filesystem/path_traits.hpp:14,
                 from include/boost/filesystem/path.hpp:21,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
/nix/store/v819nrv8d33ns36gm4v9vqydq1v95axi-gcc-10.3.0/include/c++/10.3.0/functional:221:34: note:   'std::placeholders::_1'
  221 |     extern const _Placeholder<1> _1;
      |                                  ^~
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
In file included from include/boost/bind/bind.hpp:2336,
                 from include/boost/signals2/slot.hpp:15,
                 from include/boost/signals2/connection.hpp:25,
                 from ../utsushi/signal.hpp:28,
                 from ../utsushi/device.hpp:29,
                 from ../utsushi/scanner.hpp:27,
                 from ../utsushi/monitor.hpp:31,
                 from monitor.cpp:41:
include/boost/bind/placeholders.hpp:58:38: note:   'boost::placeholders::_1'
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
monitor.cpp: In function 'void utsushi::configure_combo_device(utsushi::monitor::container_type&)':
monitor.cpp:557:41: error: '_1' was not declared in this scope
  557 |                                         _1, id->first, id->second));
      |                                         ^~
monitor.cpp:557:41: note: suggested alternatives:
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
In file included from include/boost/system/detail/error_category.hpp:17,
                 from include/boost/system/error_category.hpp:10,
                 from include/boost/filesystem/path_traits.hpp:14,
                 from include/boost/filesystem/path.hpp:21,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
/nix/store/v819nrv8d33ns36gm4v9vqydq1v95axi-gcc-10.3.0/include/c++/10.3.0/functional:221:34: note:   'std::placeholders::_1'
  221 |     extern const _Placeholder<1> _1;
      |                                  ^~
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
In file included from include/boost/bind/bind.hpp:2336,
                 from include/boost/signals2/slot.hpp:15,
                 from include/boost/signals2/connection.hpp:25,
                 from ../utsushi/signal.hpp:28,
                 from ../utsushi/device.hpp:29,
                 from ../utsushi/scanner.hpp:27,
                 from ../utsushi/monitor.hpp:31,
                 from monitor.cpp:41:
include/boost/bind/placeholders.hpp:58:38: note:   'boost::placeholders::_1'
In file included from include/boost/mpl/aux_/include_preprocessed.hpp:37,
                 from include/boost/mpl/placeholders.hpp:43,
                 from include/boost/iterator/iterator_categories.hpp:16,
                 from include/boost/iterator/iterator_facade.hpp:13,
                 from include/boost/filesystem/path.hpp:22,
                 from include/boost/filesystem.hpp:16,
                 from monitor.cpp:36:
include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note:   'mpl_::_1'
make[3]: *** [Makefile:706: monitor.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/build/source/lib'
make[2]: *** [Makefile:722: all-recursive] Error 1
make[2]: Leaving directory '/build/source/lib'
make[1]: *** [Makefile:618: all-recursive] Error 1
make[1]: Leaving directory '/build/source'
make: *** [Makefile:526: all] Error 2
****

When pinning the channel and installing the package to the previous revision b0249fdf998d782e1058b0cf3239091e59e393ef
the package doesn't break.
Please let me know if you need any more input
Notify maintainers
@abbradar
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.5-zen1, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`

Thanks for the report!

@abbradar Thanks, the fix works! :raised_hands:


Don't send credentials over the wire with SSL on (try SSL first)

Don't send credentials over the wire with SSL on. Try ssl
connection first. This way we will avoid sending credentials
unencrypted over the wire, when we want SSL connection.

I really like the idea of trying to update Excon with better exception messages.  Nothing I wanna hold up this PR for.  But, definitely something to think about.
@Ladas, can you open an issue on excon to suggest this idea (if for nothing else than to just track the idea)?

@blomquisg ook, I'll try :-)


python311Packages.cloudsplaining: 0.5.1 -> 0.6.0

Diff: https://github.com/salesforce/cloudsplaining/compare/refs/tags/0.5.1...0.6.0
Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 240876 run on x86_64-linux 1

6 packages built:

checkov
checkov.dist
python310Packages.cloudsplaining
python310Packages.cloudsplaining.dist
python311Packages.cloudsplaining
python311Packages.cloudsplaining.dist

Result of nixpkgs-review pr 240876 run on x86_64-linux 1

6 packages built:

checkov
checkov.dist
python310Packages.cloudsplaining
python310Packages.cloudsplaining.dist
python311Packages.cloudsplaining
python311Packages.cloudsplaining.dist


V2 (Maps Feature) - Add a 'Loading data...' message when data is still loading for each of the map views

Current Behavior:
V2 Build 33
Sometimes while switching between map views, while data is loading, the map is blank for a long time.
Expected Behavior:
This is going to get more pronounced as users add MORE data. I suggest for every case when a user is loading a map view - and all the data isn't fully loaded yet - have a 'Loading data...' message appear - and disappear once all the data is loaded and the map is ready for use.

Works great. Thanks @monikap0612 !

Works great. Thanks @monikap0612 !


Rename the '[service] connect' commands to '[service] login'

We should rename all connect commands (like spo connect, graph connect, etc.) to login (spo login, graph login), to clearer indicate that the command is meant to obtain an access token rather than establish a working context.
The currently used connect name is particularly confusing when working with SharePoint commands. If you've worked with CSOM or PnP PowerShell, you know that before performing an operation on a site you have to connect to that particular site. Everything you do afterwards, will assume the context of the site to which you connected.
This isn't the case with the CLI, where you can connect once and operate on any site in your tenant you want. Connecting to a service means obtaining an access token. Because you don't need a different access token for each site, there is no need to reconnect. In each command that operates on site-scoped resources, you specify the URL of the site through its arguments.
@andrewconnell and I realized this when discussing some commands in the CLI and how they operate on the different resources. We came to the conclusion that changing the name from connect to login would make it clearer that you only need to sign in once and unless you want to communicate with a different tenant, you can work with any site without reconnecting.
To prevent a breaking change, we wouldn't remove the connect command but would show a deprecation warning suggesting using the login command instead. The internal working of the command would remain as-is. For consistency, we'd also introduce a logout command which would be a counterpart to disconnect.
What do you think? @VelinGeorgiev @rfjschouten @RARomano @mpowney @wictorwilen

Piling on... why login & logout? It matches what the Azure CLI uses.

If you're interested how it would look like, check out #578

I agree that this is much clearer. Just a small remark; shouldn't lines like the following also be updated to match the change from connect to login?
     cmd.log({
       connectedTo: auth.site.url,
       connectedAs: Utils.getUserNameFromAccessToken(auth.service.accessToken)
     });

So maybe use something like 'Logged in to' and 'Logged in as'?
Lines like these can be found in the following files

office365-cli/src/o365/aad/commands/status.ts
office365-cli/src/o365/azmgmt/commands/status.ts
office365-cli/src/o365/graph/commands/status.ts
office365-cli/src/o365/spo/commands/status.ts


Rename suite,

Codecov Report

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

@@            Coverage Diff            @@
##             master      #20   +/-   ##
=========================================
  Coverage     92.50%   92.50%
  Complexity       34       34
=========================================
  Files             5        5
  Lines            80       80
=========================================
  Hits             74       74
  Misses            6        6

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 82a8099...90a568f. Read the comment docs.


[Story] View summary of latest upload

Epic
Epic issue includes overview, complete list of user stories, technical and content requirements, user testing task ideation, and current design mock-ups.

https://github.com/cfpb/sbl-project/issues/35

User story

As a filer, I want to view a summary of the latest upload, so that I can know which version of my file is being checked for errors and warnings.
Summary includes:

File name
User name
Date and time uploaded
Number of data errors
Number of warnings

Acceptance criteria

Given [some context or conditions], when [the action that is performed], then [the expected observable outcome or behavior].

Technical tasks
Developers should create technical tasks and add links (below) prior to sprint planning.
Front end

[ ] Task (link)
[ ] Task (link)

Back end

[ ] Task (link)
[ ] Task (link)

Small suggestion for the language in the user story here: change "which version of my file is being checked" to "which file was checked". This just keeps it clear that the summary shows up after the file is checked.


fix : Optimize get_all_models Function by Adding Caching for Improved Performance

Pull Request Checklist
Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.
Before submitting, make sure you've checked the following:

[x] Target branch: Please verify that the pull request targets the dev branch.
[x] Description: Provide a concise description of the changes made in this pull request.
[ ] Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
[x] Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources?
[x] Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?
[ ] Testing: Have you written and run sufficient tests for validating the changes?
[x] Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
[x] Prefix: To cleary categorize this pull request, prefix the pull request title, using one of the following:

BREAKING CHANGE: Significant changes that may affect compatibility
build: Changes that affect the build system or external dependencies
ci: Changes to our continuous integration processes or workflows
chore: Refactor, cleanup, or other non-functional code changes
docs: Documentation update or addition
feat: Introduces a new feature or enhancement to the codebase
fix: Bug fix or error correction
i18n: Internationalization or localization changes
perf: Performance improvement
refactor: Code restructuring for better maintainability, readability, or scalability
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
test: Adding missing tests or correcting existing tests
WIP: Work in progress, a temporary label for incomplete or ongoing work

Changelog Entry
Description

Implementing caching within the get_all_models function is expected to reduce processing time for repeated calls, thereby enhancing the responsiveness and scalability of our application.

Changed

[List any changes, updates, refactorings, or optimizations]
optimizations  backend performance

Additional Information

[Insert any additional context, notes, or explanations for the changes]

[Reference any related issues, commits, or other relevant information]

Screenshots or Videos

[Attach any relevant screenshots or videos demonstrating the changes]

Awesome! I'm loosing 6 seconds of my life, every time I open the ui. Would be handy to have the cache time configurable, because I don't need model refreshes every 10 minutes. Once a day is totally fine imho.

Does that mean that if I'm coding a pipe or pipeline, I won't see it updated for 10 minutes ? Same for ollama (i'm using my own separate container). I support @kaiiiiiiiii 's idea to add an env variable to make the cache duration customizable.

indeed, the default needs to be no cache, config option should be exposed as an env var here!

Closing due to conflicts, feel free to reopen!


XML response conversion is not consistent

It's a common issue with XML parsing. Array of one element is treated as a single object.
There are two solutions:

The elegant way is to do something similar to what was done in bigbluegraph:

...
const xml = await this.get(pathname)
const json = parseXml(xml).response
let recordings = json.recordings ? json.recordings.recording : []
recordings = Array.isArray(recordings) ? recordings : [recordings]
...

Might just delegate the functionality to the consumer library, but provide utilities for parsing, and normalizing.

Solved in 0.2.0

Solved in 0.2.0


Async / Promise Variables

Variables option in smart query isn't being waited for async variables function to be resolved before fetching.
apollo: {
        list: {
            query,
            async variables() {
                const data = await getData();
                return { data };
            },
       },
},
`

Is there any solution to this?

any update on this? is there any solution?

In these cases, I load required data elsewhere (mounted, on some event, whatever is appropriate) and use the skip() option of vue-apollo to wait until the data is available to run.


helm-critique breaking change

Repro
Gonna pin to an older version to avoid this but I noticed there were indeed some recent changes made here that disapper if i go to an older version (the one with the decode implemented for neurips client)
From here https://github.com/llm-efficiency-challenge/neurips_llm_efficiency_challenge
pip install git+https://github.com/stanford-crfm/helm.git
helm-run --conf-paths run_specs_full_coarse_600_budget.conf --suite v1

Logs
Traceback (most recent call last):
  File "/opt/conda/envs/helm/bin/helm-run", line 5, in <module>
    from helm.benchmark.run import main
  File "/opt/conda/envs/helm/lib/python3.10/site-packages/helm/benchmark/run.py", line 19, in <module>
    from .executor import ExecutionSpec
  File "/opt/conda/envs/helm/lib/python3.10/site-packages/helm/benchmark/executor.py", line 9, in <module>
    from helm.proxy.services.server_service import ServerService
  File "/opt/conda/envs/helm/lib/python3.10/site-packages/helm/proxy/services/server_service.py", line 22, in <module>
    from helm.proxy.clients.auto_client import AutoClient
  File "/opt/conda/envs/helm/lib/python3.10/site-packages/helm/proxy/clients/auto_client.py", line 21, in <module>
    from helm.proxy.critique.critique_client import CritiqueClient
ModuleNotFoundError: No module named 'helm.proxy.critique'

Thanks for the report.
@JosselinSomervilleRoberts could you take a look at this?

Hey @msaroufim, could you please see if #1888 solved it? I was not able to reproduce the error on my side. Thanks for reporting the bug!


Design delay button in power management area

User story

As a User
I want to be able to trigger an action with a delay of 30secs or 1min
So that I can simulate a delayed start of an action in the power management area.

With this User story the button to delay an action in the power management area is to be implemented.
The functionality of actually delaying an action will be implement with #52 and #53 .
Acceptance criteria

In the power management area, there is a button to delay an action.

Definition of done (DoD)

Code compiles and builds
Acceptance criteria are met
Feature tests have been written and were passed at/above 75% test coverage
Code is peer-reviewed
Feature is merged into development branch
Documentation is updated
Bill of Materials is updated

DoD general criteria

Feature has been fully implemented
Feature has been merged into the mainline
All acceptance criteria were met
Product owner approved features
All tests are passing
Developers agreed to release

Reopened as feature has been automatically closed with PR.


Guess colour by RGB game added

Fixes #160

Rules of the Game

the game has 2 levels, easy and hard.

On picking hard, you will have to choose the closest match out of 6 options to the given RGB coordinates.
On picking easy, you will have to choose the closest match out of 3 options to the given RGB coordinates.
After picking the most accurate colour you win!
Click on play again to start over again. If you want to restart a game just click on 'new colors'.

Working Video of the Project
https://github.com/ssitvit/Code-Canvas/assets/93376863/ae123e70-e8d6-4be3-a4fc-eed9302eb349

@Shreyaar12 @cleveranu @Dharmesh177 @artimanputra I added the screenshot of the game. Can you please check and merge it with GSSoC23 and the level 2 label?

@Shreyaar12 @cleveranu @Dharmesh177 @artimanputra I added the screenshot of the game. Can you please check and merge it with GSSoC23 and the level 2 label?

Please share a screen recording of your project

Added the working video of the project along with the rules of the game. Kindly merge it with the main code.

@Dharmesh177 index.html file updated, here too. Kindly merge this PR with the main code.

Please merge this with the main code.
@artimanputra @Dharmesh177 @Shreyaar12 @cleveranu


Add support to init NiFi with REST API calls to create controller-services, parameter-providers ....

This has been merge with #975 into the platys-mdp-init service, which allows to both initialize NiFi and Vault over the REST API.
The docker image which supports it can be found here: https://github.com/TrivadisPF/docker-nifi-init


Unable to download the C code from the cells nor able to identify where compiled files are stored

I get the following error when attempting to download the C file from the notebook.
nbconvert failed: FileExtension trait 'file_extension' does not begin with a dot: 'c'
And I am unable to locate the compiled files. Is the first issue resolvable, and is there a location where the kernel sends the compiled files (as is similarly done for cython and fortran magics)?

The problem looks like it is fixed in the new version.
The compiled file are temporary files and cannot easily be viewed. Why do you need them? :)
Please re-open the issue it it does not work after upgrading.


HBASE-26083 In branch-2 & branch-1 L1 miss metric is always 0 when using CombinedBlockCache

https://issues.apache.org/jira/browse/HBASE-26083

@anoopsjohn any comment about this?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 39s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ branch-1 Compile Tests _

+1 :green_heart:
mvninstall
10m  2s
branch-1 passed

+1 :green_heart:
compile
0m 43s
branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19

+1 :green_heart:
compile
0m 48s
branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10

+1 :green_heart:
checkstyle
1m 50s
branch-1 passed

+1 :green_heart:
shadedjars
3m 11s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 51s
branch-1 passed with JDK Azul Systems, Inc.-1.8.0_262-b19

+1 :green_heart:
javadoc
0m 41s
branch-1 passed with JDK Azul Systems, Inc.-1.7.0_272-b10

+0 :ok:
spotbugs
3m 14s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
3m 10s
branch-1 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 51s
the patch passed

+1 :green_heart:
compile
0m 41s
the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19

+1 :green_heart:
javac
0m 41s
the patch passed

+1 :green_heart:
compile
0m 45s
the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10

+1 :green_heart:
javac
0m 45s
the patch passed

+1 :green_heart:
checkstyle
1m 30s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
2m 49s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
5m  9s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1 :green_heart:
javadoc
0m 33s
the patch passed with JDK Azul Systems, Inc.-1.8.0_262-b19

+1 :green_heart:
javadoc
0m 40s
the patch passed with JDK Azul Systems, Inc.-1.7.0_272-b10

+1 :green_heart:
findbugs
2m 53s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
141m 52s
hbase-server in the patch passed.

+1 :green_heart:
asflicense
0m 36s
The patch does not generate ASF License warnings.

184m 57s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3474/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3474

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux ff06f9f9c9c2 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-agent/workspace/Base-PreCommit-GitHub-PR_PR-3474/out/precommit/personality/provided.sh

git revision
branch-1 / 3b3ec32

Default Java
Azul Systems, Inc.-1.7.0_272-b10

Multi-JDK versions
/usr/lib/jvm/zulu-8-amd64:Azul Systems, Inc.-1.8.0_262-b19 /usr/lib/jvm/zulu-7-amd64:Azul Systems, Inc.-1.7.0_272-b10

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3474/7/testReport/

Max. process+thread count
4048 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3474/7/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Approved.  I had approved another branch-1 PR also yesterday. Thought that was the one :-).   NP all looks good. Pls merge.   Nice work


Ability to modify puzzle details after creation

People make typos.
We should support editing of fields post-creation -- most importantly the puzzle name and URL fields which are user-generated. It'd be nice to be able to change slack channel as well if there was a typo in the puzzle name.

Maybe this feature should only be available to admins so that we don't have to deal with lots of people deleting stuff at the same time.

Oh one thing that is super important is editing the "meta" status of a puzzle (that is... whether or not it's a meta puzzle). Since it's such a small checkbox, it's easy to forget. Also, sometimes you won't know right off the bat if an existing puzzle is actually a meta puzzle or not.
I can see how this can be tricky from the Django model perspective since a Metapuzzle is actually a subclass of Puzzle. You'd probably have to create a new Metapuzzle, port over the existing puzzle's fields, and then delete the old Puzzle.

Actually, the more I think about it, the more I'm leaning towards just removing the whole Metapuzzle subclass altogether, and have "is_meta" be a field. The reasons being what I said above, and the fact that it's awkward to search through both Puzzles and Metapuzzles. For example, when we check for channel_id uniqueness, we search through both classes.
@rawxfish -- what do you think?

Those sound like compelling reasons, let's do it.