How to - links to translations

Problem
As a user of rtd theme, how can we add a link to the translated versions?
ReadTheDocs takes the example of phpmyadmin for that, here is a screenshot of the feature.

Solution
Is it implemented here as well, or just on the hosted version? I searched issues, code and documentation, I didn't find this feature.
I'm asking to improve Nextcloud documentantion.
Thanks for your help!

This is only a feature of Read the Docs currently. We're discussing whether the flyout menu should be separate from the theme or not, as there is confusion here about where this is rendered right now.
You can manually manipulate a _templates/versions.html to accomplish what you're looking for either way though, but that is outside the scope of what core team supports.


Get mp4s rendering and playing on editorial page

https://www.pivotaltracker.com/story/show/155603725

          1 Warning

:warning:
Please provide a linked tracker story for this PR in the description

  Generated by :no_entry_sign: Danger

I still need to get tests passing and cover images rendering gifs properly again.


feat: Dynamic Address Book Phase 2 protobufs changes

Description:

Related issue(s):
Fixes #343
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Apologies for the volume of suggestions. Nearly every specification comment could use substantial improvement here.
Note Github will hide the majority of these; you'll need to "show more" a few times. Also, it may be prudent to "add to batch" all of these and edit from there to save time.

Thanks for the review comments @jsync-swirlds. I took some of the suggestions and left some others unchanged as most of the field definitions and comments have been reviewed in other PRs and Notion page and HIP has been created from them. Some of them are to match the current definitions in other proto files.

I took some of the suggestions and left some others unchanged as most of the field definitions and comments have been reviewed in other PRs and Notion page and HIP has been created from them. Some of them are to match the current definitions in other proto files.

The field comments are pretty lacking in details and I think Joseph has a lot of really good additions to the comments. I don't think we should cherry pick a few of those but should try to incorporate as much as possible. We probably need a meeting to discuss further.

There will be another meeting later today to possibly change public_key. If needed, I will setup a meeting tomorrow for us to discuss. Thanks.

Current hedera-services, develop branch uses hedera-protobufs, v0.50.0-release branch. The main branch will be used after release .50 branch cut. There will be another hedera-services PR merged after release .50 branch cut.


[Feature] Simcoe Example Project

Added a sample project to the Simcoe Workspace.

Noticed a couple general things, but not sure if I need context on this PR so lemme know if so

Are SimcoeExample and SimcoeExample3 supposed to be included in this PR? SimcoeExample2 is the runnable one. If not, should remove the unused projects and rename example for the repo to not include a number
Could definitely use a better directory structure for the project. AppDelegate/info.plist/etc in Supporting Files. Maybe group the other files by feature/related functionality or Models/Views/View Controllers


How translate large texts

How could I translate large texts since the package omits them. Would I have to manually put them into Excel?

@bikram0000 Thank you, good work.

@bikram0000 Thank your, good work.


[Request] Add favourite article

Goals
If we had hundreds of article, it's better to inform reader which one to read first.
Inspiration: Julia Evans's blog
working code
Unstaged changes (1)
modified   templates/archives.html
@@ -57,8 +57,13 @@ Full archives of {{ SITENAME|striptags|e }} blog.
                     {% endif %}
                 {% endif %}

-
-                    {{ article.title }}
+
+               {% if article.favourite %}
+                    {{ FAVOURITE_SYMBOL }} {{ article.title }}
+                    {% else %}
+                      {{ article.title }}
+                    {% endif %}
+
                     {%if article.subtitle %}

                         {{ article.subtitle }}

in pelican.conf:
FAVOURITE_SYMBOL = "🌟"

oh, no. that bug label added automatically after I choose 'bug' template. even if I remove the [bug] tag :)

@talha131 if pelican teams okay with this. I will make appropriate PR.

@azzamsa couple of feedback.
Do we really need it?
I have seen some blogs create a special page, "Start here", or "Essential Readings" or "Greatest Hits". They list their essential and popular articles in it.
For example:

https://www.kalzumeus.com/greatest-hits/
https://www.kalzumeus.com/start-here-if-youre-new/

Users can do similar in the Elegant theme. Pages appear in the top menu bar automatically.
If you insist
I have no strong feelings on this feature. You are more than welcome to open PR provided you take care of following things.

The symbol should be a Unicode emoji instead of SVG or PNG image
Symbol should be configurable like ⭐ or 🥇 or 🔖 or 📌 or 📍 (I see you already have that 👍 )
Symbol should appear in the list on Categories, tags and archives pages

Questions?

How to show this information on the article page? If in the sidebar then under what heading?
Should be make it configurable such that the user can rate his article like some articles are five stars (⭐⭐⭐⭐⭐) and some only 2 (⭐⭐)?
Should we have a new page to automatically generate a list of favorite articles?

Do we really need it?

Yeah, that's why I asked before making such PR. I though this is not for everyone.
So I'd better go with 'favorite pages' in my navbar.

So I'd better go with 'favorite pages' in my navbar.

Does this mean we can close this issue?

Yeah, I just wait your response :)

For anyone landing here:
I don't plan to add this feature to upstream pelican. This style is not for everyone.
But if you want, you can take this commit as patch and apply to your 'customized' theme.


The value of HEX make wrong when drag the alpha-pointer

The value of HEX make wrong when drag the alpha-pointer

Give me please wrong value, as I can see from Demo, everything works fine


.cd not working

Describe the bug
When trying to use .cd, the bot always comes back with "The directory does not exist", despite it being in the path to the malware itself or anywhere else
To Reproduce
Steps to reproduce the behavior:

Type .cd
Error.

Expected behavior
The bot to change active directory.
Screenshots

Desktop:

OS: Windows 10
Python Version: 3.11.3
PySilon language: Python

well it deletes your command, what did you write that you had an error?

I will close this as resolved for now?


Documentation for scipy.signal.resample should say what to use with nonperiodic signals

The documentation at https://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.resample.html  says that this resampling function assumes the input is periodic. It would be helpful if it also linked to the appropriate function to use for resampling non-periodic signals.
Thanks!

Hi @creidieki, the "See Also" section for resample includes a link to resample_poly, which does not perform an FFT on the input signal, and thus doesn't require the periodicity assumption. PRs that improve documentation clarity are always welcome, if you'd like to submit one.


api idea: extract packages: subscriber, event

import { on } from "resubscriber";
import { event } from "revent";

const ev = event();
on(ev, (v) => {
  console.log(v)
});

Events exclude from remini
And add resubscriber as a dependency

"resubscriber" - is a good idea. But now it is on hold.


[stable/verdaccio] Add myself as maintainer and update home domain and icon

Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

No
What this PR does / why we need it:
Add maintainer
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #13869

Special notes for your reviewer:
I maintain the Verdaccio project.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

/retest

Test are failing after retry? Could someone help me what I'm suppose to do now?

Well, I'm still waiting for what to do, so please bot un-stale.

/retest

@juanpicado it seems like the stable repo is getting sunset in favor of orgs owning their own repos https://github.com/helm/charts#deprecation-timeline
If you make a new repo under the Verdaccio org and add me as a maintainer for that repo I'd be happy to poke around getting that set up for you as the existing chart needs some clean up, even just regarding documentation. Also happy to work in a folder in https://github.com/verdaccio/verdaccio and PR if you like.

@juanpicado it seems like the stable repo is getting sunset in favor of orgs owning their own repos https://github.com/helm/charts#deprecation-timeline
If you make a new repo under the Verdaccio org and add me as a maintainer for that repo I'd be happy to poke around getting that set up for you as the existing chart needs some clean up, even just regarding documentation. Also happy to work in a folder in https://github.com/verdaccio/verdaccio and PR if you like.

Let's do it, I'll setup a new repo, I wonder how we are suppose to publish Helm charts from there?

Just gotta setup github packages and then add the repo to helm hub
https://github.com/features/packages
https://github.com/helm/hub

Just gotta setup github packages and then add the repo to helm hub
https://github.com/features/packages
https://github.com/helm/hub

Let's keep discussing here https://github.com/verdaccio/verdaccio/issues/1767 , please help me to describe the list of things we need to finish in order to accomplish this task


docs: remove “With …”

All headings start with “With…”. I don’t think that’s needed. 😅

good call ✨🥳


Cant rotate to 90 degrees while in grid mode

The text shows up crooked when trying to rotate to 90% using the anchor

Hey! This seems to be working now. I am able to rotate text to 90 degrees while in grid mode.

@pvaliyaveedan Please always provide steps to reproduce the issue

Hi @dwelle, I was looking at the behaviour and code responsible for this and below are my findings, please let me know if I have missed anything in the findings:

When user has kept the pointer down on the rotate button, the function onPointerMoveFromPointerDownHandler gets called and inside we have pointerDownState.resize.isResizing as true and pointerDownState.resize.handleType as rotation and maybeHandleResize function gets called.
Inside the maybeHandleResize function, we compute resizeX and resizeY which correspond to the pointer's actual x and y location if the grid is not enabled and if grid is enabled or if the grid is enabled but the ctrl or cmd key is pressed, otherwise they are rounded off to nearest location on the grid.
These resizeX and resizeY coordinates are used to calculate the new angle by which we want the current element to rotate. Since the grid is enabled, it will keep rounding off to the nearest location so a chunk of pointer locations they will get mapped to the same grid location and for all of those coordinates the angle will be returned same.
In certain dimensions the new angle won't ever reach the multiples of 15 degree (our SHIFT_LOCKING_ANGLE) that are near to let's say 0, 90, 180, 270 and 360 because the resizeX and resizeY are computed in such a way relative to grid that either they'll pick 15 or 345 but not 0, similarly for the other angles.

The work around for this is - pressing ctrl/cmd key overrides the behaviour where resizeX and resizeY are never rounded off to nearest grid points and pressing shift will allow the angle to reach the 0 deg, 90 deg and other multiples of 90 degs. Not sure if that's the semantic purpose of the pressing cmd key while pointer is down, or what we can also do in code is as follows:
+   const isRotatingWithShiftKey = event.shiftKey && transformHandleType === "rotation";
    let [resizeX, resizeY] = getGridPoint(
      pointerCoords.x - pointerDownState.resize.offset.x,
      pointerCoords.y - pointerDownState.resize.offset.y,
-     event[KEYS.CTRL_OR_CMD] ? null : this.state.gridSize,
+     event[KEYS.CTRL_OR_CMD] || isRotatingWithShiftKey ? null : this.state.gridSize,
    );

