move GeoInterface conversions to a separate lightweight package

Hello,
I am opening this issue to understand whether there will be willingness (or if there is already an alternative) to move the functionality to translate geometries implementing the interface from GeoInterface into a separate much more lightweight package.
From what I see this is fully enclosed within the conversions.jl file and would only need to depend on Meshes.jl and GeoInterface.jl as a very bare minimum if removing the 4 added methods depending on AbstractGeoTable:
https://github.com/JuliaEarth/GeoIO.jl/blob/8c0eb84223ecf8a8601850f8b7cc27f81a18d68c/src/conversion.jl#L40-L43
Alternatively and probably more meaningful within the JuliaEarth ecosystem would be to include GeoTables as dependency and maybe also provide the contents of src/utils.jl to allow easily creating a GeoTable as output from this hypotetical new basic package.
My use case is wanting to provide some basic functionality relying on Meshes and GeoTables in one small package of mine https://github.com/disberd/CountriesBorders.jl where I just want to transform the data related to countries coordinates into a Meshes compatible format so that I can exploit all of the nice functionalities of JuliaEarth.
I had already opened a discussion on zulip on the matter here, where I explained that for the package I did not want to depend on GeoIO.jl since this directly depends on all the possible packages dealing with the formats GeoIO supports, which especially due to GDAL (at least in my experience) can cause issues on windows and long precompilation times.
I understand that things are getting better with precompilation but I still rather not have this huge list of indirect dependencies for some vary basic functionality I know will only depend on one specific geojson file.
The discussion in the zulip above led to the suggestion of just generating the table and saving it as binary, but this comes at the risk that the loaded binary format will be very coupled to the specific version of Meshes and GeoTable that generated it.
I think a solution where the file is simply read with GeoJSON.jl (much lighter than GeoIO.jl) and then converted to a GeoTable upon loading is much cleaner.
I have checked a bit the internals here and indeed it would seem to be rather easy to "excise" this functionality into a separate package that GeoIO would depend on.
This would also open a much easier path for other developers in my shoes to adopt the Meshes ecosystem, and if this was to be included inside JuliaEarth it would give more confidence on its support and it being kept up-to-date with changes to GeoTables and Meshes.
I also believe this work of compatibility maintenance would not be higher than what it currently is as this code already lives in GeoIO which is part of the ecosystem and the effort would just be moved from GeoIO to this new light GeoInterfaceConversion package.
Would this be something you would be open to consider?

Hi @disberd , thanks for raising the issue here. Appreciate your attempts to improve the ecosystem.

My use case is wanting to provide some basic functionality relying on Meshes and GeoTables in one small package of mine https://github.com/disberd/CountriesBorders.jl where I just want to transform the data related to countries coordinates into a Meshes compatible format so that I can exploit all of the nice functionalities of JuliaEarth.

Can you please confirm that you are creating CountriesBorders.jl because you don't want to take GeoArtifacts.jl as a dependency (which depends on GeoIO.jl)? As explained in Zulip, the Natural Earth dataset is already available as a GeoTable with Meshes.jl geometries that are compatible with our ecosystem. Can you please explain how CountriesBorders.jl differs from GeoArtifacts.NaturalEarth?

I think a solution where the file is simply read with GeoJSON.jl (much lighter than GeoIO.jl) and then converted to a GeoTable upon loading is much cleaner.

It seems to me that your main concern with the current situation is the heavy GeoIO.jl dependency. I would like to ask you again: are you concerned with the heavy dependency in CountriesBorders.jl or in some other user-facing app that you are building that depends on CountriesBorders.jl? In the former case, I'd argue that CountriesBorders.jl is not needed, especially if you simply use/contribute to GeoArtifacts.jl (please let me know if there are feature differences other than just loading the boundaries). In the latter case, your user-facing app will be compiled anyways, and you will be able to load many other formats in the future, without manual intervention. Issue #23 is something that we need to solve in parallel. Contributions are welcome.

I did not want to depend on GeoIO.jl since this directly depends on all the possible packages dealing with the formats GeoIO supports, which especially due to GDAL (at least in my experience) can cause issues on windows and long precompilation times.

We do share your second concern very much. We've been working really hard over the years to get rid of this GDAL madness that is spread across various programming languages. Our ultimate goal is to completely remove this dependency in GeoIO.jl. However, this removal depends on the existence of more native Julia packages to load file formats that are not supported yet. We should probably make a list of the missing formats to make this road map more explicit.
In summary, and answering to your request: we do not envision a promising direction with a separate package for geometry conversions.

Thanks for the quick reply.
Indeed my problem is that CountriesBorders is a dependency (direct or indirect) of a number of private packages we develop inernally for work.
I decided to make this package public as it's simple, does not rely on any internal data and might be useful to someone else.
The problem with the huge GeoIO dependency is that precompilation does not really help in CI where everything is recompiled again from scratch (we use GitLab at work with a self hosted instance so I do not have access to all the julia actions on github that might help with caching).
We also test both on windows and linux so for the foreseeable future I do not have a dependency on GeoIO within this package due to the massive increase in CI time and significant issues with windows CI.
I am working a new PR to allow a more recent version of Meshes here:
https://github.com/disberd/CountriesBorders.jl/pull/11
For the time being, considering your reply about not being move this outside of GeoIO, it seems like I can just live with adding some internal compat based on the files from GeoIO.jl as done here:
https://github.com/disberd/CountriesBorders.jl/pull/11/files#diff-900f3fdd76930cfba1347564aa40447c497c942e2138e935e99ca9c9d9f7b4e4
I added the full copyright from this repo in the comment at the beginning of the file, let me know if this is sufficient or if I have to handle the copyright differently

The problem with the huge GeoIO dependency is that precompilation does not really help in CI where everything is recompiled again from scratch (we use GitLab at work with a self hosted instance so I do not have access to all the julia actions on github that might help with caching).

As a side comment, I remember that our precompilation time in GeoIO.jl increased massively with the addition of one single format (maybe it was geoparquet?). The issue #23 needs to investigated by someone with more time and compiler skills. Perhaps, solving the issue can solve your huge CI times as a side effect.

I added the full copyright from this repo in the comment at the beginning of the file, let me know if this is sufficient or if I have to handle the copyright differently.

It is perfectly fine :) We are happy that you can find your way into the source code and adapt it to your needs.

EDIT: @juliohm Regarding how this differs from what is available in GeoArtifacts.NaturalEarth, not much in the raw content but I do export functionality in CountriesBorders to allow easy selection of specific countries and downfiltering based on region/name.

That would be super nice to have as a feature in GeoArtifacts.jl for example. This convenience options can help other users in the future. If you have them isolated, and could easily port in your free time, that would be great.
Will close the issue, but feel free to continue the discussion here.

Thanks for confirming I could reuse the code as proposed.
Regarding the filtering functionality I will try to see if it can be added once we stabilize the API a bit more.
We also have a core internal package that implemented a lot of things that are now in CoordRefSystem for dealing with visibility between satellites and points on ground.
I have been thinking about checking how difficult or impactful on performance using CoordRefSystem internally would be so I might come again to open issues or ask questions in other packages of JuliaEarth.
Overall I think you are doing a very commendable effort into trying to harmonize these fields in Julia and I would like to re-use and contribute back to the ecosystem when possible :)

I have been thinking about checking how difficult or impactful on performance using CoordRefSystem internally would be so I might come again to open issues or ask questions in other packages of JuliaEarth.

That would be lovely. CoordRefSystems.jl unlocks various paths of innovation that were previously locked by PROJ. Feedback and improvements are very welcome.

Overall I think you are doing a very commendable effort into trying to harmonize these fields in Julia and I would like to re-use and contribute back to the ecosystem when possible :)

Appreciate your kind words. Despite the stubbornness of very few people, we are seeing more community members sharing our long-term vision.


It's called hereby, don't use it, thanks -- Why?

In the talk-ts-congress-2023 slides, there is a line:

It's called hereby, don't use it, thanks 😅

Could I ask why? TypeDoc's build system has become somewhat messy, and I liked the way this looked last time I looked at the TS compiler's build setup...

This package was intended for use in TypeScript's build system, and that's basically it. It has all of the features it needs, and it's unlikely I'm going to add any more. If you're happy with those warnings, then feel free to use it!
That line was more of a joke; I'm not one to advertise my projects, so at best I can try to be funny about it.


Exclude private IP addresses in other cloud accounts in ACLs, try 2

In 8.201.15 and rolled out to main on July 26.


[ Notes ] : PRs to collapse

Collapse
#245 (Invalid)
#244 (Invalid)
#248 (Valid, but a research PR)
Once collapsed #243 can be merged and this, close this issue!

#243 merged, I don't know why it didn't automatically close despite being linked.


Please fix storage account mistakes

Line 143 should be
"name": "[parameters('storageAccountName')]",
Line 146 should be
"name": "[variables('storageAccountType')]"
The parameters/variables are reversed leading to deployment failures.

Thanks for the feedback. We fixed this in the template posted 6-Aug-2018.


FIXED enableDrag feature and exposed it to showModalBottomSheet

Description
Currently, there is a widget in BottomSheet which has a property of enableDrag (this makes the bottom sheet un-draggable). When this widget is used directly on the Scaffold, it works. But, while using showModalBottomSheet property the enableDrag property is not exposed and is set to false by default (Refer to line: 297 of bottom_sheet.dart).
This PR has just exposed this property for showModalBottomSheet, which will help developers to access enableDrag property from anywhere using showModalBottomSheet.
Related Issues
https://github.com/flutter/flutter/issues/39297
Tests
This is pending as of now. Just wanted a little help here. Can anyone tell me what test cases should I consider for this enhancement? Thanks!
Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[ ] All existing and new tests are passing.
[ ] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes).
[x] No, this is not a breaking change.

