Added filtering for dereferenced nodes

Ability to filter which schema can be dereferenced by checking its contents.
Usage
    const refParser = require("json-schema-ref-parser");

    refParser.dereference(originalJsonSchemaObj, {
        // dereference the following schemas: model properties, path & query parameters
        dereference: {
            filter: (value) => {
                return ['query', 'path'].includes(value.in)
                    || ['string', 'array', 'integer', 'number', 'boolean'].includes(value.type);
            }
        }
    }).then((schemaDerefed) => {
        // ...
    });

Effect
Before:
      "AccountDepositPaytrailInitRequest": {
        "type": "object",
        "properties": {
          "amount": {
            "$ref": "#/components/schemas/Record/properties/amount"
          },
          "itemName": {
            "$ref": "#/components/schemas/ItemSearchResult/properties/name"
          },
          "userId": {
            "$ref": "#/components/schemas/UserRearchResult/properties/id"
          }
        },
        "required": [
          "amount",
          "itemName"
        ]
      },

After:
      "AccountDepositPaytrailInitRequest": {
        "type": "object",
        "properties": {
          "amount": {
            "type": "integer",
            "description": "Money amount.",
            "example": 17500
          },
          "itemName": {
            "type": "string",
            "description": "Technical name of the product (item).",
            "minLength": 1,
            "maxLength": 128,
            "example": "EXERCISE_EMONEY"
          },
          "userId": {
            "type": "integer",
            "description": "User identifier.",
            "readOnly": true,
            "minimum": 1,
            "example": 1
          }
        },
        "required": [
          "amount",
          "itemName"
        ]
      }

Pull Request Test Coverage Report for Build 368

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 92.768%

Totals

Change from base Build 364:
0.1%

Covered Lines:
7381

Relevant Lines:
7788

💛  - Coveralls


Disable omnibar scrolling when on new tab page

Task/Issue URL: https://app.asana.com/0/72649045549333/1207845944313948/f
Description
Disable omnibar scrolling on new tab page.
Steps to test this PR
See task

#4776  👈
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @marcosholgado and the rest of your teammates on  Graphite


2.0 wip: Fix vertical layout for navbars with different heights

I just added a little bit of LESS math to make the layout in the navbar to scale properly if you change the value of the navBarHeight variable. This will affect the vertical position of links, buttons, search fields and brands. It also makes the vertical dividers stretch to the full height.
This is my first pull request so let me know if I've done anything wrong!

Great idea to make the navbar more easily customized

Cool... I'll try to think of a cleaner way to do this when I have some free time!


added location path of mplog file

as per user report #8796 , i added the location of  MPLog-xxxxxxxx-xxxxxx.log , file path after cross-checking on Windows 11.

@schmurky Please merge this PR. Thanks


Fronius meter model (240) not showing up in selection

I have a Fronius inverter & meter installed.
I can manually query both model 1 (Inverter) and 240 (meter) without issue.
The Integration is working well for the Inverter, but model 240 (meter) does not show up in the selection.
I'm not proficient at coding so I haven't figured out how to trace what may be missing.

What models are showing up in the select menu? (either in step 2 of initial setup or if you click "Configure" from the integrations screen)
Model 240 is not enabled by default but if your inverter supports it it should be able to add it using that select menu, in theory at least :)

1,111,120,121,122,123,160 all turn up in the selection box. Only 1,111 & 160 having useful live readings but they all work otherwise.
Using QModMaster I'm scanning slave 240 address 40071->40192 without an issue. I've got a NodeRed process reading data out atm, but it is a pain to maintain in its current form. I've already used this to replace the nodered readings for the inverter, so just the Meter is left now.

It sounds like the inverter and meter are actually two separate modbus slaves, the inverter having slave id 1 and the meter have slave id 240?
In that case it should be possible to have to set up two devices, first add the inverter using slave id 1 and then create another for the meter using slave id 240. The meter, if it supports SunSpec, should have models in the 200 range (most likely model 201 for a single phase meter).
Does that help?

Yes that right the ID of the first fronius meter is on a Symo Hybrid 240, not the model. The first inverter is ID 1.
If you have a gen24 the meter starts with ID 200.

Both slaves are addressed by the one interface card. e.g. x.x.x.x:502
The integration scans for slaves, currently finds 1,111,120,121,122,123,160, but not 240.
How do I setup a second device to the same card and get a different result?

It sounds like the inverter and meter are actually two separate modbus slaves, the inverter having slave id 1 and the meter have slave id 240?
In that case it should be possible to have to set up two devices, first add the inverter using slave id 1 and then create another for the meter using slave id 240. The meter, if it supports SunSpec, should have models in the 200 range (most likely model 201 for a single phase meter).
Does that help?

As you figured out it does not scan for slaves, it scans for SunSpec models (Modbus registers).
I haven't been able to test multiple instances of the integration so it's nice to hear that it seems to work!

Give me 24 hours to confirm. Bad weather right now, so only the meter is giving me real readings. Once I get some sunlight I'll be able to confirm both are working simultaneously as expected.

You have to setup two integrations one with ID 1 and one with ID 240, regardless the weather you have instantly the values…

may it help if the ID is presented in the overview behind the up-port.

You have to setup two integrations one with ID 1 and one with ID 240, regardless the weather you have instantly the values…

Correct, but until both are showing live data changing frequently (e.g good solar weather) there is no proof both are working correctly with good refresh rates.

may it help if the ID is presented in the overview behind the ip-port.

Agreed. Multiple ID's behind the same interface is messy.


Slow compiler feedback

Hey,
I'm trying to build a small web app with your project, but I've noticed that even with only 3 files and ~300LoC Visual Studio as well as VSCode are consuming a lot of resources and the feedback from the compiler is very slow. I'm wondering if that's due to the high usage of CEs? Anyone else seeing such behavior or maybe it's something on my machine?
Also, I tried to switch to the Template.html syntax, but unfortunately it looks like it's not part of the Fun.Blazor.Wasm Nuget package V 2.0.0-beta006, is that expected? Never mind, after looking at the readme again, I saw that I've to use Fun.Blazor.HtmlTemplate ;-)
Thanks in advance and keep up the great work!
Marc

I think I saw this myself as well with the generated bindings from MudBlazor, I dropped them for a spare project I had and things improved a bit

@marcpiechura I noticed this today with my another project(MyLogs). It maybe related to CE. If you keep your single file smaller it may be faster. And you can try to declare some variables for your UI fragment to avoid too much code for a single fragment of UI, which may help.
I will try to figure out why. I am also not sure if inline is the issue.

According to the feedback from fsharp repo, CE it is not suitable for large DSL definition which is so sad because I spend a lot of time on this.
But luckly, for default dom attribute I can use a static class (which need to open explicitly) or module  to define them to reduce the custom operations. It should work. I hope.

Just tried it. Even I moved all the attr operation out of the CE builder, it is still very slow when code grows. It looks like you just cannot have too much stuff put into the CE body.
div {
    // We cannot put too much lines or nest too much lines in a single CE
}

Sperate them in multiple block can help:
let v1 =
    div {
        ...
    }
div {
    v1
    ....
}

I do think so. According to the issue comment it just the problem of CE:

However there should be no real expectation that using CEs on very large inputs will be free of some downsides - it's in their nature.

If you do below things it should be ok for IDE perf, and it will also help comipler to do better inline to reduce allocation and also help on readability:

Keep your single file small
Keep your single CE block small

@albertwoo that's unfortunate, I really liked the CE style :(
I switched to the html templates, since I'm fine with having less type safety on the view side and it works pretty well.
Nonetheless, I'm continue to use Fable + React for now, the missing hot reload feature is ruin it for me. I could live with loosing state and doing a full page reload on every change, but the wait time is simply to long compared to the sub second hot reload from Fable + React. (I know that's not the fault or your library).
I'll have to wait until the .Net team finally implements HR for F# projects and then will come back as a happy user ;-)
Thanks,
Marc

@marcpiechura fable is great. I use it too.
 Limited hot reload is implemented, you can check: https://funblazor.slaveoftime.fun/hot-reload


Trouble building this with my Webpack config

Hi, I am very new to all this and this is how I build my js/css bundles:
webpack --mode production --optimize-minimize --progress
Using this command however produces the following error:
ERROR in ./node_modules/alwan/dist/js/alwan.min.js 1:10685
Module parse failed: Unexpected token (1:10685)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders

I suspect my current Webpack config cannot work with minimized js files? Can you please advise what to do?
Thanks!

You can rebuild alwan color picker and output it as esm module.

Is there an easy way to do this?

Clone the repository the you can modify the config file in scripts/webpack.common.js, set the output.library.type  to var.
then build it using the command npm run build.


PoC of race condition between reload() and cleanTombstones()

@roidelapluie
Adding a test on top of release-2.25 branch that proves the race condition

Closing as the test is not representing the real behavior


Unit send targets should be by ID

The internal data format should be changed: units should be optionally given a running ID and send targets should be identified by their ID. Trying to keep the send targets synced to all mutations currently is a pain and likely source of bugs.
IDs can be stripped for units that don't need them during save, to keep the overall file format clean.
The question of polyphonic sends remain. There are a few possible solutions:

Still have optional "voice" parameter, which defines target voice (relative to the instrument). 0 = auto ("if this is local send, then target the same voice that is currently getting run, otherwise just voice 1"), 1 = voice 1, 2 = voice 2 etc.
Try to use the polyphony bitmask to repeat sends during run time
Try to pack the number of voices sent into lodsw data. Unlikely to work, as we already use all 16 bits (3 for ports, 1 for POP, 1 for global send, 6 for unit, 5 for voice)... LEB128 encoding might be future proof, but could theoretically make some send addresses 3 bytes long, while sometimes making them 1 byte (first bit must be 0, 3 bits for unit, 1 for POP, 3 for port... actually might work in some cases)... The LEB128 decoding in the beginning of send might result in further juggling for the carry flag.
Multisends, with completely new address for every send, and one bit snipped from unit number to indicate if there's a new address coming. If so, repeat the entire send, starting from lodsw.