Let me know what your thoughts are on this and would be happy to raise the PR for the above change if it sounds good to you!

I would like to work on this issue. My suggestion is to show the angle input box whenever user try to rotate anything. Using the custom input for changing angle will make it far better. Assign this task to me!


Write more robust tests

Make sure the project is fully tested for all many of possible inputs and use cases.
For example:

Ensure sensible errors are thrown when presented with incompatible inputs.
Find and create tests for edge cases.
Each static function can be unit tested.

where does this work i don't see it in any of my terminals

@ebarnsli What is it you've tried to do? Have a look in the test dir for how to pass data to the Table.create method.
I'll write up some documentation.

Whenever i used it in the terminal i the Color separators just come out as unicode characters and not a colored |

thanks for taking my tests :) i tried to knock off the smaller functions, unfortunately it was a little challenging to dig into some of the large functions. After about an hour i felt relatively familiar with your code which was a 👍 to me :)

@ebarnsli Thanks so much, your contribution is very much appreciated. If you want to tweak anything or add any other features do feel free, ping over a PR anytime.


Update issue caused by nvim 0.10.0

Everything is normal in nvim v0.9.5, but when I updated nvim to 0.10.0, diagnostics sign disappeared

https://github.com/luukvbaal/statuscol.nvim/issues/103#issuecomment-1937791243

https://github.com/luukvbaal/statuscol.nvim/issues/103#issuecomment-1937791243

thank you!
After changing the configuration according to your guidance, everything works well!
PS: the word "diagnostic", The first letter must be lower case 'd' not 'D', the upper case doesn't works


Add JHipster Quarkus support

The JHipster Quarkus blueprint has now an Okta support.
https://github.com/jhipster/generator-jhipster-quarkus/releases/tag/v0.2.0
It would be great to propose the same level of integration as Spring Jhipster

Nice!!
Do we need anything in addition to what is here: https://github.com/okta/okta-cli/pull/71
Are the redirect URI's, scopes, etc needed all the same? Between JHipster's Spring and Quarkus integrations?

IMHO, when #71 is merged.
Jhipster Quarkus can be made in couple of hours!
I need your help to fix the #71 CI, I'm stuck...

In the context of Jhipster Quarkus the scopes and redirect uris are the same but the properties are different

Fixed in 0.8.0. https://github.com/okta/okta-cli/releases/tag/okta-cli-tools-0.8.0


Empty row packet -> user error

I'm pretty sure this used to be handled and retried in some previous versions
\nExporting to in.c-keboola-ex-db-mysql-pics-organizer-25.accounts-test\nEmpty row packet body#0 [internal function]: {closure}(2, 'Empty row packe...', '/code/vendor/ke...', 256, Array)\n#1 /code/vendor/keboola/db-extractor-common/src/Keboola/DbExtractor/Extractor/Extractor.php(256): PDOStatement->fetch(2)\n#2 /code/vendor/keboola/db-extractor-common/src/Keboola/DbExtractor/Extractor/Extractor.php(156): Keboola\DbExtractor\Extractor\Extractor->writeToCsv(Object(PDOStatement), Object(Keboola\Csv\CsvFile))\n#3 /code/src/Keboola/DbExtractor/Extractor/MySQL.php(153): Keboola\DbExtractor\Extractor\Extractor->export(Array)\n#4 /code/vendor/keboola/db-extractor-common/src/Keboola/DbExtractor/Application.php(153): Keboola\DbExtractor\Extractor\MySQL->export(Array)\n#5 /code/vendor/keboola/db-extractor-common/src/Keboola/DbExtractor/Application.php(65): Keboola\DbExtractor\Application->runAction()\n#6 /code/src/run.php(66): Keboola\DbExtractor\Application->run()\n#7 {main}",

Yes. thanks for reporting it.

or actually it should retry

solved in 9.0.0


remove ebpf clang pre-commit

What does this PR do?
remove ebpf clang pre-commit
Motivation
No eBPF developers are checking this, largely because we don't have a style that we all agree on. clang-format and clang-tidy are also not as flexible as we would like.
Additional Notes

removed clang-format and clang-tidy tasks in system-probe tasks

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

I just see that we also have a pre-commit check-winclang-format do you know if this requires the .clang-format files you just deleted?

@KevinFairise2 I checked with WKIT and they don't use this check. I'm checking with the other windows agent teams.

@KevinFairise2 @julien-lebot is using the .clang-format file, so I re-added it.

/merge


Release new stable

The Translatable behaviour really acts weird when I'm iterating over a Translatable based on the locales as I describe in a topic on the TranslatableFormBundle.
This is already fixed in this commit but it isn't released in a stable tag yet.
Please release v1.1

https://github.com/KnpLabs/DoctrineBehaviors/releases/tag/v1.0.3

pilot released this 7 hours ago

:+1:  Was I really too impatient? ;)

Rvanlaak commented 2 hours ago

:D time collapse


Fixed PDF view with the new name of "billingData" of entity Channel

It has been fixed in #93

Indeed 👍 Nevertheless, thank you for the contribution 🖖


Update iced to v0.9 and rename project to iced_aw v0.5

This pull request updates the iced library dependency to version 0.9 and renames the project to iced_aw v0.5. The update includes new features and bug fixes from iced, and the project has been renamed to align with its version compatibility with iced.
These changes have not been tested yet and require testing by the project team. Please review the changes and test them thoroughly before merging.
Once the changes have been tested and confirmed to work correctly with the updated version of iced, please update this pull request with the testing results and confirm that the changes can be merged. Thank you for your attention to this matter.

looks good thank you.


MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #63.
If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

@conda-forge-admin , please re-render


[BEAM-5707] Add a periodic, streaming impulse source for Flink portable pipelines

This is a rough attempt at addressing BEAM-5707. This is something we've found very useful internally for validating streaming functionality in the python SDK without needing a real streaming source like kafka or kinesis.
I'm still pretty new to beam, so wanted to get feedback early (before cleaning things up, writing docs, tests, etc).
A few questions up front:

Should something like this have a standard beam URN? Currently I'm using flink:transform:streaming_impulse:v1.
How should configuration be serialized between the python pipeline and the flink translation code? I've used JSON here; should it be protobuf or something else?

Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

My main concern is that this should be clearly scoped as Flink specific and not require changes in core. Right now it is the only way for us to run something in streaming mode on Flink portable runner, but as soon as we have the timer support in the Flink runner we can replace it with a transform written in Python.

Thank you Micah. I'll try to take a look.

@mxm from the comments it looks like you are now ok with the changes for this round (per review status you still request changes)?

Checkstyle still needs to be fixed before merging.

Run Python PreCommit

Style checks are passing, should be good to merge. Thanks for the reviews!

Very cool. Thanks Micah!


Allow tests to be run locally easier

Hopefully this can help fix #2.
PKS are also currently using this branch

Add defaults if no config is provided

Run all tests
Use 5minutes default timeout

Use kubeconfig that is on system

Just to add why PKS have to use this branch is because of the restriction on using basic auth, whereas they are using LDAP


Release 0.2.1

<!-- Make sure you have read http://napalm.readthedocs.io/en/latest/contributing/index.html --!>

Coverage remained the same at 77.739% when pulling fff7931e975a5e658ce3c0dd565ba4a7eaa00a25 on develop into ad1a10f08b016bf9eb80852fcf0d2b92e4034535 on master.


Make it clear the lib gives you the metadata

I almost skipped out on the project, because from the example it seemed like it only provides the URI in the response and no mime type or file size or file name.
I haven't reviewed what it does on iOS, hopefully the same.

Cool I'll take that


Throughput skew

I write all documents to Cosmos with a GUID generated on the fly.   The Storage metric shows a near perfect distribution but Throughput metric is always skewed with most of the load usually on Partition 0 (not sure if there is some sort of administrative load on that partition).   Queries never use partition key and mostly use generic properties such as date ranges as a filter so something is not quite right.   Even the lowest consumption is over reserved allocation so my theory is that RUs can be exceeded when partitions are not being used heavily over all tenants and the higher used partitions by me are those lesser used by others.

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

ID: 4535fb42-55f9-4d8c-52d2-30b5eb0ef726
Version Independent ID: f5cccae0-a752-4065-605a-4179016a5a42
Content: Monitoring and debugging with metrics in Azure Cosmos DB
Content Source: articles/cosmos-db/use-metrics.md
Service: cosmos-db
GitHub Login: @gnot
Microsoft Alias: govindk

@beneuto Thanks for the feedback. We are actively investigating and will get back to you soon.

@beneuto Can you take a look at the Provisioned throughput and the Partitioning and Partition Keys sections in the content: Best practices for query performance.
With Azure Cosmos DB, typically queries perform in the following order from fastest/most efficient to slower/less efficient.  GET on a single partition key and item key Query with a filter clause on a single partition key Query without an equality or range filter clause on any property Query without filters Queries that need to consult all partitions need higher latency, and can consume higher RUs. Since each partition has automatic indexing against all properties, the query can be served efficiently from the index in this case. You can make queries that span partitions faster by using the parallelism options.
It would be helpful to understand specific details about your Cosmos DB to answer if the above information does not provide you any insight.
Regards,
Mike

There is also the Prerequisites for partitioning content that explains some of the nuances of Cosmos DB throughput.

Thanks Mike,
There is nothing much new in there for me, however the section "Partitioning and logging/time-series data" has got me thinking that a time based partition key may help optimise performance for operational needs (e.g. latest record per device/last 24 hours history) albeit possibly at the expense of more general analytics.
Regardless, this still does not explain the behaviour of the monitoring tool.   In my case, all writes are using a unique GUID for the partition key.   Predictably this results in a fairly even spread over all partitions - max = 2.01GiB, min = 1.93GiB (incidentally, partition 0 is the minimum).   All queries are something like:
SELECT c.partitionkey, c.timestamp, c.something FROM c WHERE c.source = 'xyz' AND (c.timestamp BETWEEN  AND )
I would expect such queries to result in fairly even load over all partitions as there is no filter directly related to the partition key.   However, looking at peak throughput yesterday this is what I see:
Partition 0 - ~20K RU
5 partitions - ~12K RU
10 partitions - ~9K RU
2 partitions - ~6K RU
7 partitions - ~3K RU
Unfortunately, the monitoring tools are not sufficient to really work out what is going on.