It seems like this feature has already been implemented with https://github.com/flutter/flutter/pull/46685. Thank you for your initial contribution, and apologies that we did not get to reviewing this sooner! I will close this PR.

I'm happy that finally this feature has been merged. 😃


It looks like azcopy isn't supported with Azure managed disk exports -- something about list permissions?  Who do I talk to about this?

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az storage copy
Errors:
Not valid file
Traceback (most recent call last):
Temp\pip-install-qxmmnr17\knack\knack\cli.py, ln 206, in invoke
azure\cli\core\commands\__init__.py, ln 603, in execute
azure\cli\core\commands\__init__.py, ln 661, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 654, in _run_job
Local\Temp\pip-install-qxmmnr17\six\six.py, ln 693, in reraise
azure\cli\core\commands\__init__.py, ln 631, in _run_job
azure\cli\core\commands\__init__.py, ln 305, in __call__
azure-cli-core\azure\cli\core\__init__.py, ln 485, in default_command_handler
cli\command_modules\storage\operations\azcopy.py, ln 83, in storage_copy
cli\command_modules\storage\operations\azcopy.py, ln 73, in get_url_with_sas
ValueError: Not valid file

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az storage copy -s {}

Expected Behavior
Environment Summary
Windows-10-10.0.18362-SP0
Python 3.6.6
Shell: powershell.exe

azure-cli 2.0.72

Additional Context

@Geof23 What is your source parameter value here?  Azure cli only support url and local_path now.

Hi @Geof23 , does azcopy work for your scenario?

@Geof23, any update?

Hey Yonzhan, it’s been working.  I can provide more details if you like
later.
On Sat, May 30, 2020 at 8:03 AM yonzhan<EMAIL_ADDRESS>wrote:

@Geof23 https://github.com/Geof23, any update?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-cli/issues/10431#issuecomment-636342689,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMJOD7UJKCKPPAE3DJPHHLRUEN4JANCNFSM4ITYMT6Q
.


Remove font padding from the game info header's second title

In the XML world, TextView allows disabling the font padding by specifying includeFontPadding="false". This was used by the second title of the game info header to remove any extra space between the first title & second one.
However, as of 1.1.1 version of the Jetpack Compose, it's not possible to do that. As of the 1.2.0-beta01, the support for that has been added. As soon as the project gets updated to use 1.2.0 version of the Jetpack Compose, consider removing the font padding, just like it was before the migration to Compose.

Since Jetpack Compose 1.2 has been released recently, it provides an experimental API to try out setting includeFontPadding property.
However, since it is planned to make includeFontPadding property to be false by default in an upcoming release, it makes no sense to put the experimental code just to remove it a couple of releases later.
Therefore, as soon as a release of Compose comes out that sets includeFontPadding to false by default, double-test for visual changes and call it a day.

Starting from 2024.01.01 version of the Jetpack Compose, the includeFontPadding is false by default.
Closed by #211.


Non-rpi4 balenaOS has the rpi4 boot firmware in the boot partition

Fixed by https://github.com/balena-os/balena-raspberrypi/pull/370


Make past data page

List previous versions of database on a page for download.

voteview user's cron runs weekly dump.


Dictionary: add "Upload from file" functionality

The current Discovery panel allows to type the entries in the UI. This is tedious if the dictionary should contain more than a few terms.
Solution:
The UI should provide an Upload from file button that allows the user to upload the dictionary from a file.

What would the file contents look like?

The file would be a plain text file, with one entry per line. Some examples can be found here: https://github.com/CODAIT/nlp-editor/tree/main/sample-data/revenue by division (abbreviations.txt and divisions.txt).


Stem library

Stem library. Members could upload stems similar to the way they upload tracks, but they could specify a BPM, key, and keywords, and be able to view and download the uploads from other members at any time

complete


I can't install it

Hello guys,
You are doing a great job.
I just need to install it using NPM,
 npm install --save @ramotion/react-native-circle-menu
it appears that this is not working for me.

all the other dependencies are installed except  @ramotion/react-native-circle-menu.

#I solved this issue
by adding this to AndroidManifest.xml
android:exported="true"
like this:
        <activity android:name=".MainActivity"
            android:exported="true"
            />

Thanks, this can be closed


Version Packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Patch Changes

bf70ff9: Fixed publishing pipeline and releasing

<EMAIL_ADDRESS>Patch Changes

bf70ff9: Fixed publishing pipeline and releasing
Updated dependencies [bf70ff9]

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>Patch Changes

bf70ff9: Fixed publishing pipeline and releasing

The following preview packages were published:

Name
Version
Install Command

@frontside/backstage-plugin-humanitec-common
0.1.3-changeset-release-main.5
yarn add @frontside/backstage-plugin-humanitec-common@changeset-release-main

@frontside/backstage-plugin-humanitec-backend
0.2.3-changeset-release-main.0
yarn add @frontside/backstage-plugin-humanitec-backend@changeset-release-main

@frontside/backstage-plugin-humanitec
0.2.3-changeset-release-main.0
yarn add @frontside/backstage-plugin-humanitec@changeset-release-main

Generated by @thefrontside/actions


Remove nunjucks dependency

nunjucks is too large library.
When an user execute npx @kintone/dts-gen --help, it tooks a little time.

https://github.com/kintone/dts-gen/tree/Issue-21


UP-4863: Change JGroups pbcast.GMS join_timeout to 2 seconds and max_…

…join_attempts to 3.

Checklist

[x] the individual contributor license agreement is signed
[x] commit message follows commit guidelines

Description of change

Reduce time spent joining JGroups cluster.

https://issues.jasig.org/browse/UP-4863

Are there any common/normal circumstances where we can expect joining to fail?

Given a working, stable network, there should not be a need for 10 attempts to connect to the cluster.

Do you know why it often fails (after 10 attempts) to connect on my local portal?

It's attempting to connect to a cluster. In a dev environment, there usually isn't one.
I looked for a way to disable JGroups conditionally, but did not find much.

How is a "cluster" defined in this context?  What's wrong with a cluster of one?


docs(README): update link to v0.21 instructions - #351

Signed-off-by: Poppy22<EMAIL_ADDRESS>

Closes #351

Updating the link in the README form How to use the Cicero Templating System. The previous link was pointing to instructions for v0.13. Because the previous instructions link contained both installing and using templates in the same page, I added one link and modified the previous one; see below.
Changes

I added the line Install Cicero to the Documentation section, with link to https://docs.accordproject.org/docs/started-installation.html
I changed the link for How to use the Cicero Templating System from https://docs.accordproject.org/docs/basic-use.html to https://docs.accordproject.org/docs/started-hello.html

Author Checklist

[x] Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
[ ] Vital features and changes captured in unit and/or integration tests
[x] Commits messages follow AP format
[ ] Extend the documentation, if necessary
[x] Merging to master from fork:branchname
[ ] Manual accessibility test performed

[ ] Keyboard-only access, including forms
[ ] Contrast at least WCAG Level A
[ ] Appropriate labels, alt text, and instructions

Needs some looking into on #351

I'm very tempted to remove all this part of the README and point to the techdocs. Or we'll end up again with X PRs to review all a little bit different.

I believe this is no longer an issue after #358


Ember 1.13 Support

Extends https://github.com/kurko/ember-localstorage-adapter/pull/124
To add support for ember 1.13+
This has two failing tests that i think should just be removed.

I, I'm interested by you pull request. Could you let me know how to use it in my project please? I make heavy use of the local storage adapter in my application, but I am thinking of switching to something more reliable as I have tons of problems every time I update my project.

You can just change the local storage adapter reference line in the package.json file to use my branch until this gets pulled or another one comes along and gets merged into the main.
"ember-localstorage-adapter": "git://github.com/Kilowhisky/ember-localstorage-adapter.git#ember-1.13.+",

Tank you for your help!
Le sam. 22 août 2015 à 01:44, Kilowhisky<EMAIL_ADDRESS>a
écrit :

You can just change the local storage adapter reference line in the
package.json file to use my branch until this gets pulled or another one
comes along and gets merged into the main.
"ember-localstorage-adapter": "git://github.com/Kilowhisky/ember-localstorage-adapter.git#ember-1.13.+",
—
Reply to this email directly or view it on GitHub
https://github.com/kurko/ember-localstorage-adapter/pull/129#issuecomment-133591585
.

I get an error when trying to install:
$ npm install --save-dev "
https://github.com/Kilowhisky/ember-localstorage-adapter.git#ember-1.13.+"
npm ERR! Command failed: git -c core.longpaths=true clone
--template=C:\Users\alex\AppData\Roaming\npm-cache_git-remotes_templates
--mirror git@github.com:Kilowhisky/ember-localstorage-adapter.git
C:\Users\alex\AppData\Roaming\npm-cache_git-remotes\git-github-com-Kilowhisky-ember-localstorage-adapter-git-dc5accbf
npm ERR! Clonage dans le dépôt nu
'C:\Users\alex\AppData\Roaming\npm-cache_git-remotes\git-github-com-Kilowhisky-ember-localstorage-adapter-git-dc5accbf'
npm ERR! Permission denied (publickey).
npm ERR! fatal: Could not read from remote repository.
Do you have any idea where it's from?
Thanks for your help if you mind to share some time on this
On 22 August 2015 at 08:47, Alexandre Melard<EMAIL_ADDRESS>wrote:

Tank you for your help!
Le sam. 22 août 2015 à 01:44, Kilowhisky<EMAIL_ADDRESS>a
écrit :

You can just change the local storage adapter reference line in the
package.json file to use my branch until this gets pulled or another one
comes along and gets merged into the main.
"ember-localstorage-adapter": "git://github.com/Kilowhisky/ember-localstorage-adapter.git#ember-1.13.+",
—
Reply to this email directly or view it on GitHub
https://github.com/kurko/ember-localstorage-adapter/pull/129#issuecomment-133591585
.

