No Linux ARM64 binaries available

This took quite an effort to build on Ubuntu 22.04 ARM64.
The resulting binaries are available at:
https://home.mattfoster.me.uk/PEPEPOW-v0.4-aarch64-linux.tar.gz
sha256sum /var/www/html/PEPEPOW-v0.4-aarch64-linux.tar.gz
5f12ed5bfd5a0eeccbcb5d9739cf0285ade42471aac73cf499920ee49eacf138  /var/www/html/PEPEPOW-v0.4-aarch64-linux.tar.gz
md5sum /var/www/html/PEPEPOW-v0.4-aarch64-linux.tar.gz
45afa28ce64ebd9176cb8975960c4112  /var/www/html/PEPEPOW-v0.4-aarch64-linux.tar.gz

./PEPEPOW-cli: error while loading shared libraries: libboost_thread.so.1.74.0: cannot open shared object file: No such file or directory

./PEPEPOW_qt: error while loading shared libraries: libzmq.so.5: cannot open shared object file: No such file or directory
is on RPI4 I tryed installing
sudo apt install libboost-dev
is a plain image of rpi
Raspberry Pi OS Lite
Release date: May 3rd 2023
System: 64-bit
Kernel version: 6.1
Debian version: 11 (bullseye)

Do you think is it possible to get it work in ARM32 for RPI3 ??

libzmq

Try apt install libzmq5

Do you think is it possible to get it work in ARM32 for RPI3 ??

I'm sure it is, but I don't have an arm32 cross build chain setup, and the chances of building it natively are slim to none (CC+ is a big memory pig).   If I get time, I'll post up my cleaned up source tree that builds on Ubuntu 22.04, but it's still a bit of a mess.

Do you think is it possible to get it work in ARM32 for RPI3 ??

I'm sure it is, but I don't have an arm32 cross build chain setup, and the chances of building it natively are slim to none (CC+ is a big memory pig). If I get time, I'll post up my cleaned up source tree that builds on Ubuntu 22.04, but it's still a bit of a mess.

Let me know I can procure you and RPI3 environment to test it, or if you give some directions I can try to make it work, I think if we  have a inexpensive RPI3 running a wallet node could be great mainly for this moon core update.

libevent-2.1.so.7

Well I give up, install a lot of required libraries but always a newone appears, until
./PEPEPOW_qt: /lib/aarch64-linux-gnu/libcrypto.so.3: version OPENSSL_3.0.0' not found (required by ./PEPEPOW_qt) ./PEPEPOW_qt: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.32' not found (required by ./PEPEPOW_qt)
./PEPEPOW_qt: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by ./PEPEPOW_qt) ./PEPEPOW_qt: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.33' not found (required by ./PEPEPOW_qt)
./PEPEPOW_qt: /lib/aarch64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./PEPEPOW_qt)
and there is no way to update it, also I recompile the openssl, but doesn't work, Tryed to build the project from the source and was worst if you can share the sources you use in your project I can try to recompile it for RPI4 and Will share it with the community.
thanks in advance regards

Version 0.5 now available for ARM64 - complete with all the necessary libraries.
https://home.mattfoster.me.uk/PEPEPOW-v0.4-aarch64-linux.tar.gz
md5: bef5f21ad2a7285913babd65226ea880  PEPEPOW-v0.5-aarch64-linux.tar.gz
SHA256: 8f1db233bfe353d71e412788c18b0792f26312ec0e2c6be77952fcabb4440248  PEPEPOW-v0.5-aarch64-linux.tar.gz
The tar ball contains opt/PEPEPOW/lib and opt/PEPEPOW/bin
Extract it into the root filesystem, and then do
export LD_LIBRARY_PATH=/opt/PEPEPOW/lib:$LD_LIBRARY_PATH
export PATH=/opt/PEPEPOW/bin:$PATH
This should allow you to run without going through the library dependency hell

Source tarball which compiles against modern versions of libboost available at
https://home.mattfoster.me.uk/pepe-0.5-src.tar.gz
source code - hopefully useful to someone wanting to compile for a non X64 architecture.

Source tarball which compiles against modern versions of libboost available at
https://home.mattfoster.me.uk/pepe-0.5-src.tar.gz
source code - hopefully useful to someone wanting to compile for a non X64 architecture.

Great I am trying, to make it work on RPI4 , First I tried with the binaries and the libraries posted, but also fail and then tryed to recompile this source, I execute the configure and I get this error
checking for Berkeley DB C++ headers... default configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore or --disable-wallet to disable wallet functionality), now trying to recompile the version of DB

It's relatively easy to compile, or you can loose the wallet portability and configure with --with-incompatible-bdb

I've forked the tree, committed my changes, and submitted a PR to get this merged in.
Whilst we're waiting for that, you may find it easiest to check the modified source code out from
https://github.com/MattF42/PePe-core

V0.6 Binaries
https://home.mattfoster.me.uk/PEPEPOW-v0.6-aarch64-linux.tar.gz
$ md5sum PEPEPOW-v0.6-aarch64-linux.tar.gz
7a1fb65e9f8b7cc5f9e457a06e8ec2d2  PEPEPOW-v0.6-aarch64-linux.tar.gz
$ sha256sum PEPEPOW-v0.6-aarch64-linux.tar.gz
b5bd0fd1512b5232ff00da3d6aca505f4c095de59f2b71e2ec920117604983e9  PEPEPOW-v0.6-aarch64-linux.tar.gz


NTR: endothelial cell-matrix adhesion via collagen

Please provide as much information as you can:

Suggested term label:

endothelial cell-matrix adhesion via collagen
endothelial cell-matrix adhesion via laminin
endothelial cell-matrix adhesion via vitronectin

Definition (free text)

The binding of an endothelial cell to the extracellular matrix via collagen.
The binding of an endothelial cell to the extracellular matrix via laminin.
The binding of an endothelial cell to the extracellular matrix via vitronectin.

Reference, in format PMID:#######

PMID:8442917

Gene product name and ID to be annotated to this term

Dicer1, RGD:1309381

Parent term(s)

endothelial cell-matrix adhesion (GO:0090673)

Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?

1., 2., 3. The corresponding regulation, positive, and negative regulation terms are also requested.

Synonyms (please specify, EXACT, BROAD, NARROW or RELATED)

Cross-references

For enzymes, please provide RHEA and/or EC numbers.

Can also provide MetaCyc, KEGG, Wikipedia, and other links.

Any other information

Hi @slaulederkind
Sorry about the long delay in looking into this - The definitions you propose dont distinguish the various 'pathways':
The binding of an endothelial cell to the extracellular matrix via collagen.
The binding of an endothelial cell to the extracellular matrix via laminin.
The binding of an endothelial cell to the extracellular matrix via vitronectin.

Can you be more specific in the definitions? as this stands, they look like annotations (to collagen, laminin, and vitronextin).
Thanks, Pascale

We  probably don't need such granular terms.  The requested terms are BP versions of the MF children of "cell-matrix adhesion mediator activity" (GO:0098634): collagen binding involved in cell-matrix adhesion (GO:0098639) and laminin binding involved in cell-matrix adhesion (GO:0098638).

OK, I'll close, assuming the MFs are sufficient.
Pascale


SSL image proxy

Fixes #354
This PR adds an image proxy for inline images which are referenced over HTTP. This only happens if the lets-chat instance is served over HTTPS and the sslImageProxy setting (see below) is set to true.
Configuration

Path
default
Environment Variable

rooms.sslImageProxy
false
LCB_ROOMS_SSLIMAGEPROXY

great job!

Hi @hhaidar,
is there any chance to get this one merged in the near future?
I plan to upgrade our lets-chat instance at work to 0.4 and it would be awsome if I could minimze the merge effort :smile:

I'm good with this, if @sibartlett is on board let's merge!

@sibartlett @hhaidar *poke* :wink:

@maximilian-krauss I'm so sorry this is taking forever to get in, I'll try and make it go into 0.4.3 (we're testing it on our instance)


ExponentialBackoff does not honor set InitialInterval

I have been trying to use ExponentialBackoff with an InitialInterval of 5*time.Second, but it continues to use the default of 500*time.Millisecond.
expBackoff := backoff.NewExponentialBackoff()
expBackoff.InitialInterval = 5*time.Second

With the first expBackoff.NextBackOff() that's logged:
DEBU[0000] Retrying login in 582.280027ms

You can't change InitialInterval after ExponentialBackOff is created.
However, you can do:
b := &backoff.ExponentialBackOff{
	InitialInterval:     5 * time.Second,
	RandomizationFactor: backoff.DefaultRandomizationFactor,
	Multiplier:          backoff.DefaultMultiplier,
	MaxInterval:         backoff.DefaultMaxInterval,
	MaxElapsedTime:      backoff.DefaultMaxElapsedTime,
	Clock:               backoff.SystemClock,
}
b.Reset()

Can you change MaxElapsedTime after NewExponentialBackoff()?

The behavior is undocumented so you should not rely on it.
It is used in NextBackOff function. If you change MaxElapsedTime before NextBackOff is called then it should be okay.


Demo app

What is missing with intercooler is a cool demo app.
With some ajax/json request.
Loading a list of users, click a user and get user informations.
Using this: https://randomuser.me
or this: https://jsonplaceholder.typicode.com
as examples

That sounds great.  Can I ask you to start work on it?  ;)

Hi, not really, i want it to learn.
For example, i learned Ionic and Angular because Ionc have a lot of demo to start with.
I would never learned it or even started with it if there's was not multiples demos

What do you think of this demo app:
https://sparktutorials.github.io/2016/06/26/ajax-without-writing-javascript.html

I should had write it before.
when i asked for a demo i wanted to write.
Anything except a todo list.


Update environments repo provider files so that users don't need to modify them to run local plans

User Story
Do this to all provider files in the environments repo - https://user-guide.modernisation-platform.service.justice.gov.uk/user-guide/running-terraform-plan-locally.html#running-local-plans-without-file-modifications
conditional - there is an example in the documentation. check that this works for all users, SSO and collaborators.
User Type(s)

Value

Questions / Assumptions / Hypothesis

Definition of done

[ ] readme has been updated
[ ] user docs have been updated
[ ] another team member has reviewed
[ ] tests are green
[ ] UR test OR added to continual research plan

Reference
How to write good user stories

Note we discussed this as something to do when we refactor to use terragrunt to save updating everything in multiple places

