*.twigc files

Hi @okdana,
Thank you for twigc and the work behind it, great tool.
I wanted to ask a philosophical question relating to how twigc applies the UNIX design philosophy: currently stdin is assumed to be a template while the data is passed via various options. Wouldn't it make sense for it to be the other way around?
UNIX commands are very composable because they manipulate input data, apply a transformation, and output the transformed data.
If stdin is the raw input data, and the twig template is just a parameter then you are taking data, applying a (twig) transformation, and outputting the transformed data (ex.: html).
jq '.|transform' data.json | twigc -j -t template.twig | tidy > transformed_data.html

# in this case -j would be a flag telling twigc how to interpret STDIN rather than being the value itself

WDYT?

Strongly correlated with the above would be the following usecase:
Assuming we have an executable file with a twigc shebang (hello_world.twigc):
#!/usr/bin/twigc -j
Hello, {{ name }}!

We can the invoke this behavior easily via:
echo '{"name": "world"}' | ./hello_world.twigc

Thanks for the comments!
Firstly, maybe you already knew, but just to be clear, you can do this in your case:
jq '.|transform' data.json | twigc -j- template.twig | tidy > transformed_data.html

(-j- is basically a short-hand for -j /dev/stdin, which makes twigc expect the JSON data instead of the template on stdin. Using the hyphen that way is a convention that many other UNIX tools also use.)
As far as how standard input is handled in general, i'm pretty sure my thinking was based on two things:

You always need a template, but you don't necessarily use variables in it — the variable data is optional, hence it's provided via the options.

Most other UNIX software takes a document to work with on stdin. For example, php itself takes code (which can act as a template) that way, and by default grep takes data to be searched (not patterns to search for) that way. grep does have the -f option to take search patterns from a file, so you can do like grep -f- file_to_search.txt < patterns.txt... which is equivalent to the twigc -j- command i gave above. jq works basically the same as grep, i guess — the filter string is like the search pattern and the JSON file (or stdin) is like the file to search. Do you feel that's not analogous, or can you think of a counter-example?

One annoying issue with the 'overloading' approach i took with -j is that it's inconsistent with how -p and --query work, and i don't think it's as easily generalisable to other input formats i could add in the future, like YAML or TOML. Though maybe it doesn't need to be, idk.
As far as the 'shebang' thing, you can do that now with -j-, though it will leave that first line in the output. I'm not sure if making Twig templates executable is something that a lot of people would want to do, though.

Hi,
Yes, I made jq + twigc work in the command line with twigc -j - works like a charm.
The point I got stumped at is when trying to create an executable *.twigc file with #!/usr/bin/twigc -j because twigc -j - doesn't work but apparently your example with twigc -j- does work (10x).
Executable templates are a nice way to decouple views from data and even from the rendering engine. You could have an arbitrary number of different templating engines, all you know is that you pipe data into it and transformed data comes out.
You could build a static site generator with just json + jq + twigc + make (or yaml + yq if you swing that way).

I read somewhere about historical UNIX underpinnings (possibly here or here) which made all commands default to reading stdin as their main (and most of the time only) source of data.
For example cat wasn't initially able to take a filename as the first argument. You would invoke it with cat < inputfile > outputfile and since cat would default to reading from stdin and writing to stdout the filename processing component resided entirely in sh.
Later on they added features and gained arguments and options such as -f to specify the input file. But in order to inspect their original design I wouldn't check to see if they have -f or not, I'd check to see what they expect to receive in stdin.

grep takes data into stdin and the patterns are via arguments
php takes data into stdin the code is via arguments
jq / yq / q all take data into stdin and their transformations come via arguments
column / awk / sed / gz / sort / uniq all  take data into stdin and they allow options

Since you solved my issue with -j- I'm covered, thank you.
Nice talk!

The point I got stumped at is when trying to create an executable *.twigc file with #!/usr/bin/twigc -j because twigc -j - doesn't work but apparently your example with twigc -j- does work (10x).

It doesn't work with -j - (with space) because most systems only support one argument in interpreter directives. So #!/usr/bin/twigc -j - is interpreted as ['/usr/bin/twigc', '-j -']. That's just a limitation of interpreter directives, unfortunately. Some implementations of the env command, like FreeBSD's, have a special option to handle splitting the argument up externally, so you could do like #!/usr/bin/env -S twigc -j - and then it would work... but that's not portable.
If executable templates are a desirable feature, we could maybe add an option to strip the first line of the 'entry' file if it starts with #!. So you could do like #!/usr/bin/twigc -xj- or something. Feel free to make a feature request for that if you want


Fix typo of EventState.initialize, and 'initialize' in a comment

Fixes #9909
Also found a comment with the same typo so I just went ahead and fixed that as well.

Oops, missed the line about adding info in what's new! Since this is public API it should be added under Breaking Changes, right?

Correct :)

If we want to keep back-compat, you can actually leave public initalize and proxy it to the actual function.


[WIP] push_to_pulp: filter out uploaded layers if possible

Coverage decreased (-6.2%) to 81.224% when pulling de5c610069f9b595e5a488b4246805ca12446ff5 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.3%) to 81.152% when pulling 492379e93bdac73fb116f5d65e99d7a432e67ae6 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-0.1%) to 87.326% when pulling 3fcf752db55f38bdbcbd078a875a6707222964c0 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

The way we'd need to implement this properly is to:

Run the compress plugin after the pulp_push plugin
In pulp_push, create a new tarball that omits the unnecessary layers, compress it (gzip), and upload that instead
Then copy all the layers into the repo and apply tags

Since the running order for plugins is set by osbs-client, we should handle compress being run before pulp_push as well as after. In that case, we'll need to uncompress the tarball in order to create a new smaller one.

Coverage decreased (-0.5%) to 86.971% when pulling 65f01159ac816854191b25dc52e53251a3848912 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.723% when pulling 871075e68399943e60307e06d715ac7c8b82501f on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-1.1%) to 86.34% when pulling e2e465c007f9fbf90c89f977268d5d51341a39a0 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-0.5%) to 86.939% when pulling e6504d66495e2e6281cfc02c9855b3be63d007c1 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-0.5%) to 86.99% when pulling 65c521f7dd64593c4e3220ae0bab1587df139cbe on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-0.5%) to 86.99% when pulling c7a7a0428adf0ea04053d3e2a0fe59b6b77b9a02 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.794% when pulling aed9669edab3a0482e859c58be1ade439193f874 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.77% when pulling 5acfcc41e7943e8d7143d438ae313be5725666bd on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.77% when pulling 357a2aef0648a26b4688444f26ff0e7c6c6aaec2 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.77% when pulling b912ea2bd3e4f284451cb042663a46451720e3eb on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.77% when pulling e57a5b2c65abd73eb336cc540362541d9bf46533 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.77% when pulling bdc9d67f3fb3cebbfd68e44f9fa7bec10ec70f4b on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.7%) to 80.747% when pulling 21353ed7d64e7ff5f8aaa809750501e179af3649 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.6%) to 80.842% when pulling 649827ccdfcdc06407847e28d3cf952f9012e5ab on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-6.6%) to 80.842% when pulling 52e8a681d68b4eab2e8531ea0831683e52c21998 on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-0.7%) to 86.794% when pulling 5bf8b4a7ea9c18fb692b6642883a5c61e16ddb3d on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage decreased (-0.3%) to 87.118% when pulling 604454e455fcd8acb6be11d639696d3a1140bbcf on vrutkovs:pulp_layer_filter into 59a4ca57f31b2fcffd5d9e323583c91103dec417 on projectatomic:master.

Coverage increased (+5.4%) to 86.828% when pulling db85b7d4d49b5e8cfb5778414b191e0ffa0d393f on vrutkovs:pulp_layer_filter into 64efa5e25a6097f0219cc65d16dc9d231d79633b on projectatomic:master.

LGTM, merged.


Describe how the risk model selected effects leverage

In the market creation tutorial:
How might we describe how the risk model selected effects leverage?
During the market creation incentive, participants were asking:

Can we limit the amount of leverage possible?
Does the choice of parameters of the risk model affect the leverage ratio chosen?. I don’t understand the risk model very well.
How do I check leverage level?
What is the maximum leverage for this market looking at the risk model?

This is pretty complex I believe....basically some combination of these equals max leverage.
logNormal: {
tau: 0.0001140771161,
riskAversionParameter: 0.01,
params: {
mu: 0,
r: 0.016,
sigma: 0.8
}}
I believe David has a spreadsheet that modelled this, I wonder if there's some way we can expose this via the docs?

leverage = 1 / risk_factor and you can get the risk factor from the API for an extant market:
query {
  market(id: "b3ed2767848b86240224526986fc98b134e9e3e82e123b7dec6e8315f9df41ea") {
    id, name
    riskFactors { long, short }
  }
}

{
  "data": {
    "market": {
      "id": "b3ed2767848b86240224526986fc98b134e9e3e82e123b7dec6e8315f9df41ea",
      "name": "Apple Monthly (30 Jun 2022)",
      "riskFactors": {
        "long": "0.0085081329932736",
        "short": "0.0085717903672853"
      }
    }
  }
}

So that has leverage of 117.5x by the looks of it 🤠
Calculating the risk factor from the risk model plus params is harder, though. This spreadsheet can help, it'll show you the risk factors and leverage.

Have also just noticed we actually dont have a sub-heading for the risk model in general ... I think we need to add a section here to explain those parameters, and ideally work out how we can make David's spreadsheet available via the docs so that people can experiment.

Final thinking on this with Barney before I left the office was maybe actually the easiest thing to do here is to include a table of example risk models which lead to various values for the max leverage, along with some explanation of how to select an appropriate one.
We could leave it open to users to ignore the examples and choose their own custom risk model, but state that to do so implies a need to justify that model as part of making the market proposal.  Ultimately we want the process to imply a higher burden of proof the more aggressive the risk model chosen, down to an almost non-existent burden of proof for a 1 max leverage.
I think I can pick this one up as it doesnt involve any tech stuff with the docs pages,


Facing TypeError: Cannot read properties of undefined (reading 'tap')