The system is now implemented as with option 1; auto = same voice (local send) if targeting unit in the same instrument; auto = first voice if global send


fix(field-group): enable invalid slot when invalid prop is true

To Reviewers

[ ] Skipping review is not a problem (style, chore ONLY)
[x] Not that difficult

Type of Change

[ ] New feature
[x] Bug fixes
[ ] Feature improvement

[ ] These changes require a usage change

[ ] Others (performance improvement, refactoring, CI/CD, etc.)

Checklist

[x] Updated Storybook documents
[x] Tested with console

Description
SSIA
Things to Talk About

:tada: This PR is included in version 1.1.0-beta.405 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add a possibility to specify that a TC/TS should be run with threadsafe disabled

We have quite some functions marked as threadsafe in MIES.
Currently when an RTE happens in such a function it gets not visible to the IUTF, when threadsafe is enabled.
However, a lot of tests can also be run with threadsafe support disabled and then the IUTF would catch such RTEs that are currently hidden.

From discussion on 25 Mar 2024:

add tag on a per TestSuite basis to run suite with disabled ThreadSafe.
run TestSuite regular and when tagged also with disabled ThreadSafe


Add support for ListSeparator after const (closes creditkarma/thrift-parser#12)

+1

Closed by e1a5d2870b706b9bc4d349c8e8e84b4fa7f20292


BLE notifications does not work on HexiWear

BLE notifications does not work for some characteristics, e.g. the mode characteristic.
But notifications works for battery characteristic, for example.

app.startNotifications = function() {
// but first, read static data.
app.status("Reading data...");
app.readCharacteristic(app.INFO_SERVICE, app.INFO_MANUFACTURER, "manufacturer", evothings.ble.fromUtf8);
app.readCharacteristic(app.INFO_SERVICE, app.INFO_FIRMWARE, "firmware", evothings.ble.fromUtf8);
app.readCharacteristic(app.INFO_SERVICE, app.INFO_SERIAL, "serial", app.convertHexData);
app.readCharacteristic(app.BATTERY_SERVICE, app.BATTERY_CHARACTERISTIC, "battery", app.convert8bitPercentageData);
app.readCharacteristic(app.MODE_SERVICE, app.MODE_CHARACTERISTIC, "mode", app.convertModeData);
// OK, now we can do notifications.
app.enableNotification(app.BATTERY_SERVICE, app.BATTERY_CHARACTERISTIC, "battery", app.convert8bitPercentageData);
app.enableNotification(app.MODE_SERVICE, app.MODE_CHARACTERISTIC, "mode", app.convertModeData);

// or not. These services do not support BLE notification, even though you would expect it.
// Polling is possible, but quite inefficient by comparison.
// app.enableNotification(app.MOTION_SERVICE, app.MOTION_ACCELEROMETER, "accel", app.convert3x16bitData);
//app.enableNotification(app.MOTION_SERVICE, app.MOTION_GYRO, "gyro", app.convert3x16bitData);
//app.enableNotification(app.MOTION_SERVICE, app.MOTION_MAGNET, "magnet", app.convert3x16bitData);

// Let's try polling instead.
app.timer = window.setInterval(app.poll, 1000);

}
app.poll = function() {
app.readCharacteristic(app.MOTION_SERVICE, app.MOTION_ACCELEROMETER, "accel", app.convert3x16bitData);
app.readCharacteristic(app.MOTION_SERVICE, app.MOTION_GYRO, "gyro", app.convert3x16bitData);
app.readCharacteristic(app.MOTION_SERVICE, app.MOTION_MAGNET, "magnet", app.convert3x16bitData);
app.readCharacteristic(app.WEATHER_SERVICE, app.WEATHER_AMBIENT, "ambient", app.convert8bitPercentageData);
app.readCharacteristic(app.WEATHER_SERVICE, app.WEATHER_TEMPERATURE, "temperature", app.convertTemperatureData);
app.readCharacteristic(app.WEATHER_SERVICE, app.WEATHER_HUMIDITY, "humidity", app.convertHumidityData);
app.readCharacteristic(app.WEATHER_SERVICE, app.WEATHER_PRESSURE, "pressure", app.convertPressureData);

app.readCharacteristic(app.HEALTH_SERVICE, app.HEALTH_HEART, "heart", app.convertHeartData);
app.readCharacteristic(app.HEALTH_SERVICE, app.HEALTH_STEPS, "steps", app.convert16bitUnsignedData);
app.readCharacteristic(app.HEALTH_SERVICE, app.HEALTH_ACTIVITY, "activity", app.convert16bitUnsignedData);

}

Turns out this is by design, notifications are not available for all characteristics. Closing issue.


how to use filter When superset + shillelagh to get data from api

I installed shillelagh on superset to get data from api
I am running weatherapi demo and datasettes demo which works fine
but filter function seemed not working. How to make superset filter working?
Any suggestions are welcome
SQL on superset:
SELECT * FROM "https://san-francisco.datasettes.com/sf-trees/Street_Tree_List" LIMIT 5

Did you press UPDATE CHART button at the bottom? The chart says "Your chart is not up to date" (means it has not been refreshed after you changed your settings)

Did you press UPDATE CHART button at the bottom? The chart says "Your chart is not up to date" (means it has not been refreshed after you changed your settings)

yes. i did clicked the update chart button. then the "Your chart is not up to date" tip show


Whether the training parameters depend on the camera settings

Hi, since the normalized depths don't consider the camera settings, I guess all training and test data should have the same focal length and baseline. Is my understanding correct?

You get it. The normalized depth map is derived by setting the minimum disparity or maximum depth of the dataset. This is a general statistical value and should be set for every target dataset.

Understood. Thank you.


Rename functions scripts

@yquansah @glinton Shouldn't this be included in contracts/cloud as well?

No, contracts/cloud and contracts/oss are carryover from the single-file-to-describe-the-world days and were never intended to include definitions from new sub services. Here, we opted for granularity for developer satisfaction (extrapolate the "single file" idea out to an api the size of amazon and it's clear to see it isn't a great idea (someone targeting only route53 apis shouldn't be forced into everything else)). For those who demand an all-encompassing file, we still provide them in contracts/ref/. Otherwise, the preferred consumption method is to produce client libraries for each subsystem in the api so they can be utilized individually. That doesn't stop us from packaging those clients up into a hierarchical pattern to match programming languages. For example, our golang client libs could be structured something like:
/influxdb
  /tasks  \
  /write    | -> currently all coexist inside the cloud/oss definitions, but will one day (hopefully) be split out.
  /query  /
  /scripts
  /annotations
  /any-other-service-specific-client


Update client_resume.md

resumetoken not resumeid
Was trying to find out why my code was not working for hours

Ah, thank you. Nice catch.


imageLayer does not call appendImage on all images

For this PDF I would suspect that imageLayer's appendImage would be called on all diagrams in the PDF, but from what I can tell this is not so. It is just called for some micro images displayed for QED symbols.

appendImage only works for images included either as standard XObjects, or as inline images (i.e. using BI-ID-EI operators).
Most of the "figures" in that PDF file are actually just comprised of standard PDF drawing operators, occurring at various positions within the Contents streams, meaning that it isn't possible to know that those should be regarded as "images".
Closing as answered, since this isn't something that we can realistically fix.
(And a work-around would most likely require a lot of potentially slow heuristics, with many false positives, for a use-case that isn't really relevant to the core library.)


windows dev setup recommends install of babun

step 6 recommends installing babun which is officially discontinued as of january this year
an alternative should be found somehow. like mingw or cygwin or something like that.

I'm currently working on getting a proper setup to run maybe I can fix the docs then. But I'm happy for anybody else who wants to help out

I don't run windows... But docksal has an issue like this as well, and I think they're moving to just using WSL: https://github.com/docksal/docksal/issues/1004

that's not a bad idea at all. I just use the git bash that's installed with git for windows but using WSL could work too

curl http://localhost:8065/api/v4/system/ping                                                                                /cygdrive/c/Go/src/github.com/mattermost/mattermost-server
curl: (7) Failed to connect to localhost port 8065: Connection timed out
how should i solve this?thx

I'm gonna do a setup on my windows machine and check if WSL works fine for the setup. @jespino Can you assign this issue to me? I'll raise a PR to update the docs accordingly.

Alternatively, I'm thinking should we remove the Windows tab completely since we already have a setup documentation for Windows WSL? @svelle

Alternatively, I'm thinking should we remove the Windows tab completely since we already have a setup documentation for Windows WSL? @svelle

good point @singh-sarabjeet at the time of opening the issue the WSL section wasn't available yet so I'd be good with removing that section. However I'm not part of the dev team this is not my decision to make so I'd wait for feedback from @jespino and other folks from engineering.

@svelle Sounds good. In the meantime can you assign this issue to me?

@singh-sarabjeet assigned to you, I'm not very familiarized with the windows environment, maybe @hmhealey have an strong opinion here.

Will wait for reply from @hmhealey . Also, @svelle was there a JIRA ticket associated with this?

That would probably make sense. I haven't developed MM on Windows myself, but I know of a few people on the team who use WSL primarily, so those instructions should be stable enough.

Please check and approve the PR. I also realised there are no instructions for windows setup for Mattermost documentation. I had to engineer my way by using WSL to install make, homebrew and then Hugo. I think these steps are required on README. @svelle can you create an issue for that or maybe I can report it.


fix switch subsampling and downsampling bug

PR checklist

[X] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

Yes XD, I think the versions were moved to prettify and then it stopped working but it wasn't tested. Could be worth it adding a test where every switch is off.


Refactor Register email notification

Popup is shown off of screen not aligned with form

Create & Register blocked because of this hence the block chain of having the other two issues blocked


Unable to install gmp and bcmath extensions on i386

Describe the bug
In the past week, i386 builds that depend on the bcmath or gmp extensions have started failing. Looking at the build logs, it appears that the extension setup is failing:

Previously, this worked file.
The amd64 builds work as expected. I did try downgrading to 2.52.2, but that did not seem to help. I did not debug it further.
Version

[X ] I have checked releases, and the bug exists in the latest patch version of v1 or v2.
[X] v2
[ ] v1

Runners

[X] GitHub Hosted
[ ] Self Hosted

Operating systems
Ubuntu on i386.
PHP versions
7.2-8.2
To Reproduce
https://github.com/maxmind/MaxMind-DB-Reader-php/blob/f8cd5d7f83e36b8f1b8de7e3dea149739f7a1bfd/.github/workflows/test.yml#L9-L61
Expected behavior
For gmp and bcmatch to be installed.
Screenshots/Logs
See above.
Additional context
None.
Are you willing to submit a PR?
I don't have any real insight into where the problem is.

@oschwald
The shivammathur/node i386 image is based on Ubuntu 18.04. I haven't found a newer Ubuntu i386 image and ppa:ondrej/php does not support Ubuntu 18.04 anymore as it is deprecated.

Thank you for the update. That is unfortunate. I think 18.04 was the last LTS release to support i386.
Maybe it would be worth adding a note to the extension section of the documentation.

@oschwald I have switched the base for i386 containers to Debian 12 in https://github.com/shivammathur/node-docker/commit/0c55baf6ab661edbd285c1e245224f3bab6c9e2b. So this should work again.

Thank you!

@oschwald
I cannot reproduce this, it might be that the PPA was down, please try running it again.
https://github.com/shivammathur/test-setup-php/actions/runs/5701114466/workflow


Implement authorization framework

Currently, authorization is not handled consistently. This issue would address this by implementing an authorization system via the gem Action Policy. This would set up a framework to unify authorization logic as well as help guide devs to set up future authorization logic.
Goals:
Implement

[ ] Add Action Policy gem
[ ] Implement verify_authorized is called in ApplicationController to force all controller actions to require authorization
[ ] Create Policies for every controller that requires them. Use skip_verify_authorized for actions that should not require authorization. ActionPolicy::UnauthorizedAction error should never raise in production.
[ ] Have another contributor create and implement a policy to confirm ease of use with Action Policy gem for others.

Testing

[ ] Create test file for each Policy class created.
[ ] Create controller tests to test the required authorizations are performed.

Notes:

Since Rolify is being used, these roles should be integrated with authorization checks.
If Action Policy is deemed to not fit well, we can migrate most of this logic over to Pundit instead.

I will start working on this now. Please assign me if you have permission. Thanks!

@mononoken great thank you for taking the initiative! This will be a great addition.

#466 is working on this one. Can someone add it to the development of this issue? I think that will prevent the bot from marking this as stale.

#466 is working on this one. Can someone add it to the development of this issue? I think that will prevent the bot from marking this as stale.

Done!


Update Inian's title

"Building Supabase Storage. DevX, performance, security - choose three"

fixed in #97


no error when accessing undefined property on sealed object

Please consider the following example: https://flowtype.org/try/#0C4TwDgpgBAglC8UDeAoKUCGAuKA7ArgLYBGEATgDRpTE4DOwZAlrgOYoC+KKAZvrgGNgTAPa5MGMAAoWYfMBwwAlKihMeM3HOAA6ASupQBYuiIA2EHWZGtN2vUoDcaLmq3ydAEwRQAzM64UY1wGN21FHyRsAEYKGhwAcgALCDNrBI5nDEk7eScgA
Why do I get an error on accessing input.d but not when accessing input.c? I have refactored my code and renamed one of the properties and would expect problems on all checks for the old property name.

This is intended as reading an undefined value essentially gives you undefined. You're only logging it. If you tried to use the value as a non-null value Flow would catch it.

@nmn Sorry but I completely disagree. The object is sealed for a reason, I know what the properties of the given object are. It can never be intentional to reference a property which is not part of my type annotation.

I'm having the same issue as @hmeerlo. I would expect the if statement to give me an error. I have never defined ID in my type so why would I reference it?. If I do the same check with a function then I would get an error.
On multiple occasions I have changed some property name and every if statement that checks if the old property is defined gives no errors.
example


Detail the Molecule installation using conda

This workshop assumes that all are consistently using pipenv in order to manage Python dependencies, however, there were multiple participants who were instead required to use conda.

These tasks do not seem to require more than just avoiding the usage of Virtualenv and Pipenv, as the conda documentation just guides one to use pip alone: https://docs.anaconda.com/anaconda-cloud/user-guide/tasks/work-with-packages/#installing-pypi-packages


Token Name and Logo not showing in wallet

-After readding my token with a new Logo and name with the correct token address ,these changes are not reflected in my wallet e.g Phantom , however all changes are seen on Solscan

Same issue here. Something's not working quite right as I've made my commit on Friday and still hasn't propagated properly on client wallets. (It was almost instantly picked up by solscan and explorer)

different apps sync from this repo at different rates
i believe phantom is a lot less frequent than solscan


How to enable voting for guest users (not logged).

Hello, could you please provide more details on how to enable the voting feature to guest users? I have followed the instructions from the docs, but I may be missing something, since it's not working as expected.
Thanks in advance!

Installed it on a site today and adding add_filter( 'hmn_cp_allow_guest_voting', '__return_true' ); to my plugin worked without a problem.
The vote buttons are now displayed for guests too and they can vote as usual.

thanks @swissspidy for confirming. I did check but forgot to update here.


Hpatches issue

the url for the Hpatches dataset doesn't work

Indeed, it seems to not be working for me as well. But this should be reported in the original HPatches dataset, not here.


Added preset system.

I tinkered around a little bit with the preset system and got it working.
-TheAsian EggrollMaker

Thanks! Appears to work perfectly.


Add Dynamic Repeat

Still a draft rn.
(Edit, ready for review):
Adds a static repeat operator
Works by transforming
repeat num_repeats {repeat_body}

into
initialize cond_reg = 1; idx = 0;
while cond_reg.out {
  body;
  cond_reg = (idx + 1 < num_repeats)
  idx +=1;
}

I also made some changes to the domination analysis: I realized that there was
an edge case (repeats w/ num_repeats=0 should be ignored in the dominator map) and added
a test case.
Also a correctness test case for compiling static repeats. (I turned static-promotion pass
off for this test case just to be able to test the compilation of dynamic repeats)

Awesome! Does static-promotion also support promotion using it now or is that another PR?

Yep, it promotes to static repeat if the body is static.

(Obviously not actionable in this PR). Next step could be to get CIRCT Calyx to support repeat statements, and then making the MLIR->Calyx flows supporting repeat statements.

Yeah, I see what you're saying, and was actually thinking along the same lines as you. Maybe I could do the following changes:

Implement the repeat simplification in the canonicalization pass, and get rid of the special cases for the analyses.
For the domination stuff, maybe we should throw an error if we see the "repeat 0" case? Because the analysis is literally incorrect if we treat "repeat 0" like the other "repeat" statements.

This is looking good to me! Let's merge it when you're ready @calebmkim!


[Bug] SAFARI : Page crashes on Safari on trying to add action

Steps to reproduce:

Add an widget (Button, Text)
Click to open property pane
Navigate down to "On Click"
Select to add any action
and observe

Observation :
It is observed that the application crashes on try to add an action to the button
Expectation :
The application must not crash and user must  be able add an action to widget

Screenshot of console log from chat

@hetunandu from the console log, this looks like a string was undefined in https://github.com/appsmithorg/appsmith/blob/release/app/client/src/components/editorComponents/actioncreator/ActionCreator.tsx

@hetunandu from the console log, this looks like a string was undefined in https://github.com/appsmithorg/appsmith/blob/release/app/client/src/components/editorComponents/actioncreator/ActionCreator.tsx

This is on Safari version 12
matchAll is only supported across ~86% devices
https://caniuse.com/?search=String.matchAll

This is on Safari version 12
matchAll is only supported across ~86% devices
https://caniuse.com/?search=String.matchAll

We have no users on the unsupported versions on Appsmith cloud today. (@areyabhishek checked)
If that changes, we can re-open and take this up.
In case this becomes important to solve later,  you can either

use a shim
Change implementation in ActionCreator

If you plan to use String.match, you might need to skip \g.

A decent path forward might be to warn users on unsupported browser versions.
Something along the lines of #1228

We have no users on the unsupported versions on Appsmith cloud today. (@areyabhishek checked)
If that changes, we can re-open and take this up.
In case this becomes important to solve later,  you can either

use a shim
Change implementation in ActionCreator

If you plan to use String.match, you might need to skip \g.

A decent path forward might be to warn users on unsupported browser versions.
Something along the lines of #1228

On an Observation of the Stats we see that number of user on this particular browser is less and hence closing the issue for the issue

On an Observation of the Stats we see that number of user on this particular browser is less and hence closing the issue for the issue


How to copy/paste/share terminal text output cleanly?

To show someone a series of terminal commands and their output, it is nice to copy/paste the entire terminal text, prompt and all. oh-my-zsh's default theme was pretty clean for this. powerlevel9k however introduces some noise. Pasting it into a regular web text area, there are special symbols that render as boxes. powerlevel9k's right-aligned content, like the current time, often goes way off the right edge of the screen. What is the recommendation for copy/pasting powerlevel9k terminal output cleanly?
Example direct paste:
 ~/S…/P…/powerlevel9k  master  git branch -r                                                                                 ✓  08:55:40
  origin/HEAD -> origin/master
  origin/debug-svn-icon-color
  origin/master
  origin/merging-awesome-font-fix
  origin/nerdfont-complete
  origin/next
  origin/zsh-async-integration
 ~/S…/P…/powerlevel9k  master  git checkout merging-awesome-font-fix                                                                                 ✓  08:55:43
Branch merging-awesome-font-fix set up to track remote branch merging-awesome-font-fix from origin.
Switched to a new branch 'merging-awesome-font-fix'
 ~/S…/P…/powerlevel9k  merging-awesome-font-fix  git remote -v                                                                                 ✓  08:55:49
origin  git@github.com:bhilburn/powerlevel9k.git (fetch)
origin  git@github.com:bhilburn/powerlevel9k.git (push)

@john-kurkowski - You're right in that this can be problematic.  Unfortunately,  I don't know of a good way to resolve this.
Unfortunately, adding a command that disables parts or all of the prompt to make it easily selectable also won't help, because the terminal emulator wouldn't do this for text that has been already printed - you would have to do it preemptively.
Does anyone else have thoughts on this? I agree it's obnoxious, but I'm honestly not sure it's fixable.

@john-kurkowski I don't think there is a good way to get a clean copy of the terminal output, because the prompt was already printed. These boxes are characters that can not be rendered correctly in the application you paste the content to. Comparing a prompt theme that has no special characters with p9k is a bit unfair, IMHO.
Usually that noise comes from copying the prompt as well. Only way to get that working is to redo your commands and disable p9k prior to that - or redirect the command output to a file. Both ways are no good, because you have to redo your commands which is annoying..

Yeah, I'm just not sure what could be done here.
Adding a command that toggles the prompt on/off is probably our best option, to be honest. It would require you to do it pre-emptively, but that's better than nothing, I suppose. That shouldn't be too hard to implement, as it's simply making a function available to toggle a flag that, if enabled, bypasses the prompt rendering.

Well, I copied a lot of text with an enabled powerlevel9k.
Here is an example of my favourite 'pastebin' called filebin:
The important stuff is still readable.

Another option is a screenshot or to mark only the important text without the prompt.
I don't think this is really a problem

I updated the original comment with an example paste. The prompt is noisy and the timestamps are way off the screen.

@shibumi Your example isn't bad! As you can see from my OP, my prompt does not paste as cleanly. Is your pastebin doing anything special that pasting into e.g. GitHub doesn't?
Can you link to your favorite pastebin? (There are a few hits on Google for "filebin")

Another option is a screenshot or to mark only the important text without the prompt.

A screenshot is a fallback, sure. Though not great for copying a long subset of the paste, like a hash or URL. Not great for screen readers. Often it's not up to the paster to determine what part of it is the "important text."

Okay, I think @docwhat provided the best option we are going to get in #525, which has now been merged into next. You can now call prompt_powerlevel9k_teardown to go back to a very minimal prompt, which is much more copy/paste-able.
Update your branch to the HEAD of next and enjoy =)

I'll give it a try! Thank you!


Add Splitting Delegations

Hi all,
Really like the work you've done here after a skim read over myself.
I think a cool feature (I was thinking of building a dApp for this myself but you guys have beaten me to it :)) would be to split delegations equally across a number or all restake validators. Say I want to delegate 1000 JUNO, and there are 5 restake validators, they would each receive 200 JUNO. I think it would help promote decentralisation across the network.
Especially if more validators onboard with this.
Apologies if this is in the wrong place, but happy to hear your thoughts.

Hey @Callum-A - love this idea! Right now it would only be the manual claim/compounding this would affect as the validator is only authorised to delegate to themselves (although have some ideas here in the future too).
I think what would be really nice.. is a 'bulk actions' feature. Checkboxes to choose the validators you want to affect, then options to:

Delegate to multiple (splitting the total)
Claim from multiple (currently can do all or 1)
Compound multiple (takes the total rewards from selection and splits between selection)

Potentially the boring stuff like undelegate/redelegate too.
Would fit in nicely into the UI and not a challenging thing to build. I'll get this into the todo list asap!

Hey @Callum-A - love this idea! Right now it would only be the manual claim/compounding this would affect as the validator is only authorised to delegate to themselves (although have some ideas here in the future too).
I think what would be really nice.. is a 'bulk actions' feature. Checkboxes to choose the validators you want to affect, then options to:

Delegate to multiple (splitting the total)
Claim from multiple (currently can do all or 1)
Compound multiple (takes the total rewards from selection and splits between selection)

Potentially the boring stuff like undelegate/redelegate too.
Would fit in nicely into the UI and not a challenging thing to build. I'll get this into the todo list asap!

Yeah I definitely support the addition of mass actions. Nice work!


Add IAMGroup as a custom resource

What problem are you facing?
AWS IAM resources such as IAMUser, IAMRole and IAMPolicy are already supported by provider-aws. It would be nice to have IAMGroup. There can also be support for creating a relation between an IAMUser  and IAMGroup resources
How could Crossplane help solve your problem?
Add a CRD and the respective controller for managing AWS IAM Group resource. Also, use the reference pattern in Crossplane to create a member relationship between IAMGroup and IAMUser

fixed via https://github.com/crossplane/provider-aws/pull/249


Update recipe to production release

:tada: This issue has been resolved in version 2.1.1 :tada:
The release is available on:

GitHub Release
NuGet Package
Chocolatey Package


Ingest data on late-T and Y dwarfs from Leggett 2021 compilation

Closes #261
T and Y dwarf sources and photometry from the Leggett et al. 2021 compilation in their Appendix C: https://iopscience.iop.org/article/10.3847/1538-4357/ac0cfe#apjac0cfeapp3. Converted the table to a Google Sheet: https://docs.google.com/spreadsheets/d/1MMuo9MXfaQ09wqlcblFdi0rN5hfhWjWzeEciD0jqaig/edit?usp=sharing
Citation: S. K. Leggett et al 2021 ApJ 918 11
DOI: 10.3847/1538-4357/ac0cfe

Improvements ideas from @Will-Cooper :

Use string.replace
make Leggett ref names and SIMPLE ref names some kind of dictionary to loop through.

Regarding the binary names, we agreed on this format:
A: WISE 014656.66+423410.0
B: WISE 014656.66+423410.0B

Original data is here: https://docs.google.com/spreadsheets/d/1MMuo9MXfaQ09wqlcblFdi0rN5hfhWjWzeEciD0jqaig/edit?usp=sharing

This is ready for review. Not sure of the best way to review it since so many JSON files got touched.
I think I might add some more tests. Here's a link to the commit that has most of the changes in test_data. Given how big of an ingest it was, I feel like I should have had to change more.

For future PRs: we should try and give a description of what the pull is about. For example, where can we find the Legget 2021 compilation? Is there a paper or URL to go to?
Also, what is the nature of the ingest: we are adding X sources or we are adding Y photometry from Z instrument. That can go a long way into what we expect to see in the changes, especially when working asynchronously, and for capturing a descriptive history.
In this case I see 584 brown dwarf changes, with some being brand new sources. Most changes appear to be publication name updates, but there is also new Spitzer IRAC photometry for some subset of the changed brown dwarfs.

I'll approve this since it's working fine in terms of the database changes, but something we should think about for a quick follow up: we should mention some aspect of this ingest in the Versions table, which was not updated as part of this PR.

Added more info to the PR description and updated Versions table.


Dream image every time a new contract is created.

Looks great, thanks for setting this up!
Note: the Manifold Dream bot's image will be different than the cover image, unless we sync on a seed (which we could do, probably by just using/hashing the slug). See the Stability SDK https://github.com/Stability-AI/stability-sdk

I'll look into it.


Shifting Login Page to centre

I'm an LGMSOC participant, as we see the login page slightly upwards so I will shift the login page to the centre of the page to look better

@NOiR-07 any updates?

@NOiR-07 any updates?

Sir, i can't find the file where code of login page is written

It's in client/src/components/auth

It's in client/src/components/auth

BUT THERE IS NO HTML FILE

We work on react to we have js file

We work on react to we have js file

OKAY

@NOiR-07 you know the react js .

@NOiR-07 you know the react js .

not much

Respected mentor,
I am a participant from "Developer Days". Can i also contribute to this?

Hello mentor,
I would like to take up this issue !
I am into MERN development since last 1 year
Understanding basic css can easily solve this issue
But my knowledge about grid, flexbox would really help me!

Go ahead @adarsh45

@Tejas1510 the deployed site and the one in code (/client) are different
And in the repo's code there is no need to center, as it is already done
Is there any different branch to work on this issue ?

I think it's done... You can vertically align them @adarsh45
Give a minHeight of 100vh and can bring the card at center vertically

You can go ahead @onifs10

@AmeyaJain-25  what we have on the repo is different from what we have on the live demo .. and the from is well align from what i have here

Hosted link isn't updated.
And you have to align the box vertically center


freebsd.libc: break into many small derivations

The freebsd libc derivation is this monster which compiles many many libraries. This breaks it up into many small derivations and symlinkjoins them together.
Most of this diff is just the new files and the destruction of the big libc file. There are some knock-on effects that some of these libraries were already packaged but only for the bootstrapping (host != freebsd) cases. These were renamed to have a -boot suffix and dependent packages were adjusted.
Things done

Built on platform(s)

[x] x86_64-linux (freebsd cross)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Very much like splitting it up! But can we do this without -boot though? Just adding some conditional stuff to those packages should work fine.

It would be helpful if https://github.com/NixOS/nixpkgs/pull/337351 were merged before we work on non-hacky solutions for -boot.

Debooted. This entailed adding some more patches to make the makefiles work as expected in both cases (mostly related to installing with chown). I had to merge this with a different patch that touched the same file for a different reason, so the diff looks a little funky.

@ofborg eval


wayfire and wcm had a 0.3.1 release

This is an issue for updating the relevant ebuilds. ;)
At least wayfire and wcm have now 0.3.1 versions.

Great I've added the newer versions for wayfire and wcm!
Am still working on the default install bug (?!).


 I will add it to the documentation when it is complete.

I wonder if mempool should be behind it's own resource, instead of blocks since it only indexes events and events/<event> ( i.e. is not totally symmetrical with other block resources.
/mempool/events
/mempool/events/<event>

Just a few minor thoughts for the /transactions/compose/ API.  You are going to need to post data anyway here, so I don't think it's necessary to have /compose.  Could just be a POST to /transactions.  To that end, would it be more clear to call this endpoint something like /rawtransactions to make it explicit that this is not tantamount to a create and broadcast?  Also, maybe it would be nicer from the callers standpoint to pass the transaction type as data in the POST request?   Question for you: are these resources paginated?

A basic pagination only for some queries (with the parameters last and limit)

I wonder if mempool should be behind it's own resource, instead of blocks since it only indexes events and events/<event> ( i.e. is not totally symmetrical with other block resources.
/mempool/events
/mempool/events/<event>

I hesitated.. we can say that the mempool contains the next block, it's a mental view, but in the code it is managed like that with a block_index=999999999.. as you wish I can change easily ..

Just a few minor thoughts for the /transactions/compose/ API. You are going to need to post data anyway here, so I don't think it's necessary to have /compose. Could just be a POST to /transactions. To that end, would it be more clear to call this endpoint something like /rawtransactions to make it explicit that this is not tantamount to a create and broadcast? Also, maybe it would be nicer from the callers standpoint to pass the transaction type as data in the POST request? Not 100% sure.

hum..  I am sure that all our requests must be GET and there must be no POST. We open the database in read only mode and no queries modify the database. Also in most cases the url is formed with a script/CLI or something else, I don't think this is a problem.

I wonder if mempool should be behind it's own resource, instead of blocks since it only indexes events and events/<event> ( i.e. is not totally symmetrical with other block resources.
/mempool/events
/mempool/events/<event>

I hesitated.. we can say that the mempool contains the next block, it's a mental view, but in the code it is managed like that with a block_index=999999999.. as you wish I can change easily ..

Yeah I think we should have a dedicated route and later fix  that magic number block index, which bothers me :/ (it's my fault originally!)

I wonder if mempool should be behind it's own resource, instead of blocks since it only indexes events and events/<event> ( i.e. is not totally symmetrical with other block resources.
/mempool/events
/mempool/events/<event>

I hesitated.. we can say that the mempool contains the next block, it's a mental view, but in the code it is managed like that with a block_index=999999999.. as you wish I can change easily ..

Interesting.  I presume these requests would be errors?
/blocks/999999999/sends
/blocks/mempool/sends

Interesting. I presume these requests would be errors?
/blocks/999999999/sends /blocks/mempool/sends

yep

Just a few minor thoughts for the /transactions/compose/ API. You are going to need to post data anyway here, so I don't think it's necessary to have /compose. Could just be a POST to /transactions. To that end, would it be more clear to call this endpoint something like /rawtransactions to make it explicit that this is not tantamount to a create and broadcast? Also, maybe it would be nicer from the callers standpoint to pass the transaction type as data in the POST request? Not 100% sure.

hum.. I am sure that all our requests must be GET and there must be no POST. We open the database in read only mode and no queries modify the database. Also in most cases the url is formed with a script/CLI or something else, I don't think this is a problem

I think this is slightly murky territory.  You are not looking up an existing resource, but creating an ephemeral one.  In any case, I think passing data as JSON will be more familiar to web developers building on top of the platform relative to serializing in the URL.  We could pass JSON in a GET, but that too would be non-standard.

Just a few minor thoughts for the /transactions/compose/ API. You are going to need to post data anyway here, so I don't think it's necessary to have /compose. Could just be a POST to /transactions. To that end, would it be more clear to call this endpoint something like /rawtransactions to make it explicit that this is not tantamount to a create and broadcast? Also, maybe it would be nicer from the callers standpoint to pass the transaction type as data in the POST request? Not 100% sure.

hum.. I am sure that all our requests must be GET and there must be no POST. We open the database in read only mode and no queries modify the database. Also in most cases the url is formed with a script/CLI or something else, I don't think this is a problem

I think this is slightly murky territory. You are not looking up an existing resource, but creating an ephemeral one. In any case, I think passing data as JSON will be more familiar to web developers building on top of the platform relative to serializing in the URL. We could pass JSON in a GET, but that too would be non-standard.
Just my 2 cents 🤑

nah I don't think so.. there is no question of resource here.. a raw transaction is not one.. etc.. we make a REST API so let's respect the basic principles.. here we only read and use data (from the bitcoind and counterparty db) to construct a response... no matter the size of the response or the request, this is not what determines whether we must do a GET or a POST (this is the case for example of charts API which uses huge urls). It's easy for a developer to convert a json, a dict or anything into an url.

The basic principles of REST do not dictate that a resource is created after a POST.
https://stackoverflow.com/questions/19843480/s3-rest-api-and-post-method/19844272#19844272
And while it is possible for developers to serialize data in URLs, it is non standard from the perspective of most web developers and requires an explicit encoding step.  Obviously it can be done it just creates a bit of friction.
In any case, it's your call! :)

Hm, this is a tough one. I think we're not retrieving any (existing) resource, so GET feels wrong to me. And there are already times when using POST for idempotent operations is totally fine. Also think that passing the params in the URL is indeed awkward.
I think we should use POST /transactions/compose. POST /transactions/ makes it look like you're writing to the DB, as would POST /rawtransactions/. These would obviously be more ReSTful, but I think sticking with good HTTP is more important than following ReST principles where they don't apply.

Hm, this is a tough one. I think we're not retrieving any (existing) resource, so GET feels wrong to me. And there are already times when using POST for idempotent operations is totally fine. Also think that passing the params in the URL is indeed awkward.
I think we should use POST /transactions/compose. POST /transactions/ makes it look like you're writing to the DB, as would POST /rawtransactions/. These would obviously be more ReSTful, but I think sticking with good HTTP is more important than following ReST principles where they don't apply.

Yes we retrieve utxo from the bitcoind database and we check data from the counterparty database. Using a GET is not weird and using a POST makes no sense other than preventing developers from doing what is necessary, which is to say building a URL. Using a POST to make a request that does not do any writing to the database is a design error.

I'm not aware of any specification and convention that requires a POST to trigger any change to server state. I'm going by https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3, which is pretty clear that all that is necessary is that the server "target resource process the representation enclosed in the request according to the resource's own specific semantics" and that no resources need to be created as a result of processing the request.
I also think it's actually nice to use GET for retrieving network state and POST for generating ad hoc data, esp. when the latter requires a proper payload.

I'm going by https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1
The compose method returns a representation of inputs and outputs in transaction form. I think using a POST here is ugly, non-standard and useless.

esp. when the latter requires a proper payload.

This is not a good enough reason to use a POST. It is nowhere written that a url does not contain a payload. We are not talking about a domain name but a URL systematically generated by code.

esp. when the latter requires a proper payload.

This is not a good enough reason to use a POST. It is nowhere written that a url does not contain a payload. We are not talking about a domain name but a URL systematically generated by code.

I agree with all of that, and that's why I wrote "esp."! :)

I'm going by https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1

The GET method requests transfer of a current selected representation for the target resource.

So this does not describe what we are doing—the newly constructed transaction is not a set of already extant inputs and outputs. The request to compose a tx is really a request to "process", not to "transfer". In any case, I totally hear what you're saying, but I think we should proceed with POST /.../compose. Yes, it'd be simpler and cleaner in some sense to just use GETs, but I think it's not quite as correct, and it's no uglier than HTTP in general. ;)

Let's include this only into v10.0.4.

Note about API design
The idea behind the new API is “one route, one function”. Example:
in api/routes.py:
...
ROUTES = util.prepare_routes(
    {
        ### /blocks ###
        "/blocks": ledger.get_blocks,
        "/blocks/<int:block_index>": ledger.get_block,
        "/blocks/<int:block_index>/transactions": ledger.get_transactions_by_block,
        "/blocks/<int:block_index>/events": ledger.get_events_by_block,
        ...
    }
)
...

in ledger.py:
def get_blocks(db, last: int = None, limit: int = 10):
    """
    Returns the list of the last ten blocks
    :param int last: The index of the most recent block to return
    :param int limit: The number of blocks to return
    """
    ...

The new API uses type annotations and docstrings to generate route arguments, default values, and documentation.
curl http://api:api@localhost:4000/ returns:
{
  "backend_height": 839940,
  "counterparty_height": 839940,
  "network": "mainnet",
  "server_ready": true,
  "version": "10.1.0"
  "routes": [
    ...
    {
      "path": "/blocks"
      "description": "Returns the list of the last ten blocks",
      "args": [
        {
          "default": null,
          "description": "The index of the most recent block to return",
          "name": "last",
          "required": false,
          "type": "int"
        },
        {
          "default": 10,
          "description": "The number of blocks to return",
          "name": "limit",
          "required": false,
          "type": "int"
        }
      ],

    },
    ...
  ]
}

this output will be used to automatically generate a blueprint/swagger.

moved here https://github.com/CounterpartyXCP/counterparty-core/pull/1716


Update Composer dependencies (2024-09-10-00-09)

Visual regression test passed!
View the visual regression test report


[vue3-apollo-quasar] Fix profile story data not loading

Profile related stories do not load profile data in stories

This is because they try making a request to the github graphql API which ends up being unauthorized. That means the story that should contain profile information (username, profile pic) ends up blank.

Acceptance

The profile story data should be mocked and not come from a live call

Notes
See #533 - we're adding some utilities there to help

This is blocked by #533 .


retain registry in image ref

stop removing the registry from the index.json image ref annotations during cosign save.
expect the original registry to be part of the image ref annotation during cosign load and replace it with target registry.

Let's discuss this during tomorrow's meeting before merging?

Yeah that's the plan.  I meant to set this as draft.  I'll do that now.

I'm going to break things into 2 separate annotations to be more compatible with older versions.

PR updated to reflect last comment.  io.containerd.image.name added as an additional annotation in index.json.
with registry specified:
cosign save rgcrprod.azurecr.us/rancher/mirrored-elemental-operator:1.6.4 --dir ./store
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
         "size": 708,
         "digest": "sha256:d6cbb5dbd733a118f541e5fe827d04b9efa4338efa6ef9e9c334f375f8e6e76a",
         "annotations": {
            "io.containerd.image.name": "rgcrprod.azurecr.us/rancher/mirrored-elemental-operator:1.6.4",
            "kind": "dev.cosignproject.cosign/imageIndex",
            "org.opencontainers.image.ref.name": "rancher/mirrored-elemental-operator:1.6.4"
         }
      },
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "size": 2995,
         "digest": "sha256:e8f14b91431fda303243a87fb5d47575374c3ef2e9b8fb90f6fab2dcb634b7fc",
         "annotations": {
            "io.containerd.image.name": "rgcrprod.azurecr.us/rancher/mirrored-elemental-operator:1.6.4",
            "kind": "dev.cosignproject.cosign/sigs",
            "org.opencontainers.image.ref.name": "rancher/mirrored-elemental-operator:1.6.4"
         }
      }
   ]
}

