Improve battery segment

@rjorgenson I found in #344 some inconsistencies (harsh word, this is a mere suggestion) in the battery segment. These come from mixing up capacity-values ("low") and status information ("charging", "charged", "disconnected").
My suggestion is to clear that up by changing the color only at certain capacity thresholds, like the "low" one now. And to add some more thresholds for "medium" and "high".
The status information could be indicated by an icon (similar to the "incoming" and "outgoing" feature of the vcs segment.
This suggestion could be pivoted, so that capacity values could be indicated by icons and status information control the colors..
I came up with this idea while writing tests for that segment..
What do you think? Is this a bad idea?

Hmm, I guess I never really thought of the 'low' warning as a strict capacity value, and as more of a status warning. More-so since it's a configurable threshold. I don't particularly like the idea of indicating charge levels at various capacities because such things are generally vague and mostly without meaning. Especially when it says exactly what the charge capacity is right next to that. Though I could see that being useful if all someone didn't want the text output(percentage and time remaining). I think multiple icons might start to get confusing though, what icons did you have in mind?

My thoughts were just that we have two classes of values, and one (the more important one) of them should be responsible for changing the background color. For me that is the capacity. I agree these values are vague, but still valuable ;)
For 'charging' and 'discharging' I had in mind an up and a down arrow, or maybe plus and minus (maybe doubled).

I'm probably the wrong person to have input on that behavior as I'm not a big fan of different background colors on segments lol - If we did move that behavior over and have the capacity control the color I'd still like to maintain a 'critical low' status independent of the capacity behavior. As it's written now I don't really see it as changing colors on capacity, but on battery states. The states are charging, charged, discharging, and critical low - all of which I feel are important independent of the actual current capacity of the battery. Anyone else have any thoughts on this?

@rjorgenson @dritter - I saw this discussion when it took place 10 days ago, and I've mulled over a bit since then. To me, I would prefer that any color changes are dependent upon the status (charging / discharging / etc.,) rather than charge level alone. If I'm at a low battery level, but am plugged in & charging, a "battery warning color" state would annoy me. What I care about is:

Am I at a low charge level and discharging
Am I discharging (battery level okay)
Am I charging
Am I charged

It looks like the existing code covers these scenarios. I do like @dritter's suggestions of icon changes, though, as that would also limit the color changes of the segment. I prefer the double ++ and -- suggestions.
Something like:

state
icon
color

low level & discharging
{battery icon} {warning icon}
red

discharging
{battery icon} --
blue

charging
{battery icon} ++
blue

charged
{battery full icon}
green

But, this could also make it way too busy. Probably can't say definitively without mocking it up, honestly.

Interesting. I started this discussion coming from the other direction. While writing the tests for this segment, I found it strange that connecting/disconnecting power supply changes the color.
Consider the following tests:

function testBatterySegmentIfBatteryIsAlmostFullWhileDischargingOnOSX() {
  OS='OSX'
  makeBatterySay "Now drawing from 'Battery Power'
 -InternalBattery-0 (id=1234567)	98%; discharging; 3:57 remaining present: true"

  prompt_battery "left" "1" "false" "${FOLDER}"
  p9k_build_prompt_from_cache 0

  assertEquals "%K{black} %F{white%}🔋%f %F{white}98%% (3:57) %k%F{black}%f " "${PROMPT}"
}

function testBatterySegmentIfBatteryIsAlmostFullWhileChargingOnOSX() {
  OS='OSX'
  makeBatterySay "Now drawing from 'Battery Power'
 -InternalBattery-0 (id=1234567)	98%; charging; 3:57 remaining present: true"

  prompt_battery "left" "1" "false" "${FOLDER}"
  p9k_build_prompt_from_cache 0

  assertEquals "%K{black} %F{yellow%}🔋%f %F{yellow}98%% (3:57) %k%F{black}%f " "${PROMPT}"
}

The only different is mocking power supply/disconnecting.
What is odd to me, that yellow always has a "warning" connotation. But on 98% there isn't IMHO anything to warn about. Connected or not..

When I originally chose the colors to indicate each state, I tried replicating what showed up on my power adapter(green = charged, orange = charging, and no light when unplugged). The LED glows orange when charging, and yellow was the closest color in the 16 default colors so I went with that. I can understand how that might be confusing for someone not used to an Apple power connector. If we were to stick with having the color indicate state, what colors would you suggest? As with @bhilburn I don't really care about the capacity of my battery at a quick glance unless it's critical. Maybe we could change the name of the low state to critical or something along those lines to be more clear about it's purpose?

@rjorgenson Well, that explains a lot. 😄  I have a mac, but never associated the battery segment with the power plug. And thinking about it, the power plug tells a different story than the battery segment. The power plug can differentiate between the loading states, but the battery segment tells me something about the capacity..

Yeah, it wasn't meant to replicate the power adapter, but to replicate the battery menu item in OS X. It can do much fancier things with it's icon than I was able to in text without ramping up font size ridiculously high, and I wanted to keep it nice and compact so I decided to use colors to indicate state, and the colors that seemed most appropriate were the colors already used to indicate state on the power adapter =]
This idea is much older than the segment, I initially wrote a 'geeklet' in 2008 when I got an  11" MacBook Air and wanted to remove as much from the menu bar as possible but still keep things compact. Perhaps the use case for my reasonings is no longer that valid =]

@dritter @rjorgenson - Great discussion! Thanks for sharing your opinions!
So, setting aside what the battery segment currently does, what are your ideal scenarios in terms of state / icons / color? Can you put together a table to lay it out? I think I'm having trouble following the suggestions, at this point.

For me it would be:

cable plugged
cable unplugged

empty
background red, icons "++"
background red, icons "--"

half full
background yellow, icons "++"
background yellow, icons "--"

full
background green
background green, icons "--"

Maybe with a critical level (but then the colors above should be foreground colors, and the critical level changes it to background color red).
Thresholds and icons are to be discussed.

Personally I still don't like the idea of indicating capacity with colors, but I wouldn't want to block changes based on my bias if that's the way people want to go with it. If that is the way people want it done I think @dritter's table makes sense. I also suggest a state-based foreground and background color so the user can customize the colors in case green/yellow/red doesn't really fit with their prompt colors. As far as icons go I don't initially see anything better than the + and - inside a circle, though I'm not sure having more than one icon in a segment is ideal. In every other state there is one icon and it indicates what data is displayed in the segment and not any particular data within the segment(with the exception of the recent changes to the dir segment). All that said I prefer how it is now, but again I am definitely biased in that regard =]

I wouldn't want to block changes based on my bias if that's the way people want to go with it.

Same applies to me and changing something just for the changes sake. Nobody except me seems to be confused by how the battery segment works now. At least I didn't hear any complaints.. So, maybe we should leave it like it is and wait for some other folks to raise their voices..
Btw. + / - in a circle is an excellent idea!
Hmm. I might be blind, but I just find the full icons (not the open ones) $'\uE168' / $'\uE169':

Just stumbled upon:
$'\uE86B' / $'\uE86C' (patched mode)

Yeah those were the icons I was referring to, I don't have the open circle ones in my patched font either. The square ones are better, I didn't catch those ones =]

I wonder if the best solution, here, might be to provide something that's heavily customizable using our usual state structure, but have the default be really, really simple. Example:
Default:

cable plugged
cable unplugged

critical
no color, icon "+"
background red, icon "-"

half full
no color, icon "+"
no color, icon "-"

full
no color
no color, icons"-"

As long as the levels for what constitutes critical, half-full, and full were customizable, and we enabled our usual modification of FG / BG color and icons, this is a fairly non-obnoxious default as it only really blares at you if you are critical and aren't charging.
With this structure, folks that want more information, like @dritter, could easily configure something more complex, like this:

cable plugged
cable unplugged

critical
background red, icons "++"
background red, icons "--"

half full
background yellow, icons "++"
background yellow, icons "--"

full
background green
background green, icons "--"

Thoughts?

For me it looks good :)
Only thing I would consider is using a more colorful version by default. IMHO the battery segment is a quite important one and more people would want to have it more colorful and the other way is still possible (to configure the segment more grayscale).

While on the topic, Nerd fonts support 5 icons for battery, from full to empty.
Nerd Icons: \uF240  \uF241  \uF242  \uF243  \uF244
Would it be possible to make the icon change to reflect the charge level?

Finally a different voice. 😄
Well, it would be, if we make this change. And you need to convince @bhilburn to add five states. 😆

Thanks for hopping in, @onaforeignshore! We definitely appreciate another viewpoint =)
Okay, so the one issue there is that in non-nerdfont configurations, which are the majority of our users, how would we deal with the extra state? I suppose we could just set the same icon for all of them, which would actually be pretty easy.
I can't actually see the icons you used, @onaforeignshore, since Github / Chrome won't render them. Can you screenshot them? What might make sense? States with steps of 25% charge levels (e.g., 0%, 25%, 50%, 75%, 100%)?

@onaforeignshore is working on this in #476.

Filed PR #498 for this

#498 has been merged! Thanks, @onaforeignshore, for all of your work, and thanks to @dritter and @rjorgenson for the great discussion in this thread =)


On print, blank page at the end

Hello!
When I call the print method, on Chrome or on Edge, there is always a blank page at the end, but on firefox, it works fine.
What can be the cause?
For example, here I have a 3 pages PDF but it shows an empty fourth one in the preview on chrome.

Hi @MitiaElodie,
Unfortunately, I have not been able to reproduce this. Could you provide more information about the environment (OS, browser versions) as well as some code snippet?

Hi @tanfei21,
Were you able to reproduce this issue? If so and the proposed changes fix the issue, would you open a PR?

https://raw.githubusercontent.com/tanfei21/pdf/c100a3d89ef69ed46f4acb665118b13a10867ece/test.pdf
You can use this file to test.


Implement the swagger / openapi file parser

In addition to just parsing comments from generic source files, it would be good if it could parse x-threatspec keys from swagger files, especially if they're in JSON which doesn't support comments.

Implemented in https://github.com/threatspec/threatspec/pull/30


Python JSON serialization in test cases

Test cases contain JSON serializations that are python specific.
It would be better to ensure compact JSON is used (no extra spaces)... otherwise implementations will need to adjust their JSON serializer to match Python in order to to match the testcases.
Some additional string cases would also help force errors for any brittle reimplementation of python dumps.
{
  "I'm a 🧊, :cool: string": "with 🌶, and :pepper:"
}

(, and : have spaces after them in the default JSON serialization used)

Happy to accept PRs for new test cases :-)
I'll look into the JSON serializiation, although there are more parts that may vary, e.g., the order of elements. My expectation is that JSON is not compared as strings, but based on the decoded content.