Getting below error in my code when I install webpack5 :
TypeError: Cannot read properties of undefined (reading 'tap')     at /Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/@pmmmwh/react-refresh-webpack-plugin/lib/index.js:236:65     at SyncHook.eval [as call] (eval at create (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:15:1)     at SyncHook.lazyCompileHook (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/tapable/lib/Hook.js:154:20)     at Compiler.newCompilation (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/webpack/lib/Compiler.js:631:26)     at /Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/webpack/lib/Compiler.js:667:29     at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)     at AsyncSeriesHook.lazyCompileHook (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/tapable/lib/Hook.js:154:20)     at Compiler.compile (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/webpack/lib/Compiler.js:662:28)     at /Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/webpack/lib/Watching.js:77:18     at _next0 (eval at create (/Users/a0s0mwv/Documents/Work/Insights/ui-channel-perf/node_modules/react-scripts/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:34:1)
Here is my package.json 👍
{   "name": "Sample_app",   "version": "0.1.358",   "dependencies": {     "@amcharts/amcharts4": "^4.10.20"<EMAIL_ADDRESS>"^8.6.8",     "@emotion/react": "^11.7.1",     "@material-ui/core": "^4.12.3",     "@material-ui/icons": "^4.11.2",     "@material-ui/lab": "^4.0.0-alpha.60",     "@mui/icons-material": "^5.1.1",     "@mui/material": "^5.1.1",     "@mui/styled-engine-sc": "^5.1.0",     "@mui/styles": "^5.1.1",     "@reactour/tour": "^2.9.0",     "@testing-library/jest-dom": "^5.11.4",     "@testing-library/react": "^11.2.7",     "@testing-library/user-event": "^12.1.10",     "@wsp/map-gl": "^2.1.11",     "@wsp/map-react": "^1.1.2",     "axios": "^0.24.0",     "classnames": "^2.3.1",     "dayjs": "^1.10.7",     "express": "^4.17.1",     "ignore-styles": "^5.0.1",     "jest-fetch-mock": "^3.0.3",     "jsonwebtoken": "^8.5.1",     "lodash": "^4.17.21",     "lodash.debounce": "^4.0.8",     "md5-file": "^5.0.0",     "mui-datatables": "^4.0.0",     "node": "^16.13.1",     "react": "^17.0.2",     "react-data-export": "^0.6.0",     "react-dom": "^17.0.2",     "react-redux": "^7.2.6",     "react-router-dom": "5.2.0",     "react-scripts": "4.0.3",     "react-select": "^5.4.0",     "redux": "^4.1.2",     "redux-mock-store": "^1.5.4",     "redux-saga": "^1.1.3",     "styled-components": "^5.3.3",     "web-vitals": "^1.0.1"   },   "scripts": {     "start:local": "react-app-rewired start",     "start": "REACT_APP_ENV_HOST=$REACT_APP_ENV_HOST node --max-http-header-size 16384 build/server",     "build": "REACT_APP_ENV_HOST=$REACT_APP_ENV_HOST react-app-rewired build && cp -R ./server/* ./build && npm run moveFiles",     "test": "react-scripts test",     "test:coverage": "react-scripts test --coverage --watchAll=false",     "eject": "react-scripts eject",     "moveFiles": "cd build && mkdir channelperformance && cp -r ./static ./channelperformance/static",     "storybook": "start-storybook -p 6006 -s public",     "build-storybook": "build-storybook -s public",     "test:update": "react-scripts test -u"   },   "eslintConfig": {     "extends": [       "react-app",       "react-app/jest"     ],     "overrides": [       {         "files": [           "**/*.stories.*"         ],         "rules": {           "import/no-anonymous-default-export": "off"         }       }     ]   },   "jest": {     "collectCoverageFrom": [       "src/**/*.{js,jsx}",       "!/node_modules/",       "!src/coverage/**",       "!src/index.js",       "!src/stories/**"     ],     "coveragePathIgnorePatterns": [       "/src/constants",       "/src/routes",       "/src/helper",       "/src/reportWebVitals.js",       "/src/components/Drilldown/DownloadMuiTable",       "/src/components/Drilldown/ReactVirtualized",       "/src/components/Drilldown/Common/ChannelBreakdown.js"     ],     "transformIgnorePatterns": [       "[/\\\\]node_modules[/\\\\](?!(@amcharts)\\/).+\\.js$"     ]   },   "browserslist": {     "production": [       ">0.2%",       "not dead",       "not op_mini all"     ],     "development": [       "last 1 chrome version",       "last 1 firefox version",       "last 1 safari version"     ]   },   "resolutions": {     "babel-eslint": "^10.0.0"   },   "devDependencies": {     "@e2e-test-utils/ui-shield": "^3.0.3",     "@e2e-test-utils/ui-shield-utilities": "^4.1.5-0",     "@storybook/addon-actions": "^6.5.10",     "@storybook/addon-essentials": "^6.5.10",     "@storybook/addon-interactions": "^6.5.10",     "@storybook/addon-links": "^6.5.10",     "@storybook/builder-webpack4": "^6.5.10",     "@storybook/manager-webpack4": "^6.5.10",     "@storybook/node-logger": "^6.5.10",     "@storybook/preset-create-react-app": "^3.2.0",     "@storybook/react": "^6.5.10",     "@storybook/testing-library": "^0.0.13",     "@wojtekmaj/enzyme-adapter-react-17": "^0.6.6",     "babel-jest-amcharts": "^0.0.2",     "enzyme": "^3.11.0",     "enzyme-to-json": "^3.4.4",     "eslint": "^7.28.0",     "prettier": "2.3.1",     "react-app-rewired": "^2.2.1",     "redux-devtools-extension": "^2.13.9"   } }

@alexander-akait
I am suddenly experiencing the "cannot read properties of undefined"  error in my Nuxt project after years of no problems.
 FATAL  Cannot read properties of undefined (reading 'get')                                                                                17:56:44

  at /Users/user/htdocs/renderai-backup/node_modules/webpack/lib/DefinePlugin.js:354:38
  at SyncHook.eval [as call] (eval at create (node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:13:1)
  at SyncHook.lazyCompileHook (node_modules/tapable/lib/Hook.js:154:20)
  at Compiler.newCompilation (node_modules/webpack/lib/Compiler.js:631:26)
  at node_modules/webpack/lib/Compiler.js:667:29
  at AsyncSeriesHook.eval [as callAsync] (eval at create (node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
  at AsyncSeriesHook.lazyCompileHook (node_modules/tapable/lib/Hook.js:154:20)
  at Compiler.compile (node_modules/webpack/lib/Compiler.js:662:28)
  at node_modules/webpack/lib/Compiler.js:321:11
  at Compiler.readRecords (node_modules/webpack/lib/Compiler.js:529:11)
  at node_modules/webpack/lib/Compiler.js:318:10
  at AsyncSeriesHook.eval [as callAsync] (eval at create (node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
  at AsyncSeriesHook.lazyCompileHook (node_modules/tapable/lib/Hook.js:154:20)
  at node_modules/webpack/lib/Compiler.js:315:19
  at AsyncSeriesHook.eval [as callAsync] (eval at create (node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
  at AsyncSeriesHook.lazyCompileHook (node_modules/tapable/lib/Hook.js:154:20)

Any tips on how to debug this? Where to look? What to search my codebase for?
I have never touched webpack directly and have no idea how its internals work or what might be at play.

@alexander-akait This is happening in the context of a nuxt generate (nuxt v2) command. This is all the context that is provided. No reference to any lines from my own code.

Sounds like bug on the nuxt side, can you run npm ls webpack?

Closing due to inactivity. Please test with latest version and feel free to reopen if still regressions. Thanks!


Support for point fields / multiple csv columns to one field

Great project! I love it! Wondering if i can import a csv that contains geographical data.
For example, something like this
c = CopyMapping(
MyModel,
"./data.csv",
dict(point=['x', 'y'], number='NUMBER')
)
c.save()
Here's a row from the dataset for example:
['-77.0297110577', '38.9291522717', '11802074', '8330232', 'False', 'P173', 'NO PARKING STREET CLEANING', '3200 BLOCK 13TH ST NW EAST SIDE', 'DC', '4D', '806540', '5618.0', '397424', '140141', 'Parking_Violations_in_April_2010.csv', '2010-04-06T09:39:00.000Z']

Hmm. I never thought to try this. What happens if you preformat the points as WKT format or something that PostGIS expects?

+1
It looks like this, or something pretty close to it, would work--see this SO answer. A few years ago I was doing something comparable by using django.contrib.gis.geos.GEOSGeometry -- for a geosgeometry g, g.hex work(ed), though I can't remember why I went that route.

I'm all for trying it, I just want the API syntax we select to be as clear as possible. Generally this library is modeled on the layout of Django's LayerMapping tool for loading shapefiles. You see anything there we could crib from?


1.1.1 斐波那契数列 | Computer Cookbook School Recruitment

https://books.grayson.top/school-recruitment/docs/algorithm/1算法框架/1.1-动态规划/1.1.1-斐波那契数列/

测试


SPIKE: ZEVA - GMT Dates

Problem Description
Dates are stored in ZEVA as GMT. This can cause issues if we don't adjust for PST date/time in the front end. Transactions can appear to be done in the wrong day. ZEVA requires deadlines to be met in PST.
Solution Needs

Date/time needs to be displayed (and possibly recorded) throughout the system as PST regardless of the users local time zone.

Timebox

How much effort are we committing to this research?

Outcome
Details describing the outcome of the research

Was it successful? What direction should the work go?
Was it unsuccessful? Discuss next steps with team

Additional Context

See https://docs.djangoproject.com/en/5.0/topics/i18n/timezones/#overview for more information on how Django handles timestamps

Hey team! Please add your planning poker estimate with Zenhub @JulianForeman @tim738745

Echoing what Emily said above, plus a few notes:
From the Django Docs:
“When support for time zones is enabled, Django stores datetime information in UTC in the database, uses time-zone-aware datetime objects internally, and translates them to the end user’s time zone in templates and forms.
This is handy if your users live in more than one time zone and you want to display datetime information according to each user’s wall clock.
Even if your website is available in only one time zone, it’s still good practice to store data in UTC in your database. The main reason is Daylight Saving Time (DST). Many countries have a system of DST, where clocks are moved forward in spring and backward in autumn. If you’re working in local time, you’re likely to encounter errors twice a year, when the transitions happen. (The pytz documentation discusses these issues in greater detail.) This probably doesn’t matter for your blog, but it’s a problem if you over-bill or under-bill your customers by one hour, twice a year, every year. The solution to this problem is to use UTC in the code and use local time only when interacting with end users.”
According to this, it’s best practice to store dates in the UTC+00 (GMT) format, and to convert them to users’ timezones in the frontend, which is what we’re currently doing using moment.js.
However, if the ZEVA legislation or regulations state that dates need to be stored in PST or PDT, then we can make this change by setting USE_TZ to False, and setting TIME_ZONE to “America/Vancouver” (see https://docs.djangoproject.com/en/3.2/ref/settings/#std-setting-TIME_ZONE). To update previously saved timestamps, we can do a data migration (see https://docs.djangoproject.com/en/3.2/topics/migrations/#data-migrations).
If there is relevant text contained in the legislation or regulations, please attach them to this card so developers can better assess what needs to be done, if anything.

I think for ZEVA we don't care about the user's wall clock time, we probably want everything displayed as PST. This is especially true for the compliance report that must be submitted by 12:00 PM PST.


Netflix not loading

Netflix add-on version
V 1.23.3+matrix.1
Operative systems used
Android
Kodi version used
Other (specify in description)
Description of the bug
Kodi 21 Omega
Once I go into my Netflix add-on, I click onto a show that I want then it only stays on the loading process. It does not go any further will not open the show to play meaning it’s stuck on loading.  It’s stays on “please wait loading”.
Steps to reproduce the behavior
1- click on Netflix add on icon
2-Click on continue watching
3-Click on the show I want to watch
4-It says “please wait loading”
5-nothing happens it’s just stay on “Please wait loading.”
Debug log - mandatory
It doesn’t give me a debug log on this
Possible fix
Not sure how to fix it that’s why I’m creating a ticket. Thank you for all your hard work though. I really love this. Add on when it works.
Additional context
https://github.com/CastagnaIT/plugin.video.netflix/assets/70737955/ec03a4ba-596e-42bc-a4ad-76099439f03e
Screenshots

Any update on fixing this? Thanks

Obviously, I really don't know what I'm doing, but all I know is it's not loading anything I want to watch and I have no idea how to fix it. I don't know if I did this log correctly either but here you go: https://paste.kodi.tv/ocovahufak
I hope this helps or you can tell me how I could fix why nothing is loading once I'm logged in. Thank you and I'm so sorry for bothering you. 🙏🏼

Cannot be fixed. The addon cannot be used on Android. Windows and MacOS platforms for now
https://github.com/CastagnaIT/plugin.video.netflix/issues/1627

Just curious, where does this add-on work now?Sent from my iPhoneOn Jun 13, 2024, at 17:59, gujal @.***> wrote:
Cannot be fixed. The addon cannot be used on Android. Windows and MacOS platforms for now
#1627
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Works on linux and linux based LibreElec and CoreElec for now

ThanksSent from my iPhoneOn Jun 14, 2024, at 19:26, gujal @.***> wrote:
Works on linux and linux based LibreElec and CoreElec for now
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>


Automated version bump

It would be nice to have automated version bump for the packages when their /main branch is updated, based on the commit messages.

My initial tries failed unfortunately. Version bumping works correctly, but it also bumps versions when updating the element/main branch from main...
Maybe there is a different approach with vanilla nom workspaces, or maybe we need to introducehttps://lerna.js.org/ for this.

Introduced with release-please action.


My LN not visible on explorers

Background
I am running bitcoin fully syned testnet and mainnet both on different systems. But my both nodes are not visible on any explorers. I added my externalip and other node_info in lnd configuration file too.
Help me how to solve this issue.
Your environment

version of lnd
lnd version 0.4.2-beta commit=f6ea91af713546174bf04a79302116aa455d89c8
which operating system (uname -a on *Nix)
Linux 16.04LTS
version of btcd, bitcoind, or other backend
bitcoind:
version": 160200

Expected behaviour
My node should be visible on any explorers.
Actual behaviour
My node is not visible on any explorers.
Thanks.

Thanks @Roasbeef for your comments.


Logging arguments rearrange

Most loggers propose to log errors or objects as first arguments and then a message.
See https://github.com/pinojs/pino/blob/master/docs/api.md and
https://github.com/trentm/node-bunyan#log-method-api

I swear I wanted to do this change myself. But forgot.

Published as v2.0.1


CSimple NPE even if CSimple language is not used

The route below runs into NPE while packaging a project:
@ApplicationScoped
public class MyRoute extends EndpointRouteBuilder {
    @Inject
    MyProcessor myProcessor;

    @Override
    public void configure() {
        from("direct:start").process(myProcessor::process);  }

    @ApplicationScoped
    public static class MyProcessor {
        public String process(Exchange el) {    return "";   }
    }
}

As confirmed by @davsclaus the route does not use csimple at all, so that quarkus builder
shouldn't cause that NPE bug.
Using lambda works however .process(e -> myProcessor.process(e))
[WARN] [org.apache.camel.quarkus.core.deployment.CSimpleRouteDefinitionProcessor]
Could not extract CSimple language expressions from the route
definition Routes: [Route[From[direct:start] -> []]] in class class
com.simple.temp.MyRoute.
java.lang.NullPointerException: null
        at java.base/java.util.Objects.requireNonNull(Objects.java:222)
        at com.simple.temp.MyRoute.configure(MyRoute.java:17)
        at org.apache.camel.quarkus.core.deployment.CSimpleRouteDefinitionProcessor.collectCSimpleExpresions(CSimpleRouteDefinitionProcessor.java:115)
        at jdk.internal.reflect.GeneratedMethodAccessor305.invoke(Unknown
Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:972)
        at io.quarkus.builder.BuildContext.run(BuildContext.java:277)
        at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
        at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2046)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1578)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1452)
        at java.base/java.lang.Thread.run(Thread.java:832)
        at org.jboss.threads.JBossThread.run(JBossThread.java:479)

Thanks for the report, @ennishol. This is a valid issue and we need to figure out, how to address it.

Thanks for the report, @ennishol. This is a valid issue and we need to figure out, how to address it.

BTW, if you really do not use CSimple language, you can ignore the warning, or even suppress it by adding
quarkus.camel.native.csimple.on-build-time-analysis-failure = ignore

to your application.properties

BTW, if you really do not use CSimple language, you can ignore the warning, or even suppress it by adding
quarkus.camel.native.csimple.on-build-time-analysis-failure = ignore

to your application.properties

thanks, I'll disable the warning then

thanks, I'll disable the warning then

https://github.com/apache/camel-quarkus/pull/2108 puts the csimple build time analysis to a new separate camel-quarkus-csimple extension. In that way, users not having csimple language in their routes won't see any warnings if their routes are not analyzable at build time.

https://github.com/apache/camel-quarkus/pull/2108 puts the csimple build time analysis to a new separate camel-quarkus-csimple extension. In that way, users not having csimple language in their routes won't see any warnings if their routes are not analyzable at build time.


Ubuntu session close during building wheel step

Hello,
My system :
Ubuntu 24.04
Cuda 12.1
CuDNN 8.9.2
Python 3.10
I've quite a strange problem. When i'm trying to install TransformerEngine with pip install git+https://github.com/NVIDIA/TransformerEngine.git@stable, my computer "crash" during the build_wheel step as my ubuntu session automatically close !
I also tried building from source, and it has the same behavior during the running setup.py
As it crashes, i've no error message so no idea what could be the problem....

Most probably you encounter OoM error. Could you try changing threads value in this line: https://github.com/NVIDIA/TransformerEngine/blob/main/transformer_engine/CMakeLists.txt#L17 from 4 to 1? It should take longer but use less memory.

I tried to change, but still the same problem. However as i was monitoring the gpu usage with nvidia-smi; it didn't seems to grow at all during the building. (For information, I have one rtx3090). I'll try to see what else i can change.

It was effectively an OOM error, and i had to change the MAX_NUM_WORK env for ninja build  !


store manifest information in indexeddb, swap cache

Currently make load files all at once, as I noticed it a bit faster than load them manually

Thanks!
Your solution worked great for me. Even if its not merged yet :P
I had to change only one thing.
In service worker I replaced this line:
await cache.addAll(nextManifest.cache);
with this
for (var i=0; i<nextManifest.cache.length; i++) {   await cache.add(nextManifest.cache[i]); }
Reason for this change is that for some reason if you use cache.addAll it blocks all normal fetch requests until caching is done.
For slow connections it could mean you can't refresh website for a minute or more until caching is done.
But if its split in smaller cache.add page is refreshing fine, while caching is happening in background.
Honestly I would make the same mistake. It makes no sense why addAll works like that.
Mini rant starts here :)
Anyways.
I still don't get it why AppCache is getting removed from browsers. If service workers are so great like they say, then why they didn't create compability layer where browsers would implement old appcache using new service workers automatically. It does not seem that hard.
Rant over, Cheers. :)


Why are deployments loaded based on network name, and not only on chainId?

Is your feature request related to a problem? Please describe.
I was initially using a public endpoint, and deployed my contract using that endpoint. Now I just spinned my own node, and so created a new hardhat network config with name "my_node". When trying to load my previously deployed contract, I get a Uncaught Error: No Contract deployed with name Liquidator error. I thought hardhat-deployed only looked up deployments based on the .chainId file in the deployments folder, but it seems it actually looks at the hardcoded network name, which seems arbitrary to me.

Describe the solution you'd like
Is there a good reason for this? Is there a reason why hardhat-deploy can't just look up previous deployments based on the .chainId file?
I tend to have many avalanche endpoints in my hardhat file: avalanche_moralis, avalanche_my_node, avalanche_ipc, etc. I need to copy the deployment and rename it for each one of these, which seems a bit bloated and unnecessary.

I use this feature all the time to have different set of deployment on the same network.
If you need use different node for the same network you could probably configure it dynamicly in your hardhat config


Just a remark

From the 1.5.1 changelog:

Fixed possible critical bug that makes the miner unable to see if a miner is running or not thus opening multiple miners

That bug was real. One of my targets had issues using his PC because there were 17 Miner instances started at some point, basically crippling the Machine and almost got it detected.
Just wanna let you know that 1.5.1 fixed it.

Ah great, I didn't notice it because it doesn't happen on my computer or VMs due to how my user is configured. So it's good to get confirmation that the change fixed it.


Windows EKS - Pod to pod dns and calls to services or other pods all fail when Windows Calico services are running

Steps to reproduce the issue:
Using latest install-calico-windows.ps1 script:
calico-windows-v3.16.1.zip
Windows Node is 1909 Server Core
Cluster created with eksctl, one linux node and one Windows 1909 Server Core node
Implemented config change to solve #4037 and changed NODENAME in config.ps1 to solve #4040
So now calico services are running on the Windows node, and I don't see obvious error. When I run my pods on the Windows node, they cannot reach other services that I am running, which are all in the same k8s namespace. I have 3 pods, all in the same namespace. Resolve-DnsName fails on the services, and curl fails, even when the container IP address is used. These commands are issued from inside of one of my containers. Before running Calico on the Windows node, these commands all work correctly. Not sure what to check or try next.
      : No
   Autoconfiguration Enabled . . . .        : No
   Autoconfiguration Enabled . . . .  : Disabled
   Connection-specific DNS Suffix Search List :
                                       green.svc.cluster.local
                                       svc.cluster.local
                                       cluster.local

All Steps:
- Created an EKS cluster using eksctl, using one managed linux node and one unmanaged Windows 1909 Server Core node.
- Deployed Kubernetes Dashboard and some pods for the application I work on.
- Deployed Calico from my controlling EC2 instance and checked that the pods were all running successfully:
           wget https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.3/config/v1.7/calico.yaml -o calico.yaml
           kubectl.exe apply -f .\calico.yaml

Remoted into the Windows node and ran the following commands in an elevated PowerShell window:

mkdir c:\k
cd k
curl -o kubectl.exe https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.9/2020-08-04/bin/windows/amd64/kubectl.exe
Invoke-WebRequest https://docs.projectcalico.org/scripts/install-calico-windows.ps1 -OutFile c:\install-calico-windows.ps1
c:\install-calico-windows.ps1 -ServiceCidr <IP_ADDRESS>/16 -DNSServerIPs <IP_ADDRESS>
Get-Service -Name CalicoNode
Get-Service -Name CalicoFelix

Windows Calico log files and the config.ps1 file: calico-logs-plus-config-script.zip

Calico-node and Calico-typha linux pod logs: calico-linux-pod-logs.zip

Looking for any ideas of what to check. I'm not sure where to look since I didn't notice an obvious error. If anyone has experience with these kind of problems, please look through the attached logs files. Thanks!

Sorry for the delay @dave-meier . I took a quick look in the calico-felix.log and there's a line indicating there might be policy applying to these workloads:

2020-10-02 14:45:10.956 [INFO][7140] felix/calc_graph.go 411: Local endpoint updated id=WorkloadEndpoint(node=ip-10-12-40-102.us-west-2.compute.internal, orchestrator=k8s, workload=green/ae-tomcat-6db96d9fc9-glhgd, name=eth0)
2020-10-02 14:45:10.956 [INFO][7140] felix/win_dataplane.go 248: Received *proto.WorkloadEndpointUpdate update from calculation graph msg=id:<orchestrator_id:"k8s" workload_id:"green/ae-tomcat-6db96d9fc9-glhgd" endpoint_id:"eth0" > endpoint:<state:"active" name:"calid896d1a7c35" profile_ids:"kns.green" profile_ids:"ksa.green.default" ipv4_nets:"<IP_ADDRESS>/32" tiers:<name:"default" ingress_policies:"green/knp.default.default-deny" egress_policies:"green/knp.default.default-deny" > >
2020-10-02 14:45:10.956 [INFO][7140] felix/endpoint_mgr.go 130: Processing WorkloadEndpointUpdate workloadEndpointId=orchestrator_id:"k8s" workload_id:"green/ae-tomcat-6db96d9fc9-glhgd" endpoint_id:"eth0"

This is the last update to that endpoint in the log. Were your tests done after the policy was removed? If you did the tests after the policy was removed, then for some reason that wasn't processed on the Windows node.

Thanks @lmm for taking a look!
I see what you mean. This may have been a faulty assumption on my part that the policy would go away when I restarted calico pods, but the policy would still be there in the cluster. When I had the last issue, and no traffic was denied, I was experimenting with the following policies. I don't see the "access-green" policy in the log, but perhaps I was experimenting just with default-deny by itself at one point. I could have sworn I was listing the policies with kubectl and seeing none, but maybe there was operator error in there!
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
  namespace: green
spec:
  podSelector:

---

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-green
  namespace: green
spec:
  podSelector:
    matchLabels:
      environment: green
  ingress:
    - from:
      - podSelector:
          matchLabels:
            environment: green

I will recreate the test cluster I was using and try it again, and then apply the following policy, which I'm assuming with only deny traffic from other namespaces to the green namespace:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: green
  name: deny-traffic-other-namespaces
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

Not reproducible.


Change [default] to [defaults]

https://github.com/martinlindhe/wmi_exporter/blob/2f7a372429903a331e1bcf58444ff16da72a42f4/exporter.go#L172
Please change help message corresponding to source code. Now in help there is [default], but in source code it knows only [defaults]

Thanks for reporting this, fix incoming!


[WFLY-10930] Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution

The removed configuration is no longer valid for this plugin since Galleon wildfly plugins 2.0.0.Final
This configuration does not affect to build, but it should not be there.
Jira issue: https://issues.jboss.org/browse/WFLY-10930
cc: @aloubyansky

Right, I removed the equivalent from galleon-pack module but forgot to clean this one up. Sorry.


inline grid list field children

I am trying to configure the combo/list inline grid in order to show the results grouped and i am not sure if there is already a way to do it as it is right now in 2.0 out of the box

at the moment i have the list/combo configured with url: param with the backend returning an array like : [['id'=>'1','text'=>'item1'],['id'=>'2','text'=>'item2']] and works great BUT,
is there a reasonable simple way to configure the list/combo css using the array like :
[['id'=>'1','text'=>'item1','children'=>[
['id'=>'1','text'=>'subitem1'],['id'=>'2','text'=>'subitem2'],
]],
['id'=>'2','text'=>'item2','children'=>[
['id'=>'1','text'=>'subitem1'],['id'=>'2','text'=>'subitem2'],
]]]

Please submit questions elsewhere. These issues are for bugs/feature requests.


IDP will not be logged out when two service providers authenticate with two different IDPs

Describe the issue:
In the current DefaultLogoutRequestHandler, it retrieves authenticated IDPs from the sequenceConfig (in each step) [1]. This sequence config is read from the authentication context [2]. This flow initiates incorrect behaviors when we have two service providers which are authenticated with two different IDPs.
How to reproduce:
Consider below two scenarios.
Scenario 1

Configure two seperate IS instances as federated IDPs in the main IS (Let's call them PrimaryIS, SecondaryIS and TertiaryIS). [I configured SAML federated IDPs]
Create two service providers (SAML SP and OIDC SP) in the PrimaryIS and configure to authenticate with federated IDP as below.

SAML SP -> Federated authenticate with SecondaryIS
OIDC SP -> Federated authenticate with TertiaryIS

Login to the SAML application with SecondaryIS.
Login to the OIDC application with TertiaryIS.
Open SAML tracer and logout from SAML app.

Ideally this should initiate a logout for the SecondaryIS where the SAML app is authenticated with. This flow will not detect SecondaryIS as a authenticated IDP. Only the TertiaryIS will exist as previousAuthenticatedIdP in the context.
Scenario 2
Try out the same scenario with two SAML service providers.

SAML SP1 -> Federated authenticate with SecondaryIS
SAML SP2 -> Federated authenticate with TertiaryIS

The same behavior can be observed.
Note
With the fix for #13696, the logout request will be sent to the TertiaryIS. However still the SecondaryIS session will not be logged out. Hence this should be fixed for both force and normal authentication flows.
Expected behavior:
When initiating the logout, both IDPs should be logged out from the session.
[1] https://github.com/wso2/carbon-identity-framework/blob/master/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/request/impl/DefaultLogoutRequestHandler.java#L166
[2] https://github.com/wso2/carbon-identity-framework/blob/master/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/request/impl/DefaultLogoutRequestHandler.java#L107
[3] Configuring wso2 IS as federated IDPs

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Allow to access Note id through __get

In gushphp/gush, we need to access the comment id. The simplest way is to use the Model definition to map loaded data.
It's a really simple PR but it'll allow to simplify our code :smile:.

:+1:

:smile: thanks for your quick approval !


An alternative to PathShape

This is from http://www.garagegames.com/community/forums/viewthread/137542
I'm calling this resource WalkableShapes (I'm open to suggestions for better class names). It provides three classes that can be used in games. TSPathShape is a simple path following shape. TSAttachable builds on TSPathShape to add the ability for players to walk on the shape while it's moving. The script interface for this class is almost identical to the traditional PathShape. The setup is slightly different. Since the DataBlock has been eliminated, the shape file is set in the editor. The WalkableShape class is a simple shape object that players can walk on while it's moving. It provides no movement of it's own, but can be mounted to...Anything! So if you want to walk on the back of a flatbed truck, model the bed as a separate shape and mount it to the truck in game as a WalkableShape. It can be mounted to any shape that provides movement. There is a demo level included that has a platform-jumping mini-game and a Cheetah with a platform mounted to the roof where the turret normally mounts. You'll need two connections to try that though.

What about that? Does someone is interested on this? tsDynamic is a new class we need to merge with the new tsStatic additions since last year. Also, does bullet physics compatible with that? I remember long time ago I had troubles on that because of gravity which still push down also bullet ghostObjects. Please someone can verify that?

Hello again!  Ok, this resource allowed you to have moving platforms, I needed it to implement a floating disc game where players would jump disc to disc and I wanted the disc's to move and such.  I did the initail PR but I didn't write it, some other guy did.

https://github.com/OTHGMars/Torque3D/tree/walkable_shapes the origional

https://github.com/Azaezel/Torque3D/tree/walkableShapes_Mege contains a merge-updated version, as well as some initial factfinding for working around the reason this was apparently rejected. Turns out with the physics plugins, players would attach, but continue falling. https://github.com/Azaezel/Torque3D/commit/efa2f9abe3b8efcb4ba686b18b1909e9bdafe741#diff-b8335f02a980665dd7dc953db7a637caR2804 Seems to do the job for bullet at least. No guarantees on physX.
*Note: On talking with @Areloch , this may remain sitting in the queue as a reference until such time as the general methodology is rolled in as a component.


Make a navigation bar using html and css

Warning: Please do not use any kind of copypaste and also don't do any hacking

can I work on this task if you want\

I have done this

I want to work on both of the issues please assign it to me.

@iamneeraj542  assign me

close #1
thanks to all contributors give me the chance to call you again.!!


fix(slots) return empty array, test multiple vues

add shell script to test multiple vue versions
add peer dependencies

Fixes #109

Codecov Report

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

@@           Coverage Diff           @@
##           master     #112   +/-   ##
=======================================
  Coverage   86.25%   86.25%
=======================================
  Files           1        1
  Lines         160      160
  Branches       44       44
=======================================
  Hits          138      138
  Misses          4        4
  Partials       18       18

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 458f3e2...ab16195. Read the comment docs.


Bootloader not working with -device q35

Bootloader does not work with -device q35 argument passed to qemu to access the MCFG tables and SATA. Heres the output:

[dependencies.bootloader]
version = "0.9.16"
features = ["map_physical_memory"]

Hmm, I never tried to use q35. Looks like it doesn't even detect the boot disk. Could you try whether it works with other system images? This would tell us whether the problem is in the disk image generated by this crate or whether it is in QEMU itself.

Hmm, I never tried to use q35. Looks like it doesn't even detect the boot disk. Could you try whether it works with other system images? This would tell us whether the problem is in the disk image generated by this crate or whether it is in QEMU itself.

I did try it with another image before I tried it with this crate and it seems to work. This crate seems to be the err. @phil-opp

Thanks for the quick reply! I suspect that is because we currently only write the boot signature 0x55aa, but not any partition table. I'll try to fix this soon, but I'm currently still busy with the rewrite for UEFI support.

We now create a proper FAT partition for booting. Does this issue still occur with v0.11?


Add feature for spring boot oauth2 providers

The spring boot oauth2 modules for providers should be in the same feature:

spring-boot-oauth2-auth0
spring-boot-oauth2-okta

@DamnClin : can you suggest a name for this feature?

oauth-provider sounds good

shouldn't springdoc-oauth2-auth0 and springdoc-oauth2-okta follow the same logic ?

shouldn't springdoc-oauth2-auth0 and springdoc-oauth2-okta follow the same logic ?

Probably

What about oauth-springdoc for the name ?

Sounds good


New types v2

cc @sdroege @EPashkin

@GuillaumeGomez Seems you forgot add Gir.toml changes

generally seems fine but I don't have the time to go through each function in detail now. Did you check that each Option return value can actually be NULL?

No, I'll.

Ok, should be ready now.

Removed extra files as well!

Thanks, now we can eject CD ;)
👍 but better wait until https://travis-ci.org/gtk-rs/gio/jobs/390942790 passed.

Haha, true!
I wait for CIs in any case.


ESP32: Integrate GPS Library into ESP-IDF Framework

As part of the effort to create an EPS32 based Golioth Frog Sensor https://github.com/Ribbit-Network/ribbit-network-frog-sensor/issues/126 , we need to find and integrate drivers for the Frog Sensors into the ESP-IDF framework stared in this branch: (https://github.com/Ribbit-Network/ribbit-network-frog-sensor/tree/esp32_golioth)
Sensor
GPS PA1010D - https://www.adafruit.com/product/4415

@beriberikix suggested in #158 that this https://github.com/jacketizer/libnmea might work for our GPS.
However, I'm not quite sure since our GPS uses I2C as the physical interface and I think the library above is linked only for serial / NMEA strings, but I might be wrong.

There is an arduino supported library for the I2C interface, so it may be possible to port that source into ESP-IDF?
https://learn.adafruit.com/adafruit-mini-gps-pa1010d-module/arduino

Ya, that's correct! If you take a look at https://github.com/igrr/libnmea-esp32 you can see how it's modified to work with the esp-idf.  So the steps could be:

Include libnmea into the project like @igrr's example
Adapt to use i2c instead of uart
Update to ensure you're grabbing the right NMEA data

I also created https://github.com/UncleRus/esp-idf-lib/issues/460.

Thanks @beriberikix, still learning all of this, but it seems like step 2 above is the uncertain one :). I'll play around with the code, but definitely will be tracking the issue under esp-idf-lib.

@akhilgupta1093 let me know when this is at a stopping place for now and I can move the esp32 esp-idf branch into the new repo at https://github.com/Ribbit-Network/ribbit-network-frog-software


Headers needed in Conan package to build xbridge witness server

Headers required for the xrpl Conan package to build xbwd

[x] libxrpl change (any change that may affect libxrpl or dependents of libxrpl)

note: legleux currently on PTO; to follow up after returning

This is ready.
I did notice a few more things could be alphabetized in the CMakeLists.txt.

@legleux at your convenience, confirm that you still think this PR is ready to merge.
(I'm not sure who has permission to apply the Passed label, but if you can, feel free to do that when this is ready.)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (90d463b) 61.48% compared to head (9aa2bad) 61.49%.
Report is 1 commits behind head on develop.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #4885   +/-   ##
========================================
  Coverage    61.48%   61.49%
========================================
  Files          797      797
  Lines        70121    70122    +1
  Branches     36238    36238
========================================
+ Hits         43117    43124    +7
+ Misses       19759    19757    -2
+ Partials      7245     7241    -4

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I assume the force-push was just to rebase and resolve merge conflicts?


Aggregate identifier should be handled by the Framework

Thanks for adding this here ;)
This is slightly related to #6:
IMO we should hide the technical identifiers from the implementation as much as possible (sill providing ways to interfere with them if needed).
For the creating command/event this is a bit special of course and there we most probably want to have control over the identifier. I think this could work:
Command (create):
final class RegisterCustomer implements CommandInterface
{

    /**
     * @var string
     */
    private $customerId;

    /**
     * @Flow\Validate(type="NotEmpty")
     * @var string
     */
    private $name;

    public function __construct(string $name)
    {
        $this->customerId = Algorithms::generateUUID();
        $this->name = $name;
    }

    public function getUserId() : string
    {
        return $this->customerId;
    }

    public function getName() : string
    {
        return $this->name;
    }
}

Event (create)
final class CustomerWasRegistered extends AbstractAggregateEvent {
{

    /**
     * @Flow\Validate(type="NotEmpty")
     * @var string
     */
    private $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }

    public function getName() : string
    {
        return $this->name;
    }
}

Handler (create)
class CustomerCommandHandler implements CommandHandlerInterface
{

    /**
     * @Flow\Inject
     * @var CustomerRepository
     */
    protected $customerRepository;

    public function handleRegisterCustomer(RegisterCustomer $command)
    {
        $customer = Customer::register(
            $command->getId(),
            $command->getName()
        );
        $this->customerRepository->add($customer);
    }
}

Aggregate (create)
class Customer extends AbstractEventSourcedAggregateRoot
{

    static public function register(string $id, string $name) : Customer
    {
        $customer = new Customer($id);
        $customer->recordThat(
            new CustomerWasRegistered(
                $name
            )
        );
    }
}

Finally, the AbstractEventSourcedAggregateRoot would need a protected constructor like:
final protected __construct(string $aggregateIdentifier)
{
    $this->aggregateIdentifier = $aggregateIdentifier;
}

And it will be set by the Repository whenever the aggregate is reconstituted.
This is all untested, but do you think that this make sense and could work like this?

Need to think a bit more about that ;) fee a bit like make thing complex ... but maybe not ;)