without registry specified:
cosign save rancher/mirrored-elemental-operator:1.6.4 --dir ./store
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
         "size": 708,
         "digest": "sha256:d6cbb5dbd733a118f541e5fe827d04b9efa4338efa6ef9e9c334f375f8e6e76a",
         "annotations": {
            "io.containerd.image.name": "index.docker.io/rancher/mirrored-elemental-operator:1.6.4",
            "kind": "dev.cosignproject.cosign/imageIndex",
            "org.opencontainers.image.ref.name": "rancher/mirrored-elemental-operator:1.6.4"
         }
      }
   ]
}


Remove deprecated in future React Component lifecycle methods

As discussed in #150 remove React.Component lifecycle methods that marked as UNSAFE in React 16.3.0 release.

@contra I updated PR with UNSAFE prefixes, but i think in future all updates will be in componentDidUpdate

I think this is outdated so I'll close PR.


What else does this plugin do?

This is a questions and maybe a documentation update request.
From docs we have:

This plugins does the following:
It provides commands to create and run tests manually
It provides a command to create a function, which automatically also creates a test

Seems that the plugin also loads environment variables from serverless.yml. If it was only for the aliases commands mentioned I would be using plain mocha instead. So I was wondering, are there any other differences between running the tests with plain mocha and running it with sls invoke test?