@Kilowhisky merging. Any chance you can PR a fix for those deprecations? :smile:


upstream subset lb: add redundant keys support

Commit Message: upstream subset lb: add redundant keys support
Additional Description:
Description is same with the comment:
    // If true, redundant key/value pairs are allowed in the request (route, weighted cluster or dynamic)
    // metadata. By default, only when the request metadata has **same** keys with one of the subset
    // selectors and the values of related keys are matched, we will get valid subset. For example:
    //
    // .. code-block:: json
    //
    //   { "subset_selectors": [
    //       { "keys": [ "version" ] },
    //       { "keys": [ "stage", "version" ] }
    //   ]}
    //
    // A request with metadata ``{"redundant-key": "any", "stage": "prod", "version": "v1"}`` or
    // ``{"redundant-key": "any", "version": "v1"}`` can never get valid subset even if the values of
    // ``stage`` and ``version`` are matched because of the redundant key/value pair in the request
    // metadata.
    //
    // By set this to true, only the necessary key/value pairs will be evaluated and redundant key/value
    // pairs will be ignored. Take the above example, if the request metadata is ``{"redundant-key": "any",
    // "stage": "prod", "version": "v1"}``, the subset lb will keep the ``{"stage": "prod", "version": "v1"}``
    // as the request metadata for the evaluation. If the request metadata is ``{"redundant-key": "any",
    // "version": "v1"}``, the subset lb will keep the ``{"version": "v1"}`` as the request metadata for
    // the evaluation.
    //
    // .. note::
    //   To avoid the performance impact and potential complexity, subset lb will keep at much as possible
    //   key/value pairs in the request metadata. Take the above example, if the request metadata is
    //   ``{"redundant-key": "any", "stage": "prod", "version": "v1"}``, the subset lb will keep the
    //   ``{"stage": "prod", "version": "v1"}`` as the request metadata for the evaluation and will not
    //   try the ``{"version": "v1"}`` as the request metadata.

Risk Level: low. minor change.
Testing: unit.
Docs Changes: n/a.
Release Notes: added.
Platform Specific Features: n/a.

This is more readable.

friendly ping @adisuissa

Re-assigned this to @zuercher because @zuercher is code owner of subset lb.

/docs

cc @zuercher test was updated. 😸

cc @adisuissa any other concern to the API? 🤔

cc @adisuissa Thanks for your detailed review. Related comments are addressed and comment of API is updated.

Hi, @zuercher, could you give another LGTM. We updated API's comment after your code review. Thanks.

/assign-from @envoyproxy/envoy-maintainers

cc @RyanTheOptimist (on-call maintainer) Hi, could you give this PR another LGTM? @zuercher has approved this PR before. And after his approve, we just update the API's comments.

ho, @zuercher thanks 🙏


Emission Views SP Partition Speed Solution

Background
ECMPS uses Emission View tables to store display ready versions of emissions data.  The tables are needed because formatting the reported data for display takes too much time for a user expecting to see the data.  Because the emissions data exists in both the Workspace and Official schemas two sets of the Emission View tables are needed.  A set of stored procedures were created to populate the Workspace schema Emission View tables and those procedures were performant.  A version of those SP were created to populate the Official schema Emission View tables, but those procedures where not performant.
I believe the initial understanding of the Official schema performance problem was primarily because of the much larger amount of data in the Official schema.  Additionally and based on testing, the multiple joins on the single emission tables for different parameters appeared to exacerbate slowness.  Because of the perceived join issue, the "pivot" method was developed, which used table functions to flatten the hourly rows for multiple parameters into single rows for each hour to require one join per table.  Although the "pivot" method reduced the slowness issue, speed problems with some of the Official stored procedures still exist.
Additional research exposed some truths about querying the RPT_PERIOD_ID partitioned Official schema emission tables.  Where and especially join conditions on the tables will result in searching each partition for a table if the RPT_PERIOD_ID is not included in the condition for the table.  This was the original slowness problem and explains why the "pivot" method worked since it included the RPT_PERIOD_ID in the where clause it used.
Previous Tickets
This ticket is intended to replace previous tickets and will result in a QA of all Emission Views and will cover the testing for those tickets.  As a result, both of the tickets below will be closed.
#5793
#6324
Requirement
Update the stored procedures that load the Emission View tables to use direct joins for each parameter to an emissions table.  However each join to the tables must  include the RPT_PERIOD_ID.
Additionally, after ensuring they are not used outside of Emission View population, drop the following table functions in both the CAMDECMPS and CAMDECMPSWKS schemas.

GET_DERIVED_HOURLY_VALUES_PIVOTED( varchar, numeric, text )
GET_HOURLY_PARAM_FUEL_FLOW_PIVOTED( varchar, numeric, text )
GET_MONITOR_HOURLY_VALUES_PIVOTED( text, numeric, text )
GET_MONITOR_HOURLY_VALUES_PIVOTED( varchar, numeric, text, text, text )

Stored Procedure List
Handled SP already include the adjustment to use the RPT_PERIOD_ID in any where or on clause that references a partitioned emissions table.

Stored Procedure
Screen Name
Official
Workspace

REFRESH_EMISSION_VIEW_ALL
Hourly Combined Parameters View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_CO2APPD
Hourly CO2 Appendix D View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_CO2CALC
CO2 Calculation
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_CO2CEMS
Hourly CO2 CEMS View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_CO2DAILYFUEL
CO2 Daily Fuel Sampling View
:red_square:
:red_square:

REFRESH_EMISSION_VIEW_DAILYCAL
Daily Calibration View
:ballot_box_with_check:
:white_check_mark:

REFRESH_EMISSION_VIEW_HIAPPD
Hourly Heat Input Appendix D View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_HICEMS
Hourly Heat Input CEMS View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_HIUNITSTACK
Heat Input for Unit/Stack View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_LME
LME View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_MASSOILCALC
Mass Oil Calculation View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_MATSHCL
MATS HCL View
:ballot_box_with_check:
:white_check_mark:

REFRESH_EMISSION_VIEW_MATSHF
MATS HF View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_MATSHG
MATS HG View
:ballot_box_with_check:
:white_check_mark:

REFRESH_EMISSION_VIEW_MATSSO2
MATS SO2 View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_MATSSORBENT
MATS Sorbent View
:red_square:
:white_check_mark:

REFRESH_EMISSION_VIEW_MATSWEEKLY
MATS weekly View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_MOISTURE
Moisture View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_NOXAPPEMIXEDFUEL
Unit Level Fuel Curve View
:red_square:
:white_check_mark:

REFRESH_EMISSION_VIEW_NOXAPPESINGLEFUEL
NOX Appendix E Individual Fuel Curve View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_NOXMASSCEMS
Hourly NOx Mass CEMS View
:ballot_box_with_check:
:white_check_mark:

REFRESH_EMISSION_VIEW_NOXRATECEMS
Hourly NOx Rate CEMS View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_OTHERDAILY
Other Daily Tests View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_SO2APPD
Hourly SO2 Appendix D View
:white_check_mark:
:white_check_mark:

REFRESH_EMISSION_VIEW_SO2CEMS
Hourly SO2 CEMS View
:white_check_mark:
:white_check_mark:

Additional Issues

CO2DAILYFUEL and NSPS4T has data in CAMDECMPS after test run of "refresh_emissions_views" for the following Monitoring Plan and Reporting Period Ids, but data did not exist in CAMDECMPSWKS after the test run.

( 'TWCORNEL5-C0E3879920A14159BAA98E03F1980A7A'  , 123 ),
( 'MDC-19939DF8A9FD4C12B3869C394A2C0B1D'        , 123 ),
( 'EGWITLT01-C88ABE75BA5D4C6CB5E2D1EFEC8C4F38'  , 123 ),
( 'MDC-0B5C7E00DEFD410A9B883B5E381A8C4B'        , 113 ),
( 'MDC-80A407D4AC8D478E93F95FB702EC0B3E'        , 123 ),
( 'BPU094-545C837365784BE781EDECEAA08626A3'     , 123 ),
( 'MDC-07AC944F78A043E08E21977F9DA727EA'        , 123 ),
( 'MDC-4F0130B46ADB4B4F9C2EE0BA4A72D463'        , 123 ),
( 'MDC-88B24CFAC6E94EFAA0517A9EC9FB4D9E'        , 123 ),
( 'MDC-98642474BB9D49CAB5CB11F2352A3598'        , 123 ),
( 'RMUENSTERL-FBE23B81FE4A4C6DADBDDAA1496DB309' , 123 ),
( 'MDC-EC0E1E1664394A6DB9DF0DBCFD5C93C1'        , 123 ),
( 'MDC-3B23A43070D74F53AA2DAD83ABFC190C'        , 123 )

Explain Plant Results
The explain plan for the actual pivot version of the select used to populate the Emission View tables uses a default for the pivot function call that does not reflect the work the pivot functions actually do.  So the a version of the select statement had to be created to get a more accurate explain plan cost for the pivot version.

Model's Stored Procedure
Pivot Low
Pivot High
New Low
New High

REFRESH_EMISSION_VIEW_ALL
10,822.33
138,045.30
8,327.44
32,209.00

REFRESH_EMISSION_VIEW_CO2APPD

REFRESH_EMISSION_VIEW_CO2CALC

REFRESH_EMISSION_VIEW_CO2CEMS

REFRESH_EMISSION_VIEW_CO2DAILYFUEL

REFRESH_EMISSION_VIEW_DAILYCAL

REFRESH_EMISSION_VIEW_HIAPPD

REFRESH_EMISSION_VIEW_HICEMS

REFRESH_EMISSION_VIEW_HIUNITSTACK

REFRESH_EMISSION_VIEW_LME

REFRESH_EMISSION_VIEW_MASSOILCALC

REFRESH_EMISSION_VIEW_MATSHCL