fee a bit like make thing complex

Really? It's actually almost the same as now with the exception that you don't have to do weird things like
	/**
	 * @param CustomerWasRegistered $event
	 * @return void
	 */
	public function whenCustomerWasRegistered(CustomerWasRegistered $event) {
		$this->aggregateIdentifier = $event->getId();
	}

in your aggregate, which makes it quite flaky and would even allow an aggregate to change it's identifier during runtime.


Migrate the parser to the language definition v2

At the moment we use our Rust macros 1.0 (aka DSL v1) to define the language for our parser. We already have:

YAML spec
DSL v1
DSL v2

So to cut down the different definitions, we should migrate to the newest definition (see https://github.com/NomicFoundation/slang/pull/617).
Migration PR:

[X] #650

Impacts the AST:

[X] https://github.com/NomicFoundation/slang/pull/693
[X] https://github.com/NomicFoundation/slang/pull/698
[X] https://github.com/NomicFoundation/slang/pull/699

Clean up PrecedenceExpression#rule_name and adapt the codegen model to fit the v2 definition better
Precedence items should also produce their own NonTerminalKind kind, wrapping the single child (PrecedenceExpression or PrimaryExpression).
PrecedenceExpression should get their own parse_XXX() function.

Does not impact the AST:

[ ] Re-introduce EOF/EOI (End of Input) virtual token/trivia parser
[ ] Change LeadingTrivia definition in v2 to allow being terminated by EOI as well (changed in #650)
[x] Don't monkey-patch SourceUnit rule to always be followed by EndOfFileTrivia (copies v1; trivia model in v2 is a bit different)
[x] Always try to parse ZeroOrMore(AnyTriviaItem) at the end when parsing any production with pub fn parse
[x] Stop leaking identifiers by adapting either v1 or v2 models (#977)
[x] Keyword trie inclusion should be reworked to not require synthetic rules over all keywords (v1 model) (#1018)
[x] Revert https://github.com/NomicFoundation/slang/pull/646 (done in #800)
[x] Ordering of parsing statements variants (context).~ (separated into #1019)
[x] See if we can remove Scanner::not_followed_by completely and automatically calculate it instead (context).
[x] Remove redundant versioning checks in precedence expressions (context).
[x] Precedence individual operators need to be deduped across versions (context).
[X] Delete codegen_grammar crate. (https://github.com/NomicFoundation/slang/pull/972)

While implementing #1002 I started thinking whether using v2 types only makes sense for our existing parser generator.
The goal of #1002 and this issue in general was to reduce duplication between the very similar types and get rid of the bridging types whenever possible.
While it was enabled by the mechanical and lexer-oriented design of model::Scanner, I'm worried that it might not be possible to do the same with ParserDefinitionNode because of the higher level of abstraction of the v2 types for structs, choices and precedence operators.
The are a couple of points here:

The v1 model for the parser definition was very generic and dynamic in a good way - I feel that trying to shoehorn the v2 to fit into it will make it harder to reason about and make it less composable
Moreover, because of the mutually recursive nature of the parser (and how v2 inherently differs from v1: flat list of definitions vs recursively defined parsers via DSL macro) we need to resolve/lower the v2 definition anyway into a structured representation
The structured representation is required to perform some analysis for the purposes of codegen, like reachable terminals in a given lexical context etc.

Having the above in mind, while there are some unnecessary translation hacks still that I'd like to smooth out, I would probably reconsider dropping the v1 interface entirely.
cc @AntonyBlakey @OmarTawfik for visibility

@OmarTawfik from what I understand:

we don't need the end of input token (first item) and
the "Change LeadingTrivia definition in v2 to allow being terminated by EOI as well" (second item) is somewhat subsumed by us trying to always parse the trivia after the end of the production.

If not, then, I'd propose that we treat it as general improvement to the trivia handling rather than being a core component of the DSL v2 (we did already migrate the parser to the DSL v2 and we're happy with the current behavior) and we should probably track it separately if we're not already happy with what we have, as per above.
The listed scope for this issue almost feels like a quarterly KR and I'd love if we could finally close it, once #1018 is merged (and we revert the string rule) :sweat_smile:

we don't need the end of input token (first item)

sounds good.

is somewhat subsumed by us trying to always parse the trivia after the end of the production.

IIRC, the hack we added is to "reuse" leading trivia as EOF trivia, and the proper fix was to construct a specific EOF parser in codegen, with its definition being Choice([all trivia items in the grammar]) and run it after each successful parse. This allows LeadingTrivia definition to remain true/accurate to DSL v2, and remove the TODO(#638) comments in the definition.
Is that still the case? If so, it is definitely not blocking, and I would not prioritize it over other important tasks we have, but I think we should still do it. If you have a full plate, please feel free to put it in a separate issue and assign it to me, and we can close this one.

I've opened #1020 to track this.

If you're fine with it, I'd propose that we separate an issue/thread dedicated to it as I feel we had already too many items bundled in this issue and the decision is not clear-cut at this moment.

Sounds good. Let's follow up on #1020. Thanks!


Organizational logos and job titles no longer appear on individual profiles

The organizational logos and job titles seem to no longer appear on user profiles. This was working fine until last week when I created this profile and confirmed that everything looked fine with the user:
https://www.landportal.info/users/nicky-rehbock
The organization and job title are linked and included in the user profile, but no longer appear.

according to the site settings in manage display (user account and work profile) it should work and be displayed.
Is this (again) something you guys hardcoded?

@jcr fixed, please check http://beta.landportal.info/users/nicky-rehbock
not sure though if the styling is 100% correct

I still don't see any organization / position in her profile in there

@jcr sorry broke when merging with master yesterday, fixed now - http://beta.landportal.info/users/nicky-rehbock

ok , now it shows on the full profile page. We will see for a better design in the next Milestone
"2.3.2 - Theme"


Aidand tool calls 2 - Approach #2 - Scratch PR

What does this PR do?
In short, provide a summary of what this PR does and why. Usually, the relevant context should be present in a linked issue.

[ ] Addresses issue (#issue)

Test Plan
Please describe:

tests you ran to verify your changes with result summaries.
provide instructions so it can be reproduced.

Sources
Please link relevant resources if necessary.
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Ran pre-commit to handle lint / formatting issues.
[ ] Read the contributor guideline,
Pull Request section?
[ ] Updated relevant documentation.
[ ] Wrote necessary unit or integration tests.

Sorry - wrong source branch


Remove the "Add images If possible" part.

I don't think there is any way to add images to "bash" render.

I don't think there is any way to add images to "bash" render.

what do you mean by this?

what do you mean by this?

if you try to add an image to the bash render, it doesnt work

Closing due to this being fixed.


Dealing with conflicts

In the case that a milestone with the given title already exists, our options ( as I see them at the moment ) are:

Exit the script
Ask the user if they want to delete the milestone and re-create
Attempt to sync the issue pack with the given milestone
Look through existing issues & only create new ones from the pack that don't already exist

Including closed issues
Matched by title

I'm going to work at this in the order above.  I do think it's necessary to get to the third option, and here's a use case for it:

A team installs an issue pack
Work begins on some or all of the issues ( including issue comments )
The issue pack is updated

Right now if the milestone exists, it requests all milestones, iterates until it finds one with the given title, and uses that milestone number.  This is probably good enough for this stage.

Yes, finding an existing milestone and using it the right solution. This will allow additional issues to be added to an existing milestone, and eventually enabling user to choose which milestone to add issues.


Addons: trying to save messages into influxdb

I'm trying to save sent messages using addons (Influxdb) while using mqtt. My application works fine - the messages are sent and received, but when I try to read them, none are saved. I saw in one old example  using http that I should add content type header, but mqtt doesn't have that option. I saw here something like having special topic "/ct" but I don't understand how to use this.
The mainflux I'm using is from April 29. this year. Writer and reader are installed successfully.
My apps are in python, so I'm using paho library.
Here is my code:
app sending data

app showing data (partially):

app trying to read the messages from influxdb:

Find in log for influxdb-writter if messages is saved at all when you send them. Keep in mind that message must be in SenML format to be saved in database, try with message from documentation .
Content-type subtopic is not used anymore, that is old blog post.

The messages I was originally sending are:

When I try to send a message from example  I don't see anything in writer neither:

can you pull latest images? there was some bug that caused messages not being propagated via nats to writers

Perfect!
Pulled the last images (docker-compose -f docker/docker-compose.yml pull) and updated the project (git pull) and now it works
Thanks! 😄

@marijadstankovic great! Closing this one.


Adding singledatepicker

Hi I would like to add a feature wherein we can use this library to somewhat disable the two tabs (From,To). So we can use it for just getting a single date. However I'm new to library cloning so can anyone help me with this? I know how to clone but my idea for adding this as a module is limited. Thanks

In this case use the native Android date picker :)
https://developer.android.com/guide/topics/ui/controls/pickers.html

Yeah its possible but I want to keep the design consistent to all my datepicker. Anyway I was able to clone the project and create an option for single date. closing this thread now.

@christianCallelero Hi, can you share the single date selection option you implemented?

@christianCallelero Hi, can you share the single date selection option you implemented?

maybe it's late, but anyway: you could just subclass the datepicker, and override #onViewCreated.
use findViewById(android.R.id.tabs) to get "tabs" layout at hands and make it's visibility = GONE, so it is not displayed anymore. works with config change/screen rotation, because when view recreated - tabs are "GONE" again.
the ondatechange listener stays the same, except you do not use "end" dates, since user intacts with the first tab only.
probably you need to recreate static constructors too (#newInstance methods)
internal class OnlyDatePickerDialog : com.borax12.materialdaterangepicker.date.DatePickerDialog() {
	override fun onViewCreated(view: View?, savedInstanceState: Bundle?) {
		super.onViewCreated(view, savedInstanceState)
// hide tabs heading so user cant see it
		view?.findViewById<TabWidget>(android.R.id.tabs)?.let{
			it.visibility = View.GONE
		}
	}
// static constructors are not inherited in kotlin, so recreate them
	companion object {
		fun newInstance(
			callBack: OnDateSetListener, year: Int,
			monthOfYear: Int,
			dayOfMonth: Int
		): OnlyDatePickerDialog {
			val ret = OnlyDatePickerDialog()
			ret.initialize(callBack, year, monthOfYear, dayOfMonth)
			return ret
		}

		fun newInstance(
			callBack: OnDateSetListener, year: Int,
			monthOfYear: Int,
			dayOfMonth: Int,
			yearEnd: Int,
			montOfYearEnd: Int,
			dayOfMonthEnd: Int
		): OnlyDatePickerDialog {
			val ret = OnlyDatePickerDialog()
			ret.initialize(callBack, year, monthOfYear, dayOfMonth, yearEnd, montOfYearEnd, dayOfMonthEnd)
			return ret
		}
	}
}
`


Implement a delete 3D asset function on 3D editor

There has to be a delete 3D asset functionality baked in the 3D Editor. Preferably on each asset list item.

The buttons are there from commit f2c0578dd3de7ca3ac29c28ce108146e26b1772e We have create the appropriate links.


Add run on repl.it badge to README

This pull request adds a  badge to the . This will allow users to easily run this repository in their browser, without having to set up an environment. You can learn more about Repl.it here.

Thanks for sharing the link, but I don't think it is appropriate for kivy to link to it given that kivy doesn't actually run there.
You'd either need to compile kivy every time you start the repl, which fails anyway since you need to install all the deps on linux. Or you can use an existing wheel with pip, but then linking to github master is misleading. Finally, kivy doesn't actually run headless so I don't think this will be useful much.

yeah, doesn't seem to work, i guess if there was a way to either force python3.7 or to force kivy version to be 2.0.0rc3, it could work, but i didn't manage to do that.
I'm pretty sure i remember someone linking a similar service on which they were able to run kivy, though, but can't seem to find it again.

You can install kivy more easily with pip install kivy --pre. I didn't see the x Window because of an ad-blocker, but now it runs.
However, it's not connected to the cloned version of kivy and you need to cd to a different directory to work. It would be better to start from a clear shell, rather once that cloned kivy.
It's also somewhat slow and unresponsive. Do you think there's a benefit to linking to it?

I'm unsure, i feel like our installation procedure has improved a lot compared to a few years ago, and it's rarely an issue for an user to install kivy to start experimenting with it, so while this might give a solution to some users, i'm not sure it's a really interesting one, so, meh? i'm not against it if there is literally 0 instructions to maintain to use it, but i'm not the one going to make a strong case for it.

OK, closing then because it doesn't seem it would be that helpful for us or our users.


Updated formatting errors

Hi @devinrader, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, AZPRBOT;

@devinrader Thanks for the contribution!


Refactor PWM for simpler generic use

this is just a draft / proof of concept for discussion
related to complaints about existing PWM trait usability, this attempts to improve the Pwm trait for use as a generic in higher level applications / logic. the key consideration here is that associated types that vary by implementation should be avoided as inputs to minimize integration complexity, and this applies to roughly all Channel based traits.

Removes Time associated type, replaced with core::time::Duration
Removes Channel associated type, replaced with associated const CHANNELS and usize indices

This means the driver does need an error for channel out of bounds rather than allowing type-system enforcement
Another approach would be a TryFrom<usize> bound, but, we're getting more complicated again

Questions:

Is there a good / useful way to replace the Duty associated type?

One option would be to add a couple of From bounds for useful intermediates such as f32 so consumers could leave Duty unbound but consistently pass in f32 or other useful arguments.
This approach does not work for the &dyn case, which is useful but maybe not critical

Is this a worthwhile goal?

I think so, and i believe we have achieved this reasonably well with the i2c/spi bus traits

r? @eldruin
(rust_highfive has picked a reviewer for you, use r? to override)

Thank you @ryankurte for working on this! I appreciate that you're making a concrete proposal here. That said, I don't like it :-)
I do have the following problems:

While this makes Pwm easier to use, it doesn't improve the core problems with the module as a whole. PwmPin is still here. Now I can move the PwmPin implementation somewhere else, but still change that channel's duty cycle from somewhere else.
As @eldruin noted, this adds a runtime error, which I'd like to avoid.
I think this is too opinionated and not flexible enough. As a HAL author, I'd like to implement something that is more flexible (provide the ability to move a single channel to another context, for example) and more solid (no needless runtime errors). As a driver author, I might only need a single channel (i.e. the ability to set duty cycle of a signal, not change frequency as a whole). With this proposal, I'd either build my driver on PwmPin, which makes it possible to mess with my operation by using Pwm from somewhere else, or I'd use the whole Pwm implementation, blocking resources I don't need.

(Side note: The conflict between Pwm and PwmPin and related problems can be solved by some runtime management of channels. The Pwm implementation could keep track for which channels a PwmPin instance exists for, and hand out runtime errors accordingly. I'd again argue that this is too opinionated. As a HAL author, I wouldn't want to write runtime code to manage something that could just as well be solved at compile-time using move semantics.)
Aside from these big-ticket criticisms, I'm wondering if embedded-time would be better than core::Duration. I've just started using it, so I can't say with certainty that it would be a good idea, but it seems it's specifically designed for cases like this.
Regarding the replacement of Duty, I see the following problems:

If you use a type that's too small (e.g. u8), you might give up precisions on hardware that, for example, has 32-bit timers.
If you use a type that's not suited for the target hardware (e.g. u32 on an AVR, or f32 on a Cortex-M0), you make embedded-hal unattractive for that target hardware.

I think this is pretty obvious, but I wanted to spell it out. All those type parameters and associated types exist for a reason. Yes, they are a pain to build abstractions on top of, and we pay a price in complexity, but the alternative might be to make embedded-hal less useful as a general abstraction. (And as a side note, personally I wouldn't mind if all number types were u32 or i32, as that would fit my use case perfectly. I'm just saying, if we want to be general, we might need to pay for that in complexity.)

I'd like to provide a counter-proposal that I think is more flexible and more robust. It would completely replace the current traits.
This is also only a draft, and a quick one at that. I haven't thought all aspects through (we might want to support type state for enabled/disabled channels, for example, which this proposal does not). And I haven't had a chance to try this in real life yet.
trait EnableChannel {
    type Error;

    fn try_enable(&mut self) -> Result<(), Self::Error>;
    fn try_disable(&mut self) -> Result<(), Self::Error>;

First, a separate trait for enabling/disabling channels. A HAL that wants to support one type per channel, can implement this directly on the channel type (channel.try_enable()). If this is not possible or desired, it can be implemented on an intermediate type and integrated into the timer API (timer.channel1().try_enable()).
trait Period {
    type Period; // or embedded-time, or `core::Duration`, I don't know

    fn try_set_period(&mut self, period: impl Into<Self::Period>) -> Result<(), Self::Error>;
    fn try_get_period(&self) -> Result<Self::Time, Self::Error>;
}

On the hardware I've seen, the period can be set once per timer and affects all channels of that timer (which is represented in the current traits). So most likely, HALs would implement this on timers directly (timer.try_set_period()), but on more exotic hardware, having it as a separate trait provides flexibility.
trait Duty {
    type Error;
    type Duty;

    fn try_set_duty(&mut self,  duty: impl Into<Self::Duty>) -> Result<(), Self::Error>;
    fn try_get_duty(&self) -> Result<Self::Duty, Self::Error>;
    fn try_get_max_duty(&self) -> Result<Self::Duty, Self::Error>;
}

Like the EnableChannel trait, this can be implemented on a channel type (channel.try_set_duty(duty)), or through an intermediate type for the timer (timer.channel1().try_set_duty()).

So much for the traits themselves. Now my thoughts on how to abstract over them. I'll use drivers for motor controllers as an example, as that's what I've been thinking about recently.
Example 1: DC Motor Driver
I think for a DC motor, you just need to control the duty cycle to control speed. So the driver would just take ownership of a Duty implementation, which on typical hardware corresponds to a channel. You can control multiple motors using the same timer.
timer.try_set_period(some_appropriate_value)?;

let motor1 = DcDriver::new(channel1);
let motor2 = DcDriver::new(channel2);

If, for some reason, you can't separate timers and channels (my timer.channel1().try_set_duty(duty) example from above), you can either give the intermediate type to DcDriver, which would likely have a reference to the timer, or you could transform your timer into a new type that implements both Period and Duty for a given channel (timer.into_channel1()). I can't think of a reason why this would be necessary. I'm just saying this model provides options.
Example 2: Stepper Motor Driver
To a stepper motor driver, the duty cycle doesn't matter much. It needs control over the period. One option is for the driver to require an impl Period and an impl Duty:
let motor1 = StepperDriver::new(timer1, channel1_1);
let motor2 = StepperDriver::new(timer2, channel2_1);

Another option is for the driver to require one single type that implements both Duty and Period. Whether to do this is up to the driver author. Either the HAL or the user of the driver and the HAL can easily accommodate this by providing an additional type that wraps the timer and one of its channels.
let timer_and_channel = TimerAndChannel::new(timer, channel1); // API is up for debate
let timer_and_channel = channel1.upgrade(timer); // maybe this instead; doesn't matter to embedded-hal anyway

let motor = StepperDriver::new(timer_and_channel);

As I said, this is just a quick draft. I'm going to have need for solid PWM traits in the near-ish future (timeline is a bit unclear; it's a side project and I got lots to do), including traits that abstract over DMA-powered PWM. So unless someone preempts me with another solution, I will likely try to implement my proposal on both the driver and HAL sides.
Elsewhere I've floated the idea of doing this in an embedded-pwm crate, which would take away some burden from embedded-hal (allowing for a 1.0 release that much sooner) and merging the traits back into embedded-hal, once matured.

thanks for looking at it, all fair criticisms. the key point to me is to address the use of generic traits by consumers, though i am sure there are many ways to go about this and happy with any that do adequately provide abstraction over Pwm and PwmPin instances.

While this makes Pwm easier to use, it doesn't improve the core problems with the module as a whole. PwmPin is still here. Now I can move the PwmPin implementation somewhere else, but still change that channel's duty cycle from somewhere else.

yeah, i didn't intend to address this initially. splitting the traits as you suggest seems reasonable, though the split methods or similar cannot easily be represented in our traits (at least without const-generics). i have updated the PR with an approach to mitigate this, definitely interested in what you come up with when you get to working on this.

Regarding the replacement of Duty, I see the following problems ...

keeping the Duty type is not so bad as far as things go, especially if we can loose some other associated types and if it is only implemented over primitive / numerics, though with a further point about associated type bounds at the end.

Aside from these big-ticket criticisms, I'm wondering if embedded-time would be better than core::Duration. I've just started using it, so I can't say with certainty that it would be a good idea, but it seems it's specifically designed for cases like this.

once embedded-time has stabilised and been adopted here this may be a good option, however, for now this means we avoid an additional (unstable) dependency and it'll just work (tm) with std::time::Duration for linux users. nothing precludes using  core::time::Duration as the interface between e-h and e-t to achieve (i believe) the same outcome.

Elsewhere I've floated the idea of doing this in an embedded-pwm crate, which would take away some burden from embedded-hal (allowing for a 1.0 release that much sooner) and merging the traits back into embedded-hal, once matured.

i have wondered about this too, we could remove all the unfinished / blocked traits from the 1.0.0 release and work towards re-implementing them later. this does however seem pretty annoying for hal users who will have to pay the porting penalty twice (and work out what to do with missing functionality in between) :-/ maybe something that could be raised with the larger working group.

I think this is pretty obvious, but I wanted to spell it out. All those type parameters and associated types exist for a reason. Yes, they are a pain to build abstractions on top of, and we pay a price in complexity, but the alternative might be to make embedded-hal less useful as a general abstraction.

absolutely, the problem is that every associated type that isn't usefully generic breaks the abstraction, and any additional complexity either in or due to our e-h traits is something that the entire ecosystem has to content with, it's tradeoffs all the way down.
As it stands, it is currently impossible to write a Something<P: Pwm> implementation crate without a concrete implementation for each possible Pwm instance (and associated types) you may wish to use, which imo isn't a useful generic abstraction.
due to compiler constraints it's also impossible to box (or &dyn) a trait using associated type bounds (you must to specify the concrete underlying type), so while adding conversion bounds can smooth the associated type interoperability pains in some situations, it only addresses function inputs, and breaks in frustrating and irreconcilable ways in others. we have to work out what the midpoint is but, i am sure we can improve the existing trait on all fronts ^_^

yeah, i didn't intend to address this initially. splitting the traits as you suggest seems reasonable, though the split methods or similar cannot easily be represented in our traits (at least without const-generics). i have updated the PR with an approach to mitigate this, definitely interested in what you come up with when you get to working on this.

I don't think a split method (or any other architecture that a HAL might choose) needs to be represented, or even should be. We don't do this for any of the other modules. Why do it here?

once embedded-time has stabilised and been adopted here this may be a good option, however, for now this means we avoid an additional (unstable) dependency and it'll just work (tm) with std::time::Duration for linux users. nothing precludes using core::time::Duration as the interface between e-h and e-t to achieve (i believe) the same outcome.

embedded-time can work with core::time::Duration, but as that link states, "Due to the inner types used by core::time::Duration, a lot of code bloat occurs when it is used.". I haven't checked how significant that is, but one of the stated goals of embedded-hal is to be zero-cost, which a forced conversion from u32 to core::time::Duration, back to u32, for example, definitely wouldn't be.
You said "for now", and I totally agree that core::time::Duration is good enough for now. I don't think it would be good enough to release with 1.0, unless a very clear and informed decision has been made, that other options (like embedded-time) are not acceptable.

i have wondered about this too, we could remove all the unfinished / blocked traits from the 1.0.0 release and work towards re-implementing them later. this does however seem pretty annoying for hal users who will have to pay the porting penalty twice (and work out what to do with missing functionality in between) :-/ maybe something that could be raised with the larger working group.

The fact is, there are interfaces in embedded-hal which are not ready (otherwise we wouldn't be able to have this discussion), and the goal of the working group (as far as I know) is to release embedded-hal 1.0. These two points are in conflict, and there is some price we have to pay to resolve this conflict:

Remove stuff from embedded-hal, make it more difficult for users of that stuff.
Delay the 1.0 release of embedded-hal, until said stuff has matured.
Release un-matured traits with embedded-hal 1.0.

It's not my call to make, but out of these I think option 3 is the only unacceptable solution. My fear is that the desire to avoid option 2 will lead to option 3, which is why I favor option 1.

hey thanks for all the reviewing! again i don't really intend to land this just, think it useful to explore the problem space. probably be good to do some impls / drivers to prove any approach but, doesn't seem worth the time without more direction / consensus.

embedded-time can work with core::time::Duration, but as that link states, "Due to the inner types used by core::time::Duration, a lot of code bloat occurs when it is used.

ohhhh, i always forget there's a u64 in there :-/

I don't think it would be good enough to release with 1.0, unless a very clear and informed decision has been made, that other options (like embedded-time) are not acceptable.

relates to https://github.com/rust-embedded/embedded-hal/issues/211, it seems to me this would also block e-h on the stabilisation and adoption of e-t into the wg. wrt the rest of your points this may need more wg-wide discussion but, i agree that option 3 is the least desirable outcome / would aim to keep chugging away with -alpha releases until we get it all polished.

hey thanks for all the reviewing! again i don't really intend to land this just, think it useful to explore the problem space. probably be good to do some impls / drivers to prove any approach but, doesn't seem worth the time without more direction / consensus.

Thank you again for the proposal and the discussion! Totally understood that this isn't intended to be the final solution. I hope I don't come across as too stand-offish. Like you, I'm interested in exploring the problem space and pointing to potential problems where I see them.

I don't think it would be good enough to release with 1.0, unless a very clear and informed decision has been made, that other options (like embedded-time) are not acceptable.

relates to #211, it seems to me this would also block e-h on the stabilisation and adoption of e-t into the wg. wrt the rest of your points this may need more wg-wide discussion but, i agree that option 3 is the least desirable outcome / would aim to keep chugging away with -alpha releases until we get it all polished.

Yes, it would. No idea how pratical that would be in the near-term. Personally, I'd be fine chugging away with alpha release for the next few years, if that's what it takes. Given the overall push for 1.0 though, I'd imagine that would be a problem for some people. Hence my idea of taking problematic areas off the table, via an embedded-pwm and maybe other crates along those lines.

After this whole discussion and some thinking, I looked at the current traits with fresh eyes again, and I think I've been wrong about most things I said about them:

The biggest misunderstanding I've been hung up on is that the channel argument in Pwm and the type implementing PwmPin are somehow supposed to be the same type. This can't work (which was part of my criticism), but I now believe that it would be fundamentally wrong to try and do it, or somehow enable it by modifying the traits.
My other misunderstanding (which I based a criticism on) is that the existence of Pwm and PwmPin are in conflict. I no longer think they are, and the right way to implement it seems quite obvious in retrospect (and probably has been obvious to everyone else the whole time): Pwm is what exists initially. PwmPin must either invalidate Pwm once it comes into existence (via split()), or PwmPin must be a field of Pwm, which would make Pwm impossible to use once a PwmPin is used separately (i.e. moved somewhere else).
My own proposal is wrong and should be discarded. It doesn't support the use case of needing to set the period and duty cycle for multiple channels. It only allows for either setting the duty cycle of multiple channels or the period and duty cycle for one.

With these new insights, I think that the current traits capture two different use cases and need to be kept. At least I can't think of a way to substantially improve upon them (modulo the details, like embedded-time or bounds on Duty, as discussed above).
From my perspective, this leaves one thing wrong with the current traits: That abstracting over them requires a Copy or Clone bound on Pwm::Channel (which @ryankurte addresses in #246).

Based on my new understanding, I'm thinking that the changes made in this pull request are a step in the wrong direction:

I'm still doubtful that converting Duty into a generic argument is a good idea, for the reasons expressed above.
I believe that using usize for the channel argument is a step in the wrong direction.

I'd like to expand on that second point a bit:

Unless we assume that HALs provide separate APIs for generic use (i.e. embedded-hal trait impls) and concrete use (i.e. the API of that specific HAL), which is the opposite of what I've seen in the wild, we also have to consider how changes to embedded-hal affect the concrete use case. Here, the switch to usize is a clear loss in type safety.
It also wouldn't be zero-cost, as the usize argument will have to be checked for validity in all methods that accept it. While an enum, on the other hand, can be relied upon to only provide valid values.
I don't even think it would be a win from the driver perspective (although this has yet to be proven by experience; I have not yet tried to write a driver on top of the current traits):

The driver would need an additional check in its constructor (e.g. if Timer::MAX_CHANNELS < 2 { return Err(...); }). This incurs another runtime cost that wouldn't be needed otherwise (not zero-cost) and it might complicate the driver API (might require a Result where none would be needed otherwise, and adding a source of panics is never good either).
With the current traits, the driver could just take the channels that are relevant to it as arguments to its constructor, which would be zero-cost (e.g. fn new<Timer>(motor1: Timer::Channel, motor2: Timer::Channel) or even fn new<Timer>(motors: &[Timer::Channel])).

replying to lots of comments here because, we're a bit everywhere 😂

With 1.0 out, we could lock ourselves into a non-optimal situation, where most drivers require some bounds, but not always the same ones, and not all HALs provide them (if the duty type were a newtype, and not u16/u32 directly, for example).

yep, gotta be careful of all this eh. with i2c we've sealed the traits so Addr can only be a u8 (7-bit) or u16 (10-bit), could do something like that if required i guess (and extending the allowed types is non-breaking).

I think this would be an unfortunate situation. It's fine for SPI/Serial, as there's a standard type that every HAL provides in practice (u8), but I don't see such a standard type here (as timers have different resolutions). Not sure what the best solution here is.

the resolution thing is interesting but, as a fundamental a timer has some count register width and as a low level abstraction it seems reasonable to me to bound duty to the appropriate width (like u16) with a MAX_DUTY constant representing the top value? on your classic ARM platform it might even always be a u32 for register width, but with const MAX_DUTY: u32 = 2^12 or whatever.

If there's one implementation-defined value of Duty, it should be an associated type. Associated types are less cumbersome to abstract over, in my experience, as they don't have to show up as a type parameter on the methods or impl blocks of the driver.

oh, the other reason to do this is i believe (though may have missed something) on cannot have a const MAX_DUTY: Self::Duty. not critical as we can also express this with fn max_duty() -> Result<Self::Duty, ..> as the trait currently is. i suspect this might not be quite as compiler optimizable but, i'm also not sure what the implications of associated constants on type bounds are either so...

With the current traits, the driver could just take the channels that are relevant to it as arguments to its constructor

yeah passing a Pwm and an array of channel objects (or, an array of PwmPins, tho that may require some fun dyn tricks) isn't at all unreasonable / is how i intend to mitigate this with my radio.Channel trait. and switching to by reference per 246 makes this possible, totally onboard with this.

the resolution thing is interesting but, as a fundamental a timer has some count register width and as a low level abstraction it seems reasonable to me to bound duty to the appropriate width (like u16) with a MAX_DUTY constant representing the top value? on your classic ARM platform it might even always be a u32 for register width, but with const MAX_DUTY: u32 = 2^12 or whatever.

I think I said somewhere before, as far as I'm concerned, we could make it u32 everywhere and be done with it. But my use case is not the only one, and we have to consider the goals of embedded-hal. I've seen lots of timers with resolutions of 31 or 32 bits, so u16 is the wrong choice (not general enough). Using u32 seems like it wouldn't be zero-cost for lower-resolution timers, especially on 16-bit or 8-bit platforms (although I don't have a good enough intuition about how the compiler might optimize certain cases to really be sure).
I'm going off of the stated design goals here. I think it's totally reasonable to want a simple abstraction layer that works well enough on common embedded platforms and is not necessarily zero-cost on all of them. In that case, u32 would be good enough everywhere. It goes against the design goals and established precedent of embedded-hal though.

oh, the other reason to do this is i believe (though may have missed something) on cannot have a const MAX_DUTY: Self::Duty. not critical as we can also express this with fn max_duty() -> Result<Self::Duty, ..> as the trait currently is. i suspect this might not be quite as compiler optimizable but, i'm also not sure what the implications of associated constants on type bounds are either so...

Interesting, I didn't know about that limitation.
Short note: You say duty, but I think you're talking about the period. The maximum duty will depend on the timer period, which is runtime adjustable, while the maximum period is a constant value that depends on the timer resolution.

Short note: You say duty, but I think you're talking about the period. The maximum duty will depend on the timer period, which is runtime adjustable, while the maximum period is a constant value that depends on the timer resolution.

yeah, i have conceptually combined period and duty on the basis that they're usually the same width (with the same maximums), which is the justification for a type parameter over this (which can be u32 or u16 or u8 as appropriate). perhaps this would be better termed Width or something.

yeah, i have conceptually combined period and duty on the basis that they're usually the same width

Ah, understood, makes sense.

closing now PWM has been removed, see #358 for reintroduction


BTD not working/loading after new OldTweetDeck update

Describe the bug
BTD 4.11.3 not working/loading with new OldTweetDeck update
To Reproduce
Update OldTweetDeck to 4.0.2
MacOS 14.6.1
Firefox Nigthly 131.0a1 (2024-08-15)
OldTweetDeck to 4.0.2

same
BTD 4.11.3 not working/loading with new OldTweetDeck update
Win10 Pro x64 22H2 build 19045.4780
Firefox Dev 130.0b6 (64-bit)
OTD 4.0.2 (since rolled back to 3.6.8)

same BTD 4.11.3 not working/loading with new OldTweetDeck update Win10 Pro x64 22H2 build 19045.4780 Firefox Dev 130.0b6 (64-bit) OTD 4.0.2 (since rolled back to 3.6.8)

When you rolled back to 3.6.8, did BTD work again?

yes, all is well with rollback to OTD 3.6.8 + BTD 4.11.3

Can confirm BTD not working with latest build, rolling back to before 4.0 fixed it.

I can confirm that it doesn't work. At least, it doesn't work very well. In fact, I've noticed that if I refresh my page several times, I manage to get BTD to load. But I'm going to do as the others do and put back an old version.


[keyvault] add py.typed files for each module

see https://github.com/Azure/azure-sdk-for-python/issues/9572

Resolved by #18327