@leeomaax For now sls invoke test sets the env variables and then runs the tests. This may extend in the future (e.g. building the package and running tests on the actual code to be deployed). I clarified the docs to include the info. Thanks for the feedback.


Suggestion: "Inverse" mode where tree chopping only happens while sneaking (or other keybind)

Basically the opposite of when sneaking does normal log breaking

Hi Eggshells, that actually already exists, but it's not well-documente. Press n to turn chopping off (the key can be changed in Options > Controls). While it's off, sneaking will cause you to turn chopping on instead of off.
I should probably include this in a FAQ on the mod page.

Hi Eggshells, that actually already exists, but it's not well-documente. Press n to turn chopping off (the key can be changed in Options > Controls). While it's off, sneaking will cause you to turn chopping on instead of off.
I should probably include this in a FAQ on the mod page.

I see. Thanks!

I see. Thanks!


Implement functionality of PTT speech assistant

User story

As a user
I want to be able to trigger a Push-to-talk (PTT) speech interaction in the speech assistant context area
So that I can simulate what the tested app does when a PTT speech interaction is triggered, e.g., when music is playing at the moment of triggering a PTT speech interaction.

With this user story, the functionality of triggering a PTT speech interaction is to be implemented, i.e., when a steering wheel button is pressed.
A TTT (tap-to-text) interaction will be implemented with another user story, i.e., when a software button on the screen of the car is pressed.
Notes
Android Automotive documentation: https://source.android.com/docs/devices/automotive/voice/voice_interaction_guide
For testing the PTT interaction, it is not essential which speech input is actually given and therefore does not need to be actually understood, i.e. the understood speech input can be faked.
It is essential for the user to see how a tested app handles it when a speech interaction is triggered, e.g., when music is currently playing.
Example 1:

Button for speech assistant on steering wheel is pressed (PTT-interaction).
After button was pressed, the system listens to what is being said, e.g. "I am cold."
After 5 secs, the car confirms understanding the speech input by a short audio sound, e.g. a ping sound.
The car turns up the heat.

Example 2:

Button for speech assistant on steering wheel is pressed (PTT-interaction) while music is playing.
After button was pressed, the music pauses and the system listens to what is being said, e.g. "Call XY."
After 5 secs, the car confirms understanding the speech input by a short audio sound, e.g. a ping sound.
The car keeps the music paused and calls person XY.

Acceptance criteria

There is a button to trigger a PTT speech interaction in the speech assistant context area.
When triggering the interaction, the speech listener takes focus and the app listens to what is being said.
When another audio action is currently running, e.g., music is playing, the action is paused-
After 5 secs, a sound should confirm that the speech input was understood (actual speech input does not have to be understood; can be faked).

Definition of done (DoD)

Code compiles and builds
Acceptance criteria are met
Tests have been written and were passed
Code is peer-reviewed
Feature is merged into development branch
Documentation is updated
Bill of Materials is updated

DoD general criteria

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

It is not clear if we are supposed to implement a whole Voice Interaction Application(VIA). This would have the side-effect of becoming registered by the car and overriding the default VIA and therefor beeing called when pushing the real PTT button, while providing no real functionality.
Same applies to #108