Docker

Convert dictorm to use a common docker container.

Coverage remained the same at 100.0% when pulling bc5db23ba465a2edc0a211e554e3a434642a2aee on docker into 5e5596942d838ebfe8f03fbb820a07d1263a3144 on master.

Coverage remained the same at 100.0% when pulling bb9c3688a7de55e211073740ef561bc3d6a6bf84 on docker into 5e5596942d838ebfe8f03fbb820a07d1263a3144 on master.

Coverage remained the same at 100.0% when pulling 9c7aba95c874ebab6e569902afa3d06ac9d8bd0f on docker into 5e5596942d838ebfe8f03fbb820a07d1263a3144 on master.

Coverage remained the same at 100.0% when pulling 9c7aba95c874ebab6e569902afa3d06ac9d8bd0f on docker into 5e5596942d838ebfe8f03fbb820a07d1263a3144 on master.


docs: add complete build123d + visualization demo via ocp_vscode "standalone" mode

Now that ocp_vscode supports use in a regular browser (and not strictly bound with VSCode), it is much easier to explain how one could simply:

pip install build123d ocp_vscode
execute python -m ocp_vscode
open http://<IP_ADDRESS>:3939/viewer in a suitable browser
execute a python file with necessary build123d and ocp_vscode imports and show statement

As a way to get users "up and running quickly" I propose something similar to the above is added to the build123d docs (with appropriate links/caveats back to the ocp_vscode repo/docs). Further I propose that a screenshot is added to show what this could look like (maybe with vim + chrome, or something similar).

+1

Screenshot for the docs [using Ubuntu 20.04, gedit, gnome-terminal, ipython and firefox]:

Nice


Frederick County, Virginia defund police email

You have to go to each board of supervisors personal page to send them a message directly since we do not have access to their emails. https://www.fcva.us/departments/office-of-elections-voter-registration/elected-representatives#frederick county
To Chairman Chuck DeHaven, the Frederick County Board of Supervisors, and Frederick County Elected Officers,
My name is [YOUR NAME], and I am a resident of Frederick County. Over the past couple of weeks, our nation has been gripped by protests calling for rapid and meaningful change with regard to police behavior, an end to racism and anti-blackness, and immediate reform in how black people are treated in America. Our county has been involved in this call to action as well. In reviewing details from the fiscal year (FY) 2020 adopted budget, Frederick County Sheriff’s Office (FCSO) has utilized too much of our county’s resources. Over the past year, the Sheriff’s Office cost the county $15,860,951, which accounts for the largest portion of the Public Safety budget (39%). While we’ve been spending extraordinary amounts on policing, we have not seen large improvements to overall safety, public health, mental health, or affordability in our county.
Instead, we see financial resources that can and should be allocated elsewhere. Schools do not need more school resource officers, they need counselors and mental health providers. It was also saddening to see that last year, less than $500,000 was allocated for the local health department. As we are in the midst of a global pandemic, many have realized how underfunded public health has been across the country.
I call on you to slash the FCSO budget and instead use those extraordinary resources towards funding what Black and Brown communities need to be safe and healthy: COVID19 relief, housing, healthcare, treatment, healing, cooperative businesses, community centers, community-led organizations and projects. We can be a beacon for other cities to follow if only we have the courage to change.
Sincerely,
[YOUR NAME]
[YOUR ADDRESS]
[YOUR EMAIL]
[YOUR PHONE]

Thank you for submitting your city to defund12.org! Your request is now in the queue for review and publishing. We’ll reply here if we have any questions.

Editing notes: Small edits made. Very clean copy!
Budget confirmed (search "sheriff," not "police") here: https://www.fcva.us/home/showdocument?id=17810
Is there any way to acquire the email addresses of the city officials so it's a seamless user experience on defund12.org?
To: You have to go to each board of supervisors' personal page to send them a message directly since we do not have access to their emails. https://www.fcva.us/departments/office-of-elections-voter-registration/elected-representatives#frederick county
Message: (Don't forget to replace the [x]'s with your information!)
Dear Chairman Chuck DeHaven, the Frederick County Board of Supervisors, and Frederick County Elected Officers,
My name is [YOUR NAME], and I am a resident of Frederick County. Over the past few weeks, our nation has been gripped by protests calling for rapid and meaningful change with regard to police behavior, an end to racism and anti-blackness, and immediate reform in how Black people are treated in America.
Our county has been involved in this call-to-action as well. In reviewing details from the fiscal year (FY) 2020 adopted budget, Frederick County Sheriff’s Office (FCSO) has utilized too much of our county’s resources. Over the past year, the Sheriff’s Office cost the county $15,860,951, which accounts for the largest portion of the public safety budget (39%). While we’ve been spending extraordinary amounts on policing, we have not seen large improvements to overall safety, public health, mental health, or affordability in our county.
Instead, we see financial resources that can and should be allocated elsewhere. Schools do not need more school resource officers; they need counselors and mental health providers. It was also saddening to see that last year, less than $500,000 was allocated for the local health department. As we are in the midst of a global pandemic, many have realized how underfunded public health has been across the country.
I call on you to slash the FCSO budget and instead use those extraordinary resources towards funding what Black and Brown communities need to be safe and healthy: COVID-19 relief, housing, health care, cooperative businesses, community centers, and community-led organizations and projects. We can be a beacon for other cities to follow if only we have the courage to change.
Sincerely,
[YOUR NAME]
[YOUR ADDRESS]
[YOUR EMAIL]
[YOUR PHONE]

on it

Hi @julhav! Do you think you could comment below with the elected officials that you want to receive this email? Didn't realize this was missing before, but it's actually a requirement to get your template posted. Thanks so much.

I found them! Sorry that it took a while. I discovered another defund email
website as well which is where I found the emails:
https://defund.email/index.html?fbclid=IwAR2qrExA-DCuur3ZfUW9zAlioB-tZe02T1___Vqyiv9_jLE62wmobXxXLF8
Here are the emails of the elected officials:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Thanks!
On Thu, Jul 9, 2020 at 1:53 PM mahrer<EMAIL_ADDRESS>wrote:

Hi @julhav https://github.com/julhav! Do you think you could comment
below with the elected officials that you want to receive this email?
Didn't realize this was missing before, but it's actually a requirement to
get your template posted. Thanks so much.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/defund12/defund12.org/issues/1669#issuecomment-656266707,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQAXDXTY4OAYJNMTPVSJSY3R2X7Z7ANCNFSM4ODPV7NA
.

--
Julia Havron, PA-S
Shenandoah University Class of 2020
Division of Physician Assistant Studies
Pronouns: She/Her/Hers


Peer dependency error with react-location-devtools

Describe the bug
Hello, I'm experiencing this behaviour while installing the latest packages (see below).
Not a real issue, it's just a little bit annoying to force on all npm install I do (it complains even when installing other packages at later times), but I just wanted to report this in case nobody was aware yet.
Thank you for the awesome library by the way!
Your Example Website or App
N/A
Steps to Reproduce the Bug or Issue
Package.json containing:
"@tanstack/react-location": "^3.7.4",
"@tanstack/react-location-devtools": "^3.4.4"

(I wasn't unable to find a devtool version matching the react-location one)
When I run npm install I'm getting these errors:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@tanstack/react-location
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@tanstack/react-location-devtools
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/@tanstack/react-location
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@tanstack/react-location-devtools
npm ERR!     dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

If I run the command with the -f (force) switch, errors turn into warnings, the installation succeeds and I can see the devtools running in the app.
Expected behavior
Installation shouldn't give errors and proceed without the need to force it.
Screenshots or Videos
No response
Platform

OS: Linux
Browser: N/A
Version: N/A
NodeJS: 16.14.2
npm: 8.6.0

Additional context
No response

Had the same issue. Before Tan has an official fix I just manually edit the package-lock.json file to get around this error.
    "node_modules/@tanstack/react-location-devtools": {
      "version": "3.4.4",
      "resolved"<EMAIL_ADDRESS>      "integrity": "sha512-EyPdaPXlIgGoZl8S34RPcQ/OD2WqwZSNg89lpTfFf3yUWOOMJHmK6MUH3jubOjtAONnIs+UreePWbW+NY7gBAQ==",
      "dependencies": {
        "@babel/runtime": "^7.16.7"
      },
      "engines": {
        "node": ">=12"
      },
      "funding": {
        "type": "github",
        "url": "https://github.com/sponsors/tannerlinsley"
      },
      "peerDependencies": {
-        "@tanstack/react-location": "3.4.4",
+       "@tanstack/react-location": "^3.4.4",
        "react": ">=16",
        "react-dom": ">=16"
      }
    },

You can use npm 7 overrides:
"overrides": {
  "@tanstack/react-location-devtools": {
    "@tanstack/react-location": "^3.7.4"
  }
},

In addition to this, the docs are really confusing, as they state: No need to install anything extra, just: import { ReactLocationDevtools } from '@tanstack/react-location-devtools' which doesn't appear to be the case. This is not a great DX when trying to use this library for this first time.

Or with pnpm, you can use allowedversions:
  "pnpm": {
    "peerDependencyRules": {
      "allowedVersions": {
        "@tanstack/react-location": "3.7.4"
      }
    }
  }


Recommend using Stylus instead of Stylish

Stylus is to be preferred to use a custom CSS for a single user as a Firefox Addon.  Stylish is even said to collect a lot of user data.
Tapermonkey is also a nice alternative (can load JS as well).

Thanks!
And if I can have one more suggestion on the topic, sorry I should have added that right away, if you can add the following comments to your CSS file that would greatly help the import into the Stylish settings so that users can just do a cut&paste.
/* ==UserStyle==
@name         TangerineUI 🍊 for Mastodon
@version      0.9.2
@description  Tangerine UI is a UI revamp for Mastodon's Web interface. Last Mastodon compatibility check: v4.1.4 stable ✅
@namespace    http://www.w3.org/1999/xhtml
@author<EMAIL_ADDRESS>@homepageURL  https://github.com/nileane/TangerineUI-for-Mastodon
@supportURL   https://github.com/nileane/TangerineUI-for-Mastodon/issues
@updateURL    https://github.com/nileane/TangerineUI-for-Mastodon/raw/main/TangerineUI-single-column.css
@license      MIT
@preprocessor default
==/UserStyle== */

I'm not sure if this would be the right call as I wish to keep maintaining this as a CSS file to be used by admins as well as users. Maybe I could include it in the README for people who wish to add it to the file?

Yes, you're absoluty right. Better keep your CSS file clean.


Automatically move card to list when time tracking starts

A requested feature as of lately. A setting allowing cards to be automatically moved to a specific list of your choice when you start tracking time. Very useful if you have a 'In progress' list for your cards.

I second this. Everyone in my office who I've just gotten onto this power-up is asking for automatic start timer when moving card to list, or something similar to what is described above.

@LexGear Have an update on this. Until now I haven't been able to think of a way of archiving this. This have been due to limitations in the plugin system Trello made where i wont be able to know which user moved a card from A -> B. Without this knowledge i could not possibly start the timer for the correct person.
(Technical v )
However - I found that if i request access to the REST API I'm able to register a webhook that will notify a service of mine about any change on the cards for the board. This would allow me to recognize card moves. There is still 2 questions left to answer:

Will i know in the webhook who actually moved the card?

Billing. Moving logic onto a server & not handling everything client side brings costs. I need to either find a way to monetize this feature or pay it out of my own pocket.

I'm still researching this.

Debating with myself about this.

@LexGear I've released a beta feature that allows for this. There is no such thing in the Trello SDK that allows me to do this - so I've had to go through a lot of loop-holes to get it working.
You should (after clearing browser cache) be able to access new settings for enabling this feature under your power-up settings. Please note that this is not the 'Settings' card button shown when on a card - but the administrators 'Power-up' settings for Activity timer. Here you'll be able to enable the feature & choose which list should auto-start the timer.
Technical details:
When enabling it will request access to act on your behalf. This is so that we can register a webhook that will notify a service hosted by me whenever changes to the board occurs. Within this webhook I'm able to detect the action when a user moves a card from list A to list B. While there is no built-in functionality for communicating with the frontend or setting data that i can fetch in the frontend to start the timer - i still got it working. Worked in a Websocket that will be used by the webhook to communicate when to start a timer on the frontend.
There can be a slight delay on when it registers that it needs to start the timer. It should always do it - but i can take some seconds (1-10) to take into effect. Most cases it happens right away. This is due to me using the card badges to allow for starting the timer. Badges refresh every 2 second & allows me to have the context of the card for starting the timer.

Overall I'm very happy with the result. Let's see how it plays out in the wild :) Let me know if you have any feedback on this.