@beneuto Thank you for the detail. I am working to get some feedback.

@beneuto If you allow us to take a deeper dive into your Azure Cosmos DB instance, we can provide you specific feedback. Please send the requested information (from below) to<EMAIL_ADDRESS>and direct it to Kirill.

"The workload likely moves from one partition key range to the other over time. He can actually move over time in the portal throughput heatmap chart and see that.
It’s hard to understand from his description why his code results in such workload, but it is a very common situation when folks choose timestamp as a partition key for time series data.
If the customer can share his account name/collection name and time, we can look further."

Regards,
Mike

@beneuto We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.
Regards,
Mike


[v0.20] [Consolidated Channel] Backport of #487

Proposed Changes

🐛 Fix bug of probing the dispatcher for subscription readiness after dispatcher pods change.
Backport of #487

Release Note

🐛 A bug fix was back ported to the consolidated channel so that subscriptions becomes eventually ready even when dispatchers scale up or down.

please ignore failures in the pull-knative-sandbox-eventing-kafka-integration-test-mt-source since it was meant from 0.21.0 onward.


fix(heic): Don't auto-transform camera-rotated images

It seems that unlike most image formats where we merely note the camera rotation but don't rotate the pixels, the heic reader automatically rotated.
The trick is that using the C++ API wrapper of libheif, there is no way to pass the decoder options struct that is where you need to say not to auto-transform.  Needed to drop down to the lower level C API for this one spot.
We want this format to behave like the others -- the orientation is advisory, and it's up to the app how to deal with it. But we have back compatibility to deal with.
If a rotated image is aecountered, OIIO 2.5 and earlier will by default still auto-rotate to preserve compatibility, but OIIO 2.6+ will not auto-rotate.
When not rotating, the Orientation metadata will reflect the desired display orientation of the image, according to what was in the file.
When auto-rotating, Orientation will be 1 (canonical display orientation), and a new attribute "heif:Orientation" will reflect what was originally in the file.
When opening a file for input, the special configuration metadata hint "heif:reorient" can express a preference for auto-rotation, overriding the default. Thus, setting this hint to 0 for OIIO 2.5 will turn off auto-rotation, and setting it to 1 for OIIO 2.6+ will make it auto-rotate like it used to do.
I also added some additional tests for heif files.
Along the way I fixed a rather embarrassing documentation problem as well, where all the orientation codes were "off by 1", oh boy.
Fixes #4123