Add better docs for FasterRCNN, MaskRCNN and KeypointRCNN

This also adds a bugfix in the default value for the MaskRCNNPredictor, which was discovered when adding a different backbone.
This doesn't change the default behavior nor the default models, but is simpler when one wants to specify a custom backbone.

Codecov Report

Merging #943 into master will decrease coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #943      +/-   ##
==========================================
- Coverage   60.26%   60.19%   -0.08%
==========================================
  Files          63       63
  Lines        5001     5002       +1
  Branches      745      745
==========================================
- Hits         3014     3011       -3
- Misses       1784     1787       +3
- Partials      203      204       +1

Impacted Files
Coverage Δ

torchvision/models/detection/faster_rcnn.py
74.39% <ø> (ø)
:arrow_up:

torchvision/models/detection/keypoint_rcnn.py
81.81% <ø> (ø)
:arrow_up:

torchvision/models/detection/mask_rcnn.py
81.35% <100%> (+0.32%)
:arrow_up:

torchvision/transforms/functional.py
69.9% <0%> (-1.22%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05bc255...801c5db. Read the comment docs.


[stable/prometheus-rabbitmq-exporter] doesn't show up in the targets

Describe the bug
The rabbitmq exporter doesn't appear in the targets
Screenshot

Version of Helm and Kubernetes:
$ helm version
Client: &version.Version{SemVer:"v2.14.2", GitCommit:"a8b13cc5ab6a7dbef0a58f5061bcc7c0c61598e7", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.2", GitCommit:"a8b13cc5ab6a7dbef0a58f5061bcc7c0c61598e7", GitTreeState:"clean"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-20T04:49:16Z", GoVersion:"go1.12.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:36:19Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
stable/prometheus-rabbitmq-exporter
What happened:
I've deployed prometheus from stable/prometheus-operator. Then I've deployed Elasticsearch and RabbitmQ exporters from stable/elasticsearch-exporter stable/prometheus-rabbitmq-exporter with the following config:
elasticsearch-exporter:
  serviceMonitor:
    enabled: true
    interval: 30s
    labels:
      release: prometheus-operator
  es:
    uri: "http://es-development-master:9200"

prometheus-rabbitmq-exporter:
  rabbitmq:
    url: http://rabbitmq-development:15672
    user: admin
    password: FzWRcdWwmOtOM8b_o0
  prometheus:
    monitor:
      enabled: true
      interval: 30s
      additionalLabels:
        release: prometheus-operator
      namespace:
        - development

Elasticsearch appeared in the targets, but RabbitmQ didn't
What you expected to happen:
The rabbitmq exporter appears in the targets
How to reproduce it (as minimally and precisely as possible):
Install stable/prometheus-rabbitmq-exporter with the settings above or the default ones
Anything else we need to know:

I also have the same issue with the rabbitmq exporter. It does not show up in the targets list

What is the exporter logging?

I guess that the chart doesn't support prometheus-operator servicemonitor sd

Any news on this or any idea what needs to be fixed?

#15801  should fix this issue whenever it is merged in

Actually it may be fixed already with this https://github.com/helm/charts/commit/0a9b8a2db04baee6573f9d30b343f492e4fb1642
Try your rabbitmq exporter again with the latest chart

closed by #15801

Aug 13 - Issue was fixed by #0a9b8a2 (PR #16134) -  0.5.2
Sep 15 - Issue happening again because PR #15801 - 0.5.3
See more details at https://github.com/helm/charts/pull/15801#issuecomment-542181611


[Task]: Replace DeepDiff with MicroDiff for faster diffing

Is there an existing issue for this?

[X] I have searched the existing issues

Why MircoDiff ?
Benchmarks
According to the benchmarks mentioned it claims to be 200% faster then deep-diff for large objects.
Benchmarks: Small object
deep-diff: 17929ns - 409% slower
deep-object-diff: 10763ns - 206% slower
jsdiff: 79700ns - 2164% slower
microdiff: 3520ns - Fastest

Benchmarks: Large Object
deep-diff: 272887ns - 259% slower
deep-object-diff: 160019ns - 111% slower
jsdiff: 1688294ns - 2123% slower
microdiff: 75934ns - Fastest

SubTasks

[ ] POC to test microDiff for different object diff cases with different dataTypes
[ ] Write test similar to klona for microDiff to verify it works for all our cases
[ ] Replace it with deep-diff
[ ] Handle all the evaluation code accordingly ( dependencyMap code might get impacted by this )

@satbir121 should we pick this up given the bold benchmark claims?


Use GHA to send a PR to start.spring.io upon Solver release

Otherwise the Timefold version over there gets stale.
Current situation: Timefold 1.5.0 was released mid december, but spring initializer uses Timefold 1.3.0 (mid oct).
Update the version here:
https://github.com/spring-io/start.spring.io/blob/main/start-site/src/main/resources/application.yml#L137

The upgrade to version 1.5.0 was merged without a PR, so the automated process may only require an issue to be created. As discussed, we may need to share a matrix of compatible versions for validating dependencies.

This couldn't have been tested completely without doing a release.
Therefore the actual test will happen during the release.


500 error when streaming

Get the following page (500 error) when attempting to stream any of my tracks. The network request returns the 500, this is just the page presented if I manually attempt the URL outside of koel.

abort_unless is a new function in Laravel if I'm not mistaken. Try running composer install in the koel directory to update the serverside dependencies.

That got it - thanks!


Update chat.html

Tried to fix bugs & added ui changes

@kvcops

it's still washed out and still seems outdated...
This is the ui that you have suggested :

this is the previous UI:

It seems like for every PR it's been outdated...just try to work it on .... i am still hoping for the chance for the improvements

be waiting for your next PR :)


Schools?

I would like to thank you first for offering this tool for individual home buyer to search for properties.
This is really helpful and I really appreciate the work.
One question I have in the return array is that Is there a way to include schools in the return array?
Thank you.

I can take a look.


Improve detection of third party modules during class resolving

Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[x] If my change requires a change to the documentation, I have updated the documentation accordingly.
[x] I have added tests to cover my changes.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Describe changes

Detect whether a module belongs to a third party package when resolving a class

I thought about it but found some problems, maybe you have a suggestion on how to avoid them:
In order to test this, we would need to

create a virtual environment inside the git/zenml repository
run poetry install inside this virtual environment
delete the virtual environment

Especially the installation step would take far too long in my opinion, wdyt?

Won't we already have some sitepackages inside the testing env? Is there a sitepackage we can leverage for it that happens to be installed anyway?

Yes but they will not be inside this git repository I believe? And even if it was, to test both ways we would need one virtualenv that's inside the git repository and another one that is outside anyway I think

So I guess we could detect whether the function detects a third party module (but not the actual case for the bug which was a virtualenv inside the repo)

Ok yeah you're right, its too much overhead. But we should at least try that it works locally? We should check once before merging :-)

@htahir1 Added a small test for the simple detection of third party modules now. I tested it locally for me with virtual environments both inside and outside the git repository, but would be nice if you could run it on your machine as well :)