Template changes in sprinkler here - https://github.com/ministryofjustice/modernisation-platform-environments/pull/1350

@davidkelliott to review after assessing new roles that have been created since ticket drafted


Subworkflow for search

DatabaseSearchEngines
Including the following processes: process search_engine_msgf, process search_engine_comet and index_peptides (starting from 2.7.1, indexing is done internally per default anyway)

Channels:
takes: mzml_id, mzmls, per_file_settings
outputs: mzml_id, idxmls
Global params:
needs: params.searchengines, and any setting not defined by the sdrf
could set: nr_searchengines

done


:bookmark: Chore: Add release notes

Description
Concise description of proposed changes
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #964   👈

This stack of pull requests is managed by Graphite.


ICE form elements

Thank you for your time.  I know there are so many files and could be a lot of issues. Just to share the code as soon as possible to get some feedbacks. Hope that I'm on the track.
screenshots

The form structure:
ice-form
----ice-form-element
--------ice-text-field
------------ice-input
----ice-form-element
--------ice-radio-group
------------ice-radio
----------------simple-radio
----ice-form-element
--------ice-checkbox
------------simple-radio
@pzuraq Can you give me some feedback on the ember code, component structure? Thank you.

@pzuraq Hi, I've squashed the commits.

@pzuraq @lianliu22 I had a general question about the text input field component while working on add workflow forms.
We currently use AutoformatNumberInputComponent for text inputs that represent numbers. (We also have datepickers that similarly format date types into text input fields, but that might be out of scope for this) The number inputs look exactly the same but have a JS value of a Number type instead of String, as well as a basic number formatting function. Will this functionality be incorporated into the standard ICE form field component? If not, what would be the recommended method for formatting/parsing numeric value inputs?

Similarly, there's also a percent field that auto-formats percent values with a % suffix