REFRESH_EMISSION_VIEW_MATSHF

REFRESH_EMISSION_VIEW_MATSHG

REFRESH_EMISSION_VIEW_MATSSO2

REFRESH_EMISSION_VIEW_MATSSORBENT

REFRESH_EMISSION_VIEW_MATSWEEKLY

REFRESH_EMISSION_VIEW_MOISTURE

REFRESH_EMISSION_VIEW_NOXAPPEMIXEDFUEL

REFRESH_EMISSION_VIEW_NOXAPPESINGLEFUEL

REFRESH_EMISSION_VIEW_NOXMASSCEMS

REFRESH_EMISSION_VIEW_NOXRATECEMS

REFRESH_EMISSION_VIEW_OTHERDAILY

REFRESH_EMISSION_VIEW_SO2APPD

REFRESH_EMISSION_VIEW_SO2CEMS

Test Emission Reports

Stored Procedure
ORIS
Facility Name
Locations
Quarter

REFRESH_EMISSION_VIEW_ALL
2712
Roxboro
CS004A, 4A, 4B
2023 Q3

Monitoring Plan Ids

ORIS
Facility Name
Locations
MP Id

2712
Roxboro
CS004A, 4A, 4B
MDC-4F0130B46ADB4B4F9C2EE0BA4A72D463

Reporting Period Ids

Quarter
Id

2023 Q3
123

Testing Considerations

MODC 47 and 48 can cause duplicate rows for O2D, O2W and possibly CO2C and NOXC.

New issues affecting both public and workspace views:
Hourly NOx Rate CEMS View:

Rptd. % Diluent and Diluent MODC columns are null across an entire quarter (even for measured data hours) if MODC 46 is reported in the emissions data for the diluent component (doesn't affect NOXC MODC 46 and a diluent component reporting standard missing data MODC codes). Examples: ORIS 260, 1A (2023 Q3; only includes MODC 46 examples) and ORIS 7153, 5 (2023 Q3; includes MODC 46, 47, and 48 examples).

MATS HG View:

The "U" and "D" codes appear in the MATS Startup Shutdown column instead of "Startup" and "Shutdown". This is not an issue in the MATS SO2 and MATS HCL views (didn't check MATS HF as data does not exist). Example: ORIS 628, 4 (2023 Q3).
Sampling Train Component Id 1, Gas Flow Meter Reading 1, Ratio Stack Gas Flow Rate 1, Sampling Train Component Id 2, Gas Flow Meter Reading 2, Ratio Stack Gas Flow Rate 2 columns are null when these values are based on the prior quarter’s reported sorbent trap (quarter boundary trap). Example: ORIS 1356, CS023, 2, 3 (2023 Q3).

Responses to QA Results Comment

This was caused because the use of both Wet and Dry O2 data should include O2 without a Moisture Basis as either Wet or Dry when needed.  Before this correction, the Moisture Basis had to be explicit.

Acceptance criteria in attached document.
Testing Steps.docx

@esaber76 - would HOURGEN-9C be acceptable this test?

@ntknguyen - I would ignore that for purposes of this testing. Somebody likely reopened a QA window at some point for this facility and never resubmitted the data... If you start seeing this for every facility though, something else is going on (not related to this ticket).

@ntknguyen - ECMPS does not display records for MODC 47 and 48. These are odd scenarios where primary and primary bypass NOx systems exist at a single location and really represent two different stacks. In these cases, there could be 2 NOXC and/or 2 CO2C or O2C monitor hourly value records in the same hour. ECMPS only displays the MODC 46 records. The primary test for those examples is that 1.) MODC 46 does display in the Diluent MODC column and 2.) if measured data (MODC 01 as example) for both NOx and Diluent MODC columns is reported, the Rptd. % Diluent and Diluent MODC columns display data.

@ntknguyen - ECMPS does not display records for MODC 47 and 48. These are odd scenarios where primary and primary bypass NOx systems exist at a single location and really represent two different stacks. In these cases, there could be 2 NOXC and/or 2 CO2C or O2C monitor hourly value records in the same hour. ECMPS only displays the MODC 46 records. The primary test for those examples is that 1.) MODC 46 does display in the Diluent MODC column and 2.) if measured data (MODC 01 as example) for both NOx and Diluent MODC columns is reported, the Rptd. % Diluent and Diluent MODC columns display data.

So the view is displaying the correct data for this oris code/unit.  I understand now.  Thanks Scott.

Verified all the steps listed in the TestSteps.docx.  This issue is fixed.


Compiler doesn't infer generics on Field::from_be_bytes correctly

https://github.com/noir-lang/noir/pull/6084 added the Field::from_be_bytes and Field::from_le_bytes functions. These are generic in their inputs however the compiler doesn't seem to be able to determine the value of N from the passed array.
This is likely due to the fact that it's an impl on a primitive type, so we should check for inconsistencies between how we handle these relative to struct impls.

I thought about working on this next but this program:
fn main() {
    let bytes = [1, 2, 3];
    let field = Field::from_be_bytes(bytes);
}

crashes with the same error a recent PR tried to fix:
The application panicked (crashed).
Message:  while substituting (unbound): expected kind of unbound TypeVariable (Numeric(u32)) to match the kind of its binding (Normal)
Location: compiler/noirc_frontend/src/hir_def/types.rs:2003

so there might be other cases where Kind::Normal is used instead of Kind::Any (I wonder if Kind::Normal is the same as Kind::Any and only Any should remain).


Quill Streaming not "real" streaming (i.e. COPY stdin/stdout with Postgres)?

So I have a usecase at work where we need to input a huge amount of data into a Postgres dataset (talking about millions of rows here, if not more), perform a SELECT query and them stream the data back out
When checking the Quill docs, I firstly noticed that streaming only applies when SELECT which wasn't a problem since I was thinking that I just needed to implement the inserting however upon looking on the code I noticed that the streaming wasn't "real" streaming.
Unless I have missed something, what this means is that even though we may be streaming the data from Scala/Quill side, Postgres isnt actually aware of this. (this also explains why the streaming only works when querying i.e. with SELECT). In other words if you do a SELECT that results in, lets say, 10 million rows Postgres will actually output those 10 million rows at once into JDBC/Quill and then whatever streaming implementation you have (Monix/ZIO) will apply backpressure after that. If you had proper streaming via Postgres then it actually wouldn't output those 10 million rows at once (which can result in memory issues if the dataset is large enough), instead it would only output the number of rows that the client (in this case JDBC/Quill) can expect.
It turns out that Postgres has its own streaming support that is done via the COPY command, see

https://jdbc.postgresql.org/documentation/publicapi/org/postgresql/copy/CopyManager.html
https://stackoverflow.com/questions/6958965/how-to-copy-data-from-file-to-postgresql-using-jdbc
https://www.postgresql.org/docs/9.2/sql-copy.html

Typically this is used to stream data directly from files however postgres also lets you specify STDIN/STDOUT as an input/output. JDBC implements this as a CopyManager which allows various types of InptStream/OutputStream/Reader.
Ideally at least when working with databases that support direct streaming (i.e. JDBC+Postgres) we should be using this to do our streaming since it actually means the output (for inserts) or source (for selects) also does streaming.