Remove cmake

We noticed due to https://github.com/hyperium/tonic/issues/965 that cmake was now a dependency for tonic via prost. We've had cmake banned for quite a while since it is terrible, so I started working on a PR to make prost-build use cc to build protoc instead. However, upon investigation I quickly realized that building and shelling out to protoc is massive overkill for prost's usage, which essentially just boils down to getting a list of the input files and all of their imports. Protoc by contrast includes support for generating multiple different languages (none of which prost uses) and plugin support (again, something that prost doesn't use), so I instead just reimplemented the small part of the command line tool that prost actually depended on into a single C function that is now linked with prost-build, and when compile_protos is called, just invokes that C function to get the output.
Pros

No cmake
Only compiles the minimum amount of C++ code that is actually needed to write the file descriptor set, so the build is significantly faster than compiling the protoc binary
No shelling out to a separate program and using the filesystem to read/write the output

Cons

This does the one thing that "vanilla" prost-build does, so usage of additional protoc arguments that people may be depending on won't do anything. I consider this fine since in those more advances use cases, you can just use an installed protoc compiler.
Added C++ code. I felt bad while doing it.
Unsafe, of course, to talk with the C code.

Other options

There already exists a Rust native way to read generate FileDescriptorSets at https://github.com/stepancheg/rust-protobuf/tree/master/protobuf-parse, it states that it might not be fully feature complete compared to protoc, but I think it would be fairly trivial to fix any issues there and instead use pure Rust code, allowing prost to completely remove the protobuf code altogether.

I am curious if this supports https://github.com/tokio-rs/console/blob/main/console-api/build.rs#L17 this flag?

That flag is meaningless https://github.com/protocolbuffers/protobuf/blob/55177c3574ce2718acf3d91cfcfbe9d035a6836d/src/google/protobuf/compiler/command_line_interface.cc#L1854-L1855

I must be allergic to c++ code thanks for getting that lmaooo

It doesn't necessarily have to be done as a part of this PR, but I wonder if we could use a feature flag to control whether any of these dependencies are incurred... We'd prefer to only ever use PROTOC_NO_VENDOR, so there's no need for us to incur the cc (or cmake) dependency. It would be fine for the feature to be enabled by default. And we'd have to follow suit and re-expose the feature from tonic-build.

@olix0r I wonder if we should provide a subset of prost-build that contains no vendoring? prost-build-cc and prost-build-lite or something like that that gives you clear control. Though I wonder how this would affect down stream users of libraries.

@LucioFranco yeah, I'm not sure what the most usable approach is. The decision to use vs build a protoc is really up to the application that is building a library that includes protobuf. While, the library itself needs to depend on prost-build. The library shouldn't be opinionated on whether protoc is used or not, which is why I thought the feature-flag approach might be best.

Is there any more progress on this PR?  So for our code now since the prebuilt protoc has been removed our build time is now dominated by prost-build, especially on low spec machines like the lower end github codespaces machines.
For a build of one of our crates which is mainly dependent on prost-build (and tonic-build), on the lowest spec codespace machine (2 cores, admittedly pretty much worst case), the time it takes to build using normal prost-build was around 11 mins 40s, and with this branch it was around 2 mins 10s.
If the changes here are too much, we also tried just disabling building the protobuf tests: https://github.com/ricnewton/prost/commit/d423ca122b0f1b763a38a996e801fcff25f71364, this built in around 4 mins 40s so significantly better than master but not as good as this branch, I can raise a PR if that is acceptable and this branch isn't, but this branch is faster to build.  Any reason we would need to build the protobuf tests?

I'm unable to repro the CI failure locally, but I've submitted a change that should fix it.

Is there some way to mark this branch/me so that CI can run when I do pushes? Due to the time difference I basically have to wait like 8 hours to see if the changes I make pass CI since apparently my local environment is different enough that I don't catch all of the same things that CI does, so the turnaround time is making this PR last waaaaaaay longer than it should.

This is ready for review by the way.

We were holding off our upgrade of prost/tonic/etc until this landed but since it's taking a while to get merged/released I'm adding a patch for our code, but that's when I noticed that the protobuf submodule is using an SSH url, which makes fetching via cargo untenable, so I've switched the url to a plain HTTPS so that this repo is easier to patch.

It also seems that prost 0.10.2 and 0.10.3 were released without bumping the actual version in the Cargo.toml file.

@Jake-Shadle those patch releases are on the v0.10 branch, master contains some breaking changes.

@Jake-Shadle is this already merged or? My CI is failing:
running: "cmake" "/home/runner/.cargo/git/checkouts/prost-0f318a28dfb453a6/2c9d9c1/prost-build/third-party/protobuf/cmake" "-DCMAKE_INSTALL_PREFIX=/home/runner/work/xx/xx/server/target/debug/build/prost-build-744ea9bdfe2d1c67/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"
--- stderr
CMake Error: The source directory "/home/runner/.cargo/git/checkouts/prost-0f318a28dfb453a6/2c9d9c1/prost-build/third-party/protobuf/cmake" does not exist.

Nope, don't think so

@ricnewton still looking to merge this, I just have not had enough time to full review this yet.

Great, thanks.  If there are any issues or anything or it will take a long time I can submit the one line change that at least disables running the protocol buffer tests if that helps, that saves loads of time as well.

Just dropping by from @MaterializeInc to say that this is unfortunately a nonstarter for us. Appreciate the work you've done here, @Jake-Shadle, and I'm sorry it was our supply chain concerns that kicked off this whole mess, but if prost-build decides to essentially reimplement the protobuf build system we'll have to switch back to a fork that uses a stock vendored protoc. (I'm not a prost maintainer, just an opinionated community member, so please take this as just a data point.)
To provide some more context: I've been burned repeatedly by projects that reimplement upstream build systems. Build systems, especially C++ build systems, tend to accrete important platform-specific knowledge, built up slowly over years of bug reports because there are never any tests. All that knowledge gets lost when you fork the build system. CockroachDB maintained custom build systems for its C++ dependencies for a while (e.g., RocksDB), and it was a persistent source of bugs due to compiler flags not being set correctly [0][1].
There is also a permanent maintainability to forking a build system. Someone will need to update the list of source files here for every protobuf release. Someone will need to look through upstream's autotools/CMake build system changes with every release and ensure that any feature detection that results in new compiler flags or defines gets carried through here. Downstream maintainers are generally not well positioned to do that sort of work, since they are relatively unfamiliar with the upstream codebase.

We've had cmake banned for quite a while since it is terrible...

I think this is an unfair characterization! CMake, like most tools, has its pros and cons. I've found CMake to be by far the most robust of the C/C++ build systems.

I think it would be fairly trivial to fix any issues there and instead use pure Rust code, allowing prost to completely remove the protobuf code altogether.

Last I looked into this it is far from trivial, I'm afraid. prost relies on the --include_source_info flag to protoc, which is not supported by protobuf-parse. The source info is quite detailed and seemed to require a substantial overhaul of protobuf-parse in order to put the right bookkeeping into place.