Sorry for the late reply! Thank you so much for doing this. I'm going to
play around with it now. Just initial testing shows it is not triggering,
but let me play with it a bit more.
Regards,
Luke Molnar
On Sun, 13 Jun 2021 at 19:20, Dannie Hansen @.***>
wrote:

@LexGear https://github.com/LexGear I've released a beta feature that
allows for this. There is no such thing in the Trello SDK that allows me to
do this - so I've had to go through a lot of loop-holes to get it working.
You should (after clearing browser cache) be able to access new settings
for enabling this feature under your power-up settings. Please note that
this is not the 'Settings' card button shown when on a card - but the
administrators 'Power-up' settings for Activity timer. Here you'll be able
to enable the feature & choose which list should auto-start the timer.
Technical details:
When enabling it will request access to act on your behalf. This is so
that we can register a webhook that will notify a service hosted by me
whenever changes to the board occurs. Within this webhook I'm able to
detect the action when a user moves a card from list A to list B. While
there is no built-in functionality for communicating with the frontend or
setting data that i can fetch in the frontend to start the timer - i still
got it working. Worked in a Websocket that will be used by the webhook to
communicate when to start a timer on the frontend.
There can be a slight delay on when it registers that it needs to start
the timer. It should always do it - but i can take some seconds (1-10) to
take into effect. Most cases it happens right away. This is due to me using
the card badges to allow for starting the timer. Badges refresh every 2
second & allows me to have the context of the card for starting the timer.

Overall I'm very happy with the result. Let's see how it plays out in the
wild :) Let me know if you have any feedback on this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/danniehansen/activity-timer/issues/4#issuecomment-860180001,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB33PP3EUNHTFCWHD76U4ALTSRZ4HANCNFSM4PYVEN7Q
.

@LexGear You might need to re-enable the feature. If you've used 'Activity timer history' then you've likely given a more restrictive access to the power-up than which is asked on the 'auto timer' setting. However - due to restrictions with the SDK available i cannot detect how much privilege a given access has. Disabling the auto-move and enabling it again might solve this - as disabling will revoke the access & you will then be prompted on fresh when you try and enable it again.


Setup plugin

How do I setup the plugin I can't get working this.

@carlitux this project is just a POC. It provides very basic completion for React methods but JSX completion will not work as long as acorn-jsx will not support loose parser https://github.com/RReverser/acorn-jsx/issues/32
So I'm not sure that it's interesting for you.


Include boom weight estimative

WIP

@CamilaZandavalli Take a look on the changes I made. It was almost working and now it is.

For the lack of human resources, this is being closed for now.


[Accelerate] [vForce] New vForce Overlay

This PR contains a suite of overlays to the vForce transcendental and trigonometric functions on vectors of any length.
The overlays simplify the API to the existing functions and accept collections that implement _ContiguousCollection.
This PR contains a Swift-friendly version of each function in vForce, removing the requirement for the developer to separately supply the element count of the source and destination vectors.
cc: @moiseev @airspeedswift @stephentyrone

Based on our discussion on the basic scalar math functions with logGamma, sounds like sinPi would be the "less wild" option with precedent in IEEE 754.  Similarly, given the direction that it's taken, copySign would be more consistent than copysign, and I think sqrt is still preferred  over squareRoot. By that reasoning, rSqrt would be the reciprocal.
Wdyt, @stephentyrone?

Keep copysign. Switch to sinPi, cosPi, sqrt. I don't love rSqrt--I'll leave that one up to @FlexMonkey, but please choose either reciprocalSquareRoot or rsqrt.

Keep copysign. Switch to sinPi, cosPi, sqrt. I don't love rSqrt--I'll leave that one up to @FlexMonkey, but please choose either reciprocalSquareRoot or rsqrt.

Changed all the xxx(piTimes:...) to xxxPi(_:...).
Cheers.

I landed this (with some minor changes) as https://github.com/apple/swift/pull/24152. This PR can be closed out.


helper function for changing BCs

It would be nice to be easily update boundary conditions after loading up a model.
It might also be easier to navigate the model boundary conditions if the keys of the dict were the variable name string rather than the object itself, as it is currently hard to quickly manually edit BCs. I', not sure if this causes problems elsewhere during discretisation though. In any case a helper function would be useful.

Helper function could take in a variable name string, look through the variables to see what the symbol is and then find the corresponding boundary condition. This avoids needing to change the structure of boundary conditions elsewhere

Isn't it just this?
c_e = model.variables["Electrolyte concentration"]
model.boundary_conditions[c_e] = {
    "left": (pybamm.Scalar(1), "Neumann"),
    "right": (pybamm.Scalar(-1), "Neumann"),
}

Not sure this warrants a helper function?

Agreed, closing.


Error - not able to run ragapp successfully

I am on MacOS Monterey 12.7.4
Python v3.8.2
Docker v20.10.2
I have pulled the image from Docker Hub and then ran the run command, but then I get this error -
✝  ~/llama  docker pull ragapp/ragapp
Using default tag: latest
latest: Pulling from ragapp/ragapp
Digest: sha256:f70bc1a0dba52e7b9668ab1fa4e1171ae1a6ae9df6ecb559f5037a84463c04af
Status: Image is up to date for ragapp/ragapp:latest
docker.io/ragapp/ragapp:latest
 ✝  ~/llama  docker run -p 8000:8000 ragapp/ragapp