Loking at your PR, I think some of the code looks dodgy (343ff.):
            switch (rot) {
            case 270: orientation = cw[orientation];
            case 180: orientation = cw[orientation];
            case 90: orientation = cw[orientation];
            default: break;

A case switch is okay, but you code it with fallthrough, so e.g. if control flow arrives the first case label, it will re-set orientation thrice in a rather intransparent manner. Are you sure that is intended?
Further on,
            if (mirror == heif_transform_mirror_direction_vertical) {
                orientation = mirrorv[orientation];
            } else if (mirror = heif_transform_mirror_direction_horizontal) {
                orientation = mirrorh[orientation];

This looks like it might work, but I think it's intransparent - the orientation value may change with every execution of the loop body, and I find it hard to figure out what the final outcome might be.
I think it would be better first to extract the properties into variables (int is_rotated, bool is_flipped) - the image can be rotated in four ways, and possibly flipped, so there are eight cases to deal with, which could be handled e.g. in a nested conditional statement in a second step after the properties have all been seen (after the loop over xpcount is done). This would yield 'orientation' and you could fix it so that the value is EXIF-compatible, and the code could put a comment alongside each case, making it all more readable.

A case switch is okay, but you code it with fallthrough, so e.g. if control flow arrives the first case label, it will re-set orientation thrice in a rather intransparent manner. Are you sure that is intended?

No, it's correct. It isn't resetting it each time, it is looking up an additional 90 degree rotation in the cw array.
But I agree that it's unclear, and I will fix it with an alternate formulation. This one may be a shade too "clever."

Here is a more clear way to express it, maybe you can see that the case statement as I wrote it is equivalent:
        // cw[] maps to one additional clockwise 90 degree turn
        static const int cw[] = { 0, 6, 7, 8, 5, 2, 3, 4, 1 };
        for (int i = 0; i < rot / 90; ++i)
            orientation = cw[orientation];

Okay, I see it now. Still I'm not happy with it, and I think it's hard to comprehend. To make it palatable, it would require a lengthy comment, so instead you could just code it without the artistics. Just my fifty cents. Of course I appreciate a good bit of 'juggling', but I've come off that kind of stuff and write KISS code now ;-)

Yeah, I'm changing it to the loop, which I think is more clear than the switch.

Pushed an update based on the discussion in #4123.  New description of what this PR really does:

fix(heic): Make auto-transform of camera-rotated images optional
Policy change about ImageInput automatic transformation of images with
camera orientation data, as follows:

Some ImageInput format readers may have the capability to
automatically reorient images to the preferred display orientation
upon input, based on the camera Orientation metadata. Whether a
reader does so will tend to depend on the capabilities of the
underlying format library. If it can support reorientation easily,
it is expected to do the reorientation automatically by default.

If the pixel data are re-oriented, the "Orientation" metadata should
be set to 1 to indicate that the image returned to the caller is in
the preferred display orientation, and "oiio:OriginalOrientation"
metadata should be set to indicate the original camera orientation
(prior to the automatic re-orientation).

Open-with-configuration hint "oiio:reorient" (default: 1), if set to
0, is a request to NOT do the reorientation. In that case,
"Orientation" metadata should be set correctly to the actual
orientation.

The heif reader was previously always re-orientating images as the
default behavior of the underlying libheif. That remains the default,
but this patch makes the following changes to libheif behavior to
conform to the policy above: (a) changes to code to allow it to
disable the reorienting behavior if hint "oiio:reorient" is 0; (b)
correct setting of Orientation and oiio:OriginalOrientation metadata;
(c) make this more clean in the documentation.
Tech details: The trick is that using the C++ API wrapper of libheif,
there is no way to pass the decoder options struct that is where you
need to say not to auto-transform.  Needed to drop down to the lower
level C API for this one spot.
Fixes #4123
A subsequent PR will revisit the RAW reader to make it also conform to
the new policy.

Excellent! Just what I had hoped for.
One thing I am missing is concerning the uniform use of the EXIF standard's rotation/flip values. Prescribing that OIIO should present the Orientation property using this standard would make it clear that other ways of expressing rotation or flip remain a detail of the plugin - e.g. libRAW's use of other numerical codes. In a way you silently accept this standard at least partly by proposing the value '1' as the 'correctly oriented for display' metadatum, which is arbitrary, but conforms to the EXIF standard.
The standard is nicely documented in various places, e.g. here and there are test images to be had, e.g. here, where one can find a complete set of JPEGs to test whether one's processing pipeline does the right thing to display the images correctly - I used this set to test my latest addition to lux, the handling of 'flipped' images, which I had ignored previously.
You might want to state that if the user wants to affect pre-rotation using a plugin's capabilities (e.g. by passing raw:user_flip) they would have to adhere to that plugin's semantics and could not expect to rely on orientation values to be automagically translated.

I consider any deviation from the Exif (and, long before that, TIFF) encoding conventions of orientation to be a bug in the raw reader. The OIIO docs clearly say what the codes of the "Orientation" metadata matches TIFF/Exif conventions -- or at least, it is supposed to, though there was a very unfortunate typo that was fixed as part of this PR.

Is this, as it currently stands, adequate for heif? Should we merge what we have so far?

I did a test build from your fork's feature branch. Switching off the autorotation works and returns the data in 'native' orientation, but then I don't seem to always get the Orientation tag which I'd need to perform the rotation myself. Is this deliberate or am I maybe doing something wrong? I have the feeling that when the orientation is set in the EXIF metadata (as it is in my 'fudged' test image) it comes through, but otherwise it doesn't (e.g with the portrait HEIF test image we both discovered).

Oops.. I think it's my mistake, the oiio:reorient did not come through in time

Not all files contain the Orientation metadata. When it's not present, you should assume the default orientation. In OIIO speak, I'd recommend
int orientation = spec.get_int_attribute("Orientation", 1);

and then you'll get the 1 if the metadata is not present.

Point taken, thanks for the hint!

I think we're good on this. Merging. We can always revise more later.


Clicking 'show no exercises with full points' still shows exercises with more than 100 %

Describe the bug

Does not exclude exercises with more than 100%. Such exercises exist if there are bonus points.
To Reproduce
Trivial
Get an exercise you scored bonus points in and you have >100%, try excluding exercises with full points.

fixed by PR #2564


[#17] Uploading and downloading of generic artifacts.

Codecov Report
Base: 27.20% // Head: 28.40% // Increases project coverage by +1.20% :tada:

Coverage data is based on head (aaf5f6c) compared to base (b770370).
Patch coverage: 39.58% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #19      +/-   ##
==========================================
+ Coverage   27.20%   28.40%   +1.20%
==========================================
  Files           7        8       +1
  Lines         397      440      +43
==========================================
+ Hits          108      125      +17
- Misses        266      288      +22
- Partials       23       27       +4

Flag
Coverage Δ

unittests
28.40% <39.58%> (+1.20%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

internal/artifact/generic.go
0.00% <0.00%> (ø)

internal/artifact/npm.go
0.00% <0.00%> (ø)

internal/pkg/artifact/artifact.go
20.00% <0.00%> (-1.18%)
:arrow_down:

cmd/yaam/main.go
68.80% <73.07%> (+0.57%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Problem with Installation/Config

Hi there,
I am running into problems during installation when I execute the python3 setup.py develop --user command. For context, my previous steps are: (1) clone bigbang repo to remote server, (2) create virtualenv, and (3) execute pip3 install -r requirements.txt. When I run  python3 setup.py develop --user, I get the output pasted below. After this, I add the virtualenv as a jupyter kernel, open an example notebook (Git Collection), and when I try to import the packages I get: ModuleNotFoundError: No module named 'config'. I assume this is linked to the problems with executing setup.py.
Do you know how to troubleshoot this? Thanks!
(venv-bigbang) user1@server1:~/bigbang$ python3 setup.py develop --user
/home/user1/venv-bigbang/lib/python3.8/site-packages/setuptools/config/_apply_pyprojecttoml.py:103: _WouldIgnoreField: 'dependencies' defined outside of `pyproject.toml` would be ignored.
    !!

    ##########################################################################
    # configuration would be ignored/result in error due to `pyproject.toml` #
    ##########################################################################

    The following seems to be defined outside of `pyproject.toml`:

    `dependencies = ['beautifulsoup4>=4.9.3', 'chardet>=4.0.0', 'common>=0.1.2', 'enlighten>=1.7.2', 'gender-detector', 'GitPython', 'html2text>=2020.1.16', 'ietfdata>=0.4.0', 'ipython>=7.22.0', 'jinja2>=2.11.3', 'jupyter>=1.0.0', 'jsonschema>=3.2.0', 'matplotlib>=3.4.1', 'networkx>=2.5.1', 'nltk>=3.6.2', 'numpy>=1.20.2', 'pandas>=1.2.3', 'powerlaw>=1.4.6', 'python-dateutil>=2.8.1', 'python-Levenshtein>=0.12.2', 'pytz>=2021.1', 'pyyaml>=5.4.1', 'pyzmq>=22.0.3', 'requests>=2.25.1', 'seaborn', 'tornado>=6.1', 'tqdm>=4.60.0', 'validator_collection>=1.5.0', 'python-docx>=0.8']`

    According to the spec (see the link below), however, setuptools CANNOT
    consider this value unless 'dependencies' is listed as `dynamic`.

    https://packaging.python.org/en/latest/specifications/declaring-project-metadata/

    For the time being, `setuptools` will still consider the given value (as a
    **transitional** measure), but please note that future releases of setuptools will
    follow strictly the standard.

    To prevent this warning, you can list 'dependencies' under `dynamic` or alternatively
    remove the `[project]` table from your file and rely entirely on other means of
    configuration.

!!

  warnings.warn(msg, _WouldIgnoreField)
/home/user1/venv-bigbang/lib/python3.8/site-packages/setuptools/config/_apply_pyprojecttoml.py:103: _WouldIgnoreField: 'optional-dependencies' defined outside of `pyproject.toml` would be ignored.
    !!

    ##########################################################################
    # configuration would be ignored/result in error due to `pyproject.toml` #
    ##########################################################################

    The following seems to be defined outside of `pyproject.toml`:

    `optional-dependencies = {'test': ['pytest>=6.2.3', 'coverage>=5.5', 'testfixtures>=6.17.1'], 'dev': ['pytest>=6.2.3', 'coverage>=5.5', 'testfixtures>=6.17.1', 'black>=20.8b1', 'isort>=5.7.0', 'pre-commit>=2.13.0']}`

    According to the spec (see the link below), however, setuptools CANNOT
    consider this value unless 'optional-dependencies' is listed as `dynamic`.

    https://packaging.python.org/en/latest/specifications/declaring-project-metadata/

    For the time being, `setuptools` will still consider the given value (as a
    **transitional** measure), but please note that future releases of setuptools will
    follow strictly the standard.

    To prevent this warning, you can list 'optional-dependencies' under `dynamic` or alternatively
    remove the `[project]` table from your file and rely entirely on other means of
    configuration.

!!

  warnings.warn(msg, _WouldIgnoreField)
running develop
/home/user1/venv-bigbang/lib/python3.8/site-packages/setuptools/command/easy_install.py:144: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
WARNING: The user site-packages directory is disabled.
/home/user1/venv-bigbang/lib/python3.8/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
Checking .pth file support in /home/user1/.local/lib/python3.8/site-packages
/home/user1/venv-bigbang/bin/python3 -E -c pass
TEST FAILED: /home/user1/.local/lib/python3.8/site-packages does NOT support .pth files
bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from.  The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /home/user1/.local/lib/python3.8/site-packages

and your PYTHONPATH environment variable currently contains:

    ''

Here are some of your options for correcting the problem:

* You can choose a different installation directory, i.e., one that is
  on PYTHONPATH or supports .pth files

* You can add the installation directory to the PYTHONPATH environment
  variable.  (It must then also be on PYTHONPATH whenever you run
  Python and want to use the package(s) you are installing.)

* You can set up the installation directory to support ".pth" files by
  using one of the approaches described here:

  https://setuptools.pypa.io/en/latest/deprecated/easy_install.html#custom-installation-locations

Please make the appropriate changes for your system and try again.
pre-commit installed at .git/hooks/pre-commit

Yes, thanks for sending along the installation errors. It sheds light on this.
It looks like there are two separate issues. One has to do with the error in pyproject.toml.
But what is more likely causing the error when importing config is the problem with the python path.
Googling for this error reveals that the problem might be solved by removing the option --user from the installation command:
https://github.com/NVIDIA/flownet2-pytorch/issues/183
This may be a problem with our installation instructions, as --user can conflict with virtualenv functionality.

Thanks for your help, Seb.
Removing --user removed the PYTHONPATH error but the pyproject.toml error persists. The error message says I should list dependencies and optional-dependencies under dynamic - do you know how to do that?

@ccosborne The issues with pyproject.toml appear to be warnings, not errors. They are about parts of the build system that are soon to be (but not yet) deprecated.
Thanks for bringing that to our attention!
But it should not be blocking the execution of your Jupyter notebook.
Do you still have problems with import config?

@sbenthall Unfortunately I get the same error message with import config in the Jupyter notebook. Any clue why that might be?

Hello @ccosborne I see the issue. It's a problem with the configuration on our end. I'll work on this and let you know when I've pushed the change.

Ok, I've pushed a change and tests are passing.
Can you please try the installation again?

Unfortunately I get the same warning message when running python3 setup.py develop and the same error message when importing from bigbang.archive import Archive in the notebook, even after deleting bigbang and cloning it again...  :/

This is indeed an issue, and this pops up because the config module isn't properly packaged. It's a sibling to the bigbang module and there isn't any way to automatically make config importable unless explicitly adding it the the python system paths.
The tests will pass because they are running in the root dir so they can do import config without ever having this installed properly. This can be fixed with some adding the paths to sys.paths but I would highly discourage that. The best way here would be to restructure the package along the lines of:
- bigbang/
     - bigbang
     - config
     - tests
     - bin

with from config.config import CONFIG becoming something like from bigbang.config import CONFIG.
Let me know if I am missing something here regarding the structure of bigbang (and thus the current structure).

@MridulS Thanks so much for this analysis!
Not a lot of thought was put into the location of the config file.
I will implement your suggestions here.
One question though -- in another project I've been able to import sibling modules by adding them to the packages list:
https://github.com/sbenthall/SHARKFin/blob/master/setup.cfg#L18
Is there something wrong with that approach?
Ultimately, we use the config module just to keep track of a bunch of default file system paths and regular expressions.
We want to access them from Python, but store them in a YAML file.
Having them bundled with the bigbang source code means that there would be no way for a 'user' who is just using BigBang in development mode to modify that file -- they would need to look around in their site-packages or something.
I wonder @MridulS how you would approach this from the perspective of the on-line dashboard, which I believe is built on the package available on PyPI and not a development installation. Is there a better way to expose these configuration options?

Thanks so much @MridulS
This is all my fault -- I packaged BigBang for PyPI not long ago, but clearly made a mess of it.
Any PRs you make along these lines would be greatly appreciated. I defer to your guidance on these things.

@MridulS Fixed with #579 ?


Kubelet read pods from http

cc @vmarmol @erictune

@vmarmol @erictune
I have few questions:

Should we support reading pod in all api versions (v1beta1, v1beta2, ...)?
If so, is there a smart way to to translate the incoming json/yaml to api.Pod different than checking each api version one by one?
What kind of validation do we want to support? I think that we need to do some validation after converting to api.Pod, but asking to confirm.

Also, any comments on the working version of PR (currently even tests aren't passing) are appreciated.

Sorry, I answered your questions in line before I saw your message :)

Thanks for comments - I spent most of the time today looking through the code and fighting with some unrelated issues. Will try to fix this PR tomorrow. Thanks!

PTAL (e2e test passing)

PTAL

Minor nits, looks good overall.

LGTM, lets squash commits and I'll merge on green. Thanks @wojtek-t!

Commits squashed. Thanks for quick review!

My comment got squashed... :(
Anyway, the namespace overwriting was a conscious decision and we didn't want people using random namespace for static configs. Whether that is a reasonable decision can be argued, but file.go also does this. I expect all static sources to be consistent.

Spoke offline with @yujuhong, @wojtek-t's file.go PR should make this consistent for all static sources. Some customers wanted to have all static pods go into the same namespace. This should allow them to do so.
Merging since we're green!

@yujuhong - I've seen your comment (thx for it). I'm currently changing (will send a PR for it tomorrow) the file.go to also accept pods (similarly to http). I will change the file.go to be consistent (with namespace) in that PR. Does it sound ok?


[Tokens] Remove the states for "background" in LBC and the rest of brand tokens

Delete Background States from the libraries because the background color is solely used for the bg in pages.
No states are needed / possible / allowed.

[x] Spark tokens
[ ] LBC tokens
[x] KA tokens
[x] MA tokens

Done for LBC


Disabling loading consolidated Parquet _metadata

For large Parquet datasets, loading the consolidated _metadata file, especially when it's a remote file, can be quite slow. We should consider adding an flag to optionally disable reading _metadata. Initially I thought setting gather_statistics=False would do this, but that turned out to not be the case (at least for the pyarrow-dataset and fastparquet engines)
cc @rjzamora in case you have thoughts on this topic

I agree that we should make it possible to avoid reading _metadata if there are fundamental limits in pyarrow for parsing the file.
Other (somewhat-related) thoughts...
I also think we should try to decentralize the read_parquet "planning" stage a bit.  Note that I am working on a (second) refactor of the read_orc API in #8004, where I am breaking up the typical "read_metadata" stage, and I am getting the feeling that we need something very similar for parquet.  More specifically, I think the "planning stage" of read_parquet should follow three stages:
Stage 1: Get general dataset information. In this stage, we use pyarrow/fastparquet to populate a dictionary of general dataset information.  The engine can use the _metadata file by default, but we should also make it possible to ignore this file if desired. Note that this stage should be "fast," so it should not dig into the data or file statistics.
Stage 2: Construct output meta.  Once we have general dataset information, we should be able to construct the meta without reading in any data, parsing parquet metadata/statistics, or constructing list of output partitions.  Calculating the meta separately and early like this should also benefit the high-level expression plans discussed in #7933.
Stage 3: Construct an output-partition plan. This is the stage where the heavy lifting is done, because we need to construct a list of path/row-group-range combinations for every output partition.  In the current arrow engine, we effectively start this process by constructing a global "parquet metadata" object.  When _metadata is not present, we can do this in parallel on the workers, but we always end up processing the global metadata on the client. This is because we rely on "shared"/"core" Dask logic to process the statistics, apply filters, and calculate divisions.  However, if we move the stats/filtering/divisions responsibility onto the engine, the entire output-partition plan process can be parallelized pretty easily.  Overall, I am vaguely suggesting that we bite the bullet and move the statistics-related logic into the engine.  The engine implementations can still call shared utilities.

Stage 1: Get general dataset information. ... The engine can use the _metadata file by default, but we should also make it possible to ignore this file if desired. Note that this stage should be "fast," so it should not dig into the data or file statistics.

I suppose the idea is that the meta can be constructed exclusively with information gathered here?
I am wondering how you can do that with the current parquet datasets written by dask without either parsing a metadata file or either reading one single parquet data file + doing a filesystem scan (which can also be costly).
For example to discover the partitioning (know which fields need to be added to the schema as partition columns), you need to know something about the directory structure? (which can either be read from the metadata file, or either requires a filesystem scan, with the current information stored in the dataset?)

Stage 1: Get general dataset information. ... The engine can use the _metadata file by default, but we should also make it possible to ignore this file if desired. Note that this stage should be "fast," so it should not dig into the data or file statistics.

I suppose the idea is that the meta can be constructed exclusively with information gathered here?
I am wondering how you can do that with the current parquet datasets written by dask without either parsing a metadata file or either reading one single parquet data file + doing a filesystem scan (which can also be costly).
For example to discover the partitioning (know which fields need to be added to the schema as partition columns), you need to know something about the directory structure? (which can either be read from the metadata file, or either requires a filesystem scan, with the current information stored in the dataset?)

You are 100% correct - This step cannot always be "fast", and I am still unsure of the best way to handle the case where we don't have a _metadata file, or that _metadata file is too large.  What I do know is that we will want to be able to calculate the DataFrame._meta before starting the build the graph (gather/process parts/statistics), because we may use the high-level expressions for predicate pushdown/column-projection after the metadata is first generated.  When we can assume that the dataset is not hive/directory partitioned, this is easy - Otherwise, we do need to do some up-front work to capture the correct metadata.

We can probably read the head of the first row group and get the _meta
information happily
On Fri, Aug 13, 2021 at 8:13 AM Richard (Rick) Zamora <
@.***> wrote:

Stage 1: Get general dataset information. ... The engine can use the
_metadata file by default, but we should also make it possible to ignore
this file if desired. Note that this stage should be "fast," so it should
not dig into the data or file statistics.
I suppose the idea is that the meta can be constructed exclusively with
information gathered here?
I am wondering how you can do that with the current parquet datasets
written by dask without either parsing a metadata file or either reading
one single parquet data file + doing a filesystem scan (which can also be
costly).
For example to discover the partitioning (know which fields need to be
added to the schema as partition columns), you need to know something about
the directory structure? (which can either be read from the metadata file,
or either requires a filesystem scan, with the current information stored
in the dataset?)
You are 100% correct - This step cannot always be "fast", and I am still
unsure of the best way to handle the case where we don't have a _metadata
file, or that _metadata file is too large. What I do know is that we will
want to be able to calculate the DataFrame._meta before starting the
build the graph (gather/process parts/statistics), because we may use the
high-level expressions for predicate pushdown/column-projection after the
metadata is first generated. When we can assume that the dataset is not
hive/directory partitioned, this is easy - Otherwise, we do need to do some
up-front work to capture the correct metadata.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/8030#issuecomment-898448802, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTG6KEDQRTYB5ATDNBTT4UK7TANCNFSM5CCKW3WQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

We can probably read the head of the first row group and get the _meta
information happily

Yes - This will do the trick in most cases, but it will not capture directory-partitioned columns.

Hi folks, this might the same issue I'm currently experiencing, here is the error message I see when we call read_parquet (spatialpandas, using pyarrow v0.3.0):
ddf_packed = ddf.pack_partitions_to_parquet(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/spatialpandas/dask.py", line 530, in pack_partitions_to_parquet
    return read_parquet_dask(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/spatialpandas/io/parquet.py", line 321, in read_parquet_dask
    result = _perform_read_parquet_dask(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/spatialpandas/io/parquet.py", line 421, in _perform_read_parquet_dask
    meta = dd_read_parquet(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/dask/dataframe/io/parquet/core.py", line 313, in read_parquet
    read_metadata_result = engine.read_metadata(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/dask/dataframe/io/parquet/arrow.py", line 537, in read_metadata
    ) = cls._gather_metadata(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/dask/dataframe/io/parquet/arrow.py", line 1035, in _gather_metadata
    ds = pa_ds.parquet_dataset(
  File "/opt/conda/envs/datum/lib/python3.8/site-packages/pyarrow/dataset.py", line 457, in parquet_dataset
    factory = ParquetDatasetFactory(
  File "pyarrow/_dataset.pyx", line 2043, in pyarrow._dataset.ParquetDatasetFactory.__init__
  File "pyarrow/error.pxi", line 122, in pyarrow.lib.pyarrow_internal_check_status
  File "pyarrow/error.pxi", line 84, in pyarrow.lib.check_status
pyarrow.lib.ArrowInvalid: Extracting file path from RowGroup failed. The column chunks' file paths should be set, but got an empty file path.

I recently upgraded to 2021.8.0 and got this error. After reverting back to 2021.7.2 the issue seems to have gone away. I see there is a PR 8034 open for this already but if an extra set of hands are needed, I'm happy to contribute. I will try to test the changes in PR 8034 to see if they fix my issue as well.
Thanks for all the great work!

Stage 3: Construct an output-partition plan. This is the stage where the heavy lifting is done, because we need to construct a list of path/row-group-range combinations for every output partition. In the current arrow engine, we effectively start this process by constructing a global "parquet metadata" object. When _metadata is not present, we can do this in parallel on the workers, but we always end up processing the global metadata on the client. This is because we rely on "shared"/"core" Dask logic to process the statistics, apply filters, and calculate divisions. However, if we move the stats/filtering/divisions responsibility onto the engine, the entire output-partition plan process can be parallelized pretty easily. Overall, I am vaguely suggesting that we bite the bullet and move the statistics-related logic into the engine. The engine implementations can still call shared utilities.

In general I support parallelizing metadata harvesting and construction. FWIW I think that Spark also does this (there appears to be a small compute period when they read a dataset).
I'm curious about moving statistics functionality out of core.  My current sense is that the remote-vs-local choice doesn't necessarily have to trigger a change of responsibility from core code to engine code.  Is this understanding correct?

@iameskild that doesn't seem directly related. It is an error coming from parsing the _metadata file, and so having an option to not use that file (what this issue is about) would also help for your case as a workaround. But the fact that you get an error reading this file should have some cause / is a bug (for which I would recommend opening a separate issue).

I'm curious about moving statistics functionality out of core. My current sense is that the remote-vs-local choice doesn't necessarily have to trigger a change of responsibility from core code to engine code. Is this understanding correct?

Yes. Your understanding is correct - but the exact separation between “core” and “engine” logic already varies a bit among engine implementation.
Right now, the read_parquet logic starts by asking the engine to read and process the dataset and all relevant parquet metadata (in engine.read_metadata).  This classmethod is expected to produce the output meta, a list of information needed to produce each output partition (parts), and a corresponding list of statistics (statistics).  The engine is already free to use compute within this class method to compile parts/statistics remotely.  The "pyarrow-legacy" engine does parallelize the harvesting/construction of a global parquet-metadata object when the _metadata file is missing, but the construction of parts/statistics still occurs on the client.
It wouldn't be a significant change to implement parallel-construction of parts/statistics.  As you suggested, it does not require any official "change of responsibility" from core code to engine code.  However, the current separation of "responsibilities" requires that we follow up the read_metadata call with a second (optional) pass over the parts/statistics (on the client) to perform filtering, and then a third (optional) pass to perform part/file aggregation.  We could certainly make the filtering logic remote without making it the responsibility of the engine, or refactor things so that "core" filtering is done in parallel.  However, the "core" filtering pass is already being skipped by "pyarrow-dataset," because the row-groups/partitions are already filtered during dataset-fragment discovery.
Therefore, my general suggestion here is that we may want to stop "pretending" like filtering is "core" logic when it already isn’t.  We can maintain general/shared filtering utilities, but pushing the official responsibility into the engine actually feels like an easier-to-maintain solution to me.

Closing this issue as an  ignore_metadata_file option was added in https://github.com/dask/dask/pull/8034 and @rjzamora opened https://github.com/dask/dask/issues/8058 to discuss improving metadata processing


How to use metrics server to measure performance

What would you like to be added:
After #1797 merged, I want  to continue to work on issue #710, but I found some problems

How to use metrics server  to measure performance
When  tested locally by command  ./run-e2e.sh --testconfig=./testing/load/config.yaml --provider=gce --enable-prometheus-server=true --masterip=<IP_ADDRESS> --prometheus-storage-class-volume-type=standard, I didn't see the result of  metrics server measurement, and when config  the flag  --prometheus-storage-class-volume-type=standard,  the volume type of pod prometheus-k8s-0 is still the pv?

As the issue  #710 discussed, Can we continue to do the next work?

Why is this needed:
Automate testing scalability of Metrics Server

/cc marseel


Fix typesetter and linespacing so that the first line of a frame can …

…be aligned correctly

I've implemented some of this myself, and I think my recent changes have fixed #336 now.


[V9RC4] c5:phpcs console command doesn't work

% concrete/bin/concrete c5:phpcs check index.php -v

In PhpCodingStyleCommand.php line 38:

  [Whoops\Exception\ErrorException (2)]
  Class 'Symfony\Component\EventDispatcher\Event' not found

Exception trace:
  at /path/to/concrete/src/Console/Command/PhpCodingStyleCommand.php:38
 Whoops\Run->handleError() at n/a:n/a
 class_alias() at /path/to/concrete/src/Console/Command/PhpCodingStyleCommand.php:38
 Concrete\Core\Console\Command\PhpCodingStyleCommand->handle() at /path/to/concrete/vendor/illuminate/container/BoundMethod.php:36
 Illuminate\Container\BoundMethod::Illuminate\Container\{closure}() at /path/to/concrete/vendor/illuminate/container/Util.php:40
 Illuminate\Container\Util::unwrapIfClosure() at /path/to/concrete/vendor/illuminate/container/BoundMethod.php:93
 Illuminate\Container\BoundMethod::callBoundMethod() at /path/to/concrete/vendor/illuminate/container/BoundMethod.php:37
 Illuminate\Container\BoundMethod::call() at /path/to/concrete/vendor/illuminate/container/Container.php:651
 Illuminate\Container\Container->call() at /path/to/concrete/src/Console/Command.php:566
 Concrete\Core\Console\Command->execute() at /path/to/concrete/vendor/symfony/console/Command/Command.php:299
 Symfony\Component\Console\Command\Command->run() at /path/to/concrete/src/Console/Command.php:150
 Concrete\Core\Console\Command->run() at /path/to/concrete/vendor/symfony/console/Application.php:978
 Symfony\Component\Console\Application->doRunCommand() at /path/to/concrete/vendor/symfony/console/Application.php:295
 Symfony\Component\Console\Application->doRun() at /path/to/concrete/vendor/symfony/console/Application.php:167
 Symfony\Component\Console\Application->run() at /path/to/concrete/src/Foundation/Runtime/Run/CLIRunner.php:72
 Concrete\Core\Foundation\Runtime\Run\CLIRunner->run() at /path/to/concrete/src/Foundation/Runtime/DefaultRuntime.php:102
 Concrete\Core\Foundation\Runtime\DefaultRuntime->run() at /path/to/concrete/dispatcher.php:45
 require() at /path/to/concrete/bin/concrete:85

c5:phpcs [--no-cache] [--webroot [WEBROOT]] [-p|--php [PHP]] [--] <action> <path>...

Confirm. Following.

The problem is caused by the way we define the coding style rules.
Since we need different rules for different file paths, and because it seems that people at php-cs-fixer aren't interested in that (see https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3126), we have to work with the php-cs-fixer in a rather complex way.
I'll take a look at this issue (and maybe also switch to php-cs-fixer 3, since Concrete 9 will use PHP 7.3).

While I still think we ought to move this functionality into the console command, this particular issue has since been fixed.


Multiple optional segments

I couldn't find that in the docs. Is it possible to define a single route which has multiple optional segments? Let's say I have a list with optional sorting and pagination so I'd like to define route like: /list?(/s/:sort?(/:order)?)?(/page/:page)?. The other thing is matching segments by RegExp, so in the above example the parameter :order could only have values asc or desc. From what I found in Issue #142 there was no matching feature implemented, is that right? For now I ended up with defining 4 different routes pointing to the same handler depending on uri, which is not the optimal solution...

Yes correct, there is no support for matching using regular expressions currently. I'm not sure about this, but I think you cannot have multiple dynamic segments. A possible solution would be to just move the optional params like sorting and pagination into query params, because they are actually part of a query, not directly of the URI.

You can always do whatever crazy stuff you want in splat paths anywhere in the hierarchy.
<Route path="list" handler={List}>
  <Route path="*" handler={GoNuts/>
</Route>

class GoNuts extends React.Component {
  render () {
    var stuff = parseThatCrazyUrl(this.context.router.getCurrentPath());
    // do some branching on stuff to render what you want
  }
}

A possible solution would be to just move the optional params like sorting and pagination into query params, because they are actually part of a query, not directly of the URI.

And loose the ability to bookmark :(

@ivan-kleshnin Why would you lose those?  If they're in the query params then they're still in the URL, so are bookmarkable and shareable.


SQL deadlocks

I am using nodejs async module to execute SP's in Sql Server using mssql.
I sometimes get sql deadlocks. This is a local DB and there are no sql processes running on the table.
{
"data": "ERROR: Dude 500 : RequestError: Transaction (Process ID 55) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."
}
Did anyone face this issue? Any suggestions will be greatly helpful..

Closing this one because it is not mssql realted. Try stack overflow with more detailed explanation.

Just for the record, I had the same error message. Thanks in part to the Profiler in SQL Server I found out that I was improperly using this library.
In my code I was looping through objects and creating multiple PreparedStatements objects with the same identical UPDATE query (different values of course). While developing on a VM with SQL Server Express I never faced any issues, but when I put it on our production database, I found out that running four UPDATE queries on a small table would case deadlocks on Page items. From my understanding the different PreparedStatement objects were being run as separate processes on the server (they had different SPIDs), and thereby deadlocking each other on page writing.
I solved the issue by executing the same PreparedStatement with different values. Reusing the single PreparedStatement runs those queries on the same SPID sequentially. I image I could catch the error and rerun the statement, but upon reading more on PreparedStatements I knew that my pattern wasn't ideal. Funny enough the same pattern wasn't showing any issues when updating records close to each other in a massive table with almost 200 columns. My guess is that those UPDATEs were not locking the same pages in the database.
I hope this helps anybody looking for help.

I've same problem within loop of update:

I fire updateChannel in callback for many times.

function updateChannel(id) {
    const pool2 = new sql.ConnectionPool(config, err => {
        // ... error checks

        pool2.request()
            .query('update Table set flag=1 where ..., (err, result) => {
                // ... error checks

                //everythings
            })
    })
    pool2.on('error', err => {
        // ... error handler
    })
}

Error:
{ RequestError: Transaction (Process ID 58) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Try to initialize the connection pool outside the callback and reuse it at
each call. It should have an internal queue.
--
David Gasperoni

@mcdado How? please show me a sample code...
thanks

This is how I've done it:
const mssql = require('mssql');
const bluebird = require('bluebird');

const connectionPool = new mssql.ConnectionPool(configuration);
const connectionPromise = this.connectionPool.connect();

If I need to do sequential updates, I follow this pattern:
const statement = new mssql.PreparedStatement(connectionPool);
const query = 'UPDATE…'; // omitted

connectionPromise.then(() => {
  statement.prepare(query)
});

connectionPromise.then(() => {
  return bluebird.map(arrayOfThings, (thing) => {
    const values = {
      fieldName: thing,
    };

    return statement.execute(values);
  }, { concurrency: 1 })
});

When I was looking at my code to pull this example, I realized that since 4.0 there are no more internal queues, so I switched to Bluebird and used Bluebird.map() to execute a callback on each element of an array of data. This callback runs and returns the executing statement, which itself is a promise. This allows to use the concurrency option and limit it to 1, which basically translates to sequential execution.

I am having a similar issue but not sure how to solve it in my particular case.  I am not the OG developer so I'm trying to piece things together.
I have a db.js file where a connection is created.
var db, env, knex, runsettings, settings;
settings = global.apps[global.namespace];
env = settings.general.env;
db = settings.general.db;
runsettings = settings.db[db][env];
config = global.apps[global.namespace].db.mssql.prod;
sql = require('mssql');
knex = require('knex');

knex.mssql = require('knex')({
	client: 'mssql',
	connection: {
		user: runsettings.user,
		password: runsettings.password,
		server: runsettings.server,
		database: runsettings.database,
		connectionTimeout: 300000,
		requestTimeout: 300000
	},
	pool: {
		idleTimeoutMillis: 300000,
		max: 100
	},
	useNullAsDefault: true
});

config["options"] = { encrypt: false };
config["requestTimeout"] = 300000;
config["connectionTimeout"] = 300000;

var connection  = new sql.ConnectionPool(config, function(err) {
	// ... error checks
	settings.connection = connection;
});

connection.on('error', function(err) {
	connection.close();
	console.log(err);
});

module.exports = runsettings;

Then in one of the routes i loop through various conditions to insert or update records accordingly
knex		= require('knex').mssql;

handler: function(request, reply) {
     var fields = request.params.fields
     for(var key in fields) {
          if(fields[key].apiKey) {
               knex('dbo.MatchupTableRecords').update(recordToUpdate).where(key).then(function() {
			if(key > fields.length-1) {
                               return reply('1')
                         }
		});
             }
     }
     else {
           knex('dbo.MatchupTableRecords').insert(recordToUpdate).then(function() {
		if(key > fields.length-1) {
                               return reply('1')
                         }
		});
}


Reduce the number and size of dependencies

Adding this to a recent project and noticed the dependencies increased dramatically. One way to help mitigate this would be to better greenkeep the dependencies.

As a quick example, it looks like stupid-server should be a dev dep

Echoing my comment on the other issue - we're in the process of migrating to typescript and upgrading all dependencies as well. stanza-io moving to 11 (and being renamed to stanza) Is a bigger change because it has to be factored into various build systems.

I'll definitely move stupid-server in the short term, that's an easy fix.

One thing to note is that this SDK is prioritizing features over size at the moment, and is actually planned to grow in the future. For a more lighter weight option, you could use the streaming-client directly, and implement the webrtc features on top of that. That is up for feedback however.

@vicapow v4.0.1 was released this morning. v3 would bundle all the sdk's dependencies into the built file. In v4 the dependencies are only bundled for the cdn version which should allow for consuming applications using a build tool to bundle the deps for the sdk.
I know this doesn't necessarily reduce the number of dependencies, but it will reduce the number of duplicated dependencies. Also, the code can be transpiled to the needs of the consuming app.
If you have any issues or questions, let us know. Thanks!


Nest groups of tracked devices that are hidden do not hide

Home Assistant release (hass --version):
0.30.2
Python release (python3 --version):
Python 3.4.2
Component/platform:
group, and known_devices.yaml.
Description of problem:
When I set the values of devices in known_devices.yaml to hide_away: yes, and put them in a group, they don't hide when they are away.
Expected:
They should hide from the group.
Problem-relevant configuration.yaml entries and steps to reproduce:
  People:
    view: yes
    entities:
      - group.Family
      - group.Devices
  Family:
    entities:
      - group.Kevin
  Devices:
    entities:
      - device_tracker.ipad
  Kevin:
    entities:
      - device_tracker.kevins_watch
      - device_tracker.kevins_iphone
      - device_tracker.kevins_iphone_2

kevins_iphone_2:
  name: Kevin's iPhone (Bluetooth)
  mac: BT_XX:XX:XX:XX:XX
  picture: /local/images/bt.jpg
  track: yes
  hide_if_away: yes

kevins_iphone:
  name: Kevin's iPhone (iosApp)
  mac: XX:XX:XX:XX:XX
  picture: /local/images/ha.jpg
  track: yes
  hide_if_away: yes

kevins_watch:
  name: Kevin's Apple Watch (nmap)
  mac: XX:XX:XX:XX:XX
  picture: /local/images/watch.jpg
  track: yes
  hide_if_away: yes

Additional info:
Kinda related to #3850

This appears to be resolved from my testing.

Closing. Report back if it's still an issue.


Unable to override vim.g.have_nerd_font in custom/plugins/init.lua

Describe the bug
I am unable to override vim.g.have_nerd_font in my custom/plugins/init.lua when the main init.lua has it set to false. The main init.lua file contains the following setting:
vim.g.have_nerd_font = false

I attempted to override it by adding the following line to my custom/plugins/init.lua:
vim.g.have_nerd_font = true

However, this doesn't seem to work. My expectation was that settings in the custom/ directory would override those from the main configuration, but it doesn't seem to be the case in this instance.
I would prefer not to change the main init.lua file to avoid conflicts when pulling updates from the main repository. Is this the correct approach, or should I consider changing the main init.lua?
To Reproduce
Steps to reproduce the behavior:

Add vim.g.have_nerd_font = true in custom/plugins/init.lua.
Open Neovim and inspect the value of vim.g.have_nerd_font to see that it remains false.

Desktop

OS: macOS 15.0
Terminal: kitty

Neovim Version
NVIM v0.10.2
Build type: Release
LuaJIT 2.1.1727870382

That line is unlikely to have conflicts, so I'd say go ahead and change it

init.lua is yours to change! Please go ahead and change it in your own config/fork!


Fix enabling workman nightly service

Currently the workman-update-rust service can't be enabled, so if avendahl.dtw.io restarts then it stops running.

Closing, avendahl host is retired and replacement local Jar-Keurog doesn’t run all the time.


We need to display workshop participation data by country

We probably already have an issue on this but just noting this down. It is very important that we display this data. For reporting and this can motivate some partners to help us with advertising.

Soon ...

Soon ...

Done in 95cf1dc2227372f1233760bfda5cc848.

Done in 95cf1dc2227372f1233760bfda5cc848.


[Bug]: mention core-designsystem module in the modularization journey docs

Is there an existing issue for this?

[X] I have searched the existing issues

Is there a StackOverflow question about this issue?

[X] I have searched StackOverflow

What happened?
Not necessarily a bug, but a docs "bug" if one can call it that.
The module core-designsystem is not mentioned in the modularization learning journey at the section where there is a list which should mention all of the app's design system.
On top of that it says that stuff like icons etc are part of core-ui but they are now moved into core-designsystem.
It would be a good idea to update that documentation page and be explicit about what you believe should live in a core-designsystem module and what in a core-ui one because as it stands it is a bit up to interpretation and can easily be confusing as I see it.
ps. I think it'd be a good idea to introduce a new Issue template for documentation problems because this does not fit a feature request nor a bug report imo.
Relevant logcat output
No response
Code of Conduct

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

Thanks for the feedback. We'll update the learning journey.
Also thanks for the suggestion to create a docs issue template. Created https://github.com/android/nowinandroid/pull/201 to add this.


Dynamic loss function (changes over generations)

Hi Miles!
Most of this idea builds upon the one discussed here:
https://github.com/MilesCranmer/SymbolicRegression.jl/issues/92#issuecomment-1103198837
But it is different so I decided to make a new issue.
Ive been using the idea of 'custom_loss_functions' and it has worked great so far. Its really problem specific so I haven't made any pull requests as I dont see it as a generalizable idea, but this one might be.
Is it possible to make a loss function with a variable hyperparamenter? That changes after X generations?
like
return L2loss + alfa*custom_loss
so that alfa changes over generations (maybe decreasingly or increasingly) or this would have to be fixed?
So far I've been saving the state and restarting it changing the loss parameters on my needs but I was wondering if this could be done since the beginning.

Very interesting idea, I could definitely see this being useful for regularizations!
One difficult thing about implementing this is that the loss function is recalculated only when expressions change. So some of the losses may be out-of-date, especially in the hall of fame.
Do you want the absolute loss to change, or just for the search to favor different things over time? If the latter, it will be much easier. You could modify this line: https://github.com/MilesCranmer/SymbolicRegression.jl/blob/a093714e9416b9ccc0678a48c566948908a9708e/src/Population.jl#L103, which is the loss used in tournaments, with your custom loss. Then the search will favor expressions based on your time variable loss, but the loss actually stored will be fixed to e.g., L2Loss.

I got time to think about this:
"One difficult thing about implementing this is that the loss function is recalculated only when expressions change. So some of the losses may be out-of-date, especially in the hall of fame."
But I guess its possible to reevaluate the population members with the new loss function. like
for member in populations member.loss = EvaluateLoss(X, member, new_options) end
and similarly with the hall of fame.
The idea could (?) be used to:  1) pause the search, 2) change the loss metric, 3)reevaluate the loss of each member in the saved_state, 4) reevaluate the scores, 5)and then continue.
Ive got issues with step 4. I thought that using the built-in functions like https://github.com/MilesCranmer/SymbolicRegression.jl/blob/9034341558382188b6c4a9092d847ca8a7162b1d/src/LossFunctions.jl#L50
would help me reevaluate all the scores, but when I try to replicate the scores of a member I don't get the same value.

If all this was possible, a dynamic loss could be done externally without changing too much into the code, and just readjusting the population, as described, accordingly right?
And to answer the question, yes, im more interested in adjusting the search to favor different things :)


Code spliit a letterhead

Testing Vercel deployment. Attempting to mimic codesandbox+netlify deployment

Merging without Socket Security succes.


iOS Video not displaying in release mode from bundled assets

Current behavior
Video does not display in 'Release' Build Configuration' in iOS
Reproduction steps
<Video style={styles.landingVideo} muted repeat resizeMode="cover" source={require('../../assets/videos/bg.mp4')} />

Build in iOS a choose 'Release' build configuration by changing the scheme cmd + shift + <
Expected behavior
Video to display
Platform
Which player are you experiencing the problem on:

iOS

Package version 3.1.0
react-native 0.56.0

same issue on ios, works fine on Android !

I encountered same issue.
Then, I tried to use this PR's branch on my project. It works 👍

Same issue here

same issue here, React Native 0.51.0 and react-native-video 3.1.0

Yes same issue, React Native 0.56 and react-native-video 3.1.0

I'll take a look at the bundling issue. Am fixing another issue in the code at the same time.

From: Arpit Jacob<EMAIL_ADDRESS>Sent: Wednesday, August 1, 2018 1:33 AM
To: react-native-community/react-native-video
Cc: Mishra Ash; Mention
Subject: Re: [react-native-community/react-native-video] iOS Video not displaying in release mode from bundled assets (#1150)
Yes same issue, React Native 0.56 and react-native-video 3.1.0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/react-native-community/react-native-video/issues/1150#issuecomment-409495936, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AbpNLvCAQmXBcUnGq-var-BViSuZT5Dbks5uMWfMgaJpZM4Vhl9l.

@ashnfb 🙏 hero

Hope a new release comes soon looking forwards to it

Fix did not work for me (v3.2.0)

Trying it out now!
Shot for this! really epic

I still have this issue with react-native-video 3.2.1.
It's working well on my iOS simulator (debug & release) and on my iPad (debug)
but not on my iPad (Release)
Do you have a solution ?


[Feature Request] allow passing j.n.ByteBuffer to ArrayBuffer

When working with computation intensive applications or working with low latency applications it would be interesting to allow passing Buffers between Java and Graaljs. I've learned that Nashorn (since Java 9) allows this using the following snippet:
// usually you would get it from the java context but for simplification
// i've created a byte buffer in js
var ByteBuffer = Java.type('java.nio.ByteBuffer');
var bb = ByteBuffer.allocateDirect(12);

// the official ArrayBuffer takes 1 argument (the length)
// but nashorn has a small trick, if the argument is of type
// ByteBuffer, it uses the ByteBuffer instead of allocating a new one
var ab = new ArrayBuffer(bb);

// now we can use it with the JS specific TypedArrays views,
// for example...
var ia = new Int8Array(ab);

// in the end the java code could just inspect the byte buffer above either
// by keeping a reference to it or other ways...

Now this allows us for example to create a buffer in java, do some work, pass the buffer to js and let js do some work in a "simpler language" easier to experiment with, small dev time, etc... and in the end use the result and continue in java.
We can do something similar to this but requires that the buffer gets copied to a byte[] when passing back from js to java:
// no need to pass a buffer will rely on the Int8Array
var ia = new Int8Array(12);
// do some work
return Java.to(ia, 'byte[]');

I guess that this approach puts more pressure in the garbage collector, CPU, and probably on the java side it will be wrapped again into a buffer for further processing...
Also note that this approach does not take into account if the buffer already comes from java, in that case we need to make another slow copy into a buffer to feed to the typed array... which I guess will require a loop instead of a fast memory copy operation.
So my request would be to allow ArrayBuffer to diverge from the ECMA spec and allow this one extra constructor argument like nashorn >=9.

@pmlopes should the new ArrayBuffer be using the passed ByteBuffer directly or can it be a copy?

I think to be compatible with nashorn and to make it "useful". By useful i mean the following use case:

request comes in from a server
data is loaded to a buffer
buffer is passed to graaljs for user processing (script)
back in java take the buffer and return it to client

Hi @pmlopes ,
we recently introduced some initial support for this feature. These tests should give you an overview of what is currently supported.
Please let us know if you have any feedback!
Cheers,
Daniele

Hi @eleinadani,
Thanks for the update this seems a great feature, I just have one question: on Value::.as(ByteBuffer.class) what types will it work with? On the tests it's always a java.nio.ByteBuffer either created on the script or provided in the bindings, but will it also work if the script object is of type JavaScript ArrayBuffer ? or any of the TypedArrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray ?

Hi @pmlopes,
Currently we support automatic conversion via .as(ByteBuffer.class) only for Value objects that are ByteBuffer instances, as described in the tests. Supporting conversion from ArrayBuffer/TypedArray to ByteBuffer would require some changes to our interop mechanisms. This might be possible in the future, but we don't have concrete plans fort that at the moment.

Ok great, one last question, is is possible to access the ByteBuffer from a js ArrayBuffer so we don't have to pass the byte buffer reference all the way the call stack where it might need to interop with java?
Say a non enumerable property? That can be undefined if no backing byte buffer was provided.

Hi @pmlopes,
this sounds like a feature that could be implemented in pure JS code (e.g., by storing the ByteBuffer storage as a field of the new ArrayBuffer, or by patching the ArrayBuffer constructor). Do you have a specific example/scenario where this would not be possible?

It could but since the extension (constructor with j.n.ByteBuffer) is on graal I thing an getter on a non enumerable property could be too.
I can patch on my side but I think this would benefit all users not just me. Regardless of the outcome thanks for adding this!

Yes, that looks like a reasonable approach. The following:
var bb = new ArrayBuffer(ByteBuffer.allocateDirect(32))
console.log(bb.buffer)

should then print something like:
java.nio.DirectByteBuffer[pos=0 lim=32 cap=32]

This feature is working as described on the last could of releases.


Support any namespace\class for the migration base class.

Allow migration base class to be any namespace\class.

Didn't realize this was targeting the wrong branch. In the future, please only target the -dev branches.
Corrected merge commit is a67a301ad8d8e85a2e0bcbabfa6ef2c03be6b91b.


Upload initial MATLAB code-base

This task concerns upload of a code-base implemented in MATLAB, covering algorythmic problems of the project.
Also, a MATLAB project should be created in order to be able to compile .dll library, along with short manual, how to use it.

 MATLAB code-base

Under review as #25

Closed as 50eaf004ba


twemproxy not set keepalive for client fd?

recently my twemproxy machine connection reach the limit of our monitor threshold， i found twemproxy have many dead connection, did twemproxy have tcp keepalive switch?

this might be because connections are in TIME_WAIT state. You can change it at the kernel level. See https://github.com/twitter/twemproxy/blob/master/notes/socket.txt#L61

@manjuraj @jinhao

tcp keep alive (kernel defined) is used in Twemproxy:
https://github.com/vipshop/twemproxy-vip/wiki/twemproxy-maintained-and-used-at-vipshop

kernel defined keep alive:
int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen)

The first parameter is the socket, previously created with the socket(2); the second one must be SOL_SOCKET, and the third must be SO_KEEPALIVE. The fourth parameter must be a boolean integer value, indicating that we want to enable the option, while the last is the size of the value passed before.

But something wrong in Twemproxy:
33 redis.51fanli.it-6390: 34     listen: /var/run/nutcracker/nutcracker_redis.51fanli.it_6390.sock 35     hash: md5 36     distribution: modula 37     auto_eject_hosts: false 38     server_connections: 1 39     preconnect: true 40     timeout: 400 41     redis: true 42     tcpkeepalive: true 43     tcpkeepidle: 800 44     tcpkeepcnt: 3  45     tcpkeepintvl: 60 46     servers: 47         - redis.51fanli.it:6390:1

[2016-07-22 11:17:50.927] nc.c:187 nutcracker-0.4.1 built for Linux 2.6.32-042stab093.4 x86_64 started on pid 6204
[2016-07-22 11:17:50.927] nc.c:192 run, rabbit run / dig that hole, forget the sun / and when at last the work is done / don't sit down / it's time to dig another one
[2016-07-22 11:17:50.928] nc_conf.c:523 conf: directive "tcpkeepalive" is unknown
[2016-07-22 11:17:50.929] nc.c:198 done, rabbit done


Small screen size styling when non-ada tokens are present

+1 for this!
Native token names should be clearly visible in the app as it is the UX that user is expecting rather than some identification numbers. Should be simple enough to update so I hope this will take priority as currently it is almost unusable.

Thanks for the input @morrigan.

Native token names should be clearly visible in the app as it is the UX that user is expecting rather than some identification numbers

We support for showing metadata from the off-chain service managed by the Cardano Foundation, which will hopefully be live and populated by policy owners soon: https://github.com/cardano-foundation/cardano-token-registry
The name you're referring to intended to be a policy sub-identifier, or to encode properties for machine interpretation. Other products that choose to decode and display the value as a "name" are doing so at the risk of their users being spoofed with assetName being set as, for example, 'ada`.
This is discussed in https://github.com/cardano-foundation/CIPs/pull/64


prep

Closes
Example

Screenshots

Checklist

[ ] References any related issue by including "Closes #" or "Closes ".

If no issue exists and your change is not a small fix, please create an issue first.

[ ] Includes tests or only affects documentation.
[ ] Passes pre-commit checks.

Run pre-commit install && pre-commit run --all locally for formatting and linting.

[ ] Includes screenshots of documentation updates.

Run mkdocs serve view documentation locally.

[ ] Summarizes PR's changes in CHANGELOG.md

@desertaxle sorry, dismissed bc I had to merge a typo fix


PlotACNVResults returns Success even when no file is generated.

A mismatch in the ACNV outputPrefix and the sampleName causes an error that prevents the PNG from being generated, but the tool still returns Success.  (Also, the plotting_dump.rda file that is generated is rather cryptic and isn't that helpful for debugging...)  Regardless of the error that prevents the PNG file from being generated, the tool should still fail if this happens.
Whether we should require that outputPrefix == sampleName is a separate issue.  I don't see why this should be the case, since we require that TN files only contain one sample.  Perhaps the real issue is that we use the sample name as the column header for the coverage column?

@achevali @LeeTL1220 @davidbenjamin one more nagging issue with the plotting to be aware of.  @achevali, maybe you can look at adding a fix for this as well?

@achevali, did you fix this in a recent PR, or should I leave it open?

@achevali Did you fix this already?

We had a forum user  bring this up: http://gatkforums.broadinstitute.org/gatk/discussion/comment/32781  I think we've also seen it ourselves a few times.  So it's still an open issue.


Enhancement: Support Json Maps

Currently this project has a leg up above aws-secret-operator when it comes to AWS SM support when it comes to Plain Text mode.
The problem is that it is limited, the parsing of Map Objects is not complete.
I.e.
AWS SM - Plain Text:
{
  "item1": {
    "username": "that_user",
    "password": ""
  },
  "item2": {
    "domain": "etc.url.com",
    "region": "region2"
  },
  "item3": "ThisOneIsFlat",
  "item4": "IAmFlatToo"
}

If we use this secret definition:
apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
 name: my.individual.secrets
 namespace: "secrets"
spec:
 backendType: secretsManager
 data:
 - key: my/secret
 name: map
 property: item1
 - key: event/map
 name: flat
 property: item3

Or, if we use this one:
apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
 name: my.whole.secret
 namespace: "secrets"
spec:
 backendType: secretsManager
 dataFrom:
 - my/secret

We ALWAYS get: base64 encoded:
W29iamVjdCBPYmplY3Rd
For items with subitems like item1 and 2
Which is javascript generic Object type:
[object Object]
The following is a request for the engine to PARSE that object and subdivide into each component.
The KEY question being, DO KUBERNETES SECRETS support Maps?
Thanks!

Believe this is solved here https://github.com/godaddy/kubernetes-external-secrets/pull/247
Sadly I can't merge it myself

By solved I mean the object object part, not sure if this fulfills your request here.

Hello @silasbw, can you please REVIEW this Pull request so we can close this issue? Thanks!
https://github.com/godaddy/kubernetes-external-secrets/pull/247

#247 is merged and should have been released in 3.2.0, please reopen if it didn't solve this! :)


Works with Homebrewed Python in OS X

Both homebrewed python 2.7 and system bundled Python.framework work fine. :)
(#13 is resolved)

Thanks for solving this @davll !


Zurb Foundation Integration

I really like the simple_form integration with twitter Bootstrap... I also love Zurb Foundation
Would you fine people be interested in a pull request that allows people to choose Zurb Foundation as an option when installing? (Much like you can choose Twitter Bootstrap now).
The generator code itself would be fairly benign -- but I worry about a big if/else spaghetti-thon.
Is this type of thing on your radar at all? If so, I'm happy to share and write the PR, let you decide then.

I'd love to see this, even if you have to make it a separate gem.

@jwo hey, that sounds good, considering it's just a change to the initializer template with different wrappers - similar to bootstrap. If it requires changes to SimpleForm code, then we'd have to look carefully if it'd be a go or not.
If you want to try out a patch, just send us a PR when you're done :)

Would love it!


Bug in ext_light_viewer_capture.cpp - depth image is black

Hi, I noticed a problem in the ext_light_viewer_capture.cpp example.
When using the PIXEL_BUFFER readback option, the depth image is black.
Reason: The call to
https://github.com/koide3/iridescence/blob/8451c81e2dd5c6fcb3b86ee953f54ee6da37672f/src/example/ext_light_viewer_capture.cpp#L61
uses GL_DEPTH_COMPONENT16.
It should be GL_DEPTH_COMPONENT.

Thanks for reporting the bug. I just fixed and pushed a fix https://github.com/koide3/iridescence/pull/147.


Start by points, polygons,.. dialog is appearing in all my maps when I visit them

No matter if they have or not geometry, is it on purpose @javierarce?
In this map, there are two layers with geometry info, you can distinguish them in the background.

Damn. Maybe it was the last change I did. I'll release a hotfix.

Leave it for tomorrow, 'new_modals' aren't enabled for everybody so it is ok.

I prefer to release it now. I feel bad, I should have spotted the problem.

up to you