If the changes here are too much, we also tried just disabling building the protobuf tests: https://github.com/ricnewton/prost/commit/d423ca122b0f1b763a38a996e801fcff25f71364, this built in around 4 mins 40s so significantly better than master but not as good as this branch, I can raise a PR if that is acceptable and this branch isn't, but this branch is faster to build. Any reason we would need to build the protobuf tests?

This seems like a slam dunk to me, FWIW.

Is there a reason that you can't apt install protobuf-compiler or download the precompiled release from upstream in your CI? That'd be even faster than the approach in this PR. Coupled with #648 you'd even be able to remove the cmake crate from your transitive dependency graph.
In any case, my preference would be to figure out how to modularize prost-build! Then the code here could be in a separate crate/feature for the folks who want it.

I get where you're coming from, but in this case protobuf is a fairly small project, especially relative to the likes of rocksdb, and prost-build only uses a small fraction of it. In addition, it's not doing really doing anything complicated nor architecture specific, which is the typical reason for special flags and the like, but I could if course be wrong thinking that this would be trivial to maintain since I have never used protoc directly so have no familiarity with their release cadence or the like.

I think this is an unfair characterization! CMake, like most tools, has its pros and cons. I've found CMake to be by far the most robust of the C/C++ build systems.

Agree to disagree I guess, CMake may the best in C/C++ land but that's really not saying much. It only brought problems for us, easier to purge it completely so that the Rust ecosystem doesn't have to rely on it.

Last I looked into this it is far from trivial, I'm afraid. prost relies on the --include_source_info flag to protoc, which is not supported by protobuf-parse. The source info is quite detailed and seemed to require a substantial overhaul of protobuf-parse in order to put the right bookkeeping into place.

That's unfortunate, IMO using pure Rust would be the ideal solution since it would mean getting rid of the C++ code altogether and making prost-build and the crates that depend on it much smaller and faster to compile. Bad assumption on my part.

Is there a reason that you can't apt install protobuf-compiler or download the precompiled release from upstream in your CI? That'd be even faster than the approach in this PR. Coupled with https://github.com/tokio-rs/prost/pull/648 you'd even be able to remove the cmake crate from your transitive dependency graph.

Requiring an additional installation dependency to build a single crate dependency seems pretty terrible IMO. If we had other cmake dependencies it might be acceptable, but we purged them years ago and they are never coming back, requiring cmake for CI and users who build our code would be a major step back.
This PR still supports PROTOC_NO_VENDOR I don't understand why this solution can't coexist with those like yourself who want to use the stock protoc.

Hmm, so should I just close this then? This PR has been open coming up on 2 months now and it feels like it's getting less likely to merge given this recent feedback.
I'd of course rather not maintain our own fork and patch it in to resolve something that also seems to be problematic for other people who use prost, but this code is fairly isolated from the bulk of what prost-build does so should be easy to keep in sync with new releases, barring big changes such as the original one to vendor sources instead of using the bundled protoc.

hi! I wrote a proposal that removes cmake and can also support this work. Let me know what you think in there! Thanks for putting this together jake <3


Master builds produce artifacts with '6.0.0.-rc' versioning instead of '6.1.0-beta.1'

If I understood correctly from the last community call, the master branch is now for 6.1.0 development.
However, the artifcats of master builds are versioned as 6.0.0.-rc. See e.g. here for an example of the latest build.
Info: Latest commit of master as of November 18: cb048ea9f4f7ccc3612141ee76f7937b9ca1c823

We still are in RC stage not GA.

I thought that is what the 6.0.0 branch was for?

When we merged the changes from the RC release branch back to master, we merged everything including the version string.  Master should be 6.1.0-beta.1 while 6.0.0 continues on the Release branch.  cc @daxian-dbw

@SteveL-MSFT In blog post  the branch link is broken in "we also created a branch for the eventual PowerShell Core 6.0.0 final release. " I see Release branch renamed to 6.0.0.

@iSazonov thanks for catching that, will fix

@SteveL-MSFT Would it make sense to rather use the word preview instead of beta starting from 6.1 since .Net Core and the Visual Studio family use that term as well? Also, preview indicates that it is just the bleeding edge version of something that already had RTM quality, which  differentiates it from the past 6.0 betas.

@bergmeister agree, preview captures it better as being incomplete than beta which implies subpar quality

Based On SymVer 2.0 and modern life cycle we could give up on "beta" and "preview" and use 6.1.x on a daily basis.

SemVer 2.0 states that the 3rd number should only be for patches

PATCH version when you make backwards-compatible bug fixes


README

the method provideStore is not reflected in the README. It is now forRoot . Should I make a PR?

The README you're referring to is for version 2.0. The new version (>=4) are all in a monorepo here: https://github.com/ngrx/platform

aah! gotcha. thanks!


Fix custom pulse instruction converstion to Qobj.

Summary
This is a possible fix to #11828.
Details and comments
The behavior of ParametricPulseShapes is restored to raise ValueError when the pulse shape is not supported, and QiskitError when the pulse object is not recognized. The need for the second scenario is not clear to me, but as a quick fix I reverted to the code before #11410.
If we think that the two error types are not needed, we can alternatively change the error type used by the assemble logic.
fixes #11828

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-1 of 2 (50.0%)  changed or added relevant lines in 1 file are covered.
18 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.02%) to 89.271%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/qobj/converters/pulse_instruction.py
1
2
50.0%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
93.81%

crates/qasm2/src/lex.rs
5
90.68%

crates/qasm2/src/parse.rs
12
97.15%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
58894

Relevant Lines:
65972

💛  - Coveralls

As a side note, I think this bug highlights some deficiencies in the tests. We should probably beef up the tests there, but I didn't want to tie it up with the fix.

Thanks @wshanks! I added a test to cover something like this.


Verify custom return code on transaction

If a transaction can be rejected at execution time, it would be very useful to have the sender get an "error code".
This is to provide useful feedback when the firewall is rejecting the transacation.

This is supported in Move with assert!()
DTP define/document all errors in a single errors.move file.


Add VS2012 support to projectgenerator

Files are essentially just copied from the 2010 version with slight
tweaks, works without any warnings or errors.
It prevents having to do the annoying conversion from the VS2010 version every time you regenerate.
Is additional work on projectgenerator even wanted, seeing as there is also the competing cmake build system?

@cornytrace , have you signed OSA?
We need your GG account name for verification.

I get this error: RC : fatal error RC1110: could not open Torque.rc
I think we need to copy some files to templates/???/buildFiles/VisualStudio 2012/projects


GLUE 2.1 rendering

Work on GLUE2.1 rendering started in my repo: https://github.com/gwarf/cloud-info-provider/tree/glue_2.1_keystone

Addressed by #99


P13nSortPanel - additional items in value select in case with Array polyfil

OpenUI5 version: 1.52.30
Browser/version (+device/version): Google Chrome 70.0.3538.67 (Official Build) (64-bit) on Windows 7
Any other tested browsers/devices(OK/FAIL): Also fails on Firefox 69.0.1 and Internet Explorer 11
Minimal example:
p13n.zip
Steps to reproduce the problem:

Run the application and open personalization dialog by clicking on the button
Click on Ascending/Descending checkbox
Checkbox contains rows not just for the content of sortItems, but also for every function added to Array.prototype (which happens when polyfils are used)

To simulate polyfiling I added
Array.prototype.someCustomFunction = function() { /* this will be visible in p13n panel */ }
to the index html.
The problem seems to be in P13nConditionPanel._fillOperationListItems function, where aOperations are looped by for ( var iOperation in aOperations) { without own property check

Hello huhle,
thank you for submitting this issue. I've created an internal incident and forwarded it to the responsible development team. Please refer to the following ticket ID for further details:
1970496212
The status of this GitHub issue will be updated by the responsible processor.
Regards Sebastian

Hello huhle,
this issue has been solved. The fix will be available in the nightly build as well as OpenUI5 1.72 and higher.
Regards Sebastian


fixes test unit bip32

fixes https://github.com/NAVCoin/navcoin-core/issues/168

How do we test this?

./configure --enable-tests && make

When using docker:
CONFIGURE_FLAGS=--enable-tests docker-compose build


Use a direct link to fonts.css

Reticketed from https://github.com/gittip/www.gittip.com/issues/1447#issuecomment-52313360. It shouldn't be required to send a Referer to third-party services (typography.com in this case).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

According to https://github.com/gratipay/gratipay.com/issues/1447#issuecomment-52314694, as long as we still use Typography, I don't think the efforts to update link for font file changes is worth some of users losing fonts, for now. Please reopen if needed.


Table Markdown not Rendering

Using the example in the wiki docs, and the JSFiddle link as a demo, the example Table code does not render at all.
Table Markdown

As it stated in the documentation:

Tables aren't part of the core Markdown spec, but they are part of GFM and Showdown supports them by turning on the option tables.

So you need to turn on the option tables;
var converter = new showdown.Converter({tables: true});

We're currently looking to improve showdown with automated tests in all browsers and a proper domain and webpage. If you like our work, please donate!! Your contribution will be greatly appreciated.
https://www.paypal.me/tiviesantos

Would be great to add proper indication in the wiki for example as to enable options in Showdown as I didn't find any of this except here :/

It's both in the wiki and in the README.md

@tivie 👍 I can't read. Thanks

This isn't working when going from html to markdown, even with the table option enabled.

For CLI : showdown makehtml -i file.md -o file.html --tables

For CLI : showdown makehtml -i file.md -o file.html --tables

thanks - and for CLI Version v2.1.0 use showdown makehtml -i file.md -o file.html -c tables


Quick Fix for fields with unknown types

It'd be great to create a model/enum directly from the relation scalar field via right click -> "make this relation and create model" and "make this relation and create enum"

This should use the Quick Fix concept familiar to users of VS Code.
It could also calculate the Levensthein distance to existing enums / models, and suggest using an existing one if it is sufficiently similar.

Demo video welcome @carmenberndt (And something you could then post in the vscode and prisma2 channels in Slack)