@estelle should weigh in on that one as well, but I think in general we want to stick as close to html5 input types as possible when we start to redo the underlying components, so ideally the UX of the input would be as close as possible to number inputs. Percent inputs will be tricky because we don't actually have a percent type in HTML - one pattern I've seen is to add the percent symbol as a postfix instead of in the content (if that's not what we do already):

In terms of how it interacts with Ember, I think we should definitely parse whatever the value is into the correct type when we send the action up to change it. I'm still not sure if this should be represented as a single input component with a type field, or as many input components - I know we're already going to be having separate checkbox and radio components since they need extra templating for theming, so it may make sense to just have one component per type to follow that pattern.
Quick sidenote, we've also decided to shelve the Ember component work in the component library until the 1.13 upgrade is complete. @estelle and @LydiaBarnes will still be working on the CSS and pattern library in a separate repo (which I actually need to setup today!) but we want to be able to follow modern Ember patterns for the JS portion and we can't with Ember as it is today 😕 if you want to see what that would look like, you can check out ember-one-way-controls, which is what we'll likely build the new forms on top of once we get there

Closing as no one is actively working on this anymore.


How to expand only one group at a time

How can I expand only one group at a time and collapse the other opened group.

I am also searching for one more problem. Like how to collapse all expanded menus programmatically?

hi @amar0001  found one solution. May be its not proper solution but try this one.
int tapped =0; //let's say first group tapped
Store your current open or tapped position and then forloop below code to close the group
int groupMembers = 5;

for(int i=0;i<groupMembers;i++){

if (tapped!=i && adapter.isGroupExpanded(2)) {
                    adapter.toggleGroup(2);
                }
}

try this solution and let me know if you need any help.

collapse animation is not called when I do this
int groupMembers = 5;
for(int i=0;i<groupMembers;i++){
if (tapped!=i && adapter.isGroupExpanded(2)) {
adapter.toggleGroup(2);
}
}


IndexError: 'neighb_idx' is out of bounds for dimension 0 when extracting mesh after completing SLAM run

Hi there, thanks for your work! I just encountered a problem when the algorithm extracted mesh when it was finishing.
I first extract .ply files from rosbag using rosbag2ply.py, and I give .ply directory to the run_ncd_128.yaml file. Then I start the program by running the following command:
python pin_slam.py /home/user/PIN_SLAM/config/lidar_slam/run_ncd_128.yaml -smc
When the SLAM is finished and started to extract mesh, it gives the following error shown in the image happens in this line

I also tried to run it on the GPU, it also gives the same error. This error only comes up in some of the datasets (e.g. newer college dataset sequence 02 long experiment with the parameter of run_ncd.yaml; and sequence Cloister in Newer College Dataset with the parameter of run_ncd_128.yaml. Math institute easy works fine)
I also tried to add following code just above this line
invalid_indices_mask = neighb_idx >= self.neural_points.shape[0]
neighb_idx[invalid_indices_mask] = -1

However, it only reconstructs parts of the mesh (left: mesh extracted from PIN-SLAM, right: gt)

Thanks!

Thank you very much for reporting the bug.
I guess the cause of the bug is as follows:
In pin_slam.py, the order of the following two lines of codes is incorrect:
neural_points.recreate_hash(None, None, False, False) # merge the final neural point map
neural_points.prune_map(config.max_prune_certainty, 0) # prune uncertain points for the final output

, which should be:
neural_points.prune_map(config.max_prune_certainty, 0) # prune uncertain points for the final output
neural_points.recreate_hash(None, None, False, False) # merge the final neural point map

If we prune some points after recreating the hash indexing, the hash indexing might be out of the bound during the global mesh reconstruction.
I will push the updated version soon.
For the mesh visualization, you may also turn on the visualizer by adding the -v flag when running the code.

Thanks for your quick reply! Now the problem has been solved.


Redesign the action bar/dashboard

Previously, we have only view all patient and create new individual functions, but now we have all CRUD action. So it make sense to re-design the action bar a bit, and dashboard.

Add default language to user table so that each user their own language
Remove languages from top bar
Tooltip for whole button
Allow editing of user names, emails, addresses, institution, icon(?)

Hi, I have address the second/third check box above. The rest need some backend help.

Checkbox 1 requires a language table in the backend, that can CRUD the user's choice.
Checkbox 4 please confirm there is a API for update user information?

Ok, I'll try to get it soon for you. I may need more details but let check the code first.

So, if I understand this well we don't have either a table for language nor such a table for user's info.
We do have a table public.user_config and some python code supposed to manage it at views/save_configuration.py but I'm very unfamiliar to it.


nixos/{modules,tests}/teeworlds: init

Motivation for this change
add module and test for Teeworlds based on the OpenArena module and test
Things done

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

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

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

resolved race condition in the test and rebased on master

Will have a look.


Check that sas.test.ts has enough coverage for SAS auth

Check that sas.test.ts has enough coverage for SAS auth
will resolve #959

Check and add for Service level SAS

Done


Add missing badges like jCasbin

See: https://github.com/casbin/jcasbin

@seriouszyx plz work on this one next


Deprecate duplicate functions, update existing ones

This PR does the following:

Deprecates functions that have (basically) equivalent functionality with existing functions in the interest of reducing code duplication and people trying to run the exact same functions from multiple *funcs
Update existing functions with updated tooling that should both run faster and be more resistant to unintended user input
Improve some typing and make a the package overall a bit more Pythonic, as we ll as make it a tad more typesafe in certain scenarios
More useful and informative exceptions
Expand some functions with functionality that can be built on in the future (i.e. presets)

The biggest "drawback" for the common users of this *func is more reliance on iew-related packages. That said, most of the direct iew usage should be mitigated and abstracted away, so it should not require users learn how to use those functions per se (though of course, in my personal opinion, they should lol). The deprecated functions currently work as wrappers around those instead.
pls2test before merging <3

Fixed a couple of things.

@Setsugennoao @LightArrowsEXE It looks like vsdenoise.fft3d isn't in the latest published pip version, could I trouble whoever has the ownership to push a new release?

I have no idea why git closed this when I pushed up changes. :facepalm:

Oh because git is terrible (for usability) and it pushed my main to light's main because he didn't name his PR branch something other than main. :facepalm:

Now git is saying I don't have permissions to push to light/main, even though I just did it before. I guess I just have to recreate the PR. :facepalm:  :facepalm:  :facepalm:  :facepalm:


relicense to apache2

include notice of MIT license and copyright
add apache2 license

we're not going to do this, we're going to stick with MIT and add ourselves to the copyright


Add test for terminating the terminals

Heads up @andfoy, it looks like we're not able to properly terminate terminals anymore in pywinpty 2.0+.
 >       assert self.single_tm.terminal.ptyproc.closed
E       assert False

https://github.com/blink1073/terminado/runs/5162491817?check_suite_focus=true
The terminate function is returning True, as asserted in the test, but the ptyproc is not closing, and not triggering EOF.
I'll try and do some more debugging next week.

Thanks for the ping, please let me know if I can help in any way

@blink1073, I've just released pywinpty v2.0.3, it should be available in a few minutes

I've just released pywinpty v2.0.3, it should be available in a few minutes

Thanks!

@andfoy it works now when I specify using the WinPTY backend!


Feature request: UI component API for tabs

Is your proposal related to a problem?
We’ve recently re-implemented Wagtail’s tabs from a legacy Bootstrap widget, to a bespoke implementation following established patterns. One thing we haven’t been able to do as part of this re-implementation is creating a UI component API so tabs are easy to reuse without copy-pasting code. Right now, reusing tabs is still hard and error-prone.
Describe the solution you'd like
We should have a tabs template tag or equivalent, like we have {% icon name="rocket" %}. This would make it possible to reuse Wagtail’s tabs across the CMS admin, in core and in third-party packages, with the implementation details hidden behind the scenes.
A blocker for this is that Django templates has no built-in support for passing template fragments to template tags. We would need to either leverage a library that does this, or create our bespoke implementation. Here are potential candidates, which we can either choose to reuse as-is or learn from their implementations:

django-components – Reusable UI components for Django, going further than template partials.
django-component – Modern components for django templates
Declarative and composable components inspired by javascript frameworks.
slippers – Reusable components for Django, without writing a single line of Python.

Describe alternatives you've considered
Copy-paste HTML
This is what to copy-paste currently – we deliberately kept the markup simple so this isn’t too bad, but not good enough:

        {% include 'wagtailadmin/shared/tabs/tab_nav_link.html' with tab_id='one' title='Tab 1' errors_count='5' %}
        {% include 'wagtailadmin/shared/tabs/tab_nav_link.html' with tab_id='two' title='Tab 2' %}

        Here are tab 1’s contents.

        Here are tab 2’s contents.

Template components
Within Wagtail, there is also the concept of template components which might be a good fit, though there’s been no need to create tabs from Python so far so it’s not that clear-cut.
This might support our use case, but would require quite a significant refactoring which doesn’t feel desirable (unless we did a template component and a template tag.
Additional context
Here is pseudo-code of what the API could look like:
{% tabs %}
  {% slot "tablist" %}
    {% tab tab_id="one" title="Tab 1" %}
    {% tab tab_id="two" title="Tab 2" %}
  {% /slot %}

  {% slot "tabpanels" %}
    {% tabpanel tab_id="one" %}
              Here are tab 1’s contents.
    {% /tabpanel %}
    {% tabpanel tab_id="two" %}
              Here are tab 2’s contents.
    {% /tabpanel %}
  {% /slot %}
{% /tabs %}

Or something like:
{% tabs %}
    {% tab tab_id="one" title="Tab 1" %}
              Here are tab 1’s contents.
    {% /tab %}
    {% tab tab_id="two" title="Tab 2" %}
              Here are tab 2’s contents.
    {% /tab %}
{% /tabs %}

References:

React Spectrum tabs API
Spectrum Web components tabs API
Headless UI React tabs API

Where does the existing TabbedInterface fit into this?

TabbedInterface generates tabs from field panels, I believe it’s tied to the Panels API that’s specific to forms. I don’t think we’d want to refactor other usage of tabs to this kind of API as it would change the implementation drastically.

I think it would be the other way round - once a reusable implementation exists in HTML / Django template tags, the TabbedInterface panel's template can make use of it.

Potential addition to my initial request – we’d also ideally want official support for code executing on tab changes. Right now I believe we have a few internal DOM events to do this, or MutationObserver can be used.
Example use case: https://github.com/torchbox/wagtail-markdown/issues/98

Another potential addition, this time coming from wagtailmedia: there is no way to call the initTabs function we use in Wagtail from third-party code: https://github.com/torchbox/wagtailmedia/pull/161.
Here are potential solutions for this:

Expose this function globally similarly to e.g. window.draftail.initEditor, so it can be called by third-party implementations as needed.
Re-implement this component’s initialisation to work with MutationObserver so there isn’t a need to manually re-initialise it (see RFC 78: Adopt Stimulus (lightweight JS framework)).

Another potential option - assuming we don't get any direction on RFC 78 for some time.
initTabs - when called - sets up a global event listener. So that anyone can call.
const myTabs = document.getElementId('my-injected-tabs');
myTabs.dispatchEvent(new CustomEvent('wagtail:add-tabs'));

This will be listened to by Wagtail tabs code and any the event.target is used to initiate tabs against when called (assuming a. It is not already initiated and b. It has the appropriate data attribute).
This avoids a global and is more forward compatible if we remove this functionality (no calling of globals that may not exist).
We could even avoid building any checks for if the tabs are instantiated and trust the event dispatch to happen only when needed.

Looks like the changes in #8697 don't quite work in modals. Another one to consider here

Thanks @zerolab - I have a fix for that issue up https://github.com/wagtail/wagtail/pull/8794

I feel we need to at the very least add https://github.com/wagtail/wagtail/issues/8408#issuecomment-1150590527 for 4.0. it is causing issues for third party packages

just a quick comment here, it would be interesting to add the use case of custom StreamBlock UI edit as well.
For now what I do is I have my own re-implementation of the js Tabs part injected so I can add tabs in the Streamblock ui itself (in a StreamField).
if we could allow the JS part to be shared, this would remove the un-necessary duplication of JS code.

https://github.com/wagtail/wagtail/issues/11501 has been created for the JS (Stimulus) implementation. This will make it much easier for third party code to reuse. Maybe unofficially though as it may not be documented initially.
cc @the-r3aper7


Enhancement: store bing cookies in json file

Contact Details
No response
What features would you like to see added?
It would be nice if we can set bing cookies in json file so that we could change them without restarting entire app. Why? Bing always dropping login and we can use autologin scripts.
More details
.
Which components are impacted by your request?
No response
Pictures
No response
Code of Conduct

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

We can add support to both of them, because for most of the users (including me) it is much simpler a string instead of a file (as on PaLM)

We can add support to both of them

It would be nice

Is there a script which could be run to automatically scrape the user's bing.com cookie on startup?


Use Pylint output

Hi all,
We are supposed to include the output of pylint in our documentation, so you can run your main code using pylint like we did in class and see the errors or issues related to your code. Include the output you got  using pylint in  documentation.  Pylint are mostly preferred to see the issues in python code.

@pratibha77118 I believe that this group has added the output of pylint in their documentation.

Yeah, we have.


UnicodeDecodeError: 'gbk' codec can't decode byte 0x80 in position 2: illegal multibyte sequence

When I only import chinese_converter I get this
import chinese_converter
  File "E:\Study\Anaconda3\envs\whisper\lib\site-packages\chinese_converter\__init__.py", line 12, in <module>
    traditional, simplified = f.read().strip(), g.read().strip()
UnicodeDecodeError: 'gbk' codec can't decode byte 0x80 in position 2: illegal multibyte sequence

ps: 电脑的语言环境是简体中文

Which version are you installing?

Which version are you installing?

chinese-converter         1.1.1

You might need to reinstall. The code in your error message does not match the latest version.


Collapse roads trimmed into oblivion

Alright, now all the refactoring is starting to really pay off. When we trim roads back from intersections and some road disappears entirely, that road is too short to have its own geometry. This PR sends it through the consolidation pass. The results are pretty fantastic.

I also had to first fix an edge case with polygon_from_corners. The comments / pictures below should explain:

I'm now extremely tempted to remove the dog-leg intersection detection entirely. As we discussed, the motivation for that was basically to solve problems like this, which used to be more unclear. Before we had intersection geometry generated on totally untrimmed input, I didn't even understand the root problem.

Yeah, I removed the old dog-leg experiment. No effect on tests, because it's disabled in this repo anyway. The ideas in #131 are good to remember -- we should keep going down the minimal-intersection path and fix root problems a different way.

Looking beautiful!
Now we can try to reason about these intersections in general terms; with lane movements enumerated, intersected, and drawn. Some with lane markings, some without. Probably the stop lines too.
I'm wondering if we ought to keep the collapsed roads alive, referenced in a kinda "merged intersection" struct LogicalIntersection { ids, roads } thing. It could take over the final geometry algorithm, uses existing trim distances and supporting multiple nodes. The existing trim distance calculation stuff gets to continue ignoring existing trims, and remain in use only for the individual node "intersections". Often the road segments are a real continuation of a road (the exact piece we want to render as the "major" road through the intersection.

Keeping around the original structures has some uses for sure. Also interpreting turn restrictions -- being able to look at what's possible in the original graph, then apply that to the final one. But I don't know how to concretely start introducing this kind of LogicalIntersection structure. Maybe we need to work on something that really motivates it, like rendering lane markings through intersections. Could it be time to try that?
Thinking about the seattle_slip_lane example a bit more, really the east-west main road should be the thing determining the geometry here. The separate cyclepath shouldn't influence things so much. Maybe if we zip it, things would help. Or maybe now's the time to try calculating geometry and ignoring non-road pieces in a first pass.

Maybe a concrete next step is rendering lane markings in connections and forks. We determine the main road that continues uninterrupted, then at the render.rs layer only, draw markings using untrimmed geometry instead of trimmed. Then cases like this where we totally delete one of the original pieces of the main road will become obvious and give us a testable thing to check as we introduce LogicalIntersection

Maybe a concrete next step is rendering lane markings in connections and forks. We determine the main road that continues uninterrupted, [and draw it untrimmed].

We also need to invent the geometry to replace the non-sense angled Y shaped reference lines in sausage links. Either extending the single carriageway, or drawing arcs based on turn level movement paths.
Lane level movements is the key here. What we currently have is more like the "turns" (they match up to the "turn restrictions"), describing each direction. Then you divvy lanes up according to the connectivity tags or convention, and discover what kind of intersection you really have. Perfect lane allocations for a nice fork or converge, or lanes decreasing for a merge-in freeway entry? Each set of lanes has a kind, which determines which one covers the others.

ignoring non-road pieces in a first pass.

Ignore all non vehicle lanes - like footpaths - makes sense I think. Keep bike routes in, they are part of the vehicle flow. That way we minimum trimming and wont get too confused by footpath logic while we're trying to understand the traffic interactions.

Then cases like this where we totally delete one of the original pieces of the main road will become obvious and give us a testable thing to check as we introduce LogicalIntersection

Sounds good!


breakout create fails if user is not host/co-host

When running a breakout create command, when user is not host/co-host:
./zoom-manage breakout create breakout/WSO-groups.txt
./zoom-manage:26124:26129: execution error: Error: System Events got an error: Can’t make missing value into type UI element. (-1700)

This is due to the lack of "breakout" status menu. Notice this and exit gracefully.

Fixed in the referenced commit.


Updated Python SDK for Azure Event Grid based on 2017-09-15-preview version

Updated the Python SDK for Azure Event Grid based on 2017-09-15-preview Swagger version. Also updated the corresponding tests.

@kalyanaj,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Codecov Report

Merging #1440 into master will increase coverage by <.01%.
The diff coverage is 90.32%.

@@            Coverage Diff             @@
##           master    #1440      +/-   ##
==========================================
+ Coverage   52.92%   52.92%   +<.01%
==========================================
  Files        3347     3349       +2
  Lines       85103    85120      +17
==========================================
+ Hits        45040    45054      +14
- Misses      40063    40066       +3

Impacted Files
Coverage Δ

...tgrid/models/event_grid_management_client_enums.py
100% <ø> (ø)
:arrow_up:

...grid/azure/mgmt/eventgrid/operations/operations.py
40% <100%> (ø)
:arrow_up:

...ure/mgmt/eventgrid/event_grid_management_client.py
100% <100%> (ø)
:arrow_up:

...-eventgrid/azure/mgmt/eventgrid/models/__init__.py
100% <100%> (ø)
:arrow_up:

...ure/mgmt/eventgrid/operations/topics_operations.py
34.63% <100%> (ø)
:arrow_up:

...tgrid/operations/event_subscriptions_operations.py
22.25% <100%> (ø)
:arrow_up:

...eventgrid/models/event_subscription_destination.py
100% <100%> (ø)
:arrow_up:

...ure-mgmt-eventgrid/azure/mgmt/eventgrid/version.py
100% <100%> (ø)
:arrow_up:

.../models/web_hook_event_subscription_destination.py
100% <100%> (ø)

...rid/azure/mgmt/eventgrid/models/topic_type_info.py
100% <100%> (ø)
:arrow_up:

... and 4 more

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 e8cd3dd...e3675dc. Read the comment docs.

@kalyanaj LGTM!


Warnings with cuda 11.2.2

Hello, I observe the following warnings when I upgrade to cuda 11.2
linalg/sparsemat.cpp(679): warning #1786: constant "CUSPARSE_CSRMV_ALG1" (declared at line 6314 of "/usr/local/cuda-11.2/bin/../targets/x86_64-linux/include/cusparse.h") was declared deprecated ("please use CUSPARSE_SPMV_CSR_ALG1 instead")
cusparseSpMV_bufferSize(handle, CUSPARSE_OPERATION_NON_TRANSPOSE, &alpha, matA_descr, vecX_descr, &beta, vecY_descr, CUDA_R_64F, CUSPARSE_CSRMV_ALG1, &newBufferSize);
^
linalg/sparsemat.cpp(697): warning #1786: constant "CUSPARSE_CSRMV_ALG1" (declared at line 6314 of "/usr/local/cuda-11.2/bin/../targets/x86_64-linux/include/cusparse.h") was declared deprecated ("please use CUSPARSE_SPMV_CSR_ALG1 instead")
cusparseSpMV(handle, CUSPARSE_OPERATION_NON_TRANSPOSE, &alpha, matA_descr, vecX_descr, &beta, vecY_descr, CUDA_R_64F, CUSPARSE_CSRMV_ALG1, dBuffer);
^
OS: Ubuntu 18.04
CXX: mpiicpc
CUDA: cuda_11.2.2_460.32.03_linux.run

Hi @adam-sim-dev, were you able to resolve this issue? If so, would you like to contribute a fix?
In any case, thanks for reporting the issue. We will try to address it in the near future.

Dear @v-dobrev,
I am not so similar with CUDA, while I am glad to contribute.
After I read cuSPARSE library's user guide v11.2.1
https://docs.nvidia.com/cuda/archive/11.2.1/pdf/CUSPARSE_Library.pdf
and v11.2.0
https://docs.nvidia.com/cuda/archive/11.2.0/pdf/CUSPARSE_Library.pdf
and v11.1.1
https://docs.nvidia.com/cuda/archive/11.1.1/pdf/CUSPARSE_Library.pdf
I found that, CUSPARSE_CSRMV_ALG1 was declared deprecated after cuSPARSE v11.2.1.
It's recommed to use CUSPARSE_SPMV_CSR_ALG1 instead.
I will try to make a PR soon.

https://github.com/adam-sim-dev/mfem/commit/7dc3ff19f72bf08c3dac87eeafefadf0b1348178
Here is the proposed fix.

Can you please open a PR toward mfem's master branch and mark it with the ready-for-review label. With that, we will be ready to start the review process.
Thanks!


fix: update containerd dep to v1.4.8

Updates our dependencies to fix a security issue found in upstream containerd.

Codecov Report

Merging #60 (c767c8f) into main (7713c68) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #60   +/-   ##
=======================================
  Coverage   22.54%   22.54%
=======================================
  Files           2        2
  Lines         173      173
=======================================
  Hits           39       39
  Misses        133      133
  Partials        1        1

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 7713c68...c767c8f. Read the comment docs.


wrapper functions which can be used to define count prefixed, dot repeatable keymaps

The added wrapper functions can be used in keymaps like following:
vim.keymap.set(
    'n',
    '[s',
    function ()
        vim.go.operatorfunc = "v:lua.require'iswap'.iswap_node_with_left"
        return 'g@l'
    end,
    { desc = 'Swap with [count] left node', expr = true }
)

vim.keymap.set(
    'n',
    ']s',
    function ()
        vim.go.operatorfunc = "v:lua.require'iswap'.iswap_node_with_right"
        return 'g@l'
    end,
    { desc = 'Swap with [count] right node', expr = true }
)

The resulting keymaps are dot repeatable and can be prefixed with [count].
Examples: 2[s, ]s
closes #68

Is there a way to make setting up a dot-repeatable keymap easier than this? It seems like there still is a bit of boilerplate for the user when configuring this way.

I'm only aware of two methods getting dot repetition. One is using operatorfunc as I did, the other is using a third party plugin like vim-repeat. I could never understand the code of vim-repeat since I'm not familiar with vimscript. I've noticed that you added vim-repeat support in your plugin already. However I don't like having an extra plugin for this.
See this link
The implemented version with vim-repeat is a little broken too: When I swap a node with :ISwapWithLeft and then press ., then I get promped to pick a node to swap with. I would expect that the :ISwapWithLeft command is re-executed, but in reality the :ISwapWith command is executed.

understood, thanks! Can I put the operatorfunc bit into my plugin as opposed to the user putting it into their configuration.

Yes that would be possible. I can make a PR for this next week.

thanks! i would appreciate that a lot. i'm not super familiar with operatorfunc


Update your first report with Istio ambient

Describe the bug
Thank you so much for producing the additional report on ambient, really enjoyed reading it:
Would it be possible to add ambient to your 1st report?  Particularly in some of the diagrams under the "Performance Test Results" section:
https://livewyer.io/blog/2024/05/08/comparison-of-service-meshes/
Just wanted to provide most recent facts to folks reading the first blog - just saw it was mentioned in some doc today.  Thanks so much for your consideration!
Steps to reproduce
NA
Expected behavior
NA
Evidence
NA
Environment
NA

Hey @linsun!
Thank you for reaching out. We've made some improvements to the blogposts, making it easier for users to navigate and view the two parts of our study.
Regarding your request to add test results from the second report to the first one, unfortunately, we can't do that. We conduct all tests in isolated, carefully prepared environments simultaneously to ensure reliable results.  We see value in our current results, which show a point-in-time view of each Product, and therefore, we recommend reviewing the two reports separately.
Additionally, we will likely conduct a third study in the future using the latest versions. However, the products included in the third study may change.

Hi @oleksandr-livewyer, thank you - I understand your concer and I appreciate you cross link it.


Dynamic key and replication

Hey. This is some other idea what I think would be nice to include. I am fairly certain that you have mentioned something like this before, but I am failing to find it. After looking bit more closely to localforage replicator, I've got bit more of understanding what are replicators useful for.
I am now thinking about scenario that I have search results from 3rd party service based on some user input. I have a provider with dynamic key based on that input. Then I would like to use getInitialState to actually retrieve search results so essentially cache for repeated input will be created. Together with localforage replicator those results would be nicely stored in user browser and reused later.
However I am failing on that part as I am unable to get that user input there. Only way I see is to read it from the key. Is it true that key has to be unique throughout all providers? In that case I have to prefix that value with something and then in getInitialState parse it again? That feels totally weird.
What about actually adding something similar to key, but accepting even a object as result that can be made of props? That value could be then passed to getInitialState along with key and reducerKey. It would fairly increase ease of use.

Hey @FredyC I hope everything is going well.  Sorry I never replied to this!  I've been super busy moving, working, etc.  I should finally have some extra time over the next week and I'll take a closer look at this thread and the others and see if I can finalize an API that will cover (almost) everything.  You've made a ton of really good observations and suggestions.  And after that I'll finally try to put together proper documentation.

Hey. Yes everything is fine. I had no need to dive deeper into providers lately as it works so far for all the needs I have. There is another project upcoming in near future that will be more CRUD-like with routing and everything, so I am sure that's gonna be next level of providers for me :)

Same reason to close as in #39


azkaban can not work. requests.packages.urllib3 does not exist

Traceback (most recent call last):
  File "/usr/local/bin/azkaban", line 9, in <module>
    load_entry_point('azkaban==0.9.5', 'console_scripts', 'azkaban')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 351, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2363, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2088, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/usr/local/lib/python2.7/dist-packages/azkaban/__main__.py", line 98, in <module>
    from azkaban.project import Project
  File "/usr/local/lib/python2.7/dist-packages/azkaban/project.py", line 8, in <module>
    from .util import AzkabanError, Adapter, flatten, temppath, write_properties
  File "/usr/local/lib/python2.7/dist-packages/azkaban/util.py", line 13, in <module>
    from requests.packages.urllib3 import disable_warnings
ImportError: No module named packages.urllib3

My guess is you have a module named requests that overrides the original one (either in your current directory or in your PYTHONPATH). Do you have a file named requests.py or a folder named requests?

I'm assuming you were able to address this, feel free to reopen if not.


Change "no regressors" text in dashboard

Old text: "No Regressors"
New Text: "This functionality is not available for this prediction"

Works exactly as described. Ideally, include blurred graph behind text. 👍


Remove smoothing on soalr

Last few days we have not had smoothing on solar, due to role back issues. The forecast looks a lot better.
This may effect #69
So we would have to role back #62 but keep it on wind

Yea sure

Hi,
Can I please have more information on this? I am having some trouble replicating this repo locally.

Its basically to role back #62, so smoothing only happens on the wind forecast

So, should the fix be like this: https://github.com/openclimatefix/india-forecast-app/blob/fdf296ae4fea9923e070c912e9125326eccc3f0b/india_forecast_app/models/pvnet/model.py#L126
And also I'm trying to run it locally, facing some issues with docker.build. So I can't the test the changes i've made..

SOrry @vishalj0501, ive pushed this one forward as i needed it for production

Sure!, Sorry for the late.
I'll look into more issues across OCF repos.
Thank You


Replace "Lots!" with actual value inside Price Check UI

Can you replace Lots! with the actual value

Not many people have that problem lol

Not many people have that problem lol

Just because not many have the issues doesn't change the fact that it is a potential issue.

Where would this be expected to join plugin-wise? Potentially the price check plugin, I guess?


Build failure caused by boost-1.72.0

Platform Ubuntu 18.04
reproduce cmd:
make setup
logsnippet:
Setup.sh: Using boost backup
--2022-09-05 23:21:48--  https://carla-releases.s3.eu-west-3.amazonaws.com/Backup/boost_1_72_0.tar.gz
Resolving carla-releases.s3.eu-west-3.amazonaws.com (carla-releases.s3.eu-west-3.amazonaws.com)... <IP_ADDRESS>
Connecting to carla-releases.s3.eu-west-3.amazonaws.com (carla-releases.s3.eu-west-3.amazonaws.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 126580835 (121M) [application/x-tar]
Saving to: ‘boost_1_72_0.tar.gz’
boost_1_72_0.tar.gz                 100%[==================================================================>] 120.72M  6.05MB/s    in 30s
2022-09-05 23:22:21 (4.02 MB/s) - ‘boost_1_72_0.tar.gz’ saved [126580835/126580835]
Setup.sh: Extracting boost for Python 3.
Building Boost.Build engine with toolset clang... tools/build/src/engine/b2
Unicode/ICU support for Boost.Regex?... /usr
Generating Boost.Build configuration in project-config.jam for clang...
Bootstrapping is done. To build, run:
./b2

To generate header files, run:
./b2 headers

To adjust configuration, edit 'project-config.jam'.
Further information:

Command line help:
./b2 --help

Getting started guide:
http://www.boost.org/more/getting_started/unix-variants.html

Boost.Build documentation:
http://www.boost.org/build/

sh: 1: clang++: not found
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/tools/clang-linux.jam:63: in clang-linux.init
***** argument error

rule clang.init-cxxstd-flags ( toolset : condition * : version )
called with: ( clang-linux : clang-linux :  )
missing argument version**
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/tools/clang.jam:54:see definition of rule 'clang.init-cxxstd-flags' being called
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/build/toolset.jam:44: in toolset.using
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/tools/clang.jam:33: in clang.init
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/build/toolset.jam:44: in toolset.using
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/build/project.jam:1104: in using
project-config.jam:12: in modules.load
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/build-system.jam:255: in load-config
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/build-system.jam:486: in load-configuration-files
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/build-system.jam:607: in load
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/kernel/modules.jam:295: in import
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/tools/build/src/kernel/bootstrap.jam:139: in boost-build
/build/clarencez/carla_build/carla/Build/boost-1.72.0-c8-source/boost-build.jam:17: in module scope
Util/BuildTools/Linux.mk:143: recipe for target 'setup' failed
make: *** [setup] Error 1

issue fixed
it is my toolchain issue
sudo ln -sf /usr/bin/clang++-8 /usr/bin/clang++


update dependency, fix webworker

Manually fix webpack issues:

Webworkers not working on local dev env
assets not loading with latest nx webpack
hrefbase not working on deployment to github pages

Still in draft:

tree shaking is not working

Close in lieu of #1010


Tracking issue: Additional checks, both semver and non-semver

This is a list of all not-yet-implemented checks that would be useful to have. Some of these require new schema and adapter implementations as well, tracked in #241.
In addition to checking for semver violations, there are certain changes that are not breaking and don't even require a minor version, but can still be frustrating in downstream crates without a minor or major version bump. Crates should be able to opt into such warnings on an individual basis.
For example, based on this poll (with small sample size: ~40 respondents), ~40% of users expect that upgrading to a new patch version of a crate should not generate new lints or compiler warnings. The split between expecting a new minor version and a new major version was approximately 3-to-1.
Major version required:

[x] exhaustive enum becomes #[non_exhaustive]: #143
[ ] repr(C) plain struct has fields reordered
[ ] tuple struct has fields reordered
[ ] tuple enum variant has fields reordered
[x] pub struct pub field removed
[x] pub struct constructible with struct literal adds pub field (#233)
[x] pub struct constructible with struct literal adds non-pub field, and cannot be constructed with a literal from outside its own crate anymore (#233)
[ ] pub struct pub field changes type: #148, blocked on #149
[ ] pub enum variant field changes type: blocked on #149
[ ] pub enum tuple variant adds field
[ ] pub enum tuple variant removes field
[x] pub enum struct variant adds field: #238
[x] pub enum struct variant removes field: #153
[ ] pub enum variant discriminant removed
[ ] pub enum variant discriminant changed value
[ ] removed direct re-export of an enum variant: #291
struct with public fields changes to another kind (more details: https://github.com/rust-lang/cargo/pull/10871#issuecomment-1217103363)

[x] unit struct to plain struct is breaking since the implicit constructor disappears (Rust for Rustaceans, Chapter 3, "Type Modifications", page 51)
[x] #242

[x] pub fn moved, deleted, or renamed (#22, #23, #24)
[ ] pub fn changed return type: blocked on #149
[x] pub fn added argument
[x] pub fn removed argument
[ ] pub fn changed arguments in a backward-incompatible way

This one is hard: it's possible to go from e.g. taking &str to taking S: Into<String> without breaking
when it's not breaking, it requires a minor version

[x] #190
[x] #191
[ ] pub fn changed ABI, e.g. from extern "C" to extern "C-unwind" or extern "system"
[ ] pub method moved into a trait

even if the trait is pub, it needs to be imported in the scope to have its methods be available
Make sure to test for both trait-provided (default impl) methods and explicitly implemented methods for the trait. See the test cases added in #24 for example.

[x] repr(C) removed from struct or enum (#25)
[x] repr(transparent) removed from struct or enum (#26, #28)
[x] repr(u*) and repr(i*) changed/removed from enum (#29, #30)
[ ] #74

breaking because of:

https://jack.wrenn.fyi/blog/semver-snares-alignment/
https://old.reddit.com/r/rust/comments/kr41sq/semver_snares_sizedness_and_size/

[x] type is no longer Sized / Send / Sync / Unpin / UnwindSafe / RefUnwindSafe (auto traits) (#31)
[ ] type made Copy (appears to be breaking because of https://github.com/rust-lang/rust/issues/100905 )
[x] #73
[ ] non-sealed trait added method
[ ] #294
[ ] non-sealed trait added associated type
[ ] trait newly became sealed

this is partially covered by the "trait is not importable" rule, since one way to seal a trait is to make it unimportable
but another way to seal a trait is to make implementing or calling it require a private ZST that downstream crates cannot name, and this is not covered
reference: https://fosdem.org/2023/schedule/event/rust_rust_api_design_learnings/ time code ~00:30:00

[ ] trait removed/renamed associated type
[ ] #232

example of why this is breaking: https://twitter.com/i2talics/status/1559607755975057408

[x] #231
[x] #250
[ ] type no longer implements pub trait
[ ] implementing an existing pub trait for an existing type

breaking because the trait's methods or associated types on that type may be ambiguous relative to those from traits implemented for that type in another crate (Rust for Rustaceans, chapter 3, pg. 52, "Trait Implementations")

[ ] implementing a new pub trait for an existing type, if the new pub trait is in a prelude module that gets imported with a wildcard

similar to above, same source (Rust for Rustaceans, chapter 3, pg. 52, "Trait Implementations")
normally the trait has to be in scope for its methods to be available, but the wildcard import will bring it in scope here

[ ] blanket impl added for an existing trait

the blanket impl can cause a conflict with a downstream type that also implements the trait on one of its own types, if that type is covered by the blanket impl -- source: Rust for Rustaceans, chapter 2, pg. 30, "Blanket Implementations")

[ ] blanket impl added over a fundamental type (&T, Box etc.)

similar reasoning as above -- source: Rust for Rustaceans, chapter 2, pg. 30, "Fundamental Types"

[ ] added new implementation of existing trait that does not contain at least one new local type (and that type satisfies the exemption from the orphan rule)

source: Rust for Rustaceans, chapter 2, pg 31. "Covered Implementations"

[ ] upgrading to new major version of dependency while exporting a type that implements a trait from the dependency (new major version -> "it's not the same trait as before"): https://github.com/libp2p/rust-libp2p/pull/3170#issuecomment-1349688293
[ ] trait is no longer object safe
[ ] removing a bound on trait impl: #142
[ ] Auto trait impls for impl Trait in return type.

Requires a superset of the required schema additions as pub fn changed return type

[ ] #338
[ ] pub type typedef changes the order of generic arguments (regular, lifetime, or const generics) relative to the underlying type
[ ] pub type typedef adds a new generic parameter
[ ] pub type typedef removes a generic parameter
[ ] pub type typedef removes a default value for a generic parameter
[ ] pub type typedef changes a default value for a generic parameter
[ ] variance of type lifetime parameters changed

example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=bb4738835367fd9ef604a8fcd728699b
source: https://twitter.com/tenellous/status/1620907046911754240

Minor version required:

[ ] #57
[x] #159

Code in downstream crates that did not use a value of that type will get a compiler lint.
New lints for existing code requires a minor version: https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md#minor-change-introducing-new-lint-warningserrors

[ ] new pub struct added
[ ] pub fields added on pub struct

don't report this if the entire struct is new

[ ] new pub enum added
[ ] new pub enum variant added

don't report this if the entire enum is new

[ ] pub enum variant discriminant added
[ ] new pub inherent method added

don't report this if the entire type is new

[ ] new pub union added
[ ] pub type typedef adds a default value for a generic parameter

Project-defined whether major / minor / patch version required (for example, because they are technically breaking but commonly ignored):

[ ] Raising the Minimum Supported Rust Version (MSRV) for the crate
[ ] Changing the size of a type

Example courtesy of cargo-breaking README file

More checks here:

https://github.com/rust-lang/cargo/issues/8736
https://doc.rust-lang.org/cargo/reference/features.html#semver-compatibility
https://rust-lang.github.io/api-guidelines/interoperability.html
https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md
https://www.lurklurk.org/effective-rust/semver.html
https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed
https://github.com/obi1kenobi/cargo-semver-check/issues/5#issuecomment-1232040301

Opt-in warnings:

[ ] Depending on a #[non_exhaustive] type from another crate to remain a 1-ZST usable in #[repr(transparent)]

This is a semver hazard from the user's side. The other crate's type correctly declared that field additions (including sized ones) are non-breaking.
Related issue: https://github.com/rust-lang/rust/issues/78586

[ ] Crate does not enforce some of the recommended allow-by-default lints that are built into Rust and/or clippy: https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html

For example, own public types should be Debug i.e. the Rust missing_debug_implementations lint: https://twitter.com/Lucretiel/status/1558287048892637184

[ ] Types with a new() -> Self method should be Default: https://rust-lang.github.io/api-guidelines/interoperability.html
[ ] Don't require FusedIterator in generic bounds, instead use Iterator.fuse(): https://doc.rust-lang.org/std/iter/trait.FusedIterator.html

Opt-in warnings for difficult-to-reverse changes:

[ ] Removing #[non_exhaustive] from an item

Per semver, removing #[non_exhaustive] can be done in a patch release, but adding it back would then require a new major version.

[ ] Adding an enum variant in a #[non_exhaustive] enum

Per semver, adding variants to a non-exhaustive enum can be done in a patch release, but removing them again afterward would require a new major version.

[ ] Removing the last non-pub field in an exhaustive public struct

Structs that are not #[non_exhaustive] and have only public fields can be constructed with a struct literal. Removing the ability to construct a struct with a struct literal is a breaking change and requires a new major version.

[ ] Making an item importable in more than one way

If an item is in a pub mod and is also exported with pub use, it can become importable in multiple ways. This is easy to miss. Removing an import path is breaking, so perhaps we should warn that this is happening. Related to #35.

[ ] Making a trait object-safe if it previously was not

Object safety then becomes part of the API contract, and breaking object safety is semver-major.

[ ] A 1-ZST (1-byte-aligned zero-sized-type) type no longer being a 1-ZST

This is "possibly breaking" and whether it's breaking or not depends on the intent of the type, and can't be determined programmatically. A #[enforce_1zst] attribute could signal that the type should remain a 1-ZST and that deviations from that are breaking.
This can break downstream even if the type is #[non_exhaustive], until https://github.com/rust-lang/rust/issues/78586 is resolved and prevents this.

[ ] Leaking or re-exporting another crate's type in one's own API

for example, having a function that returns a value of another crate's API
this can cause coupling to the other crate's version, and can be a pain
there are legitimate reasons to do this sometimes, but it should be an intentional decision and probably worth flagging in review

[ ] Making a type Send/Sync/Sized/Unpin or other auto traits, when it previously wasn't.

this is possible to do indirectly, e.g. by removing the last field that prevented the type from (auto-)implementing those traits
reverting this is a breaking change

Own public types should be Debug:

That's already available in the compiler as #[warn(missing_debug_implementations)], and already only fires for pub types.

That's already available in the compiler as #[warn(missing_debug_implementations)], isn't it?

Oh, neat, TIL. It appears to be allowed by default and has to be enforced by manually enabling the check. In that case, perhaps the wish-listed query should be checking that #![deny(missing_debug_implementations)] is set instead.

This also gets into a conversation that I think we only had over zulip so good to summarize here.
Especially if we want this in cargo some day, I think we should clearly define the scope.
cargo clippy is meant for linting an API as it exists
cargo semver-checks would be meant for linting changes in an API

missing_debug_implementations is an example of something that imo doesn't belong in cargo semver-checks
Linting that a lint is enabled is both getting a bit meta and again something that should be out of scope

Misc notes

Making it easier to add lints to clippy is a conversation with the clippy folks and they are interested in solving it
User-generated lints in either type of tool shipped with rustup would likely be marked as unstable initially.  A path to being stable is dependent on how comfortable people are on stabilizing the query language and the data model which is a large surface area
In the mean time, there could be room for a linter that handles user defined lints.

One possible way forward would be something like:

Extract the data model components (the Trustfall schema and adapter) into a library crate (essentially #67).
Make cargo-semver-checks be just a set of semver queries + a binary that wraps that library crate to execute those queries.
Make one or more other tools for the other use cases: any queries that don't fit within the current cargo-semver-checks / clippy domains, custom user-specified queries, etc.

That way, we could easily experiment with querying for more things without bloating the scope of cargo-semver-checks and without making the integration into cargo messy.
I think extracting the data model into a library crate is pretty straightforward and I would be happy to do it if that's what we decide is the best path forward.

Auto trait impls for impl Trait in return type.

Requires doing  pub fn changed return type

[ ]  Auto trait impls for impl Trait in return type.

Requires doing  pub fn changed return type

Thanks, added to the list! If you'd like to try your hand at it, this lint is probably easier than pub fn changed return type since the actual check is less complex, and I'd be happy to mentor.

I think "trait added method" might be a bit more complicated.
The way I see it adding default methods is fine, and even adding non-default methods is fine, so long as the trait cannot be implemented by an external user. This can be the case for example when using a private super trait or blanket impls. Especially sealed traits are a common pattern in Rust.

Non-defaulted items of any kind in a trait that is implementable outside its crate are semver-major, because any implementers must add the new items: https://doc.rust-lang.org/cargo/reference/semver.html#trait-new-item-no-default
Defaulted items in a trait are trickier. They are definitely at least minor, but could be major as well; some such circumstances are described in the semver reference which shows this as a "possibly-breaking" change: https://doc.rust-lang.org/cargo/reference/semver.html#trait-new-default-item

it's possible to go from e.g. taking &str to taking S: Into<String> without breaking

This is not true, changing an argument type from a concrete type to a generic will break calls like the_function(foo.into()), which only works for non-generic functions because the parameter type guides type inference. There are cases where changing a parameter types as well as a return type is non-breaking though:

Removing trait bounds on parameter types, e.g. x: impl Foo + Bar to x: impl Foo
Adding trait bounds to an existential return type, e.g. -> impl Foo to -> impl Foo + Send

I want to note that while Iterator/Itertools is a good example of the issue, it's a symptom of the wider semver-minor upgrade hazard of adding any new items.
This happens because of how name lookup works in Rust, since Rust allows arbitrary namespace mixins.

Adding an item to a trait is name resolution inference breaking, as it could conflict with another trait item where both traits are implemented for the same type.^[Preventable if the trait is sealed and implemented only for types you control.^[If implemented on upstream types, still potentially breaking, if upstream updates; generally we blame downstream if the inference breakage does not happen without downstream, even if it is triggered by updating upstream.]]
Adding a (public) item to a struct/enum is name resolution inference breaking, as it could conflict with a trait item implemented for the type, changing the name from referring to the trait associated item to referring to the struct/enum associated item.
Adding a (public) item to a module is name resolution inference breaking, as downstream could be glob importing your module's contents and another module's contents which defines the same name, causing the name to be ambiguous between your and the other module.

In other words, in a pedantic mode, semver-checks'd be justified on requiring minor for any new public item. Even weakening generic requirements might cause inference issues, so e.g. --strict-pedantic should probably require a minor bump for any change to the public API's types; IIUC this matches the intent of semver-minor's "new feature" trigger as well, since the API by construction has new API surface.
In practice, API evolution in this manner is necessarily considered perfectly acceptable, and is imho very rarely worth warning for. It's a subjective evaluation of how likely both that a name conflict is possible and that some downstream would have both names in scope simultaneously; in most cases this is reasonably rare because of the convention to avoid glob imports^[If you want a version of the lint which can fire without firing on every API change, consider linting only for new trait associated items reachable through a module called prelude, since that's likely designed for glob importing.], and there's not really a good analytical way to determine the risk of a non-globbed name conflict to provide a lint cutoff better than yes/no.
Iterator is an especially interesting case because it's a language item trait in the prelude. User types don't have this exacerbating factor (being implicitly available everywhere) for this concern.

Adding trait bounds to an existential return type, e.g. -> impl Foo to -> impl Foo + Send

Note that RPIT already "leaks" autotraits (Send/Sync/Unpin), so that isn't actually a return type refinement.
Actually refining the return type is not-inference-breaking, though you still run the risk of being name-resolution-breaking (e.g. refining to a concrete type or even adding a new guaranteed trait could cause a name conflict with newly applicable extension traits).

In practice, API evolution in this manner is necessarily considered perfectly acceptable, and is imho very rarely worth warning for

The fact that there is a lot of nuance to semver and some parts that are contextual is why I feel like https://github.com/obi1kenobi/cargo-semver-check/issues/58 is going to be important.

Here's one not listed: adding a generic (type or const) to a function is a breaking change.

That one is very interesting, and I'm not exactly sure what to make of it.
It's definitely breaking, no doubts there. But as I've written before, some Rust breaking changes don't require a major version — the API evolution RFC says so: https://rust-lang.github.io/rfcs/1105-api-evolution.html
Is adding a generic to an already-generic function covered under that exception?
Is adding a generic to a function that previously wasn't generic covered?
Would love to get your thoughts @jhpratt! These kinds of existential questions are things we run into a lot here 😅

Yes, adding a new generic to a function is a major breaking change.   It will break in any case where the type parameters are explicitly provided, like if inference didn't work out.  This is true for other API items as well with one exception: if a new generic to a type or trait is defaulted, then its a minor breaking change.  The explicit type parameters are unchanged but there are cases where inference won't work and it will fail to compile and the API Evolution RFC decided to brush that under the rug and ignore it (I've been bitten by it...)
Also, just because the RFC says something is a minor semver breakage, that doesn't mean the user shouldn't be told as that RFC was written specifically for the stdlib and not as guidance for the ecosystem and even the stdlib sometimes goes to extra lengths to avoid minor breaking changes if the impact is large enough.  From what I've heard, they are designing a whole new language feature to allow migrating trait methods from itertools to Iterator without breaking people.  Granted, #58 will be important for controlling this.

type no longer implements pub trait

How hard is this one to implement? I assume this covers things like removing the From impl from an error type? I'd like to try myself on that one.

type no longer implements pub trait

How hard is this one to implement? I assume this covers things like removing the From impl from an error type? I'd like to try myself on that one.

It does cover removing From from a type. Unfortunately, From is generic, and queries over generics are blocked on #241 as the hardest-to-design bit of schema in that issue. I wouldn't recommend it as a starting point, since it's likely to turn into yak shaving.
A better first issue would be something like #368 where the design is reasonably clear already.
In the meantime, I'm going to migrate the adapter implementation from Trustfall v0.2 to Trustfall v0.3 and take advantage of the massively improved ergonomics therein. If you'd like, I can loop you into that as well!

Leaking or re-exporting another crate's type in one's own API
* for example, having a function that returns a value of another crate's API

* this can cause coupling to the other crate's version, and can be a pain

* there are legitimate reasons to do this sometimes, but it should be an intentional decision and probably worth flagging in review

Two thoughts regarding this:

It would be great if we could somehow specify the intention that a certain item is meant to be hidden from the public API. For example, it is very easy and common to leak a dependency via a From impl for that dependencies Error type.
A reasonable default for the above could be to lint against all dependencies that are < 1.0 and appear in the public API. For a crate that is < 1.0, this could be allowed by default but as soon as you bump to 1.0, it should be a warn. If a crate wants to stabilise their public API, they can then opt-in to that lint ahead of time.

See https://rust-lang.github.io/api-guidelines/necessities.html#public-dependencies-of-a-stable-crate-are-stable-c-stable.

It would be great if we could somehow specify the intention that a certain item is meant to be hidden from the public API. For example, it is very easy and common to leak a dependency via a From impl for that dependencies Error type.

Except there is no way to convey this intention to your users.  If you implement a public trait on a public type, then that is a compatibility boundary.  I avoid From for error types for this very reason.

It would be great if we could somehow specify the intention that a certain item is meant to be hidden from the public API. For example, it is very easy and common to leak a dependency via a From impl for that dependencies Error type.

Except there is no way to convey this intention to your users.  If you implement a public trait on a public type, then that is a compatibility boundary.  I avoid From for error types for this very reason.

What I meant was, I want to specify to cargo semver-checks that I want crate XYZ not in my public API. If I make a mistake and still include it, it should generate a warning.

Rather than being a list of checks, just a list of version pairs that have seen known ecosystem breakage, but pass all current checks. Maybe even something that can run in CI automatically to see if they start being detected.

Sorry, I'm still having a bit of trouble understanding the exact suggestion, and who the target audience is / how they benefit.
Would this list of version pairs be something posted in this issue, or part of cargo-semver-checks itself in some way?
When you say "run in CI automatically," is that referring to cargo-semver-checks' own CI, or in the CI of users of cargo-semver-checks?
Sorry I'm having a hard time following here. If it's easier to "show, not tell" I'd be happy to look at a PR too.

Based on https://github.com/rust-lang/rfcs/pull/3535#discussion_r1429134787 which I reproduced in https://github.com/Skgland/rust-semver-break.
It is currently possible in some cases to match non-exhaustive structs exhaustively,
resulting in a breaking change if such a struct is change to have more states (i.e. by adding a  field with more than one value).
This is the case if the struct is StructuralEq (constants of the type can be used as a pattern in match) and all possible values of the struct have an accessible constant.

Wow, that's quite the semver hazard! Thanks for pointing it out.
My preference, as I mentioned in the linked issue, would be to either error or lint on this inside rustc or clippy, since a #[non_exhaustive] type having exhaustive semantics seems to me like an accidental language or compiler bug.
If that doesn't pan out, we can look into our options here and see if we can check for StructuralPartialEq in some way.

"Auto trait impls for impl Trait in return type" came up recently on URLO: Implicit Unpin on impl Any, breaking change possible

I have figured out how to properly check if a trait is sealed or not, and I've opened #870 with a list of related lints that are now ready to be implemented!
This took 9 months to get right, and I'm excited it's finally there! 🙌


Delete cookie needs same site settings

When setting DJWTO_SAME_SITE to a value other than "Lax", the delete_cookie call in djwto/views.py#delete tries to delete the cookie without the same SAME SITE setting. This fails to remove the cookie in the browser.
I have a PR ready if you would like it.

Hi @hr-curtissimo ,
Thanks for opening this issue. Not sure what's happening there, I just tested here deleting the cookies with various values for SAME_SITE attribute and the cookies were deleted as expected.
Do you have maybe some example of how you implemented the deletion call? What browser did you test? What code did you have to change in order to see it working?
Maybe it's some conflict happening somewhere due distinct environment setup but not sure either.
Best,
Will

Hi, @WillianFuks! Thanks for getting back to me. I'm sorry about the long break between your response and this message. Here's a screenshot of the problem that I'm referring to.

I pulled that screenshot from this example: https://gcurtissimo.gitlab.io/djwto-example/
I hope that the instructions are clear enough for you to reproduce the error. I'll watch this thread more carefully in case you post a reply.
 I just realized I didn't answer one of your questions. I tested it on both Google Chrome and Mozilla Firefox.

Hi @hr-curtissimo ,
Thanks for the return and information. I tried playing around with the example that you created but unfortunately it's not working for me. Regardless of how using it the /data api connection always gets refused; the logout option also didn't succeed in the same regard.
I played around with the idea and implemented a sandbox environment, similar to what you did, using vue instead of react (mainly because it's the only progressive js framework that I know ^^), you can check and test the newer code as well.
Bad news is that regardless of how setting the connections I couldn't recreate what you observed. Maybe if you see the connections I did you may find something?
Also could you please share the code you implemented for creating the demo? I'll try to find something different from my implementation and see if I can cause the same cookie setting block on my browser.
Best!
Will

Hi @hr-curtissimo ,
Sorry for the delay! As you could see, your code has been merged into master now. Could you please confirm everything is working?
As you don't have an email I couldn't reference you into the commit. Do you have a no-reply email I could use?
Best!
Will

Hi @hr-curtissimo ,
Just as a quick note, I just uploaded a new rc to pypi. You can test the new code just by installing the newer code:
pip install djwto==0.0.4rc0

Hope that helps, please let me know if it works for you!
Best,
Will


Microsoft Azure Rest Clients dont work with subscriptionId = null

               using (var subscriptionClient = new SubscriptionClient(new TokenCredentials(azureToken)))
                {
                    subscriptionClient.SubscriptionId = "";
                     var subscriptions = await subscriptionClient.Subscriptions.ListAsync();
                }

Abit wierd that one have to set it to empty string, or else it throws an exception.
Package: Microsoft.Azure.Management.Resources.3.1.1-preview

Seems like this is no longer an issue, using Microsoft.Azure.Management.ResourceManager 1.1.5-preview.


Factorize base engine run into one function

To unify treatment of multiple runs necessary between LatexConverter and PDFLatexConverter, factor the run loop into a separate function that is called from generate_pdf.

I changed _base_runner part.

Great, thanks for that!!! I was contemplating a similar change, but again - wasn't sure about the original intention of naming the functions, so I kept them.
The way it is now is much cleaner, thanks!


unexpected abort is resulting for allocating big buffers  (IDFGH-5495)

Environment

Development Kit:      ESP32-Wrover-Kit
Module or chip used:  ESP32-WROVER-B
IDF version: v4.2.1
Build System:       CMake
Operating System:     Windows
Using an IDE?: Yes (Visual GDB)
Power Supply:         USB

Problem Description
While allocating a big array (Bigger than the available free memory), an abort is being executed.
despite the SDK config options:

CONFIG_FREERTOS_ASSERT_FAIL_PRINT_CONTINUE=y

CONFIG_HEAP_ABORT_WHEN_ALLOCATION_FAILS is not set

Expected Behavior
Just return null without aborting as configured in the SDK config.
Actual Behavior
returning null followed by aborting.
Steps to reproduce

Flash the code below with the sdk config attached

Code to reproduce this issue
#include <stdio.h>
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_system.h"
#include "esp_spi_flash.h"

void app_main(void)
{
    printf("Hello world!\n");
    printf("Free heap: %d\n", esp_get_free_heap_size());

    // allocating 10 mb buffer , buffer should return null
    int* buffer = malloc(10*1000*1000);

[sdkconfig.txt](https://github.com/espressif/esp-idf/files/6760467/sdkconfig.txt)
printf("Free heap: %d\n", esp_get_free_heap_size());
   assert(buffer!= NULL);
    for (int i = 10; i >= 0; i--) {
        printf("Restarting in %d seconds...\n", i);
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }
    printf("Restarting now.\n");
    fflush(stdout);
    esp_restart();
}

// If your code is longer than 30 lines, GIST is preferred.
Debug Logs
I (28) boot: ESP-IDF v4.2.1-dirty 2nd stage bootloader
I (28) boot: compile time 20:48:58
I (29) boot: chip revision: 1
I (32) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (39) boot.esp32: SPI Speed      : 40MHz
I (43) boot.esp32: SPI Mode       : DIO
I (48) boot.esp32: SPI Flash Size : 2MB
I (53) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (62) boot: ## Label            Usage          Type ST Offset   Length
I (69) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (76) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (84) boot:  2 factory          factory app      00 00 00010000 00100000
I (91) boot: End of partition table
I (95) boot_comm: chip revision: 1, min. application chip revision: 0
I (103) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05890 ( 22672) map
I (120) esp_image: segment 1: paddr=0x000158b8 vaddr=0x3ffb0000 size=0x021e4 (  8676) load
I (124) esp_image: segment 2: paddr=0x00017aa4 vaddr=0x40080000 size=0x00404 (  1028) load
I (130) esp_image: segment 3: paddr=0x00017eb0 vaddr=0x40080404 size=0x08168 ( 33128) load
I (153) esp_image: segment 4: paddr=0x00020020 vaddr=0x400d0020 size=0x12a28 ( 76328) map
I (182) esp_image: segment 5: paddr=0x00032a50 vaddr=0x4008856c size=0x01938 (  6456) load
I (191) boot: Loaded app from partition at offset 0x10000
I (191) boot: Disabling RNG early entropy source...
I (191) cpu_start: Pro cpu up.
I (195) cpu_start: Application information:
I (200) cpu_start: Project name:     hello-world
I (205) cpu_start: App version:      1
I (210) cpu_start: Compile time:     Jul  4 2021 20:47:56
I (216) cpu_start: ELF file SHA256:  0c0626c634a8241f...
I (222) cpu_start: ESP-IDF:          v4.2.1-dirty
I (227) cpu_start: Starting app cpu, entry point is 0x400815e4
I (220) cpu_start: App cpu up.
I (238) heap_init: Initializing. RAM available for dynamic allocation:
I (245) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (251) heap_init: At 3FFB2A28 len 0002D5D8 (181 KiB): DRAM
I (257) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (263) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (270) heap_init: At 40089EA4 len 0001615C (88 KiB): IRAM
I (276) cpu_start: Pro cpu start user code
I (294) spi_flash: detected chip: generic
I (295) spi_flash: flash io: dio
W (295) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (305) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Hello world!
Free heap: 299632
Free heap: 299632
assertion "buffer!= NULL" failed: file "../../../main/hello_world_main.c", line 24, function: app_main

abort() was called at PC 0x400d5153 on core 0
Setting breakpoint at 0x40083eee and returning...

Other items if possible

[sdkconfig.txt] sdkconfig file (attach the sdkconfig file from your project folder)
[ ] elf file in the build folder (note this may contain all the code details and symbols of your project.)
[ ] coredump (This provides stacks of tasks.)

assert(buffer!= NULL);
You have the wrong test if you expect buffer to be null

Hi @formus14,
Yes, the abort is happening because the assertion fails not because the allocation fails. If CONFIG_HEAP_ABORT_WHEN_ALLOCATION_FAILS was set then it would abort before malloc() returned at all.
I think the confusion is because of the option CONFIG_FREERTOS_ASSERT_FAIL_PRINT_CONTINUE. This option only applies to FreeRTOS configASSERT() macros and not the normal libc assert() macros. There is no "print and continue" option for standard asserts, just these options.
(We realise this is a bit confusing, and in ESP-IDF V5.0 we're considering removing the FreeRTOS-only options and having the behaviour follow the standard assert behaviour.)

@projectgus Thanks, now it's clear for me!


fix - versa_flexvnf - made space at the end of prompt optional

Description
This is a small bugfix which aims our problem with prompt. For some reason we got similar errors:
scrapli.exceptions.ScrapliPrivilegeError: could not determine privilege level from provided prompt: 'xxmyuserxx@MYDEVICE-cli(config)%'
The space is missing at the end!!! But the device sends one so determining the prompt fails. My fix basically makes that space optional. This way the login and privilege escalation works. I tested on real box.
Type of change
Please delete options that are not relevant.

[X] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
The pytest test still works fine. Also tested on real box.
Checklist:

[X] My code follows the style guidelines of this project (no GitHub actions complaints! run make lint before
committing!)
[X] I have commented my code, pydocstyle and darglint are happy, docstrings are in google docstring format, and all
docstrings include a summary, args, returns and raises fields (even if N/A)
[X] I have added tests that prove my fix is effective or that my feature works, if adding "functional" tests please
note if there are any considerations for the vrnetlab setup
[X] New and existing unit tests pass locally with my changes

👋 hey @viktorkertesz ! painful, I've been there :D lgtm and can merge, but maybe \s? would be safer? either way is cool with me so just lemme know and ill smack merge whenever!

👋 hey @viktorkertesz ! painful, I've been there :D lgtm and can merge, but maybe \s? would be safer? either way is cool with me so just lemme know and ill smack merge whenever!

Hi @carlmontanari, it was space char which I didn't change, but feel free to replace it if you think it would help.

copy! if it works for you it works for me! thanks as always!


can dev add toggle word-wrap?

Version?

vs code plugin
browser
both?

Feature
Describe the feature you want to suggest.

Not 100% sure what you mean but there is an option csv-edit.enableWrapping that wraps cells.

@lzygitk7 is csv-edit.enableWrapping the feature you described?

Sorry for delay reply. Not really, but thank you for your reply.
Outlook for Androidhttps://aka.ms/AAb9ysg

From: janisdd @.>
Sent: Friday, August 4, 2023 7:38:28 PM
To: janisdd/vscode-edit-csv @.>
Cc: lzygitk7 @.>; Mention @.>
Subject: Re: [janisdd/vscode-edit-csv] can dev add toggle word-wrap? (Issue #128)
@lzygitk7https://github.com/lzygitk7 is csv-edit.enableWrapping the feature you described?
—
Reply to this email directly, view it on GitHubhttps://github.com/janisdd/vscode-edit-csv/issues/128#issuecomment-1665469910, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6YQSGCUSQUAMXPYMP5FV2LXTTNLJANCNFSM6AAAAAA25TLXMA.
You are receiving this because you were mentioned.Message ID: @.***>

So what do you mean by word-wrap then? Or how it is different from the current functionality of csv-edit.enableWrapping?

You know the cell is only wrapped if you change the column size manually... by default the cell will auto size to fit the content on a single line.
You could set csv-edit.initialColumnWidth to a small value and see the wrapping immediately.

@lzygitk7 Can this be closed? You have to manually resize the column first. How should the table know which width is the best? For this reason, the initial width is adjusted to the contents of the cell.


3.19.0 appears to break server-side rendering by relying on window

Hi there,
I'm really sorry that I couldn't find a simple way to replicate this with demo code, but hopefully I can be descriptive.
We use a mixed Preact/React stack at the moment, and use preact-render-to-string to dump out the DOM to provide server-side rendering.
When our packages automatically updated to include preact-compat 3.19.0, SSR broke, with the following stack trace:
ReferenceError: window is not defined
    at evalmachine.<anonymous>:7654:360
    at ./node_modules/preact-context/dist/context.min.js (evalmachine.<anonymous>:7654:22)
    at Object../node_modules/preact-context/dist/context.min.js (evalmachine.<anonymous>:7654:118)
    at __webpack_require__ (evalmachine.<anonymous>:20:30)
    at Module../node_modules/preact-compat/dist/preact-compat.es.js (evalmachine.<anonymous>:6985:72)
    at __webpack_require__ (evalmachine.<anonymous>:20:30)
    at<EMAIL_ADDRESS>(evalmachine.<anonymous>:119:63)
    at __webpack_require__ (evalmachine.<anonymous>:20:30)
    at Module../app/static/js/render_kit/components/ResultCard.js (evalmachine.<anonymous>:2639:133)
    at __webpack_require__ (evalmachine.<anonymous>:20:30)

This rendering kit uses a React component (CdnImage) and preact-compat fails when this line, in that component, is imported:
import React, { Component } from 'react';
Something in there is relying on window and we've bisected it to 3.19.0
I hope that helps. I'm sorry again for being so vague.

Hi Paul - just wanted to apologize for the radio silence on this issue.
You're right that this was introduced in 3.19, since the error is coming from createContext, which was the most recently merged PR (#529). It looks like the issue is actually a build configuration error in preact-context - I'll try to find a fix there.

This should be fixed!


Can not download Bloomberg video

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like this: [x])
Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2018.10.05. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2018.10.05

Before submitting an issue make sure you have:

[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones
[x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add the -v flag to your command line you run youtube-dl with (youtube-dl -v <your command line>), copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-v', u'https://www.bloomberg.com/news/videos/2018-10-12/-bloomberg-markets-the-close-full-show-10-12-2018-video']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.10.05
[debug] Python version 2.7.14 (CPython) - Darwin-18.0.0-x86_64-i386-64bit
[debug] exe versions: avconv present, avprobe present, ffmpeg 3.4.2, ffprobe 3.4.2
[debug] Proxy map: {}
[Bloomberg] -bloomberg-markets-the-close-full-show-10-12-2018-video: Downloading webpage
ERROR: Unable to extract id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/Users/dave/venv/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 792, in extract_info
    ie_result = ie.extract(url)
  File "/Users/dave/venv/lib/python2.7/site-packages/youtube_dl/extractor/common.py", line 507, in extract
    ie_result = self._real_extract(url)
  File "/Users/dave//venv/lib/python2.7/site-packages/youtube_dl/extractor/bloomberg.py", line 58, in _real_extract
    r'BPlayer\(null,\s*({[^;]+})\);', webpage, 'id'), name)
  File "/Users/dave/venv/lib/python2.7/site-packages/youtube_dl/extractor/common.py", line 977, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
RegexNotFoundError: Unable to extract id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

...
<end of log>

Description of your issue, suggested solution and other information
Bloomberg videos can not be downloaded. Previously it was downloaded.
youtube-dl -v https://www.bloomberg.com/news/videos/2018-10-12/-bloomberg-markets-the-close-full-show-10-12-2018-video

Problem still exists in 2019.06.08.

Still exists today unfortunately

the URL from this issue works fine.
@D3MZ post the non-working URL.


Failures are not honoring retry index

There is an unused deprecated script flush queue () #dep, which appears to increment the message queue retryIndex, however the new version of this script flush queue does not. Unless there's a hard failure (i.e., error code 104) the message will be tried for eternity.

After further review, it appears that the field MESSAGEQUEUE::retryIndex is being conflated with and looking up from the field SUBSCRIBER::retryLimit. The index should be the current retry count and it should halt once it reaches the limit.


tag test case missing

US03.03.01 - MISSING
As a claimant, I want to filter the list of expense claims by tags, to show only those claims that have at least one tag matching any of a given set of one or more filter tags.
There is also some TA feedback regarding your tag Use Cases that hasn't been addressed. I made a suggestion in the UML issue(#16) about how I would handle the tags if that helps.
Then please add the tag test cases to Use cases. If you create a tag list separate from the claims themselves, I would expect that you'd need 5-6 test cases and you only have 4 written.

I'll get on it S soon as I get off work
On Feb 22, 2015 5:54 PM, "vanbelle"<EMAIL_ADDRESS>wrote:

US03.03.01
As a claimant, I want to filter the list of expense claims by tags, to
show only those claims that have at least one tag matching any of a given
set of one or more filter tags.
—
Reply to this email directly or view it on GitHub
https://github.com/CMPUT301W15T12/C301Project/issues/21.

If we have an ArrayList tagList inside of Claim and a class Taglist for all the available tags, you will need separate test cases for adding tags. One for US03.01 to make sure its associated with a claim and one for US03.02 to make sure the user can add new tags to be available to claims..

i can edit the test case as well

i extended the test case so that it adds to both the claim if we want to add to the claim, or the taglist if we want to only create a tag. i did not go into details. i just made 2 separate add methods each adding to its own list. i did not make any specific conditions of scenarios. i will work on those later.
for the filtering, i am just going to add everthing in a new list that matches the typed tag and display that.

I added the filter test case. It is not its own test case though, and is just a few extra lines added to the existing addTag test case.  Since everything was already in place, i just added it there. I can make it a standalone case when I have more things to work with.

for the filter test case just copy it again into the use cases and delete the line(s) pertaining to adding or put in a comment telling the TA that is where the test is. also the test cases (renaming/deleting) are still not posted to your second use case. please do those ASAP.
each use case should have a test case, or a comment of some kind acknowledging why there isnt a test case.

I'll do it right away.  I am pretty sure I posted it yesterday.  I will do
it again to make sure
On Feb 23, 2015 1:51 PM, "vanbelle"<EMAIL_ADDRESS>wrote:

for the filter test case just copy it again into the use cases and delete
the line(s) pertaining to adding or put in a comment telling the TA that is
where the test is. also the test cases (renaming/deleting) are still not
posted to your second use case. please do those ASAP.
each use case should have a test case, or a comment of some kind
acknowledging why there isnt a test case.
—
Reply to this email directly or view it on GitHub
https://github.com/CMPUT301W15T12/C301Project/issues/21#issuecomment-75629034
.