Okay so I did a bit more research, basically this is going to be a bit of work to implement mainly because of the reason that COPY is not a proper prepared statement its just raw SQL. This is only because COPY works on a single table with basic filtering (so prepared statements are pointless). This is also the same reason why COPY is so fast, it basically bypass entire parts of the Postgres engine that is not necessary.
After going through the code, it seems Quill doesn't natively have the ability to create SQL statements with input parameters that don't use prepared statements (basically Quill is built completely around prepared statements), there also appears to be an issue on this (see https://github.com/getquill/quill/issues/205).
Ontop of this, COPY is quite limited in what it can do, i.e. you can only COPY from a single table and it seems that only basic WHERE filtering is allowed. This would mean having to adjust the macro AST so that one can only create valid COPY statements. This means having to do changes to the PostgresDialect to create a completely new type of statement (i.e. copy[MyTable] instead of query[MyTable]`?)
What are your thoughts @deusaquilus ? I am thinking maybe this makes sense for the next iteration of Quill? (unless there is an example somewhere were we use don't use prepared statements at all).


Interactive chart for TradingEnvironment using Plotly

This is an interactive chart for TradingEnvironment using Plotly for feature request #44 with the following features:

Includes price, marks for buy and sell trades, performance, and net worth.
Progressive or final: Can show end of episode chart or step-by-step progress during training with adjustable rendering interval to balance early and regular feedback to training time.
Mouse-hover text for more details on bars (standard) and buy/sell marks.
Training information can be shown on the chart itself (currently episode number and step).
Works in Jupyter Notebook and Jupyter Lab (with special extension for Lab) and can be easily extended in the future to work in a regular web page.
The usual JS charts features (zoom, pan, show/hide graphs, save as image form browser, ...etc).
Automatic saving to folder in multiple formats (requires Orca).
A chart example has been added.

Notes:

The chart mode has been changed from 'chart' to 'human' as used in OpenAI environments.
I repeated the fixes of #186 to pass the tests as its pull request hasn't been approved yet.
The step output in dqn_agent.py has been remove because it wouldn't work well with the chart.

@notadamking @mwbrulhardt this is the current look after the last commits. Please let me know if you have any comments.

@YasserHassan this looks great! The code needs a bit of clean up, otherwise this is a great contribution and I can't wait to get it merged! What is your Discord username btw?

@notadamking this is great. I made a couple of commits after my initial PR with small changes and cleanups.  Please let me know what's required to do it. I'll message you on Discord.

Once the conflicts are resolved I will merge this.


Confirm lua script functionality

e.g., this was committed after our SE logic:

https://github.com/emschwartz/interledger-rs/pull/192/files/9de2c7f94cf1ef6975baa23099f0726b8d84be17
https://github.com/emschwartz/interledger-rs/pull/192
https://github.com/emschwartz/interledger-rs/pull/199

Fixed via dc045888205371283e1739ab6ef9458300b2713a


use RequestStore instead of Thread[:current]

Use RequestStore (https://github.com/steveklabnik/request_store) instead of Thread[:current] in order to make sure that configuration does not stick longer than we would expect in servers like Thin or Puma.

@sebcioz thanks


Idea: create package from template

This would be awesome

This is done in 305de08bfd873d38c57a2fe4ba4fd328f200ea04
Now there's a new riotgen target called pkg. Feel free to close this issue if you think it's ok.

I'm closing this issue since it's resolved.


Missing info (where is target framework value stored)

Could you please extend this docu with information where exactly is the target framework value stored? All I can find in the csproj file is the 'TargetFrameworkVersion' value. I would like to know if my project is targeting regular/core/standard framework. Some more info: I'm creating something like an inventory scan for all my solutions. And I would like to create an nuget package dependency map. The problem is that Nuget packages can target multiple frameworks and I need a way how to get the target framework from the solution or project file.
Thank you in advice
Miro

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 57adfe0d-2b80-3afc-91c9-bd2a05696556
Version Independent ID: f332c66b-81a5-e054-3c5f-db82609cbb76
Content: Target a .NET Framework version in Visual Studio - Visual Studio
Content Source: docs/ide/how-to-target-a-version-of-the-dotnet-framework.md
Product: visual-studio-dev15
GitHub Login: @gewarren
Microsoft Alias: gewarren

@MiroslavMikus Is this the kind of info you'd like to see added to the topic?
For a .NET Core console app: <TargetFramework>netcoreapp2.1</TargetFramework>
For .NET Standard: <TargetFramework>netstandard2.0</TargetFramework>
For .NET Framework: <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion> (as you noted)


pre-train ERROR

I used the FER13 dataset, but this part of the source code did not provide initialization for train_dataset. I followed the same initialization method as below, but during the pre training process, an error occurred as shown in the figure. I don't understand why this problem occurred. I hope to receive your answer. Thank you

This was caused by the fact that we saved the dataset as a .npy object for quick loading. It was optimal because of the small size of the datasets.
I have updated the code to directly load from the dataset. Please download the datasets from official websites and organize them as directed in the readme.


Income.py get_e function add description

Add description to the get_e() function in income_polynomial.py to add more description on what is going on.  Also, pull the parameters to the top of the file.

Description added.  Deleted unused functions for exponentials.


Wrong .select2-search__field width right after item is deleted by backspace button

Right after i press delete (backspace) button it sets .select2-search__field to 0.75em and visible only one character http://screencast.com/t/kAQNuyX0yf http://screencast.com/t/ZGZe9n4jMd , when I press button second time it sets right width http://screencast.com/t/yGhfV8RxmT

:+1:
Here's a GIF showing the bug. The key I'm pressing to remove is backspace.

I'm seeing this problem with the placeholder text as well. To repro, enter a long place holder text over 15 characters.
temporary solution is to set select2-search__field width to 100%

I'm seeing this problem with the placeholder text as well. To repro, enter a long place holder text over 15 characters.

Sounds like a totally different issue, might want to open a ticket with a jsfiddle about it.

Actually setting width to 100% works quite well. There doesn't seem to have any nasty side effect either.
.select2-container--default .select2-search--inline .select2-search__field{
  width: 100% !important;
}

:+1: @rrhyne


We need a template for lab reports of some sort

Last year we tried both Matlab publish() and the new matlab notebooks but we didn't really instruct the students how to do this properly, so it was a bit of a mess. We need a better way to ensure they turn in decent reports and I'm not sure the Matlab functionality is really up-to-snuff to make a report like we desire.

We have a template on the website now. Abandoned using publish(), etc.


[SPARK-20327][CORE][YARN] Add CLI support for YARN custom resources, like GPUs

What changes were proposed in this pull request?
This PR adds CLI support for YARN custom resources, e.g. GPUs and any other resources YARN defines.
The custom resources are defined with Spark properties, no additional CLI arguments were introduced.
The properties can be defined in the following form:
AM resources, client mode:
Format: spark.yarn.am.resource.<resource-name>
The property name follows the naming convention of YARN AM cores / memory properties: spark.yarn.am.memory and spark.yarn.am.cores
Driver resources, cluster mode:
Format: spark.yarn.driver.resource.<resource-name>
The property name follows the naming convention of driver cores / memory properties: spark.driver.memory and spark.driver.cores.
Executor resources:
Format: spark.yarn.executor.resource.<resource-name>
The property name follows the naming convention of executor cores / memory properties: spark.executor.memory / spark.executor.cores.
For the driver resources (cluster mode) and executor resources properties, we use the yarn prefix here as custom resource types are specific to YARN, currently.
Validation:
Please note that a validation logic is added to avoid having requested resources defined in 2 ways, for example defining the following configs:
"--conf", "spark.driver.memory=2G",
"--conf", "spark.yarn.driver.resource.memory=1G"

will not start execution and will print an error message.
How was this patch tested?
Unit tests + manual execution with Hadoop2 and Hadoop 3 builds.
Testing have been performed on a real cluster with Spark and YARN configured:
Cluster and client mode
Request Resource Types with lowercase and uppercase units
Start Spark job with only requesting standard resources (mem / cpu)
Error handling cases:

Request unknown resource type
Request Resource type (either memory / cpu) with duplicate configs at the same time (e.g. with this config:

--conf spark.yarn.am.resource.memory=1G \
  --conf spark.yarn.driver.resource.memory=2G \
  --conf spark.yarn.executor.resource.memory=3G \

), ResourceTypeValidator handles these cases well, so it is not permitted

Request standard resource (memory / cpu) with the new style configs, e.g. --conf spark.yarn.am.resource.memory=1G,  this is not permitted and handled well.

Can one of the admins verify this patch?

Hi, please take some time to look at the how to contribute page:
https://spark.apache.org/contributing.html
You'll find the code conventions we use there. You have many style discrepancies in your code.
Also, given this is a YARN feature, there should be zero changes in core. All you're trying to do should be possible by just parsing user-provided config options in YARN's Client.scala.

ok to test

Test build #88235 has started for PR 20761 at commit 11aaa69.

Test build #88235 has finished for PR 20761 at commit 11aaa69.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/88235/
Test PASSed.

Thanks for your comments @vanzin !
The earliest I can resolve these and push the fixes is week after next, as I will not be available until then (vacation).

Can one of the admins verify this patch?

Hi @szyszy are you still going to work on this PR?

Hey! Exactly, I almost addressed all of Marcelo's comments so please expect a PR update in the coming days.

Cool, thanks!

Test build #90553 has started for PR 20761 at commit e0f40e0.

@vanzin : Reply to your main comment from above:
For the documentation: Please advise which documentation(s) should I update and where!
For your question about the case when user sets both: That’s why I created the ResourceTypeValidator class. As per our discussion, ResourceTypeValidator will not accept memory / vcores resource requests with the new yarn configs e.g. spark.yarn.executor.resource.memory will be denied with an error message.
I mentioned in another comment, but it’s worth to state here as well: I refactored ResourceTypeValidator and added a bunch of javadoc comments.
Also, I included how validation works in the PR's main description.
Do you agree with this kind of validation or do you have something else in mind?

Test build #90553 has finished for PR 20761 at commit e0f40e0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/90553/
Test PASSed.

Merged build finished. Test PASSed.

I may be missing something, but doesn't this change depend on Spark's yarn client being made hadoop 3.0 compatible?

Test build #90955 has started for PR 20761 at commit d1c7674.

Test build #90955 has finished for PR 20761 at commit d1c7674.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/90955/
Test FAILed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/90968/
Test PASSed.

@vanzin , @galv : I think all of your comments are either addressed or answered, please check once again!

Can one of the admins verify this patch?

I would like to see this merged, though I got derailed by spark summit last week and other things. I will look this patch over again soon @szyszy If you're busy lately, perhaps I can take over the rest of the code changes suggested by @vanzin, if necessary (I get the impression that this PR is just about ready to merge).
@vanzin I appreciate your detailed responses. I'm curious whether you have any overarching serious concerns about this patch, e.g., about its design. I think the interface is fairly appropriate, but I thought I should check whether you think this PR will be ready to merge soon.

Hi @galv!
Thanks for reaching out.
Actually I'm quite busy with other things so that's why I haven't been working on this lately.
It would be very great and I would be really happy if you could take this over.
Please confirm whether you could do this, the sooner I could work on this again is next week, approximately.

I don't have issues with the design - I think the main two things I was concerned about were:

not adding another way to set existing Spark options like mem and cores, which has been addressed
the seemingly unnecessary complexity in certain parts of the code like the validator

I agree that there is apparently unnecessary complexity in the validator.
I'll try to take a look again at the code today.
On Fri, Jun 15, 2018 at 9:15 AM, Marcelo Vanzin<EMAIL_ADDRESS>wrote:

I don't have issues with the design - I think the main two things I was
concerned about were:

not adding another way to set existing Spark options like mem and
cores, which has been addressed
the seemingly unnecessary complexity in certain parts of the code
like the validator

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/spark/pull/20761#issuecomment-397670091, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEi_UILXcjEIr37qdC17y73u0W2iz0iUks5t892NgaJpZM4Sg4v9
.

--
Daniel Galvez
http://danielgalvez.me
https://github.com/galv

Hi @galv!
Just a quick update, I will most likely have time next week to address the comments here.
In the meantime, you can pick this up and fix the issues, ideas on how to simplify the validator are appreciated.

Test build #93286 has started for PR 20761 at commit 55dfc98.

Test build #93286 has finished for PR 20761 at commit 55dfc98.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93286/
Test FAILed.

Hi @vanzin , @galv
Please check my latest fixes based on your previous comments.
@squito : Could you please join this review to speed things up?
Thanks in advance!

Test build #93336 has started for PR 20761 at commit 0ff9dee.

Test build #93336 has finished for PR 20761 at commit 0ff9dee.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93336/
Test FAILed.

Test build #93339 has finished for PR 20761 at commit b58df80.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93339/
Test FAILed.

Test build #93340 has started for PR 20761 at commit ad96372.

Test build #93340 has finished for PR 20761 at commit ad96372.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93340/
Test FAILed.

Test build #93342 has started for PR 20761 at commit 8b50a78.

Test build #93342 has finished for PR 20761 at commit 8b50a78.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93342/
Test FAILed.

Test build #93344 has started for PR 20761 at commit 9744b3d.

Test build #93344 has finished for PR 20761 at commit 9744b3d.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93344/
Test FAILed.

Merged build finished. Test FAILed.

Test build #93346 has started for PR 20761 at commit 2c2c250.

Test build #93346 has finished for PR 20761 at commit 2c2c250.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93346/
Test FAILed.

Test build #93348 has started for PR 20761 at commit 3fed831.

Test build #93348 has finished for PR 20761 at commit 3fed831.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93348/
Test FAILed.

Test build #93379 has started for PR 20761 at commit 21e60bc.

Test build #93379 has finished for PR 20761 at commit 21e60bc.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93379/
Test FAILed.

Merged build finished. Test FAILed.

Test build #93385 has started for PR 20761 at commit b92ba1e.

Test build #93385 has finished for PR 20761 at commit b92ba1e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93385/
Test PASSed.

Test build #96143 has started for PR 20761 at commit 8781b5e.

Test build #96143 has finished for PR 20761 at commit 8781b5e.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96143/
Test FAILed.

Test build #96179 has started for PR 20761 at commit ed36545.

Test build #96179 has finished for PR 20761 at commit ed36545.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96179/
Test FAILed.

Test build #96181 has started for PR 20761 at commit 50eda13.

Test build #96246 has started for PR 20761 at commit 8603876.

Test build #96246 has finished for PR 20761 at commit 8603876.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96246/
Test PASSed.

@srowen: Once again, thanks for the review.
I fixed most of what you suggested, if not then I made a comment.
Please check the updated code!
Thanks!

Test build #96836 has started for PR 20761 at commit 64246fc.

Test build #96836 has finished for PR 20761 at commit 64246fc.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96836/
Test FAILed.

Test build #96837 has started for PR 20761 at commit 51465db.

Test build #96837 has finished for PR 20761 at commit 51465db.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #96839 has started for PR 20761 at commit c38ed38.

Test build #96839 has finished for PR 20761 at commit c38ed38.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96839/
Test PASSed.

Test build #96973 has started for PR 20761 at commit b0e68d2.

Test build #96973 has finished for PR 20761 at commit b0e68d2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/96973/
Test PASSed.

Test build #97012 has started for PR 20761 at commit 76f7e62.

Test build #97012 has finished for PR 20761 at commit 76f7e62.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97012/
Test PASSed.

Test build #97025 has started for PR 20761 at commit 707eb18.

Test build #97025 has finished for PR 20761 at commit 707eb18.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97025/
Test FAILed.

Test build #97026 has started for PR 20761 at commit f360e61.

Test build #97026 has finished for PR 20761 at commit f360e61.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97026/
Test PASSed.

Test build #97212 has started for PR 20761 at commit 7e7a55a.

Test build #97212 has finished for PR 20761 at commit 7e7a55a.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97212/
Test FAILed.

Test build #97213 has started for PR 20761 at commit 55c7be9.

Test build #97213 has finished for PR 20761 at commit 55c7be9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97213/
Test PASSed.

Test build #97215 has started for PR 20761 at commit adddf6e.

Test build #97215 has finished for PR 20761 at commit adddf6e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97215/
Test PASSed.

Test build #97216 has started for PR 20761 at commit f1c2e41.

Test build #97216 has finished for PR 20761 at commit f1c2e41.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97216/
Test PASSed.

Test build #97218 has finished for PR 20761 at commit f509153.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97218/
Test PASSed.

Test build #97282 has started for PR 20761 at commit f3955f8.

Test build #97282 has finished for PR 20761 at commit f3955f8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97282/
Test PASSed.

Test build #97320 has started for PR 20761 at commit 72e014b.

Test build #97321 has finished for PR 20761 at commit dc2e382.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97321/
Test PASSed.

Merging to master.


Make delete and insert atomic in change loader

Currently we commit twice in change loader after delete and insert.


request: more visual "differences" between DAT:// and workspace: tabs, if they are not selected

Operation System: win 10
Beaker version: prerelease 4
If tabs are selected, there is a good visual difference between dat:// page and workspace ... but if a new tab is active there are 2 identical tabs
New Tab ... The 2 open tabs look identical, but they are not!

requested:

or something similar
workspace selected -> OK

Dat selected -> OK

Oh yeah that's an interesting idea, I'll discuss it with @taravancil. Thanks for filing it.

Yea. ... The tab UI is very "minimalistic" now. .. So it's hard to place a visual indicator, without ruining the design.

Solved: we got rid of workspaces


fix(healthcheck) decrease the lock usage

As discussed offline with @kikito, I'm closing this PR because it's too broad and opening independent ones.


[SuperEditor] Tab does not change the indent of a list item node

Steps to reproduce:

Run demo app of SuperEditor
Place the selection on a list item node
Press Tab key

Expected: the indentation of the list item node changes
Actual: the editor loses focus

Cc @matthew-carroll @angelosilvestre

@angelosilvestre SHIFT+TAB should un-indent but it moves focus as well.
Should we reopen this ticket or create a new one?

I'll re-open this one. @angelosilvestre can you put up another PR for SHIFT+TAB?

@matthew-carroll Yep.


Added the ability to install a custom tokenizer function.  (Same PR, different branch)

This would be useful for applications that have command syntaxes that can't be parsed by the simple space-delimited format supported by strtok_r(3).
This PR is identical to my other one, but this time I am using a branch called customTokenizer in my fork.  This may help to resolve an issue that Phil is having processing the PR.
Please use whichever PR is more convenient and decline the other one.

Yup, things are different now.  The unit tests are failing, which means that they are running. :-)  The failure is resulting from the fact that I am expecting EpoxyDuino (and specifically V1.0.0).
The two options are (a) I change back to LinuxHostDuino (b) you change your Github workflow to use EpoxyDuino V1.0.0.  I'm fine either way, let me know what you want me to do.

One other update.  I got a message back from Brian Parks and he has agreed to control the new EOL behavior change using a flag.  That's good news because it means that the new code will be compatible with your unit tests (any many other peoples' I suspect).  I will keep an eye out for his new release.

Continuing work from #12.
I'm going to try reverting back to using the older "UnixHostDuino" (on my local branch) and see if that lets the tests pass.  If so, maybe we can worry about updating library dependencies later (at our convenience).

Yeah, sorry for all the churn caused by the change in line termination in EpoxyDuino v1.1.0. As you saw, fixed in v1.2.0. The problem is, I have really no visibility in how my libraries are used..

Yeah, sorry for all the churn caused by the change in line termination in EpoxyDuino v1.1.0. As you saw, fixed in v1.2.0. The problem is, I have really no visibility in how my libraries are used..

@bxparks It's just one of those things that happens.
A stable library may not build very often.  Your client may not notice a breaking change until they do an unrelated push to their own code -- months later.
One way to catch this sooner is to just force a fresh build every week or so.  But then you need to pay attention to a failure at a random time.
It's an argument for checking out a frozen versions of a libraries... but I'm not sure that's the right answer either.  I really do want security fixes!

@bxparks It's just one of those things that happens.
A stable library may not build very often.  Your client may not notice a breaking change until they do an unrelated push to their own code -- months later.
One way to catch this sooner is to just force a fresh build every week or so.  But then you need to pay attention to a failure at a random time.
It's an argument for checking out a frozen versions of a libraries... but I'm not sure that's the right answer either.  I really do want security fixes!

@brucemack I had some cosmetic changes (code cleanup) on branch test and next which I should merge along with your changes.  I'm going to work that through with pull request #14.
This note is just to let you know I'm still working on it.
After so much time I need to remember how to do a successful release.  So... I'm adding a checklist for releasing code, too.
Branch test should have your changes in it.
I added a NEW_LINE macro to your CustomParserTest.ino to make it easier to switch between "\n" and "\r\n". The flexibility may not be needed any more.  But I think it helps communicate the meaning of those special codes better anyway.  If you disagree, let me know and I can back out that change.

@brucemack I had some cosmetic changes (code cleanup) on branch test and next which I should merge along with your changes.  I'm going to work that through with pull request #14.
This note is just to let you know I'm still working on it.
After so much time I need to remember how to do a successful release.  So... I'm adding a checklist for releasing code, too.
Branch test should have your changes in it.
I added a NEW_LINE macro to your CustomParserTest.ino to make it easier to switch between "\n" and "\r\n". The flexibility may not be needed any more.  But I think it helps communicate the meaning of those special codes better anyway.  If you disagree, let me know and I can back out that change.

Hi Phil, Happy New Year.  Checklist and NEW_LINE changes are both good ideas.

Hi Phil, Happy New Year.  Checklist and NEW_LINE changes are both good ideas.

@brucemack I think I have merged your changes to main and created a new 0.2.3 release.
Soon (tomorrow?) you should be able to pick it up from the Arduino IDE.  There were some merge conflicts (for EpoxyDuino<-> UnixHostDuino naming, and the NEW_LINE macro), but I think it's OK to ignore them.
Let me know if this works for you.  Thanks again for the contribution!

Everything looks good, thanks for accepting my change.  I am closing this PR.  Have a good day.


Add support for new Chrome versions

@guiliredu are you using it for real? Never thought someone would and it's clearly not maintained on my side.

Yeah, i had to use it in a project... Your solution was the best of all I tried, so I made a few changes to run in Chome. I made a fork of it, so if you dont want to accept that's ok.

Music to my ears. I'm gonna merge it and make a new release. Thanks a lot man.


[Proposal] FlexLayout Basis extension method overload + Doc and samples

FlexLayout Basis extension method overload

[x] Proposed
[x] Prototype
[X] Implementation

[X] iOS Support
[X] Android Support
[X] macOS Support
[X] Windows Support

[X] Unit Tests
[x] Sample
[x] Documentation https://github.com/MicrosoftDocs/CommunityToolkit/pull/53

Link to Discussion

https://github.com/CommunityToolkit/Maui.Markup/discussions/34
Summary

This proposal adds a method overload to the Basis<T> extension method, so that FlexBasis can be set without the need for instantiating a FlexBasis struct. Also samples and docs for the existing FlexLayout methods will be added.
Motivation

Allows for more options when declaring FlexBasis.
Detailed Design

public static TBindable Basis<TBindable>(this TBindable bindable, float length, bool isRelative = false) where TBindable : BindableObject
{
      return bindable.Basis(new FlexBasis(length, isRelative));
}

Usage Syntax

Content = new Label().Basis(25, true);

Drawbacks

None
Alternatives

None
Unresolved Questions

None

Thanks @danielftz! I approve this Proposal ✅
Once we get two more votes (ie a majority approval from the core team) we'll review + merge the Pull Request 🙌

Approve

I approve this feature ✅


LWRP

Hi, I tried to use the shader point cloud with LWRP, and works, but not the color. how can I fix this?
regards

It should work with LWRP. Does it work correctly when using the legacy render pipeline?

I'm closing this issue now. Please feel free to reopen it for further problems.


If fs.renameSync fails, try fs.copySync and fs.unlinkSync instead

Issue
When setup-nextflow is ran after easimon/maximize-build-space, the fs.renameSync fails.
In github action:
      - uses: easimon/maximize-build-space@v7
      - uses<EMAIL_ADDRESS>
Results:
Run<EMAIL_ADDRESS>Input version 'latest-stable' resolved to Nextflow Version 23.04.2
Preparing to download from https://github.com/nextflow-io/nextflow/releases/download/v23.04.2/nextflow
Error: EXDEV: cross-device link not permitted, rename '/home/runner/work/_temp/f369ad38-5c5e-41aa-80b1-0ea1984b0f34' -> 'nxf-v23.04.2bkEavA/nextflow'
Warning: Nextflow appears to have installed correctly, but an error was thrown while running it.

Changes

If fs.renameSync fails (e.g. because source and destination files are on different partitions), try fs.copySync and fs.unlinkSync instead.

Hello @MillironX @Emiller88 ! Would you have a chance to take a look at this?

I recently joined the nf-core org and am a new face in this repo, but I disagree with merging these changes. It adds a lot of code to an unexpected interaction with a not very commonly used action (maximize-build-space only has 205 stars).
Also, I think it should be on easimon/maximize-build-space to ensure that their action doesn't break common commands like fs.renameSync. There are a lot of possible actions that use fs.renameSync and instead of merging similar changes to all of them, perhaps maximize-build-space should create a fix on their end?

I guess I should have better explained what the root cause of the issue is, namely that fs.renameSync does not allow to rename files across partitions. The issue I'm trying to fix is thus not unique to this particular use case.
As a side note, what easimon/maximize-build-space does is it creates a large image stored on multiple mount points in order to maximise the amount of space that the user is able to work with.

It adds a lot of lines of code

I'd argue that providing a failover mechanism for errors that your users are encountering is not added complexity, but just graceful handling.
-  fs.renameSync(nf_dl_path, nf_path)
+  try {
+    fs.renameSync(nf_dl_path, nf_path)
+  } catch (err: unknown) {
+    core.debug(`Failed to rename file: ${err}`)
+    fs.copyFileSync(nf_dl_path, nf_path)
+    fs.unlinkSync(nf_dl_path)
+  }

not very commonly used action (maximize-build-space only has 205 stars).

Star count is not a good metric for how useful a tool is. That aside, I'm actually surprised that I'm the first to report this issue, since the maximize-build-space action is commonly used when a lot of disk space is needed.
In particular, I use it to test Nextflow pipelines which require large Docker images (e.g. the nvcr.io/nvidia/pytorch easily use up 10GB of disk space) and which require large test datasets.

Also, I think it should be on easimon/maximize-build-space to ensure that their action doesn't break common commands like fs.renameSync.

I don't think this is possible. The "EXDEV: cross-device link not permitted" is an error inherent to fs.rename and fs.renameSync. See this stackoverflow for more information.

I hope this addresses any concerns you may have, @kenibrewer. If you feel my proposed solution could be improved upon, I'd be happy to incorporate your suggestions in my PR.

I'd argue that providing a failover mechanism for errors that your users are encountering is not added complexity, but just graceful handling.

I agree, I was more afraid of silent errors because it was handled. 😆
Do you have an example of it in use? Sorry, I forgot to kick off the tests, let's see if they all pass!

@rcannood Thanks for the explanation, and I apologize for being a bit too harsh on your pull request when I didn't fully understand the context behind the changes. Everything you've explained makes sense to me and your solution seems like the best course forward to me too. Cheers!


Provide page in the context of StreamField blocks

I came across the limitation that the page is missing in the context of related StreamField blocks when rendering the blocks template several times. A typical use case is when you need to implement an intro block, where the page title and author should be displayed.
So far I was not able to solve this as a complete StreamField block.  Instead I check for this block type and call a template with {% include %} and the necessary data as parameters.
The hurdle occurs in the majority of cases when you need to display data from builtin fields of Wagtails Page model. Otherwise you would be able to design it like it should be.
This issue is opened in addition to #1743 to clearly separate the discussion between the different requirements to have request and page available in the template context. I fully agree with https://github.com/torchbox/wagtail/issues/1743#issuecomment-144029475, though.

I agree, and the parent block (if any) would also be extremely useful in a lot of cases.

I solved this case in one project. It's very useful.

See updates on https://github.com/torchbox/wagtail/issues/1743#issuecomment-224543332 for a suggested way forward here, which should (hopefully...) be intuitive and consistent with Django's {% include %} tag. In the proposed solution, the entire template context is (by default) passed to the block template, so this will cater for both page and request.

Workaround: https://gist.github.com/mgd020/d841f8016024707b11b490b82ec648f0

This issue and issue #1743 were partially solved in #2786. But the feature still needs some work (see #2823 and #2824).

Closing this now, as the specific issue described here is fixed by #2786 (even if there is further work to do on the feature as a whole).


Release 0.8.0

The main changes in this release are

Added support for stk structures in the Python package
Added support for environments in chemiscope.explore
Added featurizers based in metatensor models in chemiscope.explore
Removed old functions from the Python API

Can we wait until #371 is merged? It also changes the API by removing an option for size.
I actually have another quick PR I'd like to set up. Let's leave this open for a bit if that's OK.

I need this for the plumed tutorial, but we can try to get #371 merged, as well as something else if you need it!
Although I don't think #371 is a breaking change, the only thing that would happen with the removed setting would be a warning about unknown setting.


Add bad use of tx.origin

tx.origin should not be called for authorization.
See slither testcase to have examples of incorrect and legitimate usages:
https://github.com/trailofbits/slither/blob/2aea762600ebdb46798f53c7dd65ac375783c5dc/tests/tx_origin.sol

@montyly
view PR

Hi, sorry for the late reply. The PR looks good, I added a small feedback to it.


default options to handle 401,403

handle 401,403 to emit event
handle set-cookie
method with opt param

https://github.com/unjs/ofetch/issues/441
https://github.com/unjs/ofetch/issues/207

https://github.com/unjs/ofetch/blob/main/src/fetch.ts


Investigation: ilab model serve optimizations for instructlab tuned models

This is tracking an effort to determine the optimal set of vllm versions + configuration options for serving instructlab trained granite models.

Abhishek Bhandwaldar
Dinakaran Joseph
Jason Greene
to drive main exercise of determining best practices for serving and chatting with ILAB model
Currently: ilab model serves default parameters on RHEL AI 1.2 in combination with using ilab model chat is leading to undesirable output on instructlab trained models

Investigation proved there was no differences in serving content


error[E0277]: the trait bound tarkov::constant::Item: serde::ser::Serialize is not satisfied

First off, thank you so much for replying to these issues.
I want to write the items result to a file. I try doing this with serde, however it doesn't seem like it is particularly fond of tarkov::constant::Item .
Is there a way around this?
Full error message:
error[E0277]: the trait bound `tarkov::constant::Item: serde::ser::Serialize` is not satisfied
    --> src\main.rs:61:36
     |
61   |     serde_json::to_writer(file_items, &items)?;
     |                                       ^^^^^^ the trait `serde::ser::Serialize` is not implemented for `tarkov::constant::Item`
     |
    ::: C:\Users\einarw\.cargo\registry\src\github.com-1ecc6299db9ec823\serde_json-1.0.46\src\ser.rs:2167:8
     |
2167 |     T: Serialize,
     |        --------- required by this bound in `serde_json::ser::to_writer`
     |
     = note: required because of the requirements on the impl of `serde::ser::Serialize` for `std::collections::HashMap<std::string::String, tarkov::constant::Item>`

Cargo version
1.41.0
Cargo.toml
[package]
name = "test_package"
version = "0.1.0"
authors = ["me"]
edition = "2018"

[dependencies]
serde_json = "1.0"
tarkov = "0.1.1"
tokio = { version = "0.2", features = ["macros"] }

Main.rs
use tarkov::auth::LoginError;
use tarkov::hwid::generate_hwid;
use tarkov::{Error, Tarkov};
use std::io;
//use std::time::{SystemTime, UNIX_EPOCH};
//use tarkov::market_filter::{Currency, MarketFilter, Owner};
use tarkov::profile::Side;
use std::fs::File;
use serde_json;

#[tokio::main]
async fn main() -> Result<(), Error> {
    std::env::set_var("RUST_LOG", "tarkov=info");

    let email = "<email@email>";
    let password = "<pw>;
    let hwid = "<hwid>";

    // Create a new hwid, will require 2fa
    //let hwid = generate_hwid();
    //let mut file_hwid = File::create("hwid.txt")?;
    //let byte_hwid = hwid.as_bytes();
    //file_hwid.write_all(byte_hwid)?;

    let t = match Tarkov::login(email, password, &hwid).await {
        Ok(t) => Ok(t),
        Err(Error::LoginError(e)) => match e {
            // 2FA required!
            LoginError::TwoFactorRequired => {
                // Get 2FA from email (or generate TOTP) then continue...
		let mut code = String::new();
		println!("Input 2FA:");
		io::stdin().read_line(&mut code).expect("Failed to read input");
		let len = code.trim_end_matches(&['\r', '\n'][..]).len();
		code.truncate(len);
		println!("{}", &code);
                Tarkov::login_with_2fa(email, password, &code, &hwid).await
            }
            _ => Err(e)?,
        },
        Err(e) => Err(e),
    }?;

    println!("{}", t.session);

    let sess = Tarkov::from_session(&t.session);

    // Find and select PMC profile to complete login.
    let profiles = sess.get_profiles().await?;
    let profile = profiles
        .into_iter()
        .find(|p| p.info.side != Side::Savage)
        .unwrap();
    sess.select_profile(&profile.id).await?;

    // Fetch the translation table for market categories.
    let locale = sess.get_i18n("en").await?;

    // Fetch items and write to file
    let items = sess.get_items().await?;
    let file_items = File::create("items.txt")?;
    serde_json::to_writer(file_items, &items)?;
    Ok(())
}

After having fiddled around with the problem for a while, I realized I never needed to serialize the tarkov Item to begin with. I ended up placing the properties I needed into a new hashmap, writing this new hashmap to a file with serde.
I'm pretty new to Rust and keep learning as I go, so I will close this issue. Feel free to comment still, if you have anything to add!
In case anyone else encounters this issue, and wants to know how I went about solving it, here's that part of the code:
// Fetch items and write to file
let items = sess.get_items().await?;
let mut map_items = HashMap::new();
for (k, v) in items {
	map_items.insert(v.name, v.id);
}
let file_items = File::create("items.txt")?;
serde_json::to_writer(file_items, &map_items)?;

I get the feeling I was trying to use tarkov::constant::Item in a way it was never meant to be used, so this was probably a non-issue to begin with.

Serialize trait is not implemented for that type: https://docs.rs/tarkov/0.1.1/tarkov/constant/struct.Item.html
I’ll “fix” this eventually.


New example cases: Lid-driven cavity (compressible), double Mach, and more

Simulate and add several new examples/test cases to the examples/ directory:
I will accept PRs that add these individually (they do not have to be added all at once). Please add small (in terms of MB) visualization images of the results to the example/ directory.
I will also accept additions to this list, particularly problems in 3D or multiphase 2D problems.

Shu-Osher problem (1D):

https://arxiv.org/pdf/2110.05461.pdf

Lax shock tube problem (1D):

https://arxiv.org/pdf/2106.01738.pdf (eqn 59)

Titarev-Toro problem (1D):

https://arxiv.org/pdf/2110.05461.pdf

Riemann test problem (2D):

https://epubs.siam.org/doi/10.1137/0914082
https://arxiv.org/pdf/2110.05461.pdf

Rayleigh-Taylor instability (2D):

https://arxiv.org/pdf/2110.05461.pdf (example 4.7)
https://www.sciencedirect.com/science/article/abs/pii/S0021999101968925?via%3Dihub
https://arxiv.org/pdf/2106.01738.pdf (example 4.7)

Lid-driven compressible cavity (2D), finite Reynolds number:

https://doi.org/10.1016/j.cpc.2022.108527
https://arxiv.org/pdf/2106.01738.pdf (example 4.12)

Double-Mach reflection (2D):

https://doi.org/10.1016/j.camwa.2022.12.003
https://arxiv.org/pdf/2110.05461.pdf (example 4.8)
https://arxiv.org/pdf/2106.01738.pdf (example 4.9)

Kelvin-Helmholtz instability (2D):

https://arxiv.org/pdf/2106.01738.pdf (example 4.8)

Viscous shock tube (2D):

https://arxiv.org/pdf/2110.05461.pdf (example 4.9)
https://doi.org/10.1016/j.compfluid.2008.06.008
https://arxiv.org/pdf/2204.00393.pdf

Double periodic shear layer (2D):

https://arxiv.org/pdf/2206.14891.pdf (sec 4.2)

Shock-cylinder interaction (2D):

https://arxiv.org/pdf/2106.01738.pdf (example 4.17)

Viscous Richtmeyer-Meshkov instability (2D):

https://arxiv.org/pdf/2106.01738.pdf (example 4.18)

Underwater explosion (2D):

https://doi.org/10.1016/j.compfluid.2015.07.010 (fig 12 and 15, sec 4.4)

Compressible decaying isotropic turbulence (2D and 3D!):

https://doi.org/10.1016/j.cpc.2022.108527

Spherical underwater explosion in a rigid cylindrical container (3D)

https://doi.org/10.1016/j.compfluid.2015.07.010 (sec 4.5)

Liquid jet in crossflow (3D)

https://doi.org/10.1016/j.jcp.2014.09.005 (fig 36)
https://doi.org/10.1016/j.ijmultiphaseflow.2022.104303
https://doi.org/10.1016/j.ast.2019.05.017

@sbryngelson How do you want to handle the cases that will require hardcoding analytic initial conditions?

@wilfonba for cases with analytic functions, I think we should add some functionality to make this possible without commenting/uncommenting source code. I'm open to suggestions. Some example possibilities are

Allowing analytic functions in the Python dictionary
Adding new functions as new patch types
etc.

What do you think of having the user supply an additional input file with fypp functions that can be included in m_patches.f90?

I'm not sure I understand, I would have to see a small example I think.

I'll put something together

@wilfonba I’d be happy to discuss possible toolchain implementations.

@wilfonba What if, in the case.py file you could have something like
	'patch_icpp(1)%geometry': 15,
	'patch_icpp(1)%pres': '5*x',
	'patch_icpp(1)%vel(1)': = '10*sin(2*x**2)',
	...

and then in m_patches.fpp or perhaps in m_assign_variables.fpp you would have something that copies/pastes these strings ('5*x' and '10*sin(2*x**2)') into a function that assigns the analytic values depending on the value of x_cc or x_cb or y_ or z_. Something analogous would be done for 2D/3D so you could also have
	'patch_icpp(1)%geometry': 7,
	'patch_icpp(1)%pres': '5*x*y',
	'patch_icpp(1)%vel(1)': '10*y*sin(2*x**2)',
	'patch_icpp(1)%vel(2)': '10*x*sin(2*y**2)',
	...

for example, in 2D (note that 15 and 7 are the patch numbers associated with 1D and 2D analytical right now). All such analytic string expressions would have to be in Fortran syntax.
I think something like this would actually work really nicely and cleanly, and actually shouldn't require any toolchain changes (or only very small ones). It would require using fypp in pre_process, and a new macro to parse those analytic expressions into the Fortran code. @henryleberre can easily help with those parts easily.
This would actually be quite the improvement to the code, since we could remove all hard-coded analytic functions and basically never need to do that again!

That was the first idea that had come to mind for me as well, but I didn't think to parse the strings in Python rather than in Fortran and some googling suggested doing so in Fortran is rather difficult. I'm sure there's a python package somewhere that takes care of that already though, so I'll do it that way. It is the cleanest.

So I think we don't want to parse the strings in Python at all (I may well stand corrected later).
Instead, we want to use fypp to copy-paste the Python strings into the Fortran code as raw code and do a fypp-powered substitution (like x -> x_cb(i), y -> y_cb(j)) so that you can loop through x/y/z space appropriately.

Ah, I see what you mean now. That makes sense.

Ah, I see what you mean now. That makes sense.

I would like this printed and framed :D

Updated the issue in light of #176

Riemann problem taken care of in #256

@sbryngelson the 2D single-material triple point problem here (https://arxiv.org/abs/2312.17042) might be worth adding to this.

[x] 3D: Inviscid and viscous isotropic Taylor--Green vortex
by #573


Added Mohammed Chahboun to authors

Adds Mohammed Chahboun to authors

@nate-thegrate
Thanks for your support 👍🏾


Adds event triggering for various streaming mapreduce init events

LGTM

I would like to know why you do this. Out of curiosity. LGTM.

It's nice to have events to hook into for third party modules to be able to interact or extract info from the hadoop running environment when it isn't feasible to create a new base class for people to use.
In this specific case, I was mostly looking for a way for us to change a runtime pyschema configuration setting before a job starts in hadoop, without having that code going into a derivative base class of the HadoopJobTask. In the long run, these sort of handlers will let people all inherit from the recommended/shipped classes and extend them through event handlers instead. Not sure if that's a good explanation, but maybe clear enough? :)

I think it's good. Would be awesome to see it in the commit message too.

I'll fix the failing test... The assertion I made isn't quite true for remotely executing jobs using the minicluster.

Coverage increased (+0.16%) to 76.04% when pulling 92131f1937432601255da06275f5b7917f33c933 on freider:python_mapreduce_init_events into 9a5d04e489c0981ba63767c0349667d536fcc93f on spotify:master.

I have to rethink this a bit because of how code distribution works with luigi mapreduce. Closing the PR for now