OpenBLAS blas_thread_init: pthread_create failed for thread 1 of 4: Operation not permitted
OpenBLAS blas_thread_init: RLIMIT_NPROC -1 current, -1 max
OpenBLAS blas_thread_init: pthread_create failed for thread 2 of 4: Operation not permitted
OpenBLAS blas_thread_init: RLIMIT_NPROC -1 current, -1 max
OpenBLAS blas_thread_init: pthread_create failed for thread 3 of 4: Operation not permitted
OpenBLAS blas_thread_init: RLIMIT_NPROC -1 current, -1 max
Traceback (most recent call last):
  File "/app/main.py", line 14, in <module>
    from create_llama.backend.app.settings import init_settings
  File "/app/create_llama/backend/app/settings.py", line 3, in <module>
    from llama_index.core.settings import Settings
  File "/usr/local/lib/python3.11/site-packages/llama_index/core/__init__.py", line 10, in <module>
    from llama_index.core.base.response.schema import Response
  File "/usr/local/lib/python3.11/site-packages/llama_index/core/base/response/schema.py", line 9, in <module>
    from llama_index.core.schema import NodeWithScore
  File "/usr/local/lib/python3.11/site-packages/llama_index/core/schema.py", line 15, in <module>
    from llama_index.core.utils import SAMPLE_TEXT, truncate_text
  File "/usr/local/lib/python3.11/site-packages/llama_index/core/utils.py", line 89, in <module>
    globals_helper = GlobalsHelper()
                     ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/llama_index/core/utils.py", line 45, in __init__
    import nltk
  File "/usr/local/lib/python3.11/site-packages/nltk/__init__.py", line 133, in <module>
    from nltk.collocations import *
  File "/usr/local/lib/python3.11/site-packages/nltk/collocations.py", line 36, in <module>
    from nltk.metrics import (
  File "/usr/local/lib/python3.11/site-packages/nltk/metrics/__init__.py", line 17, in <module>
    from nltk.metrics.aline import align
  File "/usr/local/lib/python3.11/site-packages/nltk/metrics/aline.py", line 41, in <module>
    import numpy as np
  File "/usr/local/lib/python3.11/site-packages/numpy/__init__.py", line 130, in <module>
    from numpy.__config__ import show as show_config
  File "/usr/local/lib/python3.11/site-packages/numpy/__config__.py", line 4, in <module>
    from numpy.core._multiarray_umath import (
  File "/usr/local/lib/python3.11/site-packages/numpy/core/__init__.py", line 24, in <module>
    from . import multiarray
  File "/usr/local/lib/python3.11/site-packages/numpy/core/multiarray.py", line 10, in <module>
    from . import overrides
  File "/usr/local/lib/python3.11/site-packages/numpy/core/overrides.py", line 8, in <module>
    from numpy.core._multiarray_umath import (
  File "<frozen importlib._bootstrap>", line 216, in _lock_unlock_module
KeyboardInterrupt

@pixelpunch here people have similar issues with docker: https://github.com/HumanSignal/label-studio/issues/3070 - can you please try the workarounds described there and post your findings here

@marcusschiesser this issue was resolved by updating Docker engine to 26.1.1

If I already have an application installed on the 8000, how do I do it on another port?

@fgonzalezlez you can change the port using the -p parameter, see https://docs.docker.com/network/#published-ports


Support CopyObject to same location for rclone

https://forum.storj.io/t/s3-sync-does-not-work/16220?u=alexey
the AWS CLI didn't preserve the modification time with Gateway-MT. It preserves in their objects though.
The interesting thing that rclone sync with s3 protocol preserves the modification time and trying to update it if this is the only a difference (it will fail, because Failed to set modification time: NotImplemented: A header you provided implies functionality that is not implemented, so you need to use --no-update-modtime).
I think the the Last-Modified (actually created at) timestamp, like the rest of the metadata, is established at the time of object creation and immutable, thereafter.  Therefore what rclone is doing is technically a call to CopyObject.  We'd been waiting on MetaInfo for this, but I'll create a ticket for the upcoming sprint to see if we can fix this particular edge case entirely in the Gateways.

Change https://review.dev.storj.io/c/storj/gateway/+/6431 mentions this issue.


How we can close the sidenav when click on the overlay?

Summary
How we can close the sidebar when click on the overlay?
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/assets/1007051/8d2dd125-df3d-43a2-a421-2ea7b4558a32
Currently, we can only close it with the x button.
https://carbon-design-system.github.io/carbon-for-ibm-dotcom/rc/carbon-web-components-v2/?path=/story/components-ui-shell--header-base-w-navigation-actions-and-side-nav
In the React version it close when you click on the overlay.
And also when you use the escape key.
https://react.carbondesignsystem.com/?path=/story/components-ui-shell-sidenav--side-nav-rail-w-header
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

@annawen1 what do you think it's the best approach to allow this? Thanks!

Closed by https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/10778


Check that the tutorials build with v0.9-dev of PennyLane

We should also update the requirements.txt file as each of the plugins are finalized

Website build
Commit: e95c9ef01e619bf67e76782d7914658a72c4e103
Circle build number: 671
Website zip: https://671-214003948-gh.circle-artifacts.com/0/tmp/qml_html.zip
Website url: https://671-214003948-gh.circle-artifacts.com/0/_build/html/index.html
Please double check the rendered website build to make sure everything is correct.


runtime assertion for c++/winrt

what is the runtime assertion call in c++/winrt headers.

Can you provide more details of what assertion you are seeing?

I mean, I want to use "runtime assertion" in my code. What is the conversion for using assert in c++/winrt code? I usually use <assert.h> or define my own assert macro. How do I use asserts in UWP applications?

<assert.h> should work just fine. We don't mandate any particular assert macro.

@kennykerr Normally the standard-library assert() function prints a message to stderr to give an idea of what assert failed. E.g. on Mac it'll print something like:
Assertion failed: (foo > 0), function myFunction, file /src/path/File.cpp, line 42.
But my understanding is that stderr doesn't exist on UWP.  Does the C++/WinRT flavor of assert.h print a message somewhere else so that we can see it?  Or does the assertion message go into a black hole if we use this standard library routine?

C++/WinRT doesn't define how assert.h works - that is the provided by the standard library. Note that typical store apps don't have a console but you can see the error information using a debugger's output window.


CLOUDSTACK-10135 ACL rules order is not maintained for ACL_OUTBOUND i…

…n VPC VR
Repro steps
1.Create a vpc with super cidr(<IP_ADDRESS>/16)
2. created a custom acl with at least 3 ACL_OUTBOUND rules with number oder like 15, 10, 20
3. Create a tier with the above ACL
4.Deploy an instance in the tier
5.In router the ACL rules wont be as per the sequence number order

LGTM, pending testing.
@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1234

Related https://issues.apache.org/jira/browse/CLOUDSTACK-10043 we are verifying

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

LGTM

cherry-picking to 4.9 and 4.10

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1254

Thanks for merging @resmo however, let's wait for tests to come back before we merge PRs. I'll kick tests on the master/baseline smoketest PR #2289


Flatten enums & parameters into extended Task type

This solution was dicussed starting here:
https://github.com/Moya/Moya/issues/1135#issuecomment-310913115
Specifically this PR does the following:

[x] Remove parameters and parameterEncoding from everywhere
[x] Extend Task with different types of request data (e.g. data & compositeEncoded)
[x] Flatten the DownloadType and UploadType enums into the Task type
[x] Use those new task cases to set url params & http body appropriately
[x] Update Tests
[x] Update Docs
[x] Write a migration guide
[x] Add Changelog entry
[x] Handle the TODO: comments (exception handling) appropriately

This solves the most apparent part of #1135 and it probably also solves #314.

          4 Warnings

:warning:
PR is classed as Work in Progress

:warning:
Any changes to library code should be reflected in the Changelog. Please consider adding a note there.

:warning:
Consider adding supporting documentation to this change. Documentation can be found in the docs directory.

:warning:
The library files were changed, but the tests remained unmodified. Consider updating or adding to the tests to match the library changes.

SwiftLint found issues
Warnings

File
Line
Reason

MoyaProvider+Internal.swift
95
TODOs should be avoided (Add exception handling here).

MoyaProvider+Internal.swift
103
TODOs should be avoided (Add exception handling here).

MoyaProvider+Internal.swift
113
TODOs should be avoided (Add exception handling here).

MoyaProvider+Internal.swift
133
TODOs should be avoided (Add exception handling here).

TargetType.swift
59
Limit vertical whitespace to a single empty line. Currently 2.

  Generated by :no_entry_sign: Danger

I have just integrated my fork into the project where I'm using the Encodable type. Here's how my target now looks:
import Foundation
import Moya

enum MyTarget {
    case createUser(CreateUserRequest)
    case signIn(SignInRequest)
}

extension MyTarget: TargetType {
    var baseURL: URL {
        return URL(string: "https://example.com/api/v1/")!
    }

    var path: String {
        switch self {
        case .createSession:
            return "user"

        case .createSessionProvision:
            return "session"
        }
    }

    var method: Moya.Method {
        return .post
    }

    var sampleData: Data {
        return Data()
    }

    var task: Task {
        switch self {
        case . createUser(let createUserRequest):
            return .request(.data(encode(createUserRequest)))

        case .signIn(let signInRequest):
            return .request(.data(encode(signInRequest)))
        }
    }

    func encode<T: Encodable>(_ encodable: T) -> Data {
        do {
            return try JSONEncoder().encode(encodable)
        } catch {
            let message = "Could not encode '\(type(of: encodable))' using JSONEncoder. Error: \(error)"
            log.error(message)
            fatalError(message)
        }
    }
}

It builds fine and I think it should work (haven't tested yet). But this is how the usage might look now. Just to have something to review. I'm not too happy about the many parentheses like in .request(.data(encode(createUserRequest))), but I can live with it until we find a better solution.

I will go ahead and say we might not want to add it to 9.0.0 release since we have many breaking changes already (and few big ones). To make transition smoother we may just hold onto this one till after the release. Meanwhile, it would be awesome if it got some attention & feedback from @Moya/contributors.

I looked this over and it seems to make sense to me.
I agree with @sunshinejr that it gets a lot more verbose at the call site... definitely not great. I'm wondering if instead of associating the new RequestDataType with the request enum case, we can extend the number of enum cases? like requestWithData, requestWithParameters etc?

@ashfurrow Sure, why not. Think that makes sense. Just rebased onto the current master and added the requested change. The task computed property example from above now looks like this:
    var task: Task {
        switch self {
        case .createUser(let createUserRequest):
            let requestData = encode(createUserRequest)
            return .requestData(requestData)

        case .signIn(let signInRequest):
            let requestData = encode(signInRequest)
            return .requestData(requestData)
        }
    }

Shall I flatten the UploadType and DownloadType enums into the Task enum as well? It would be consistent, for sure. But I'm not sure cause there's no pressing issue with them and it would require more people to change their code when updating to a newer version, so I'd understand if we would keep it as is.

Any preferences on how to deal with the exceptions thrown in places like this:
do {
    preparedRequest = try parameterEncoding.encode(preparedRequest, with: parameters)
} catch {
    // TODO: Add exception handling here
}

@ashfurrow @sunshinejr ?

I left you comments around most issues @Dschee. For flattening I agree we would need to flat upload & download types as well. I think we might do it in the same PR since naming convention in this one would be similar.
Anyhow, I like the direction that this PR has taken. Keep it up :)

Sorry for letting you wait for two weeks, I've been on vacation this entire time. Now that I'm back I've had a look onto your feedback @sunshinejr and commented on them (two of three I fixed). Also I have flattened the upload and download types into the Task enum. Unfortunately I will need more help to handle the exceptions properly (the TODOs).
Other than that, is there anything that speaks against merging this except for the TODOs on the initial Post that are still open? If not, then I would proceed implementing the TODOs so we can merge this soon.

Hey @Dschee, just a heads-up. I'll try to get to it ASAP and edit this comment. Thank you for the constant work on this one. 👍

Okay, I have now worked through my TODOs. Except for the exception handling, I think this is now finished. I've removed the [WIP] from the title cause I think it's theoretically mergeable as it is, cause I can imagine the work on the exception handling could be decided upon later and the TODO's kept in code until then, as it is right now.

Just rebased onto the current master so things are updated (and tests can pass, hopefully).

Worked through your comments again and rebased. Are you planning to add this to the current release after the alpha is out? Would be awesome to see this in the next version. :)

Thanks, @Dschee! I'd love to have it, but we are still without tests and I'm not the only one to decide such things. Would love to get some feedback on it from @Moya/contributors, since it is almost finished now.
Also, sorry that I didn't mentioned it earlier, but would you rebase it to 9.0.0-alpha.1 branch, please?

I just barely got to skim this over but will take an in depth look this weekend. Some really cool work going on here! 😃

@SD10 Just worked through your comments, looking forward for your feedback this weekend!
@sunshinejr No problem, just rebased onto 9.0.0-alpha.1. 🎉

Also, could you check CI, @Dschee, please? Seems like it is failng.

@sunshinejr I worked through your comments, should be all fixed now.
Regarding the CI: I'm running the tests locally but seems like I did not see the demo apps. :)
Those were not building and I actually saw that in one of them there was a multipart upload that also required parameters to be sent along. Since this could also happen on uploading a file, I've added two more cases: uploadFileParameters and uploadMultipartParameters.

We still need to update docs/Examples/Basic.md and possibly more in the examples section. While the examples are not pure documentation, Basic.md is a very import reference file.

@SD10 I've just rebased to master after #1181 was merged and updated the Basic example file. Note that there's one point I'm not sure about (see here) – other than that I think the file should be ready.

@SD10 I've just checked all example files and found only two which need to be updated: ArrayAsRootContainer.md and OptionalParameters.md. I've updated the latter but I can't update the first as already explained in my previous comment https://github.com/Moya/Moya/pull/1147#issuecomment-316640623. I hope this is what you were expecting!

I'm actually not sure about ArrayAsRootContainer.md but it looks like more of a specialty example, so if it wasn't updated before a release I wouldn't mind too much. My biggest concern was Basic.md considering it is our #.1 most viewed documentation file. Thanks for taking care of this!

FYI: I have just tried adding fix-its via @available lines in a reintroduced MoyaAvailability.swift file but I couldn't cover any of the cases this PR changes. Specifically my code looked as follows with the reason why it doesn't work as comments:
import Foundation

extension TargetType {
    @available(*, unavailable, message: "parameters has been removed in version 9.0.0, use new task case .requestParameters instead")
    public var parameters: [String: Any]? { fatalError() } // does not show up in a type conforming to TargetType

    @available(*, unavailable, message: "parameterEncoding has been removed in version 9.0.0, use new task case .requestParameters instead")
    public var parameterEncoding: ParameterEncoding { fatalError() } // does not show up in a type conforming to TargetType
}

extension Task {
    @available(*, unavailable, message: "upload has been removed in version 9.0.0, use new task cases .uploadFile, .uploadMultipart or .uploadCompositeMultipart instead")
    case upload // leads to an error: "Enum 'case' is not allowed outside of an enum"
}

@Dschee I think what you've listed is fine. We don't need to add unavailable attributes to specific cases in the enum. The migration guide will cover this.

Thanks @sunshinejr, I've worked through your comments and rebased onto the 9.0.0-dev branch!

Codecov Report

Merging #1147 into 9.0.0-dev will decrease coverage by 1.05%.
The diff coverage is 58.33%.

@@              Coverage Diff              @@
##           9.0.0-dev    #1147      +/-   ##
=============================================
- Coverage      79.53%   78.48%   -1.06%
=============================================
  Files             23       23
  Lines            738      739       +1
=============================================
- Hits             587      580       -7
- Misses           151      159       +8

Impacted Files
Coverage Δ

Sources/Moya/TargetType.swift
100% <ø> (ø)
:arrow_up:

Sources/Moya/MultiTarget.swift
100% <ø> (ø)
:arrow_up:

Sources/Moya/MoyaProvider+Defaults.swift
95% <100%> (-0.24%)
:arrow_down:

Sources/Moya/Endpoint.swift
66.03% <36.36%> (-27.97%)
:arrow_down:

Sources/Moya/MoyaProvider+Internal.swift
67.44% <76%> (+3.76%)
:arrow_up:

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 cd290c7...2216c2f. Read the comment docs.

Amazing work everyone, @Dschee especially! 💪

Thank you everyone for reviewing and going all the way with me. You're the best! 💪 👏 👍

Thank you for your work on this, however I'm having issues getting it to work. I looked through this thread hoping to figure it out, but unfortunately I've come up empty. Is there an example or documentation on how to get .requestData to work in my Task?

Hey @T1ASH. If I understand your question correctly, you can do it as follows:
enum GitHub {
    case zen
}

extension GitHub: TargetType {
    ...
    var task: Task {
        let data = "test data".data(using: .utf8)
        return .requestData()
    }
    ...
}

Where, of course, your data is whatever you want to send in this endpoint. This will send the data request (meaning it will replace httpBody in the URLRequest) for GitHub.zen endpoint.
Let me know if this is what you wanted or I've completely missed 😄

@sunshinejr I Edited your reply to be return .requestData(data) instead of return .requestData() :wink:

Damn it! Thanks for the great catch, though, @pedrovereza!

I have just integrated my fork into the project where I'm using the Encodable type.
Here's how my target now looks:
import Foundation
import Moya

enum MyTarget {
    case createUser(CreateUserRequest)
    case signIn(SignInRequest)
}

// MARK: - TargetType Protocol Implementation
extension MyTarget: TargetType {
    var baseURL: URL {
        return URL(string: "https://example.com/api/v1/")!
    }

    var path: String {
        switch self {
        case .createUser:
            return "user"

        case .signIn:
            return "session"
        }
    }

    var method: Moya.Method {
        return .post
    }

    var sampleData: Data {
        return Data()
    }

    var task: Task {
        switch self {
        case .createUser(let createUserRequest):
            let requestData = encode(createUserRequest)
            return .request(.data(requestData))

        case .signIn(let signInRequest):
            let requestData = encode(signInRequest)
            return .request(.data(requestData))
        }
    }
}

// MARK: - Helper Methods
extension Tm5Target {
    private func encode<T: Encodable>(_ encodable: T) -> Data {
        do {
            return try JSONEncoder().encode(encodable)
        } catch {
            fatalError("Could not encode '\(type(of: encodable))' using JSONEncoder. Error: \(error)")
        }
    }
}

It builds fine and I think it should work (haven't tested yet). But this is how the usage might look now. Just to have something to review.

How can I use the encode extension? Was it added to the library or should I simple add it myself?


Add --no-routing argument

--no-routing will skip the routing setup for tproxy and redirect routing
modes. This is for the case where you want to set up nogotofail traffic
routing in a non-standard mode with your own routing rules. It is up to
the user to properly route traffic to the socket listening on --port.

This is basically for the case where you want to do custom routing instead of ngtf's assumption that you're a box that's bridging traffic. For example I'm using some UID based rules to do some local testing and want to avoid my scripts needing to blow away the ngtf rules.


Mumbai & Rinkeby: ocean.create_data_nft() fails getting token_address from tx_receipt

To reproduce
How to reproduce:

set yourself up with the ocean.py developers flow. Note: You don't need barge going.
Have two mumbai accounts, each holding fake MATIC. In the console, make them available as envvars. That is:

export REMOTE_TEST_PRIVATE_KEY1=0x8c1..
export REMOTE_TEST_PRIVATE_KEY2=0x73d..

in console, run: pytest tests/integration/remote/test_mumbai.py::test_nonocean_tx. It should pass. This will confirm that you can indeed run simple non-Ocean transactions on Mumbai.
open tests/integration/remote/test_mumbai.py, and comment out the "@pytest.mark.skip(..)`
in console, run: pytest tests/integration/remote/test_mumbai.py::test_ocean_tx. It should fail, where it tries to create a data nft. (The first real call to Ocean.)

Traceback
data_nft = ocean.create_data_nft('NFT1', 'NFT1', alice_wallet)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/trentmc/code/ocean.py/venv/lib/python3.10/site-packages/enforce_typing/decorator.py", line 29, in wrapper
    return func(*args, **kwargs)
  File "/home/trentmc/code/ocean.py/ocean_lib/ocean/ocean.py", line 185, in create_data_nft
    address = nft_factory.get_token_address(tx_id)
  File "/home/trentmc/code/ocean.py/venv/lib/python3.10/site-packages/enforce_typing/decorator.py", line 29, in wrapper
    return func(*args, **kwargs)
  File "/home/trentmc/code/ocean.py/ocean_lib/models/data_nft_factory.py", line 444, in get_token_address
    return registered_event[0].args.newTokenAddress
IndexError: list index out of range

Background
I first encountered this issue here. I've made it easy to reproduce, as a unit test (that's currently skipped), via this work.

For reference, below is df-py's oceanutil.py::createDataNFT(). It gets a token address from the NFT-creating tx. It's short and compact, thanks to using brownie.
Key line:
data_NFT_address = tx.events["NFTCreated"]["newTokenAddress"]

Full function:
def createDataNFT(name: str, symbol: str, from_account):
    erc721_factory = ERC721Factory()
    template_index = 1
    additional_metadata_updater = ZERO_ADDRESS
    additional_erc20_deployer = factoryRouter().address
    transferable = True
    owner = from_account.address
    token_uri = "https://mystorage.com/mytoken.png"

    tx = erc721_factory.deployERC721Contract(
        name,
        symbol,
        template_index,
        additional_metadata_updater,
        additional_erc20_deployer,
        token_uri,
        transferable,
        owner,
        {"from": from_account},
    )
    data_NFT_address = tx.events["NFTCreated"]["newTokenAddress"]
    data_NFT = B.ERC721Template.at(data_NFT_address)
    return data_NFT

As another datapoint, I just published an asset into Ocean Market, on Mumbai. Free.
Tx 1: "Create Tokens & Pricing"
https://mumbai.polygonscan.com/tx/0x296da32238ee9cf7de706ef45d0e92bd1c18389ab7e5add051efa1fa1fc9238f
Tx 2: "Publish DDO"
https://mumbai.polygonscan.com//tx/0xcbe9bb08b4d92746f1305d3505858751deaba617eb5e2589824bb300865adbee
Note: I used a different wallet. 0xF5dcd..

Are you sure that https://mumbai.polygonscan.com/tx/0xa2edd4c742c67274c4fb3be64e6cf714080c17aa84b37ae607a299e65d5d707f is the tx that you are looking for ?

Mumbai Factory has another address (https://github.com/oceanprotocol/contracts/blob/main/addresses/address.json#L46)
NFTCreated  event has a different signature  (0x8125264ec1d174cb383ea0646ea1e6921ca3b0aba20370c8e18389e7c2d6a571  vs 0x4dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63 in your contract)
found

2365
LogFeeTransfer(address,address,address,uint256,uint256,uint256,uint256,uint256)
0x4dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63

I would say that you are not passing the right txid

Thanks. Maybe I shared the wrong txid in my report above. But the issue occurred independent of what I report here.
Basically, ocean.py fails on its most fundamental tx: create data nft. See traceback above. The fail doesn't happen in ganache, it does happen in Mumbai and rinkeby (the only ones I've tested so far).
Run the unit test as described in how to reproduce, you'll see.

NFTCreatedEvent has a different signature

Maybe the issue is here?

Looks like Ocean.py is not able to get the correct address for ERC721Factory:
By adding
print(nft_factory)

at https://github.com/oceanprotocol/ocean.py/blob/2a5c9fd9e626b06b3b16e4bbf82de60766a7af4c/ocean_lib/ocean/ocean.py#L172, I got this:
----------------------------- Captured stdout call -----------------------------
config filename = /tmp/pytest-of-alx/pytest-6/test_ocean_tx0/config.ini
config.network_url = 'https://rpc-mumbai.maticvigil.com'
config.address_file = '/home/alx/.ocean/ocean-contracts/artifacts/address.json'
config.block_confirmations = 0
config.metadata_cache_uri = 'https://v4.aquarius.oceanprotocol.com'
config.provider_url = 'https://v4.provider.mumbai.oceanprotocol.com'
<ocean_lib.config.Config object at 0x7f86a998fac0>
<ocean_lib.ocean.ocean.Ocean object at 0x7f86a998fa00>
alice_wallet.address = '0x8bE6c8126C4383745c25F3b3Ca76D73E3Caf8544'
bob_wallet.address = '0xD6764a9F3387B14692CC783BcF5604a23EBb779f'
Do an Ocean tx, and wait for it to complete...
ERC721Factory @ 0x8930D1F61Defb9CBD652136B4C3D93f19AC35678
0x7138aad1670502d2bce0b1894e2bb893123c4be0ee66d9052a54bdd58a301b1c
=========================== short test summary info ============================
FAILED tests/integration/remote/test_mumbai.py::test_ocean_tx - IndexError: l...
============================== 1 failed in 8.04s ===============================

so, I started to check what is with that address (0x8930D1F61Defb9CBD652136B4C3D93f19AC35678), because it's not the  [mumbai erc721factory](https://github.com/oceanprotocol/contracts/blob/main/addresses/address.json#L46
And found it in
less /home/alx/.ocean/ocean-contracts/artifacts/address.json | grep ERC721Factory

 "ERC721Factory": "0x465069D3d6Ec45CDB006ec3E22cC9E8d6f9793eF",
    "ERC721Factory": "0x7d46d74023507D30ccc2d3868129fbE4e400e40B",
    "ERC721Factory": "0xB0F8c68eF94ACB8E976b1dED6351Cc62e383d253",
    "ERC721Factory": "0x5b1E1b333B76BC81FA60cD986EA82487e4F72B8B"
    "ERC721Factory": "0x6fd867E5AEE6D62a24f97939db90C4e67A73A651",
    "ERC721Factory": "0xbFBc7A21133B4e0e54a182BE8d4337A5e036A615",
    "ERC721Factory": "0x4dD281EB67DED07E76E413Df16176D66ae69e240",
    "ERC721Factory": "0x86F2BB9F8f18B5a836b342199a3eC89F282E4018",
    "ERC721Factory": "0x1706DF1f2d93558D1d77bEd49ccdB8B88fAfC306",
    "ERC721Factory": "0xe8c6Dc39602031A152440311e364818ba25C2Bc1",
    "ERC721Factory": "0x1706DF1f2d93558D1d77bEd49ccdB8B88fAfC306"
    "ERC721Factory": "0x49E35cd2bAE043Abd9074B6e5a649a5AdEB05C33"
    "ERC721Factory": "0x8930D1F61Defb9CBD652136B4C3D93f19AC35678",

so, where is that coming from ?
"development": {
    "chainId": 8996,
    "Ocean": "0x2473f4F7bf40ed9310838edFCA6262C17A59DF64",
    "MockDAI": "0xaF6AaaA5B8D12F7d7dD4e2BE1d1B087544f585d0",
    "MockUSDC": "0x053aE1FeCdc2f391753E2Bf2AAe301E75CC0aac9",
    "OPFCommunityFeeCollector": "0x2fC1fd21cb222Dc180Ef817dE4c426fd9230b5A5",
    "startBlock": 5,
    "Router": "0x1e6d9207241DbDca82B0D9546490c97B24B1a9f6",
    "FixedPrice": "0xBb0911124E680D65358Ac46C5404D4dF01F03e80",
    "Staking": "0x98b6901cE7C9fc65dBeeC98598136593EB7b4c6C",
    "ERC20Template": {
      "1": "0x91EB42b164664cB28a09B0cF9651b404Ee105afA",
      "2": "0x9C2a015129969c98E9A5BcBEb61A5F907FF5b629"
    },
    "ERC721Template": {
      "1": "0x611f28Ef25D778aFC5a0034Aea94297e2c215a42"
    },
    "Dispenser": "0xe749E2f8482810b11B838Ae8c5eb69e54d610411",
    "ERC721Factory": "0x8930D1F61Defb9CBD652136B4C3D93f19AC35678",

so, it looks like ocean.py is unable to fetch ERC721Factory from mumbai, it always fetches the "development" addresses

So, added some debugs at https://github.com/oceanprotocol/ocean.py/blob/2a5c9fd9e626b06b3b16e4bbf82de60766a7af4c/ocean_lib/ocean/util.py#L83
 print(f"Config.address_file: {config.address_file}")
 print(f"Config.network_name: {config.network_name}")

and got:
---------------------------- Captured stdout call -----------------------------
config filename = /tmp/pytest-of-alx/pytest-7/test_ocean_tx0/config.ini
config.network_url = 'https://rpc-mumbai.maticvigil.com'
config.address_file = '/home/alx/.ocean/ocean-contracts/artifacts/address.json'
config.block_confirmations = 0
config.metadata_cache_uri = 'https://v4.aquarius.oceanprotocol.com'
config.provider_url = 'https://v4.provider.mumbai.oceanprotocol.com'
<ocean_lib.config.Config object at 0x7f34d8b92ac0>
<ocean_lib.ocean.ocean.Ocean object at 0x7f34d8b92a00>
alice_wallet.address = '0x8bE6c8126C4383745c25F3b3Ca76D73E3Caf8544'
bob_wallet.address = '0xD6764a9F3387B14692CC783BcF5604a23EBb779f'
Do an Ocean tx, and wait for it to complete...
Config.address_file: /home/alx/.ocean/ocean-contracts/artifacts/address.json
Config.network_name: ganache
=========================== short test summary info ============================
FAILED tests/integration/remote/test_mumbai.py::test_ocean_tx - UnboundLocalE...
============================== 1 failed in 1.25s ===============================

so, you need one fix:   Add network_name to config like
# Create conf file
    conf_file = tmp_path / "config.ini"
    conf_file.write_text(
        """
[eth-network]
network = https://rpc-mumbai.maticvigil.com
network_name = mumbai
address.file = ~/.ocean/ocean-contracts/artifacts/address.json
block_confirmations = 0

[resources]
metadata_cache_uri = https://v4.aquarius.oceanprotocol.com
provider.url = https://v4.provider.mumbai.oceanprotocol.com
"""
    )

and it works:
(ocean.py) alx@ubuntu:/ocean/ocean.py$ pytest tests/integration/remote/test_mumbai.py::test_ocean_tx
============================= test session starts ==============================
platform linux -- Python 3.8.10, pytest-7.1.1, pluggy-1.0.0
rootdir: /ocean/ocean.py, configfile: pytest.ini
plugins: env-0.6.2, web3-5.28.0
collected 1 item

tests/integration/remote/test_mumbai.py .                                [100%]

============================== 1 passed in 11.03s ==============================
(ocean.py) alx@ubuntu:/ocean/ocean.py$

This needs to be changed, there is no need to specify network_name when you already have the RPC connection.
The flow should be:

put network_url in config
fetch chainID from that connection ( https://web3js.readthedocs.io/en/v1.2.4/web3-eth.html#getchainid)
fetch corresponding addresses  (each deployment has a field called chainId)

@alexcos20 , thank you very much!  🙏🙏🙏
I will follow up with this issue, and the new one that you created.

so, you need one fix:
Add network_name to config at https://github.com/oceanprotocol/ocean.py/blob/main/tests/integration/remote/test_mumbai.py#L99 , like
..
network_name = mumbai

This worked perfectly on my local machine. :100:
Alas, it still has the same failure on CI tests.

Here's the PR. Here's the failing test.
My guess is that it's still got some barge-related envvars set. E.g. envvar OCEAN_NETWORK_U
My guess is that it's still got some barge-related envvars set. E.g. envvar OCEAN_NETWORK_URRL, maybe ADDRESS_FILE?
A solution: set up a different Github Action just for this test, and any future remote tests. In that action, ensure barge isn't going, and if needed, unset envvars
If that doesn't work, I can do #927 and #931 - each fixes a specific Config issue, then revisit this.


Add tests, fix formating in config, add deserializer for sections, use DurationParse from commons and add example Timer in example plugin

Co-authored-by: Rollczi<EMAIL_ADDRESS>

Please test random configurations in plugin


Theme element in highchart API

Since Highchart 3.0, a theme element can be added on some elements like navigation.exportButtons.
This element is not mapped in java classes.
HighChart documentation :
theme: Object
Since 3.0
A configuration object for the button theme. The object accepts SVG properties like stroke-width, stroke and fill. Tri-state button styles are supported by the states.hover and states.select objects.

integrated pull request into current version


Fix pvc alerts rhods 1.3

Note: this change will break the alert tests for RHODS 1.2.0. I'll fix that once we have the Is RHODS Version Greater Or Equal Than keyword introduced in PR #125

It's being tested here now: https://opendatascience-jenkins-csb-rhods.apps.ocp-c1.prod.psi.redhat.com/job/rhods-ci-pr-test/219/

Tested successfully here: https://opendatascience-jenkins-csb-rhods.apps.ocp-c1.prod.psi.redhat.com/job/rhods-ci-pr-test/226/console
All monitoring tests PASS. 11 other tests failed for unrelated reasons

It's still failing in certain situations so I prefer it's not merged yet

Closing this PR in favour of #140  & this change in the PVC testing notebooks (now they are independent of PVC size): https://github.com/redhat-rhods-qe/ods-ci-notebooks-main/commit/fcdb495191fa135ae3001a02eb23f651483bb585


Monorepo Support Proposal/Discussion 🤔 💡 💬

Greenkeeper Monorepo Support
This issue outlines our proposed approach for making Greenkeeper work with multiple package.json files. Something otherwise known as a “Monorepo”. Monorepos come in different variants that we’ll explain further below. Today, Greenkeeper only supports updating a single package.json that’s at the root of a repository.
As a general mission statement: We want Greenkeeper to work with repositories that have one or more package.json files in subdirectories.
For example, a project could combine a frontend and a backend component and only the frontend has a package.json file:
/project/
/project/backend/
/project/frontend/package.json

In the above case the backend might be written in Ruby and as such has no package.json file.
Alternatively:
/project/
/project/backend/package.json
/project/frontend/package.json

In the above case, the backend is written in Node.js and also has a package.json file, but they are independent, e.g. updates to dependencies in one package.json have no effect on the other.
See the “Scenarios” section further down for other examples.
Limitations
There are two aspects to handling monorepos:

Handling dependency updates where the target repository is a monorepo.
Handling dependency updates where the source is a monorepo, where different, dependent packages are released at once, and targets need to update them in one go. (Babel and PouchDB are examples.

This issue only covers the first case and we’ll cover the second case separately.
Features

Greenkeeper can find all package.json files in a repository.
The combined package information from all package.json files is stored in a repository document in the Greenkeeper database.
By default there will be one pull request per dependency (affecting multiple package.json files).
package.json files can be grouped by the user to receive a pull request per dependency per group.

Greenkeeper configuration file
There will be a greenkeeper.json file that will allow the user to define named groups of package.json files that should be updated together. It will also allow ignoring dependency updates of certain dependencies per group. This file is the single source of truth for how Greenkeeper handles the repo, it will make no assumptions based on the other files in the repo. If this file is not present in the project root, Greenkeeper behaves as before, handling a single  package.json in the project root, if present. No additional config is needed to run Greenkeeper in “single package.json mode”.
⚠ Note: for now, we will refer to this config file as greenkeeper.json, but we might change that name.
This will look something like this:
{
  "groups": {
    "frontend": {
      "packages": [
        "package.json",
        "apps/frontend/react-thing/package.json",
        "apps/frontend/our-own-webpack-fork/package.json"
      ]
    },
    "backend": {
      "ignore": [
        "lodash"
      ],
      "packages": [
        "apps/backend/hapiserver/package.json"
      ]
    }
  }
}

On install, if Greenkeeper finds more than one package.json file, it will generate a default greenkeeper.json with the paths to all of them. Users can then edit this file to their liking, grouping package.json files, adding ignored dependencies etc.
{
  "groups": {
    "default": {
      "packages": [
        "package.json",
        "apps/frontend/react-thing/package.json",
        "apps/frontend/our-own-webpack-fork/package.json",
        "apps/backend/hapiserver/package.json"
      ]
    }
  }
}

Current Behaviour
Currently Greenkeeper only looks for one package.json file in the root directory.
From this package.json  Greenkeeper extracts the package information and stores those in a repository document in our database. The information looks similar to this:
"packages": {
   "package.json": {
    "name": "Package Name",
    "dependencies": {
     "async": "^2.5.0",
     "chalk": "^2.1.0",
     "fs-walk": "0.0.1",
     "request": "^2.83.0",
    },
    "devDependencies": {
     "hapi": "^16.6.2",
     "mock-fs": "^4.4.1",
     "simple-mock": "^0.8.0",
     "standard": "^10.0.3",
     "tap": "^11.0.0"
    },
    "author": "Me"
   }
  }

New Repository Scenarios

Frontend and Backend are located in subfolders within the same repo, e.g. a typical Rails backend with Ember.js frontend setup
Lerna

my-lerna-repo/
  package.json
  packages/
    package-1/
      package.json
    package-2/
      package.json

‚alle‘-style monorepo configuration e.g. PouchDB (Greenkeeper already works with this kind of Monorepo configuration)

Challenges/Workflow
Installation

Greenkeeper searches the file tree for package.json files.
It creates a PR with all the updated dependencies, the greenkeeper README Badge and a new greenkeeper.json in the root directory containing the paths of all found package.json files, if it doesn’t already exist. The PR will contain information about how to customize this file.
The user may commit their desired customisation of the greenkeeper.json and merge the PR
4. After the merge Greenkeeper create its initial branch and updates all dependencies in all package.json files.

What happens to existing repositories?
Existing repositories will continue to work as before. You don’t need to add the greenkeeper.json if you only have a single package.json file in the project root.
If the greenkeeper.json is added to an existing repository, Greenkeeper will create a new initial pull request per group so all package.json files are up-to-date to have a common starting point.
What happens if a package.json is added/removed/renamed/moved in the repo?

Event
Description

Added
nothing, if it is not also added the the greenkeeper.json. The greenkeeper.json is the source of truth, we only act on what is configured there

Removed
it will be removed from our copy of greenkeeper.json

Renamed
doesn’t happen: they’re always called package.json. If the folder is renamed, it’s a move:

Moved
Since this probably reaches us in the form of a delete plus an add, we can’t know what was moved, and should treat this as exactly what it is: a delete and an add (https://developer.github.com/v3/activity/events/types/#pushevent)

What happens if a package.json is added/removed/renamed/moved in the greenkeeper.json or a group changes in any way?

Event
Description

Added
we run a sub-initial PR for the group it was added to

Removed
it just works™ because we treat the greenkeeper.json as the single source of truth. Greenkeeper will also delete all existing greenkeeper-branches of that group (this will also close open PRs)

Renamed/Path of a package.json edited
we can’t detect moves, only deletes and adds, so we treat this as “added”.

Moved to another group
greenkeeper triggers a sub-initial PR for the group it was added to

What happens if a new greenkeeper.json appears, or a new group appears in it?
Greenkeeper is already enabled, so we just need to get each group up to current, so we need a sub-initial PR for each group that has at least one out-of-date dep. Otherwise somehow inform user that we’ve noticed and will handle their monorepo from now on.
What happens if a greenkeeper.json is removed, moved from root or renamed?
Will now only handle top-level package.json, if it exists
Won’t notify user
When a group disappears from the greenkeeper.json
We close all open PRs that refer to the now non-existent group, unless that group only contained a root package.json which still exists, in that case the open PRs still have value
How does a dependency update work?

All grouped package.json files will be changed in the same commit.
The Greenkeeper dependency branch name will be changed from greenkeeper/cosmiconfig-4.0.0 to greenkeeper/[group]/cosmiconfig-4.0.0, where [group] might be the group name backend from the example configuration above.
Depending on the status of the CI build that is running on the Greenkeeper branch, the usual Greenkeeper processes happen (issues, PRs, or silently deleting branches that are no longer needed).

What is the new Initial Subgroup PR?
Every time a new group appears, or a new package.json file appears in a group, we need to get all the dependencies of all of the files in that group up to date. This is done via a new type of initial PR that only updates  package.json  files in a single group.
What happens if the ranges for a dependency in a group have become inconsistent?
This shouldn’t happen (this is why we have the initial PRs), but since users can freely edit their  package.json files, it’s still a possibility. If, for example, one or more updates are out of range, eg. two are “^1.1.0” and one is “1.0.5”, we send an “out of range” PR to get all dependencies back up to current.
When things go wrong

If Greenkeeper can’t find a package.json in the defined path, it will open the PR with the remaining files (if any) and add a note to the PR. If there are no findable files left, but there are files listed in the group, we open an issue to notify the users. This is a very likely error scenario: a folder name is changed, but paths in group in greenkeeper.json are not updated
If the greenkeeper.json is not in a valid format, Greenkeeper will also open an issue.

If repeated errors of the same type happen:
⚠ TBD: Before we open an issue, if an issue with the same name exists (“Greenkeeper has encountered a problem with your greenkeeper.json”, maybe something more specific than that), do we update the initial comment? Definitely not add a comment. This needs more thought. What if we can’t find a file 120 times? We’d like to let the user know how to fix that, but not 120 times…
New Workflow Charts

Possible Implementation
➡  💬  WIP branch
edited (14.March 2018): updated example config files, renamed .greenkeeperrc to greenkeeper.json, removed the two-step initial PR process, added some words for clarification

This has been shipped! 🚢


Villager Tabs Show If They Have No Profession (Might Show If They're A Nitwit Too) And They Also Seem Show Through Blocks

Yeah that is part of the reason the update with Entity support is marked as a beta on CurseForge and Modrinth (and pre-release on GitHub).
There currently isn't any code to manage player view for Entities (so even with the config option switched off, you can still access Entity tabs behind you and through walls.
There also isn't anything filtering tabs - I'm not using coordinates like I do for block tabs (since entities move and that would make the tab view flicker and Screens close) so there is only one tab shown per entity type (standing next to five chest minecarts would only show one), and invalid tabs are also shown (like Nitwits or Allays, anything that is instanceof Inventory, InventoryOwner, or InventoryChangedListener).
This will all be fixed in the future, but I am currently on a bit of a modding hiatus - I have a ton of college work that I need to get done, and also I'm still suffering from a recent head injury which makes it a bit hard to stare at the computer screen.


Rename default debugging configuration

Environment data
VS Code version:  1.18.1
Python Extension version:  0.9 release candidate
Python Version:   Python 3.6.3
OS and version:    Windows 10
Actual behavior
Start debugging fails with output in the debug console:
  File "c:\dev\productionready-django-api\.vscode\launch.json", line 2
    // Use IntelliSense to learn about possible attributes.
     ^
SyntaxError: invalid syntax

After changing to python: django in the debug dropdown debugging works, and continues working even after switching back to "Python" configuration.
Expected  behavior
Debugging works
Steps to reproduce:

Set up the sample app environment on windows:

git clone github.com/gothinkster/productionready-django-api.git
py -m venv env
env\scripts\activate.bat
pip install -r requirements.txt

Click start debugging, launch.json file is generated
Click start debugging again to start debugging

Logs
Output from Python output panel

Output from Console window (Help->Developer Tools menu)

Looks like you had the launch.json file opened when you clicked the debug icon.
When clicking the debug icon and using the Python debug configuration, the debugger will try to launch the currently active file in Python. I.e. it will try to run launch.json in Python, and that doesnt work, hence the error.
Please open a pythin file when debugging using the Python  configuration.
If this isn't intuitive let's discuss that separately

Let me know how this goes

Yes, this was the issue... caused by the fact that the .json file is created and it gets the main focus. I do think it's unintuitive, and could potentially confuse new first time users.
When you click start debugging it might make sense to prompt you to pick your debugging configuration, and not pop up the .json configuration by default. It might also make sense to name the "Python" configuration to be "Current Python File", so it's obvious that clicking play will attempt to debug whatever file the user has open.

Short of the file/configuration rename I believe everything else is a VS Code issue.

When you click start debugging it might make sense to prompt you to pick your debugging configuration, and not pop up the .json configuration by default

Unfortunately this is out of our hands.
What I could do is, check if the current file (defined in the setting program) is launch.json if is so, then display a specific error message for this. I.e. you'd end up with something like this:
I could also is check if file extension is .py, but this woudl be wrong.  as in the case of debugging flask apps, the setting program points to an executable.

Further to this, I believe we could improve the UX by displaying  a file picker (using new VS Code API) or similar UI based a condition (such as active file is launch.json or active file is in the  workspace but not a python file).

Chatted with Don, we agreed changing the default configuration name to "Python: Current File" would help here.

The change was no correct, we need to make changes to the localization files as well (at least for english).


ci(c): Enable Meson tests in CI

There seems to be something strange with how the ADBC tests are structured and gtest is getting used with Meson.
There was an upstream PR that had the same issue shown in CI but with a supposedly different cause:
https://github.com/google/googletest/pull/4536
Haven't been able to boil this down to an MRE yet

OK so appears that the approach I had before to make shared libraries for the validation / util tests was not correct. Compiling with -Db_sanitize=address reveled an ODR violation:
==370804==ERROR: AddressSanitizer: odr-violation (0x5622170fde40):
  [1] size=8 'kElidedFramesMarker' ../subprojects/googletest-1.14.0/googletest/src/gtest.cc:4968:19
  [2] size=8 'kElidedFramesMarker' ../subprojects/googletest-1.14.0/googletest/src/gtest.cc:4968:19
These globals were registered at these points:
  [1]:
    #0 0x7f446d837928 in __asan_register_globals ../../../../src/libsanitizer/asan/asan_globals.cpp:341
    #1 0x5622170123af in _sub_I_00099_1 (/home/willayd/clones/arrow-adbc/c/builddir/driver/sqlite/adbc-driver-sqlite-test+0x1313af)
    #2 0x7f446ca29eba in call_init ../csu/libc-start.c:145
    #3 0x7f446ca29eba in __libc_start_main_impl ../csu/libc-start.c:379

  [2]:
    #0 0x7f446d837928 in __asan_register_globals ../../../../src/libsanitizer/asan/asan_globals.cpp:341
    #1 0x7f446d3aa898 in _sub_I_00099_1 (/home/willayd/clones/arrow-adbc/c/builddir/validation/libadbc_validation_util.so+0x1aa898)
    #2 0x7f446e2a747d in call_init elf/dl-init.c:70

==370804==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'kElidedFramesMarker' at ../subprojects/googletest-1.14.0/googletest/src/gtest.cc:4968:19
==370804==ABORTING

So the new configuration ends up making the adbc_validation_util library always STATIC (CMake does this as well) and instead of building an adbc_validation_lib, makes declares that as a dependency (also roughly equivalent to the OBJECT library the CMake configuration creates for that)


Expose sentry dsn through environment variable for dashboard

Summary
Expose sentry dsn through environment variable for dashboard
Motivation
this will help us in configuring dsn through environment variable, currently its hardcoded in our code.
Proposal
expose SENTRY_DSN environment varibale like SENTRY_ENV and SENTRY_ENABLED flags

Merged


Fix minor typo in window-features-and-custom-features

Minor typo in RollingFeatures section. Changed "is" to "in".

Thanks, @g-rubio, now the user guide is closer to being correct!
The changes will appear the next time the documentation is rendered.


List examples from metamath 100

List some examples proven from the "100 Theorems List" on page 29.

"By the way, I think the order of the top systems should be changed to "HOL
Light, Isabelle, Metamath, Coq and Mizar" ;-)"

Done


[Bug]: AssetExchange Should Support Crypto Exchanges

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Crypto exchanges not supported in AssetExchange
Expected Behavior
No response
SDK Version I encountered this issue in
0.2.0
Steps To Reproduce
data = GetAssetsRequest(asset_class=AssetClass.CRYPTO)

print(broker_client.get_all_assets(data))

throws
value is not a valid enumeration member; permitted: 'AMEX', 'ARCA', 'BATS', 'NYSE', 'NASDAQ', 'NYSEARCA'

### Filled out the Steps to Reproduce section?

- [X] I have entered valid steps to reproduce my issue or have attached a minimally reproducible case in code that shows my issue happening; and understand that without this my issue will be flagged as invalid and closed after 30 days.

### Anything else?

_No response_

Crypto assets will not specify exchange


Update to latest deps

A few tracing changes, and a few from the change in the representation
of reward accounts in local state queries.

Pending final update for https://github.com/input-output-hk/cardano-ledger-specs/pull/1703

bors merge


ssh transport for podman push

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description

For the deployment of images from the development environment to a VPS we use an intermediate private registry: this works well, and is very suitable in most stable scenarios. However, for smaller cases, it also comes with disadvantages:

one must maintain a registry server;
users of the registry must be coordinated with deployments;
storage space is essentially duplicated: the same image is stored both in the registry, and in the deployment environment.

The only alternative I know of (I did perform extensive research, and even studied the docs of skopeo) is to use a load/save pair, for example:
podman save myimage | ssh user@server 'podman load'

However, this is not efficient, because all layers are transmitted in this case, even the ones which are already available on the receiving side. So I was wondering if there would be general interest in a "ssh transport" inspired by rsync:
# Example from rsync manpage
rsync -av -e "ssh -l ssh-user" rsync-user@host::module /dest

whereby with skopeo/podman one would maybe do
podman push myimage ssh:user@server
# or
podman push myimage ssh:myimage -e "-l ssh-user -i /path/to/key"

The API would obvioulsy need to be better designed by the experts: I am sure there is room for improvement; for example there would be the opportunity to use different transports via ssh:
skopeo copy containers-storage:myimage ssh-containers-storage:user@server
# or
skopeo copy containers-storage:myimage ssh-docker:user@server
# or
skopeo copy containers-storage:myimage docker:myimage -e "-l ssh-user -i /path/to/key"

During my research, I even attempted a crude prototype which roughly works as follows:

podman save to a local file;
collect the layers' sha256 from the manifest;
check which layers are present on the receiving end;
remove the unnecessary layers from the local tarball;
send the tarball to podman load via ssh.

The last step works fine, because apparently podman load first checks the manifest for the layers it needs, and ignores the ones which are already present. It therefore does not matter if these are missing in the tarball.
Obviously the downside with this approach is that, during step 1, we must save to local storage: this is slow and disk-expensive if the images are large.

@mtrmac @giuseppe @vrothberg @baude WDYT?
I kind of like the idea, although I would figure you need a matching program at the destination to  setup the protocol.
We might be able to do something with a podman service or podman varlink to receive the incoming payload and store it in the outgoing storage type.

@rhatdan Glad to hear that the idea looks interesting.
Regarding your comments, and still following the inspiration of rsync, I do not think that a "service" (in the sense of a daemon) is needed: however, yes, the "receiver" will need to implement some kind of network protocol to exchange informations at the different stages of the transfer (i.e. "peek available layers"). rsync implements this in the same executable, which is spawned via ssh by the sender.

This does seem like something that could be built in principle.
What exactly is the situation in which this would be useful?

Deploying a build to a remote data center
When there a registry neither at the build site nor at the deployment site (otherwise, pushes/pulls can use that registry)
When there is only ever a single deployment of a particular image (otherwise a registry to preserve the built image if the build computer goes down, or to minimize the network overhead of copying the image to the remote site, could be worth it)

To me, this seems rather a rare corner case to maintain and keep stable within the Podman project itself; we should not actively sabotage that, of course, but looking at the history of API.md, we already have a pretty hard time keeping the API stable, and taking on this pretty rare case as a stable API to maintain seems a stretch to me.

If this were to happen, one way would be to directly deal with the c/storage objects.
If this were to be more generic (ssh-docker:),

I really question the need for that; set up an actual VPN at the IP layer and the need to special-case every single application ever at the application layer goes away.
Anyway, if it had to exist, I’d probably suggest having a remote source instead of a remote destination, because c/image/types.ImageDestination is so much more complex, and so much less stable, than c/image/types.ImageSource. Turning a c/image/types.ImageSource into a RPC should be possible, the main gotcha is that GetBlob returns a reader stream that can be read after that Go function returns.

If this appears to too difficult to implement, or undesirable for some reason, I believe that it would be sufficient to have a way to export only some layers from an image. The network protocol can then be built around that, simply by using ssh directly.
Something like: podman save --only-layers ... or podman save --skip-layers ... would be ideal. I noticed that skopeo layers offered a similar functionality, but the command is being deprecated: however, I do not see an equivalent functionality in skopeo copy.

… and how would the caller figure out which layers are present and the destination and which ones need to be pulled over? That still requires some kind of image-structure-aware protocol, hence the suggestion to turn ImageSource in to a RPC protocol.
I guess that “image-structure-aware-protocol” could instead be a complex shell script using ssh and parsing TTY output of various inspect commands… Sure, that would benefit from a save-set-of-layers Go command as an intermediate step (and, as you say, looking at skopeo layers, one can certainly be written); it’s not obvious to me that the Go/shell code should be split at exactly that place, though.

I guess that “image-structure-aware-protocol” could instead be a complex shell script using ssh and parsing TTY output of various inspect commands...

That was indeed the idea. I already played with a prototype and it is only 20 lines of code: basically, collect the layers via ssh and pass them through cmp. Of course the script is very specific to our use case, and most importantly would break if the manifest format changes: the best solution would therefore be an RPC implementation like you suggest.
It remains to be understood whether there is enough interest for this feature, and whether it would make the API too complicated: in this regard, would it be better to implement it as a dedicated skopeo command (e.g. skopeo send)?

@matpen are you interested in working on this?

I would love to help! My only problem is that I never wrote one single line of go in my life... but I am quite experienced with other languages.
Maybe I can write an external prototype with some other technology, and as soon as that works and aligns with the project's general architecture, I can have a friend help me with the actual integration. Would that be acceptable?

Sure.

This issue should be moved over to github.com:containers/image  Since it will never be done in Podman without showing up there first.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Codecov Report

Merging #196 (64efddc) into main (2974dfe) will increase coverage by 9.55%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #196      +/-   ##
==========================================
+ Coverage   83.33%   92.88%   +9.55%
==========================================
  Files           2        2
  Lines         126      478     +352
  Branches       31       39       +8
==========================================
+ Hits          105      444     +339
- Misses         21       34      +13

Impacted Files
Coverage Δ

example/src/main.ts
95.65% <100.00%> (+7.19%)
:arrow_up:

src/index.ts
91.76% <100.00%> (+9.76%)
:arrow_up:

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 8df6035...64efddc. Read the comment docs.


Fix Image block field to wrap the entire image across left and right alignments.

Fixes #5922 for the image field container to wrap the entire image in right and left alignment.
For full-width alignment, I think it's another issue itself. Disregard the field to wrap the entire image because the image is going outside the whole container and above the sidebar on the right if you try to drag its block. So, I do not think this PR should fix it, because it is not related to the failure of the wrapper to fill the whole image. Let me know if I should fix it in this PR, and I will do so. Also, please clarify how the full width should be, because I do not see any difference between it and when the image is aligned center with size=large, as both take size=100vw in getImageBlockSizes function.

Please review this pull request. @stevepiercy ,@polyester, could you please take a look and provide your feedback? Thank you!

@MostafaMagdyy the lint CI check fails. You must fix it before review will happen. See https://6.docs.plone.org/volto/contributing/linting.html

@stevepiercy Thank you for your feedback. I have addressed all your comments and fixed all the issues. Additionally, here are the screenshots displaying the new behavior for left and right alignment.

@MostafaMagdyy you don't fully understand why the select area with the border around the image is as small as it is. It's because of a float property. That is useful when you want to have text to the right or left of your image. Here is a demo on the current feature in action:
and how it would function with your changes:
You need some css that will affect the editing selected area alongside extra code to have the text float to the left or right.

Thank you for your feedback.
Now i understand the importance of it and i will try to make the same behaviour as it was.

It looks like this PR did not solve the problem in a way that supported floating images next to text, and has been abandoned, so I will close it.