12g2

Can you release DinoDate so it works with 12g2, 18c, and 19c?

Have you had an issue with any of those Oracle Database releases?

Do you mean “Is there a reason to think DD wouldn’t work on them?”
NO

On Feb 4, 2019, at 11:15 AM, Blaine Carter<EMAIL_ADDRESS>wrote:
Have you had an issue with any of those Oracle Database releases?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_dino-2Ddate_issues_7-23issuecomment-2D460308683&d=DwMCaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=5O5ic1WDz05F-44_RkrdbaqljU1JYSRHFQPOePF-ekI&m=kP2eXvEc5QfWrjgNIb8Hai9Asa6KgKAIwY-8DQXfrbM&s=QgSwzyxlhb39ZoyvD-XD_j5PmCw0aa0pN3n12l5qSpc&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AHCF2bbt6XsnOe3Dx5Jyt-2DiUfPB4C0ARks5vKFyWgaJpZM4ahZcI&d=DwMCaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=5O5ic1WDz05F-44_RkrdbaqljU1JYSRHFQPOePF-ekI&m=kP2eXvEc5QfWrjgNIb8Hai9Asa6KgKAIwY-8DQXfrbM&s=DFC8Yi14RZsx4WKvKl0HDVTanhpNtwPxJunukRWIHn4&e=.

Yes, I get this error when I run the SQL script to setup the schemas in 12g2:
742     add_member (
743        l_id,
744        'Spinosaurus',
745        'Dot',
746<EMAIL_ADDRESS>747           'I like knitting sweaters and booties.  I would have lots of little '
748        || 'tiny dinos with you and knit them all their clothes.  I only knit '
749        || 'with red wool.  I want to meet a creative dinosaur who is good with kids.');
750
751     COMMIT;
752  END;
753  /
dd_degree_to_sdo ('29-05-37-S', '141-30-31-E'))
*
ERROR at line 50:
ORA-06550: line 50, column 17:
PL/SQL: ORA-06575: Package or function DD_DEGREE_TO_SDO is in an invalid state
ORA-06550: line 38, column 4:
PL/SQL: SQL Statement ignored
ORA-06550: line 120, column 17:
So when I investigate the function DD.DD_DEGREE_TO_SDO
There is a problem with :
LINE/COL ERROR

6/13     PL/SQL: Item ignored
6/13     PLS-00201: identifier 'APEX_APPLICATION_GLOBAL.VC_ARR2' must be
declared

From: Blaine Carter<EMAIL_ADDRESS>Sent: Tuesday, 5 February 2019 12:15:18 AM
To: oracle/dino-date
Cc: Guerin, Paul James; Author
Subject: Re: [oracle/dino-date] 12g2 (#7)
Have you had an issue with any of those Oracle Database releases?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/oracle/dino-date/issues/7#issuecomment-460308683, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AtImCeUVwn9zEjL2Ihc9SN7YV7Nlr9mGks5vKFyWgaJpZM4ahZcI.
DXC Technology (Philippines) Inc - Registered Office: 5th Floor, Three World Square, 28 Upper McKinley Road, McKinley Town Center, Fort Bonifacio, Taguig City, Manila 1630, Philippines. Registered in Philippines No: CS201308751.
DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.

Looks like there's a dependency in there that we don't need.
Thanks for find this, I'll get it taken care of shortly.

I pushed the change.
@desperate-datesless-din0 could you please try the new version?
Thank you.


Fix handling empty property of WebDav object

Folders on server may have size attribute represented as empty string. Hence, it's size cause crash while retrieving size of object via int('').

Should looked here before making my pullrequest :)
https://github.com/amnong/easywebdav/pull/37


nock.back does not respect enableNetConnect

I just noticed with @bitgal that nock.back even records http requests that are explicitly allowed via nock.enableNetConnect(). Is this the expected behavior?
Example
We want to allow unmocked requests to a local elasticsearch instance so we set
nock.enableNetConnect('localhost');

However, nock.back still records all requests to elasticsearch. Is there another way to white-/blacklist hosts/paths for which nock.back records requests?

@kelaban any thoughts?

This is the reason why I had to disable nock for my tests. Very interested in a fix.

Any news or ideas?

I have this same use case, I'm testing my own server mocking requests to external servers but allowing localhost to work. I found this workaround:
  const options = {
     // on 'lockdown' mode, 'after' is called after lockdown disables all net.
    after: () => nock.enableNetConnect('localhost'),
    // on 'record' I had to filter requests to localhost.
    afterRecord: outputs => outputs.filter(o => !o.scope.match(/localhost/))
  }

  nockBack(`${cassette}.json`, options, (nockDone) => request(nockDone));

:+1:

Having the same issue here, also with functional tests to our own server. They're getting recorded instead of being let through.


[Wallet page] Txns not refreshing

App version: v0.1.92
Should add 'swipe down to refresh' in this page, as in Home page.

Updated on main.


Error: odd number of arguments

After 1. creating a google api app, 2. editing config file to add google app credentials and 3. accepting access
./icalsync --calendar-id<EMAIL_ADDRESS>I receive error
/home/user/icalsync/config.rb:1: Use RbConfig instead of obsolete and deprecated Config.
/home/user/icalsync/lib/google/event.rb:465:in `[]': odd number of arguments for Hash (ArgumentError)
	from /home/user/icalsync/lib/google/event.rb:465:in `parse_recurrence_rule'
	from /home/user/icalsync/lib/google/event.rb:451:in `new_from_feed'
	from /home/user/icalsync/lib/google/event.rb:248:in `block in build_from_google_feed'
	from /home/user/icalsync/lib/google/event.rb:248:in `collect'
	from /home/user/icalsync/lib/google/event.rb:248:in `build_from_google_feed'
	from /home/user/icalsync/lib/google/calendar.rb:288:in `block in event_lookup_all'
	from /home/user/icalsync/lib/google/calendar.rb:275:in `loop'
	from /home/user/icalsync/lib/google/calendar.rb:275:in `event_lookup_all'
	from /home/user/icalsync/lib/google/calendar.rb:103:in `events_all'
	from /home/user/icalsync/icalsync.rb:244:in `sync'
	from main.rb:30:in `<main>'

with a quickfix outlined in the pullrequest another error pops
/home/user/icalsync/config.rb:1: Use RbConfig instead of obsolete and deprecated Config.
/home/user/icalsync/icalsync.rb:77:in `get_i_cal': missing ICS file (RuntimeError)
	from /home/user/calsync/icalsync.rb:246:in `sync'
	from main.rb:30:in `<main>'

Any updates?


Support receiving file data

Noto currently doesn't support receiving raw .txt file data. If this is an important feature for you, please let me know!

Anything that lets users migrate data is welcome. In both directions.


indicator for VS code update download ?

it would be nice to have a separate windows to track the the download task.
and cancel the task if needed. or force the update if it isn't updating for some reason

We want the update the be more transparent, not less.


Ignored import order config with @-packages

Your Environment

Prettier version: 3.0.3
node version: 18.17.1
package manager: npm@9
IDE: VScode

Describe the bug
Third party modules that starts with @ (e.g.: @headlessui/react) are placed at the top of the imports, ignoring any importOrder configuration.
To Reproduce

Install any package that starts with @ such as @headlessui/react

Expected behavior
So the expected ordered output of my imports is:
import { Fragment } from 'react'
import Link from 'next/link'
import { usePathname } from 'next/navigation'
import { Popover, Transition } from '@headlessui/react'
import clsx from 'clsx'

but the actual output looks like this:
import { Popover, Transition } from '@headlessui/react'
import { Fragment } from 'react'
import Link from 'next/link'
import { usePathname } from 'next/navigation'
import clsx from 'clsx'

Configuration File (cat .prettierrc, prettier.config.js, .prettier.js)
module.exports = {
  semi: false,
  singleQuote: true,
  plugins: [
    '@ianvs/prettier-plugin-sort-imports',
    'prettier-plugin-tailwindcss',
  ],
  importOrder: [
    'react',
    '^next(.*)$',
    '<THIRD_PARTY_MODULES>',
    '',
    '^[.]',
  ],
}

Error log

Contribute to @ianvs/prettier-plugin-sort-imports

[ ] I'm willing to fix this bug 🥇

I think this is happening because the importOrder is a regex, and @headless/react is matching react, and it comes before react because @ comes before r alphabetically.  Can you try changing your 'react' to '(react)', and see if that makes a difference?

Thanks for the fast help @IanVS. It was not clear to me that I needed to put the ^ for exact match. actually this solved the problem.


User config has no type

This makes it quite difficult to know what's supported when hosting Flowershow yourself.

I'm raising a PR for this shortly btw just creating the issue 👍

@homostellaris
Thanks again for those changes, with this PR you're helping a lot of people as this will make it much easier to work with Flowershow configuration. However, it would be better if you could move the changes to the right repo, which is https://github.com/datopian/portaljs/blob/main/packages/core/src/config/default.ts.
Let me know if you will be able to do this, or if I should take it from here. 🤝


feat: eagerly compute pruning stats during compression

follow up to #1236

@robert3005 I'm conflicted about whether to merge this now, or perhaps bundle this in with your forthcoming stats pruning?

@danking is working on stats pruning. I think you can merge it and work on stats computation improvements.

Here's the compression benchmarks, filtered to compress time & compression ratio.
TLDR: compress time goes up by 10-50% across the board (median of ~30% increase). File size & decompress time are essentially unchanged.


Run on newer tensorfolow

Great work!
It seems to be applicable to the research that I am currently doing.
However, I am struggling to run this code on Tensorflow2 and Python3.
Do you aware of the ways I can do it? Or do you have any other suggestions?
Perhaps some other pytorch implementations of adversarial nonlinear ica are existent
Thanks in advance

Hi,
Thanks for your interest and reaching out.
I haven't maintained this code in a while but if you have Tensorflow2 installed, replacing occurrences of import tensorflow as tf with import tensorflow.compat.v1 as tf would be the first thing to do and it might be sufficient but see https://www.tensorflow.org/guide/upgrade for more info. Python3 compatibility is a bit harder to predict. I might add this in the future but if you get it to work yourself, a pull request would be very welcome :)
I don't know of any other implementations of exactly this algorithm (it's research code) but the factorized VAE is almost the same idea (although not used for ICA) and can be found here: https://github.com/YannDubs/disentangling-vae. You might also want to check out Devon Hjelm's work on Deep Infomax: https://github.com/rdevon/DIM
Best,
Philemon

Thank you for your answer!
Yeah sure, if I'll manage to run it or going to implement it on pytorch, I'll let you know :)
Thanks for pointing out the works on factorized VAE and Deep Infomax. I am looking for the ways to do fMRI component analysis using neural nets instead of ICA. If by any chance you have encountered any other use of deep learning for ICA, I'd be very grateful if you share the links.
Sincerely, Yerzhan

Philemon, thanks again for your previous answer!
I found this recent work on non-linear ICA, just wanted to share with you [(https://github.com/ilkhem/icebeem)]

Hi Yerzhan,
Thanks for sharing that paper! It looks interesting.
Best,
Philemon


Option to define whether client should automatically renew token

Currently, client creates a timer roughly equal token expiry timeout to make sure token is always up to date. In some cases this timeout is not needed (Web UI handles token renew by showing user login form) or even harmful (tests are not exiting until the timeout is cleared).
User should be able to define during client initialization whether he wants token to be renewed automatically.

I think having an option for auto-renew is reasonable.
As mentioned in the past, I think client should have two APIs - one where user passes in an existing token to the constructor and one where user passes in credentials (username + password).
In the second case, client should auto-renew the token, but user should be able to disable this by passing { auto_renew: false } options object to the client or similar.
As far as actual implementation goes - I'm personally not a fan of timer and I think "lazy renewal" is better - on every request, check if the token is about to expire (e.g. expire_ts - 10 > now) and if it is, renew the token before proceeding with the request. That's also the approach which is used by a lot of other client libraries I'm aware of.

As mentioned in the past, I think client should have two APIs - one where user passes in an existing token to the constructor and one where user passes in credentials (username + password).

Until you make a request, there is no difference between the two so what I'm doing here is initializing client unauthenticated and then allowing user to either auth with credentials or set a token or key manually.
As for implementation, yeah, you probably right and it would remove the pain of clearing the timeout while the overhead of the check is negligible.

Although instead of postponing the request I'd rather run reauth in parallel for the sake of not increasing latency.

It's your call - I don't think the overhead is large since it would only happen once before the token expires and tokens are quite long lived by default so this shouldn't be a problem (so latency would only be increased for a single request which again, imo, is not a big deal).


The Multiple Values selection capablity

This is overall good Feature so far , until user is is coming up with the functionality like want to use the lookup for emails like functions , Where in To or CC we want to search contact and add multiple contacts's email in same search , This is Failed and following enhancement is possible

Allow user to specify multi select Mode
While one or more values already Selected do prepare Query String based on new value
Allow Delete the Selected Values
Wile Selecting other values previous selection should not disappear
The id should be coped in the hidden field by comma separated List

Thanks for the feedback @ybhosale!

pull requests welcome, since I don't believe any foundation team is actively enhancing this component.

Thanks David ,
Appreciate if you can share the non minified version of typeahead.bundle.min.js. There are some changes required in this javascript
Yogesh

@ybhosale that javascript was written by a third-party (Twitter). You can find the source here: https://github.com/twitter/typeahead.js, the version included here is 0.10.1.


Simplify Client::RunTransaction() functor interface

DO NOT SUBMIT.  FOR DISCUSSION ONLY FOR NOW.
Replace TransactionAction with StatusOr<Mutations> as the return
type for the Client::RunTransaction() functor. This makes it easier
to write a functor (addressing #390), and makes it very clear what
RunTransaction() should return when the transaction will be rolled
back.

This change is

When implementing the function called by RunTransaction this seems much better. Thanks.
One question I have is: as a caller to RunTransaction, how do I know if the error was in the function or in a RPC called by the function?

I'm unsure about the Mutations alias. I somewhat lean toward not using that alias because users need to know that it's a vector<Mutation> in order to use objects of that type, so it's not a real abstraction, it's simply a shorthand. And since it's a shorthand, I think users spelling vector<Mutation> may be clearer than Mutations, which hides the type of the object. Plus, I think this might be our first "convenience alias" in the code?
... but I'm maybe 60/40 in favor of dropping the alias. I'm happy to go w/ the consensus of what others think

Indeed.  Originally I didn't have it, but found the continued use of std::vector<Mutation> to be irritating enough (particularly in the lengthy std::function instantiations and the trailing return types and return expressions for the corresponding lambdas).  I imagine external users of RunTransaction() may well feel the same way.
So, I agree that it is not an abstraction, and simply a shorthand, but I would still vote for it.  I don't think there is any practical loss in clarity.  Happy to go with the consensus too, though.

One question I have is: as a caller to RunTransaction, how do I know if the error was in the function or in a RPC called by the function?

Would I be correct in rephrasing this as: "How do I know if the error was from the Commit() or from the functor?"
I think the short answer is, you don't.  Do you have a use case in mind where you might need to make the distinction?  Perhaps interrogating the Status might be enough?.

Sure, supposed my code makes assumptions about the possible values in the database:

For my money, the "right" error code in that circumstance is kAborted.

Perhaps interrogating the Status might be enough?.

I would need to check the message, right? Because there are no status codes reserved for the application. That feels icky.

If you need to distinguish errors, and the status code isn't sufficient, then I guess so.  But the same would be true for any other error indicator that doesn't have per-origin-point codes.

Okay, sounds better than what we have now.  Would be good to gain some experience using it.

So, I agree that it is not an abstraction, and simply a shorthand, but I would still vote for it. I don't think there is any practical loss in clarity. Happy to go with the consensus too, though.

If the consensus is to keep the alias, then LGTM.


Translate components props

@timlogemann 	please put your comments into a proper review. If you don't want to make an explicit approval or rejection, just set it to a comment review. But reviewing on the commit like this makes it very hard to process for the author.

I've processed the review comments. Also the ones from @timlogemann, but I agree with @Keraito that it's a lot easier to use the review tools from Github.

@Keraito ok sure! I've never worked with the review tools before, so I didn't know how they worked.

@thibmaek could you re-review this? we only need one more review to merge this in!


Fix crashes on iOS

compressWithData might return nil. In that case the app crashes
This change resolved all crashes on iOS for my app

We need a merge/rebase with the latest commit on the main branch,


clarify "typically up to 30 seconds"

[Enter feedback here]
The description leads mis-understanding .
”These mechanisms pause the VM for typically up to 30 seconds and preserve the memory in RAM. ”
Some non-reboot Azure platform maintenance takes over 30 seconds , but it is not mentioned anywhere.
"Typically" is very uncertain words .
Therefore user might trust only the comments "up to 30 seconds" .
I hope that the comments avoid to use uncertain words and clarify  if "30 seconds" is promised maintenance time or not.
It helps a lot to design VM HA and design maintenance corresponding procedure.
=======================================================
Now:::
These mechanisms pause the VM for typically up to 30 seconds and preserve the memory in RAM.
=======================================================
example:::
The mechanisms pause the VM for up to 30 seconds, except very rare cases that needs large maintenance program .

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

ID: 823a4e41-1c11-bdb6-8efe-9b50a5c630f0
Version Independent ID: 2ea84238-9763-d95b-9e6a-d11ca0bffba9
Content: Maintenance and updates - Azure Virtual Machines
Content Source: articles/virtual-machines/maintenance-and-updates.md
Service: virtual-machines
GitHub Login: @cynthn
Microsoft Alias: cynthn

@nohato
Thanks for your feedback! We will investigate and update as appropriate.

@nohato
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

@cynthn
Can you please check and add your comments on this doc update request as applicable.

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. The requested updates have not been made since the creation of this issue, and the timeline for resolution may vary based on resourcing, so we've created an internal work item to incorporate your suggestions. We are closing this issue for now, but feel free to comment here as necessary. #please-close


[PUBDEV-6868] Add missing / to the end of the path

@honzasterba should be more explicit now

Manually tested


parser.cpp segmentation error

Hi, @dillonhuff
Faced the problem of parsing this non-standard code. M76 X Or something like that, without the address at the end.
There is a segmentation error in the line 249.
string next_next = *(s.remaining() + 1);
Perhaps it's worth checking the presence of the address somehow?
if (s.remaining() + 1 != s.end()) {
    string next_next = *(s.remaining() + 1);

    if (!is_num_char(next_next[0])) {
        return parse_isolated_word(s);
    }

    return parse_word_address(s);
}
return parse_isolated_word(s);

related to https://github.com/dillonhuff/gpr/pull/13


Time offset for firing note events?

I'm making a game that involves rhythm mechanics but I want to be lenient on players who click slightly before the "note on" event. Is there some way that I could configure this addon to read ahead for note ons x milliseconds and delay note offs by y milliseconds?
Thanks for making this project btw

This might require reworking how note events are passed to the user. Right now I use signals, but as you mentioned this isn't ideal for rhythm games that need to look at future events. Here are a couple ideas I had while thinking about this:

Similar to how audio is typically transferred, expose a stream that can be read into a buffer (so you can read note events in chunks), maybe use something like this: https://docs.godotengine.org/en/stable/classes/class_streampeer.html

Make a subclass of MidiPlayer with a function that looks for events within a certain "radius" of the current time and returns them as a list.

Marking this as "help wanted" because I probably won't implement it anytime soon. Here are a couple of issues I wanted to bring up for anyone looking to take on this feature:

Midi event absolute times are calculated at play-time so fetching a "radius" of events isn't easy to implement without a lot of extra calculations
The buffer solution could be easier to implement, but I worry it will be difficult for the user (developer) to implement in GDscript without a lot of boilerplate

Hello ! A workaround to this issue that I tried was having 2 different MidiPlayer nodes, but that seems to crash the game.
I think that this could work, as the first MidiPlayer would be used to display the notes, and the second one would handle the audio start and help for player inputs.

Hello ! A workaround to this issue that I tried was having 2 different MidiPlayer nodes, but that seems to crash the game. I think that this could work, as the first MidiPlayer would be used to display the notes, and the second one would handle the audio start and help for player inputs.

It's weird the game crashes with multiple MidiPlayer nodes. That's something I'll need to look into.

You can also get the events the same way the MidiPlayer does, I did something like this to display all notes on the track
var time = 0
var microseconds_per_tick = tempo / division;
for event in track.get("events"):
if event['type'] == 'note':
	var event_delta = event['delta'] * microseconds_per_tick;
	var event_delta_seconds = event_delta / 1000000.0;
	event_delta_seconds /=speed_scale;
	time += event_delta_seconds
	if event['subtype'] == MIDI_MESSAGE_NOTE_ON:
		_note_on_events.append({ "note": event['note'], "time": time })


Option to NOT recenter and resize during preprocess_image.py

Updates preprocess_image.py to add options recenter and resize. Will turn them off for multiview_zero123
Saves a copy of image_config csv file in the experiment workspace (since we occasionally modify it across experiments)
Ignore the first 30 commits, they're already present in the main branch (will get squash-and-merged)

Hi @ashawkey, I reviewed this one carefully and since it's blocking further development, I hope you won't that I squash-and-merge it right away...

It's OK! Thanks!


Fix syntax error in schema

This change fixes the ERROR: SYNTAX ERROR T OR NEAR "text" when loading the schema into PostgreSQL.

yes please! fwiw, the failing test in travis is also failing in master


Font family names are not matched according to spec

In the CSS Fonts Module Level 3 spec (see https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#font-family-casing), case-insensitive, folding matching of font family names is required. Currently, font family names in fontdb are matched by string equality.
For example, "FOO sans" does not match "Foo Sans" and "massanzug serif" does not match "Maßanzug Serif" (examples from query tests, see draft PR for query logic rewrite).

Case-insensitive matching is very expensive (Unicode one, not the ASCII one) and it's an extreme edge-case in general. Therefore it is ignored.

If spec conformity is what we're aiming for, case-insensitive matching can't simply be ignored. But maybe we can add a flag to Query that optionally enables case-insensitive matching? By the way, the unicase crate is able to detect ASCII-only strings and only perform Unicode folding and comparison if necessary (at the cost of scanning the string for non-ASCII characters of course).

fontdb isn't a browser-grade library. It is good enough and I do not have plans evolving it into something bigger.
Also, unicase is far too heavy of a dependency for something as simple as fontdb.


docs: update instructions in readme file

Proposed behaviour
Update instructions in readme file
Checklist

[x] Release notes (Conventional Commits)
~- [ ] Unit tests~
[x] Readme updated

:tada: This PR is included in version 1.14.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


merge from template-javascript-component

.github/workflows/update_readme_api.yml

chore: add 20.11.1 (jobs.update_readme_api.steps.with.node-version)

.github/workflows/ci.yml

chore(deps): remove 20.11.0 (jobs.test-node.strategy.matrix.node-version)
chore: add 20.11.1 (jobs.test-browser.steps.with.node-version)
chore: add 20.11.1 (jobs.release.steps.with.node-version)

.github/workflows/codeql_analysis.yml

chore: add 20.11.1 (jobs.analyze.steps.with.node-version)

.github/workflows/update_package_lock.yml

chore(deps): add 20.11.1 (jobs.update_package_lock.strategy.matrix.node-version)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 86.721%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
275

Relevant Lines:
313

💛  - Coveralls


lazy: true not working

Environment
"nuxt": "3.6.5",
"@nuxtjs/i18n": "8.0.0-rc.3",
Reproduction
no
Describe the bug

i have option lazy = true, but build version still load all file language
Additional context
No response
Logs
No response

Lazy loading has been fixed in RC 4 which requires Nuxt 3.7.0 or higher, updating both should fix your issue!

@freezyh
Could you open a new issue and provide a minimal reproduction? Based on the information in your stackoverflow link, it looks like you should move some of the configuration out of i18n.config.ts and into the nuxt.config.ts.
Locking this issue as it's likely unrelated and already resolved.


[Skype] Messages to chatbot can't be delivered

Bot Info

SDK Platform: Node.Js
SDK Version:  3.14.0
Azure Storage: 2.8.0
Active Channels:  Skype, Emulator
Deployment Environment:  Azure App Service

**APP ID: 6cd7cd5b-47ad-40a8-a319-9dd7846977b7
Issue Description
Skype channel not working since this afternoon, 6th February 2018.
{"errorCode":205,"message":"One or more of the user ids provided is not valid."}
All other platforms are working as expected.
Note: I've changed the bot's service table storage recently in this chatbot.
Reproduction Steps

Go to the chatbot on the Skype channel
Talk to the bot
Error sending message icon (!) shows up

Expected Behavior
The bot is expected to answer back to the user like in the test channel - Azure Bot Channels Registration shown below,

Actual Results
On Skype, there's no answer and a ! error shows up.

@EricDahlvang yes. 2 times actually and it's still not working.

@EricDahlvang any news on this issue? Skype is the main channel for this bot and so our clients can't talk with it right now :(

@fms-santos can you share the Skype join link for the bot?   https://join.skype.com/bot/[some guid]

Sure. https://join.skype.com/bot/6cd7cd5b-47ad-40a8-a319-9dd7846977b7
Thanks

I was communicating with your bot through https://web.skype.com/en/ and the windows client simultaneously.  All of a sudden, messages started going through successfully.  Can you confirm that your bot is now functioning properly on Skype?

Yes, it's working again . Thanks! But I wanted to know what was wrong...it's not the first time this thing happens..

@fms-santos I have some ideas, but I'm not 100% sure.  Please email me at the address on my profile to discuss further: https://github.com/EricDahlvang


possible http client resource leak

Reported error is: http: Accept error: accept tcp [::]:8888: accept4: too many open files; retrying in 1s
This is likely caused by an http get response body not being closed. No more context given.

Also:
refreshing signing info for  post failed: Post "http://:26657": dial tcp :26657: socket: too many open files


Hide player

On popup icon click, hide player from the pages.
Retrieve the previous state if click again.

Now that the current channel is recorded in the background script, it should be easy to send a message to pause the player and change the css.


Resource > 404 errors when going to open this page

https://eleducation.org/resources/characteristics-of-middle-school-learners/
happening on Chrome on Android

i think i clicked the wrong project for this!

@thezekiel ?

not seeing a 404 error


DEX-323: deeper details on Asset and Sighting schema

Pull Request Overview

Modifies detailed Asset schema to include annotations: [ ]
Modifies detailed Sighting schema so that .assets includes the above

/rebase


Provides full multilingual RNN encoder-decoder (gru/lstm) with Bahdanau and Luong attentions

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos, doc improvements) (An associated github issue was created https://github.com/pytorch/fairseq/issues/3035)
[x] Did you read the contributor guideline?
[x] Did you make sure to update the docs?
[ ] Did you write any new necessary tests? (not sure new tests are necessary)

What does this PR do?
Introduces the implementation of:

a recurrent encoder decoder, with either uni/bidir GRU/LSTM as encoder and decoders
an attention unit, containing all of the attentions in Luong's paper (dot, general, concat), the original Bahdanau attention, and Bahdanau's attention modified to use the mechanisms of Luong's papers.
a multilingual recurrent encoder decoder

Doesn't this already exist?
No, at the moment, the only implementation available in fairseq is an LSTM implementation with only one of Luong's attentions (no GRU, no Bahdanau, only one Luong attention).
Use cases
When working on low resource machine translation, the transformer architecture can be too needy, in terms of data size, to perform efficiently. When that is the case, people go back to the recurrent encoder decoder with attention. It has not yet been fully implemented in fairseq, so there it is, as complete as can be in terms of modules!

Bump
On Mon 28 Jun 2021, 14:36 stale[bot], @.***> wrote:

This pull request has been automatically marked as stale. If this pull
request is still relevant, please leave any comment (for example,
"bump"), and we'll keep it open. We are sorry that we haven't been able to
prioritize reviewing it yet. Your contribution is very much appreciated.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pytorch/fairseq/pull/3034#issuecomment-869647216, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNMROAODL5SJJE75W7FPHLTVBUDNANCNFSM4U3EJHZA
.

Bump, and what should I do to get this PR merged?

@soumith Hi, I looked for reviewers for the repo, as I couldn't find how to request a review.
Could you please tell me what I need to do for this PR to be merged? That would be extremely useful, as I have no idea what more to do.

@clefourrier thanks for you PR! Perhaps it would make sense to move this to the examples directory instead?


Debug console always comes up when attaching to target

Testing #3238
When attaching to a process, we surely get no debug output at all from it. Yet, the debug console still always pops up. It's very distracting.
Especially when using the restart: true option:

ping @weinand

@isidorn a session restart should not open the debug console

Console still comes up on debug start, but no more on restart.

@isidorn we could consider to not reveal the debug console on 'attach' (but then your code would have to know the semantics of 'attach'...)


Please make a new release

__enter__ and __exit__ are helpful, but were added after v0.4.0

To achieve the same goal without touching beanstalkc code:
import beanstalkc
import contextlib

with contextlib.closing(beanstalkc.Connection()) as beanstalk:
    '''work...'''


Feature Request: expose parsing apis

it would be amazing if the parsing apis were exported, so other projects can take advantage of them
personally i would love to see the parser being broken into a separate package, but i can understand the maintenance overhead that might require
willing to head up a PR if this is acceptable

Well, do you personally have a project that would like to take advantage of it, or is it more of an abstract request?
The things is, the parser isn't really much of a parser (as in, producing a proper AST), it's very specifically tailored for the needs of the formatter.
If you're looking for an SQL parser, you might instead want to consider sql-parser-cst, which I specifically created to overcome the massive limitations that the "parser" in sql-formatter has. It's used by prettier-plugin-sql-cst to format SQL in much better way than will ever be possible with the architecture of SQL Formatter.

do you personally have a project that would like to take advantage of it

I do. I tried sql-parser-cst but it doesn't seem to work for anything more than very simple sql commands (see here for an example of something more advanced)
I can open parsing issues in that repo if you're interested

Well, it does support all the syntax of SQLite and BigQuery, but that's indeed very simple SQL compared to all of PostgreSQL, which will need a substantial amount of additional work before it's fully finished. It is though the most complete PostgreSQL parser implementation in JavaScript that I'm aware of. I did quite a lot of experimenting with existing ones before I finally decided to write my own.
There's an issue that tracks the progress of Postgres implementation.
If a part that's marked as supported in there is not working, then it's indeed worth of opening a ticket. But no real point of opening tickets about the parts of syntax for which nothing has been implemented yet. Then again I haven't even mapped out all the work that remains, like the GRANT/REVOKE syntax that's used at the beginning of that big SQL file you referenced. So it might be worthwhile to open a ticket about that, or just adding a vote for existing tickets for unimplemented stuff. That way I can possibly prioritize implementing the parts that people care the most about.


Allow reading dataframe from an ArrowReader

Some tools/frameworks like datafustion (java binding) or duckdb does not directly expose inputstream of Arrow data but an ArrowReader. It could be useful and not so complicated to add readArrowReader method

Good idea! I'm not very familiar with Arrow, but it sounds like a reasonable addition. Comparable to reading from JDBC resultSets afaik.
I would suggest another name though, as you cannot really "read a reader". Maybe readWithArrowReader or readUsingArrowReader? And additionally an extension function ArrowReader.toDataFrame() for better discoverability.
I do have one concern. Can you read multiple times from the same ArrowReader instance or not? DataFrame is functional in the sense that the same input always yields the same output. This also holds for data sources. Things might become unexpected if reading multiple times from the same reader yields different results.

Actually DataFrame.readArrow(ArrowReader) could probably work even better

Ok for DataFrame.readArrow(ArrowReader)
I think  ArrowReader should be read only once like InputStream it's maybe different for ArrowFileReader as it takes a SeekableByteChannel as input.
Should I add ArrowReader.toDataFrame() extenstion in arrowReading.kt file too ? Maybe I can detect if a reader has be already read and throw an exception or return an error. I think it's the same case for InputStream generally it's only read once ....

It's indeed the same for InputStream good point.
Yes, please put the extension there. Most of our extensions are currently in :core, but since this is an optional supported type, :core cannot depend on it.
I think an exception is a good way to go.
Would it also be possible to create some tests?

While I added some test I discover that write or read from ArrowIPC change the type of inner column.
The following test fail  because c column is a LinkedHashMap on excepted Dataframe and an Arraylist on readIpc object
May I should create a specific issue for that ....
    @Test
    fun testReadIPC(){
        val a by columnOf("one")
        val b by columnOf(2.0)
        val c by listOf(
            mapOf(
                "c1" to Text("inner"),
                "c2" to 4.0,
                "c3" to 50.0,
            ) as Map<String, Any?>
        ).toColumn()
        val d by columnOf("four")
        val expected =  dataFrameOf(a, b, c, d)
        val readIpc = DataFrame.readArrowIPC(expected.saveArrowIPCToByteArray())
        readIpc shouldBe expected
    }

Extension and tests have been added but unfortunately it's complicated to detect if an ArrowReader has already be read (or could be once again) as no method exists and the underlying used source (InputStream, Channel, SeekableReadChannel...) is not accessible.

By the way, an Exception is already thrown (the type of exception dependis of the underlying source) if we try to re-read the Arrow Reader. I don't think that catch and rethrow another exception could be relevant.


Bump aws-sdk to 1.11.697

Fixes https://github.com/prestosql/presto/issues/2614 and https://github.com/prestosql/presto/issues/1132

@cla-bot check

Can we remove the commits which are not required for this change ?

please rebase

@sopel39 rebased/squashed in https://github.com/prestosql/presto/pull/3016


Nose tests cannot find data set files

The nose tests seem to expect the data sets from https://github.com/choderalab/pymbar-datasets to be in a directory in my home folder named pymbar_data. However, it seems like some of the files are not matching up. Here is my output from those tests (I assume the first two go with these data sets as well):
pymbar.tests.test_covariance.test_gas ... SKIP: skip
pymbar.tests.test_covariance.test_8proteins ... SKIP: skip

pymbar.tests.test_mbar_solvers.test_gas ... SKIP: Cannot load dataset; skipping test.  Try downloading pymbar-datasets GitHub repository and setting PYMBAR-DATASETS environment variable.  Error was '``/home/wes/pymbar_data/gas-properties/gas-properties.h5`` does not exist'
pymbar.tests.test_mbar_solvers.test_8proteins ... SKIP: Cannot load dataset; skipping test.  Try downloading pymbar-datasets GitHub repository and setting PYMBAR-DATASETS environment variable.  Error was '``/home/wes/pymbar_data/8proteins/8proteins.h5`` does not exist'

I can't find gas-properties.h5 or 8proteins.h5 in the pymbar-datasets git repo.

Those datasets are in http://github/choderalab/pymbar-datasets
Full integration of these datasets into the testing and timing framework was underway by @kyleabeauchamp before the project was abandoned.
I don't think that there's a way to actually have these large tests complete in time in travis, but I'll give it a try.

I've also added documentation on how to grab the large datasets (to "Getting Started") if you want to test them yourself!

I followed that procedure (clone the pymbar-datasets repo to $HOME/pymbar_data) but the .h5 files are missing. Is there some processing I need to perform on the data sets? Thanks!

Looks like those were never checked in by @kyleabeauchamp, but the scripts to generate the HDF5 files are checked in. Let me try doing that.

We're going to remove those tests until we have someone who is willing to maintain working versions of them. Thanks for pointing this out!

gas-properties.h5 or 8proteins.h5 in the pymbar-datasets git repo.

I think that these were things that Kyle was trying to add - I added the gas-properties and 8proteins examples originally, as examples of real-life things that collaborators were using MBAR for.  The flat-text original scripts worked fine at the time they were committed.
I don't know that we need nose-tests on examples, as they are examples, not core code, and presumably they would take a while to complete, as they are realistic problems, not modular code designed for reuse.  All we would really expect is that if someone followed the README and ran the scripts, they would be able to reproduce the results.

I don't know that we need nose-tests on examples, as they are examples, not core code, and presumably they would take a while to complete, as they are realistic problems, not modular code designed for reuse. All we would really expect is that if someone followed the README and ran the scripts, they would be able to reproduce the results.

And they would not be able to, because the code was broken and not fully documented.
Even if they are examples, there should still be some continuous integration mechanism in place that tests to make sure they still work despite changes to pymbar or upstream tools (such as pytables). Without this and nobody to maintain them, they are no longer useful here.


Adding Mac Support

Pull Request Checklist
Description
adding macOS support
Related Issue
Fixes # .
Motivation and Context
wanted to get this working for macs
How Has This Been Tested?
has testing using Vagrant on macos sierra.
vagrant up macos-client
General

[ ] Update README.md with any necessary configuration snippets

[ ] New parameters are documented

[ ] New parameters have tests

[ ] Tests pass - bundle exec rake validate lint spec

I had trouble getting git on the macos machine during provisioning, so the script does a curl on a zip file I'm hosting to pull the module down, so I'll take any ideas on a better solution for that, but it should be adequate to prove that the code works

thanks for looking over all of this. I'll definitely make these changes, but I just started a vacation, so I might not get to it until next week or so

I made the changes you suggested, but am still struggling with a better way to get the module copied over

I made some of the requested changes and think this is ready for review again. I left one thing as-is and commented on why above

@alvagante @csoleimani is done making modifications to this PR and has been using this branch. Can you please review it and confirm it behaves as expected.

Sorry for taking so long to look at your changes. I just merged your pull request to my repo now.

@csoleimani @alvagante Thanks for this massive contribution!!
It has taken a bit and I've finally got this PR rebased in #863
Please target https://github.com/ghoneycutt/sensu-puppet/tree/macos for any changes


clojure.lang.ExceptionInfo: :auto not supported on headerless data. {}

PigPen Version: 0.3.1-20150825.165235-4
java version: 1.7
hadoop version 2.4.0
java version: 1.7
pig versions: 0.12.0
AMI version:3.4.0
Hadoop distribution:Amazon 2.4.0
At the end of our map step we are seeing the following exception:
Caused by: clojure.lang.ExceptionInfo: :auto not supported on headerless data. {}
at clojure.core$ex_info.invoke(core.clj:4403)
at taoensso.nippy$get_auto_compressor.invoke(nippy.clj:558)
at taoensso.nippy$thaw$thaw_data__10665.invoke(nippy.clj:599)
at taoensso.nippy$thaw.doInvoke(nippy.clj:644)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at pigpen.pig.runtime$fn__12071.invoke(runtime.clj:108)
at pigpen.runtime$fn__2746$G__2741__2751.invoke(runtime.clj:186)
at clojure.core$mapv$fn__6311.invoke(core.clj:6353)
at clojure.core.protocols$fn__6074.invoke(protocols.clj:79)
at clojure.core.protocols$fn__6031$G__6026__6044.invoke(protocols.clj:13)
at clojure.core$reduce.invoke(core.clj:6289)
at clojure.core$mapv.invoke(core.clj:6353)
at pigpen.pig.runtime$fn__12069.invoke(runtime.clj:111)
at pigpen.runtime$fn__2746$G__2741__2751.invoke(runtime.clj:186)
at clojure.core$map$fn__4245.invoke(core.clj:2559)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:484)
at clojure.core$seq.invoke(core.clj:133)
at clojure.core$apply.invoke(core.clj:624)
at clojure.core$mapcat.doInvoke(core.clj:2586)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at pigpen.pig.runtime$fn__12067.invoke(runtime.clj:115)
at pigpen.runtime$fn__2746$G__2741__2751.invoke(runtime.clj:186)
at pigpen.pig.runtime$exec_initial.invoke(runtime.clj:295)
at pigpen.pig.runtime$udf_algebraic.invoke(runtime.clj:337)
at clojure.lang.Var.invoke(Var.java:388)
at pigpen.PigPenFnAlgebraic$Initial.exec(PigPenFnAlgebraic.java:104)
at pigpen.PigPenFnAlgebraic$Initial.exec(PigPenFnAlgebraic.java:88)
at org.apache.pig.backend.hadoop.executionengine.physicalLayer.expressionOperators.POUserFunc.getNext(POUserFunc.java:330)
The map phase get to %100 and all the inputs seem to be processed.
Could it be some compression library thats not installed?
Any ideas where to look?
Thanks
-Bob

It should be using nippy 2.8.0, which on my machine pulls in these dependencies (via pigpen/pigpen-core$ ../gradlew dependencies):
+--- com.taoensso:nippy:2.8.0
|    +--- org.clojure:clojure:1.4.0 -> 1.6.0
|    +--- org.clojure:tools.reader:0.8.13
|    |    \--- org.clojure:clojure:1.4.0 -> 1.6.0
|    +--- com.taoensso:encore:1.21.0
|    |    +--- org.clojure:clojure:1.4.0 -> 1.6.0
|    |    \--- org.clojure:tools.reader:0.8.13 (*)
|    +--- org.iq80.snappy:snappy:0.3
|    +--- org.tukaani:xz:1.5
|    \--- net.jpountz.lz4:lz4:1.3

I noticed that you're using a different pigpen build than is in maven - could it be pulling in something different? Are you able to confirm that these are what end up in the uberjar?

lein deps :tree
[com.netflix.pigpen/pigpen-pig "0.3.1-20150825.165235-4"]
[com.netflix.pigpen/pigpen-hadoop "0.3.1-20150825.165235-4" :scope "runtime"]
[com.netflix.pigpen/pigpen "0.3.1-20150825.165235-4" :scope "runtime"]
[com.taoensso/nippy "2.8.0"]
[com.taoensso/encore "1.21.0"]
[net.jpountz.lz4/lz4 "1.3"]
[org.iq80.snappy/snappy "0.3"]
[org.tukaani/xz "1.5"]
and the project.clj in the uberjar:
(defproject com.taoensso/nippy "2.8.0"
...

@ptaoussanis Any idea what would cause that error?
Bob, did this work previously? Did something change or is this a new setup?

This is a new job, running in the same project/environment/cluster as other working jobs.
What is the root cause here? No data being passed to the reducers?

We use nippy (https://github.com/ptaoussanis/nippy) to serialize (freeze) and deserialize (thaw) data when interacting with the host environment. From the stack trace, this looks like it's at the beginning of a UDF call where it's deserializing the data for processing by your Clojure code.
The headerless bit in the error refers to the options we use to serialize the data. The default is to include a small header at the beginning of the serialized blob that documents what compressor was used, and other information that can inform deserialization later. We chose to disable this option because a few bytes per record adds up to a lot when you're processing billions of records. So far we haven't seen any issues as a result of this.
My interpretation of the error is that it can't figure out how to decompress the data because it doesn't have this header. Why this doesn't occur every time has me scratching my head. I would speculate that it's a specific piece of data you have that's hitting some edge case in the deserialization. Are you able to isolate a piece of data that causes this? Can you reproduce locally, or does this only happen in the cluster?
As a first step, we might want to try upgrading nippy to the latest release (2.9.1) & see if that fixes this issue. After that, there's likely a way to explicitly set the compressor/decompressor it's using so it doesn't have to figure it out automatically. This might be a good thing to do regardless as it will likely be faster.

@ptaoussanis Any idea what would cause that error?

Hi Matt, your interpretation is correct. This error implies that:

nippy/thaw is being called with a {:compressor :auto} option (the default)
The data being thawed was written without a Nippy header

So thaw is being asked to auto-detect the compressor used by examining the header, but there's no header to examine - so it's throwing.
If PigPen writes data without a header (something I'd recommend against, details later) - then (1.) above seems like the culprit: you'd need to track down where that thaw call's occurring.
Some points that may help with debugging:

Why this doesn't occur every time has me scratching my head. I would speculate that it's a specific piece of data you have that's hitting some edge case in the deserialization.

If the intention is that thaw never be called with {:compressor :auto}, then I'd definitely be inclined to rule out these kinds of edge cases. The only place this error can be generated is here: https://github.com/ptaoussanis/nippy/blob/38efea3ca9c2d56a281cc9644cd21e90d8e8630e/src/taoensso/nippy.clj#L558
And the only consumer of that function is here:
https://github.com/ptaoussanis/nippy/blob/38efea3ca9c2d56a281cc9644cd21e90d8e8630e/src/taoensso/nippy.clj#L599
I.e. the only way this path gets triggered is by the presence of an :auto-compressor thaw call. No data is examined to produce this error.

After that, there's likely a way to explicitly set the compressor/decompressor it's using so it doesn't have to figure it out automatically.

If you're serializing without the header, then you must be setting thaw's {:compressor _} option to the compressor that was used for serialization.

Re: disabling the error
I'd generally recommend against this in production systems. The cost of the header is 4 bytes per freeze call, and a small hit to performance. In exchange you get:

A degree of protection against data corruption or use against unintentional data (via header integrity check)
Protection against any breaking changes in Nippy version data formats (esp. nb between different servers that may be running different versions of Nippy)
Support for the :auto compressor and encryptor thaw options (the default) - i.e. no need to worry about setting the right options
Support for the :auto freeze compressor

That last one (new in Nippy v2.9+) allows Nippy to intelligently select a compressor best suited to each freeze call. For example, if it's a very small value - you'll often get better performance + space use by not using any compressor. Use of this feature requires the header since the per-payload compressor info needs to be available during thawing.
You might find that with v2.9+ the header (and default :auto) options actually lead to the smallest possible (or near to the smallest possible) serialized sized in practice.

Thanks for the info! I'm definitely interested in trying out the new stuff in 2.9+ - it seems optimized towards the sort of work we're doing. Generally, the use case we see is serializing millions to billions of tiny values, often a single long or small maps or vectors.
While we start testing that, I am still curious how our current setup works. Below is the single call we make to serialize data, and we're using thaw with no arguments. Does it have to do with the :legacy-mode argument? IIRC, you advised using that at the time, but I don't recall why.
(freeze value {:skip-header? true, :legacy-mode true})

https://github.com/Netflix/PigPen/blob/29521576969b4cf4f1556e12300e5d2e10b9f012/pigpen-pig/src/main/clojure/pigpen/pig/runtime.clj#L64
https://github.com/Netflix/PigPen/blob/29521576969b4cf4f1556e12300e5d2e10b9f012/pigpen-pig/src/main/clojure/pigpen/pig/runtime.clj#L108
Bob, I should be able to get a snapshot build out later today to start testing this. The change should be relatively straightforward - just changing the nippy version & dropping those options.

Version 0.3.1-SNAPSHOT has been released to jfrog: https://oss.jfrog.org/oss-snapshot-local/com/netflix/pigpen/pigpen/0.3.1-SNAPSHOT/
Bob, could you try this version out & let me know if that resolves your issue? We're going to do some perf testing on our production jobs before releasing this.

I'm definitely interested in trying out the new stuff in 2.9+ - it seems optimized towards the sort of work we're doing.

Sure, I'd suggest testing first (perhaps also against 2.10.0-RC1 out of curiosity) - but my guess would be that you'd see better or similar perf with v2.9+ and headers enabled.

While we start testing that, I am still curious how our current setup works. Below is the single call we make to serialize data, and we're using thaw with no arguments.

:legacy-mode? I'd avoid unless you're looking to produce serialized output readable by legacy versions of Nippy (v1.x).
Note that if you're serializing with
(freeze value {:skip-header? true, :legacy-mode true})

Then you must deserialize with
(thaw bytes {:compressor snappy-compressor})

If you're currently just calling thaw w/o any options, that'd explain the reported error.
Let me recommend some alternative calls:
;;; For Nippy v2.8.0, if you want to continue skipping headers for performance
(nippy/freeze val  {:compressor nippy/lz4-compressor :skip-header? true})
(nippy/thaw  bytes {:compressor nippy/lz4-compressor})

;;; For Nippy v2.9+ (incl. v2.10)
(freeze val)   ; Auto-select compressor
(thaw   bytes) ; Auto-select compressor

Using 0.3.1-20150925.170336-5 resolved our issue.
Thanks!

Were you able to get a read on any performance difference? Any better or worse?

Sample size of 1, using a 6 node AWS EMR cluster reading from S3.
252 min original
272 min after this change
~8% slower

Sample size of 1, using a 6 node AWS EMR cluster reading from S3.
252 min original
272 min after this change
~8% slower

I've submitted a new PR at #170 which retains the header but drops all compression (the likely cause of any performance regression).
Do you need support for Clojure 1.4?

Thanks Peter! I'm interested in seeing the result of that change (we'll test it out too), but we really don't need the versioning stability. The serialization is there to transport intermediate products between machines that are all running identical code. It's never used to read user inputs or write the final product and will never last outside of a single job. That's why I felt so comfortable omitting the header.
 We would appreciate any feedback on which of these works better for you.

Do you need support for Clojure 1.4?

Nope, pigpen requires Clojure >= 1.5.1

We'll test out the following variants on our end with 2.9.1

Okay, hold up for a sec - let's try confirm some details before choosing tests to run.
Some questions:

There's zero possibility that two freeze/thaw endpoints with different versions of Nippy will ever share data? E.g. no data is ever retained (persisted to disk, etc.) for thawing at a later time under a possibly different system?
You mentioned that a lot of your data is a single long or small maps/vectors. Could you give me an idea what you mean by "small" here? 2 elements? 100? [1]
Is space efficiency any concern? I.e. would you ever be happy to pay for space efficiency with speed? Under what circumstances? [2]
Any idea what your approximate average payload size is, in bytes?
Any idea what the variance might be like? Or otherwise approximate upper/lower size limits? [3]
Do all of your freeze/thaw endpoints definitely run the JVM in -server mode?

There's zero possibility that two freeze/thaw endpoints with different versions of Nippy will ever share data? E.g. no data is ever retained (persisted to disk, etc.) for thawing at a later time under a possibly different system?

That's correct - it's all used for intermediate products in a single hadoop job. All machines have identical copies of the jars and the frozen data is ephemeral. The serialization is only for moving data from one machine to the next.

You mentioned that a lot of your data is a single long or small maps/vectors. Could you give me an idea what you mean by "small" here? 2 elements? 100?

It really depends on the job; some of our jobs traffic in maps of a few dozen elements, a lot of them have maps of just a handful of elements. When joining data, we select a join key from each of these maps, which may be a single primitive value or a vector of 2-4 elements. More commonly we'll see fewer elements here. I would say that most of the time we're using stuff that ends up backed by array-based persistent storage in Clojure, but we wouldn't want a penalty for using larger maps.
These two cases are separate places in the code though - if there's a better method for primitives & small vectors and a different ideal config for small to large maps, we could in theory use different techniques there. That would be a much bigger change though - right now everything flows through a single method.

Is space efficiency any concern? I.e. would you ever be happy to pay for space efficiency with speed? Under what circumstances?

Potentially, but only because larger data takes longer to move between machines. Older hadoop setups will have one machine serialize the data, write it to disk, another machine reads it, and then deserializes it. Newer stuff will serialize & send over the wire to the next machine (I think - don't quote me on that).  If it takes longer to compress the data than it would just to move it, then it's not worth it. This is simply to transport data from one machine to the next as quickly as possible.

Any idea what your approximate average payload size is, in bytes?
Any idea what the variance might be like? Or otherwise approximate upper/lower size limits?

It can vary dramatically, depending on what data the user is processing. For our use cases, it will generally be 10's-100's of bytes, maybe a kb or two on the upper limit. I generally will be more liberal with the size of the record if I have fewer of them to work with. Anything under a million, I don't even consider the data size. When I know the source data has over a billion records, then I start thinking about making each record a small vector instead of a map.

Do all of your freeze/thaw endpoints definitely run the JVM in -server mode?

That's a great question - I'm not sure. @bcotton - do you know if hadoop always runs the JVM in server mode? I would be surprised if it didn't, but I can confirm that if Bob doesn't know offhand.

One last question: do you ever send the frozen data over a slow connection (e.g. non-local network) as part of job processing?

It should all be within a single datacenter or aws region. I don't know that I've ever heard of a hadoop cluster that's more spread out (which seems like a terrible idea).
So it sounds like you've got some ideas that could refine which variants to test (or just tell us the right answer)? Looking forward to what you come up with - thanks for the help on this!

These two cases are separate places in the code though - if there's a better method for primitives & small vectors and a different ideal config for small to large maps, we could in theory use different techniques there.

That shouldn't be necessary. Reason for asking: the most important knob here is compression - if, when, and how.
Nippy v2.9+ lets you dynamically select a compression method as a fn of the bytes being serialized (e.g. serialized data size). You don't seem to have a significant enough variation in data sizes to make this worth while though, so just disabling compression would likely be the right choice if performance is the priority.

Potentially, but only because larger data takes longer to move between machines.

This might be worth testing, but I suspect the cost of compression here would easily outweigh any benefits. The uncompressed format is already lean - so we're talking about saving <~5% data size at an increased ~20% roundtrip time for LZ4.

It can vary dramatically, depending on what data the user is processing. For our use cases, it will generally be 10's-100's of bytes, maybe a kb or two on the upper limit.

Okay, that's helpful - thanks.

So it sounds like you've got some ideas that could refine which variants to test (or just tell us the right answer)? Looking forward to what you come up with - thanks for the help on this!

No problem - will update the PR in a few mins with suggestions.


LocalAddr and RemoteAddr to return sensible value

With this change,mockconn can be used to test code requires the two methods to return a non-nil value. @oxtoacart does it look ok?

LGTM


Precision error when there are 18 decimal places

d3Format.format(".18f")(1.1) gives 1.100000000000000089
d3Format.format(".18f")(1.2) gives 1.199999999999999956
d3Format.format(".18f")(1.3) gives 1.300000000000000044
... etc. which are all wrong.
This package claims to fix the problem of binary floating point yet it seems to suffer from it.
Can this problem be fixed? Or is there an alternative package that is precise for many decimal places or large numbers?
I use the bignumber.js package for precise calculations with 18 decimal places, but it would be great to be able to format the results nicely for the UI.

These are not wrong; these are the correct answers, because the number literal 1.1 in JavaScript is equal to 1.100000000000000089…, not 1.1. See http://0.30000000000000004.com/
JavaScript doesn’t have decimal floating point natively, but you could use a library like big.js for arbitrary-precision decimal arithmetic.


Weird parameter hint issue with python f-string

Environment data
VS Code version:  1.19.3
Python Extension version:  0.9.1
Python Version:   3.6.4
OS and version:    macOS 10.13.3
Actual behavior
When I had the f-string like print(f"{}") typed in, the parameter hint keep shows up even when the cursor is outside of the function call.

Expected  behavior
The parameter hint should disappeared automatically when the cursor is moved outside the function call.
Steps to reproduce:

Turn on the parameter hint if you didn't
Type something like print(f"{}") and move the cursor outside of the ) and you will see what's happening

This appear to be working with jedi 0.11.1
https://github.com/Microsoft/vscode-python/commit/601546884d8e23bb941eb955b697b02f2426e675


Add ProGuard/R8 rules

It's still useful to bundle these in the JVM artifact as a JVM consumer could be using R8 to shrink their application.


VSCode

It would be cool to have this as extra.
https://github.com/cdr/code-server

It looks pretty awesome. It would fit into the part of the services that I will work on in the upcoming weeks!
Thanks for the suggestion!

It will be available in the next release (today or tomorrow). 🎉


python312Packages.apsw: <IP_ADDRESS> -> <IP_ADDRESS>, python312Packages.appthreat-vulnerability-db: 5.6.6 -> 5.6.7,  dep-scan: 5.2.14 -> 5.3.2

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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


Add delay before preloading preview videos

Summary
This PR adds a 600ms delay before preloading videos on hover in the media gallery. This fixes an issue where hovering around the gallery would suddenly start preloading tens of videos which is super wasteful.
Relevant Technical Choices
State for the timer, and a ref to ensure we can get the current value of "active" inside the callback (and not whichever was in the closure).
User-facing changes
When hover over videos, the preloading waits a bit before starting.
Testing Instructions
Verify that hovering over videos to see a preview works, albeit with a small delay before starting.

Fixes #4110

Can we add a test for it?

Done


pytest_xdist_auto_num_workers pytest missing module config

Type: Bug

Behaviour
Primary Error Message:
def pytest_xdist_auto_num_workers(self, config: pytest.Config) -> Generator[None, int, int]:
AttributeError: module 'pytest' has no attribute 'Config'

Steps to reproduce:

Running unit tests with version v2024.8.1
Upgrade to version v2024.10.0

Unit test are ran against our repo:
https://github.com/beer-garden/beer-garden
Pytest version: 6.2.5

Diagnostic data
2024-07-16 12:02:48.934 [info] Experiment 'pythonCreateEnvOnPipInstall' is active
2024-07-16 12:02:48.934 [info] Experiment 'pythonRecommendTensorboardExt' is active
2024-07-16 12:02:48.934 [info] Experiment 'pythonTerminalEnvVarActivation' is active
2024-07-16 12:02:48.934 [info] Experiment 'pythonTestAdapter' is active
2024-07-16 12:02:48.934 [error] Reading directory to watch failed [Error: ENOENT: no such file or directory, scandir '/beer-garden/.pixi/envs'
	at Object.readdirSync (node:fs:1515:26)
	at /.vscode-server/extensions/ms-python.python-2024.10.0-linux-x64/out/client/extension.js:2:574598
	at /.vscode-server/extensions/ms-python.python-2024.10.0-linux-x64/out/client/extension.js:2:574789
	at Array.map (<anonymous>)
	at d.initWatchers (/.vscode-server/extensions/ms-python.python-2024.10.0-linux-x64/out/client/extension.js:2:574507)
	at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
	at async d.ensureWatchersReady (/.vscode-server/extensions/ms-python.python-2024.10.0-linux-x64/out/client/extension.js:2:536827)] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'scandir',
  path: '/beer-garden/.pixi/envs'
}
2024-07-16 12:02:48.934 [error] Dir "/beer-garden/.pixi/envs" is not watchable (directory does not exist)
2024-07-16 12:02:49.166 [info] Default formatter is set to null for workspace /beer-garden
2024-07-16 12:02:50.160 [info] Python interpreter path: /bin/python
2024-07-16 12:02:51.915 [info] > pyenv which python
2024-07-16 12:02:51.915 [info] cwd: .
2024-07-16 12:02:52.667 [info] > pixi --version
2024-07-16 12:02:52.712 [error] [Error: spawn pixi ENOENT
	at ChildProcess._handle.onexit (node:internal/child_process:286:19)
	at onErrorNT (node:internal/child_process:484:16)
	at process.processTicksAndRejections (node:internal/process/task_queues:82:21)] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn pixi',
  path: 'pixi',
  spawnargs: [ '--version' ]
}
2024-07-16 12:02:52.712 [warning] could not find a pixi interpreter for the interpreter at /bin/python
2024-07-16 12:02:54.215 [info] Starting Pylance language server.
2024-07-16 12:03:31.522 [info] Discover tests for workspace name: beer-garden - uri: /beer-garden
2024-07-16 12:03:31.522 [info] Running discovery for pytest using the new test adapter.
2024-07-16 12:03:31.524 [info] All environment variables set for pytest discovery: <OMITTED>
2024-07-16 12:03:31.524 [warning] could not find a pixi interpreter for the interpreter at /bin/python
2024-07-16 12:03:31.556 [info] > pyenv which python
2024-07-16 12:03:31.556 [info] cwd: .
2024-07-16 12:03:31.564 [warning] could not find a pixi interpreter for the interpreter at /bin/python
2024-07-16 12:03:31.574 [info] > /bin/python -m pytest -p vscode_pytest --collect-only src/app/test
2024-07-16 12:03:31.574 [info] cwd: .
2024-07-16 12:03:31.901 [error] Traceback (most recent call last):

2024-07-16 12:03:31.901 [error]   File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main

2024-07-16 12:03:31.901 [error]
2024-07-16 12:03:31.902 [error] return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code

2024-07-16 12:03:31.902 [error]     exec(code, run_globals)
  File "/.local/lib/python3.10/site-packages/pytest/__main__.py", line 5, in <module>

2024-07-16 12:03:31.903 [error]     raise SystemExit(pytest.console_main())
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 185, in console_main

2024-07-16 12:03:31.904 [error]     code = main()
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 143, in main

2024-07-16 12:03:31.905 [error]     config = _prepareconfig(args, plugins)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 318, in _prepareconfig
    config = pluginmanager.hook.pytest_cmdline_parse(
  File "/.local/lib/python3.10/site-packages/pluggy/_hooks.py", line 433, in __call__

2024-07-16 12:03:31.906 [error]     return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
  File "/.local/lib/python3.10/site-packages/pluggy/_manager.py", line 112, in _hookexec

2024-07-16 12:03:31.907 [error]     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
  File "/.local/lib/python3.10/site-packages/pluggy/_callers.py", line 133, in _multicall

2024-07-16 12:03:31.909 [error]     teardown[0].send(outcome)
  File "/.local/lib/python3.10/site-packages/_pytest/helpconfig.py", line 100, in pytest_cmdline_parse

2024-07-16 12:03:31.910 [error]     config: Config = outcome.get_result()
  File "/.local/lib/python3.10/site-packages/pluggy/_result.py", line 108, in get_result

2024-07-16 12:03:31.910 [error]     raise exc.with_traceback(exc.__traceback__)
  File "/.local/lib/python3.10/site-packages/pluggy/_callers.py", line 80, in _multicall
    res = hook_impl.function(*args)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1003, in pytest_cmdline_parse

2024-07-16 12:03:31.911 [error]     self.parse(args)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1283, in parse

2024-07-16 12:03:31.912 [error]     self._preparse(args, addopts=addopts)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1168, in _preparse

2024-07-16 12:03:31.912 [error]     self.pluginmanager.consider_preparse(args, exclude_only=False)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 635, in consider_preparse

2024-07-16 12:03:31.912 [error]     self.consider_pluginarg(parg)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 660, in consider_pluginarg

2024-07-16 12:03:31.912 [error]     self.import_plugin(arg, consider_entry_points=True)
  File "/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 703, in import_plugin

2024-07-16 12:03:31.912 [error]     __import__(importspec)
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load

2024-07-16 12:03:31.913 [error]   File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked

2024-07-16 12:03:31.913 [error]   File "<frozen importlib._bootstrap>", line 688, in _load_unlocked

2024-07-16 12:03:31.913 [error]   File "/.local/lib/python3.10/site-packages/_pytest/assertion/rewrite.py", line 170, in exec_module

2024-07-16 12:03:31.914 [error]     exec(co, module.__dict__)
  File "/.vscode-server/extensions/ms-python.python-2024.10.0-linux-x64/python_files/vscode_pytest/__init__.py", line 895, in <module>

2024-07-16 12:03:31.916 [error]     class DeferPlugin:
  File "/.vscode-server/extensions/ms-python.python-2024.10.0-linux-x64/python_files/vscode_pytest/__init__.py", line 897, in DeferPlugin

2024-07-16 12:03:31.916 [error]     def pytest_xdist_auto_num_workers(self, config: pytest.Config) -> Generator[None, int, int]:
AttributeError: module 'pytest' has no attribute 'Config'

2024-07-16 12:03:31.990 [error] Subprocess exited unsuccessfully with exit code 1 and signal null on workspace /beer-garden.
2024-07-16 12:03:31.990 [error] Subprocess exited unsuccessfully with exit code 1 and signal null on workspace /beer-garden. Creating and sending error discovery payload
2024-07-16 12:03:31.990 [error] pytest test discovery error for workspace:  /beer-garden

 The python test process was terminated before it could exit on its own, the process errored with: Code: 1, Signal: null for workspace /beer-garden

Extension version: 2024.10.0
VS Code version: Code 1.91.1 (f1e16e1e6214d7c44d078b1f0607b2388f29d729, 2024-07-09T22:06:49.809Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Remote OS version: Linux x64 6.5.0-41-generic
Remote OS version: Linux x64 6.5.0-41-generic

Python version (& distribution if applicable, e.g. Anaconda): 3.10.12
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
Value of the python.languageServer setting: Default

User Settings

languageServer: "Pylance"

testing
• pytestArgs: "<placeholder>"
• pytestEnabled: true

Installed Extensions

Extension Name
Extension Id
Version

autoDocstring - Python Docstring Generator
njpwerner.autodocstring
0.6.1

Chrome Extension Developer Tools
aaravb.chrome-extension-developer-tools
2.0.4

Code Coverage
markis.code-coverage
1.12.0

Code Spell Checker
streetsidesoftware.code-spell-checker
3.0.1

Docker
ms-azuretools.vscode-docker
1.29.1

JavaScript Debugger
ms-vscode.js-debug
1.91.0

Pylance
ms-python.vscode-pylance
2024.7.1

Python
ms-python.python
2024.10.0

Python Debugger
ms-python.debugpy
2024.8.0

Table Visualizer for JavaScript Profiles
ms-vscode.vscode-js-profile-table
1.0.9

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 x 3600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
31.92GB (16.36GB free)

Process Argv
--crash-reporter-id 5b963a74-e961-4f03-bfe9-af0f571f4db5

Screen Reader
no

VM
40%

Item
Value

Remote
SSH: BeerGarden

OS
Linux x64 6.5.0-41-generic

CPUs
Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (2 x 0)

Memory (System)
3.72GB (2.06GB free)

VM
43%

Item
Value

Remote
SSH: BeerGarden

OS
Linux x64 6.5.0-41-generic

CPUs
Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (2 x 0)

Memory (System)
3.72GB (2.06GB free)

VM
43%

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonnoceb:30805159
asynctok:30898717
pythonregdiag2:30936856
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
chatpanelt:31048053
dsvsc021:30996838
01bff139:31013167
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecation:31068756
dwnewjupytercf:31046870
newcmakeconfigv2:31071590
impr_priority:31094925
pythonrstrctxtcf:31093870
0c838689:31092287

Same issue here after the update.

likewise, same issue. Had to downgrade to the Python extension 2024.8.1 release to get my test configuration to work.

dup of https://github.com/microsoft/vscode-python/issues/23707, look there for solutions. You likely need to upgrade your pluggy version for the best results.

Well, already have pluggy==1.5.0 (which is the latest version), and it's not working. I'm not sure it is the same issue as https://github.com/microsoft/vscode-python/issues/23707 (not the same traceback, not the same versions).
In the current issue, it seems that the extension is trying to use code deprecated by pytest in the latest versions, cf https://stackoverflow.com/questions/62762845/attributeerror-module-pytest-has-no-attribute-config.
It seems that the extension bumped the upper bound of pytest but the code is not compliant with it.
Missing references are :

pytest.Config
pytest.PytestPluginManager


Create a page to show logo portfolios

Jekyll Minimum Mistakes Theme supports the portfolio gallery, there has an official example from here: https://mmistakes.github.io/minimal-mistakes/post formats/post-gallery/
We can create a brand page to show photos from https://logomaster.ai/share/MDt82kcR in the gallery.

Done.
See: https://ai-ml.club/marketing


🚧Refactor classes to sealed

Complete The Item Below

[X] I have updated the title without removing the 🚧 emoji.

Description
Go through the entire code base and find classes that can be sealed.  These of course will include all classes that are not being inherited.  The reason for this change is for performance benefits.  All kinds of operations such as instantiation, arrays of classes, type checking, and more have substantial performance benefits by using sealed classes.
Refer to this youtube video by Nick Chapsas for more information on the perf gains and details about the subject.
If the code for the class can easily be changed not to be inherited by choosing composition over inheritance, create issues for each case to refactor this so it can be changed to sealed.

Note v1.0.0 is not out yet.  This is considered best practice in the industry now and it is much better to do this in preview than it is after v1.0.0 has been released.

Add a compiler warning to the .editorconfig file.  It has been confirmed that this warning is going to be implemented in NET v7.0.  The rule is dotnet_diagnostic.CA1852.severity = warning.
All unit test classes should be converted to sealed.  This is easy because nothing inherits the unit test classes.  This will give a performance benefit when running tests.
⚠WARNING⚠
This issue in its entirety will be a breaking change.   Changing a class from non-sealed to sealed is always a breaking change.
This issue MUST be implemented BEFORE version v1.0.0!!
Acceptance Criteria

[ ] All classes that can easily be converted to sealed is converted.
[ ] All unit test classes converted to use sealed are converted.
[ ] All classes that cannot be converted to sealed but the code base can be refactored for composition, should have a new issue created.
[ ] Warning dotnet_diagnostic.CA1852.severity = warning added to the solution level .editorconfig file
[ ] Create an issue to update the .editorconfig files in the org .github repo.

Note Include in this issue to create issues for the rest of the org projects to update their configs

ToDo Items

[X] Change type labels added to this issue.  Refer to the Change Type Labels section below.
[X] Priority label added to this issue.  Refer to the Priority Type Labels section below.
[X] Issue linked to the correct project (if applicable).
[ ] Issue linked to the correct milestone (if applicable).
[ ] Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies
No response
Related Work
No response
Additional Information:
Change Type Labels

Change Type
Label

Bug Fixes
🐛bug

Breaking Changes
🧨breaking changes

New Feature
✨new feature

Workflow Changes
workflow

Code Doc Changes
🗒documentation/code

Product Doc Changes
📝documentation/product

Priority Type Labels

Priority Type
Label

Low Priority
low priority

Medium Priority
medium priority

High Priority
high priority

Code of Conduct

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

Closed without implementation
Reason:
Work was done in another issue due to time savings and other requirements.
Work was performed in:

#158


Use Hamcrest assertions instead of JUnit in  dbclient/jdbc - 2.x (#1749)

Part of #1749
I've already signed OCA. It's an automation problem.
There is no tyrus module in 3.x . I wasn't sure about this PR. There is only line line so :)

/oca-checked

/trigger


Update contents of Project/SharedProject

We should update the contents of Project/SharedProject with more recent code from NTVS/PTVS's SharedProject, to absorb any/all of their recent fixes.
We will need to be cognizant about the risk of regression on #92 but at the moment, there aren't any other known diversions.

also related to https://github.com/adamdriscoll/poshtools/issues/78

Moving this to March; [P|N]TVS has not released a blessed build to pull from.


Check value against another value in schema

Maybe I missed it but is there a way to check the value of one property of the object against the value of another property of the same object? Like below,
const schema = z.object({
  lower: z.number(),
  upper: z.number()    // Check this value is greater than lower
})

@viduli-prime
You can use refine on the object schema itself to do arbitrary checks. Just note that refine returns a ZodEffect not a ZodObject which is often a source of confusion and frustration. Here is a pattern that I've used lately:

export const uncheckedSchema = z.object({
  lower: z.number(),
  upper: z.number(),
});

export const checkRange =
  ({ lower, upper }: { lower: number; upper: number }) => upper > lower;

export const schema = uncheckedSchema.refine(checkRange);

The reason for the extra indirection is that if you need to pick or extend or do any other ZodObject method on the base schema, you'll need to add the refinement after calling that, and only if it still makes sense:
import { uncheckedSchema, checkRange } from "./module-a";

const extendedSchema = uncheckedSchema.extend({
  middle: z.number(),
}).refine(checkRange);

const pickedSchema = uncheckedSchema.pick({
  lower: true,
}); // you can't use that refinement here since `upper` isn't defined anymore!


Plugin doesn't work with 4.8.0+

Looks like it's having peer dependency version conflicts with newer Strapi versions that use react-intl 6+ where the plugin only states ^5+.
Due to this, npm install errors out and requires --force to install.
I tested the plugin with 4.8.2 and it does appear to work fine without any problems.

+1 running into the same issue

The temporary workaround is to add an override in the package.json:
  "overrides": {
    "strapi-plugin-publisher": {
      "react-intl": "^6.0.0"
    }
  },

Still, it's not the right fix for this situation.

Feel better! And thank you as always :)

Looks like typescript dependency also should be updated to allow 5.x

Typescript? This plugin does not have a dependency on typescript.

My bad.  The new react-intl 6.x is the one that has that dependency.  So when upgrading and using react-intl 6 and typescript 5, we get this error.  So it's technically react-intl, not this plugin.

This should be fixed in the latest release


Why we use private constructor for ILazyload injection

This issue tracker is for documentation
For product issues, use https://github.com/aspnet/EntityFramework/issues

Duplicate of #865


InfluxDB Clustered partial writes

This lays the groundwork for partial writes in InfluxDB Clustered. Before this PR goes live, we will need to add information about disabling the partial writes feature using the available environment variable. This will like go in the release notes of the next Clustered release and point to the environment variable configuration docs included in this PR.

[!IMPORTANT]
Do no merge until the next Clustered release (planned for Sept 16th)

Updates Clustered API docs with new partial writes behavior
Adds information about configuring components with environment variables
Updates write task-based docs with information about new partial writes status codes

[x] Rebased/mergeable

@sanderson we are getting ready to release a new version of Clustered with partial writes enabled. Is that all this PR was waiting on?

@waynr I think so, yes. That and the release notes, but those will come after the release. @dsprogis mentioned that requiring the license will also be the new default in this release. Is that the case?

@sanderson just FYI, I have referenced these new docs in the release notes: https://github.com/influxdata/k8s-idpe/pull/48148/files#diff-de6ce98acc9bb2452a84f41b7d74980ad01f561d3fb6a18441dc4873bd558954R101

the license will also be the new default in this release. Is that the case?

Yes, that's also mentioned in the release notes.

@sanderson just FYI, the new Clustered release went out the other day so this should be good to go!

Perfect! Thank you @waynr.


@quiltt/react-native polyfill should play nice with babel-plugin-polyfill-corejs3

It's likely when babel-plugin-polyfill-corejs3 is in use, @quiltt/react-native polyfill won't work.
Either ponyfill it or remove polyfill completely and require user to polyfill themselves.

close by https://github.com/quiltt/quiltt-public/issues/176


fix: specify the cache-control for badges

Fixes #341
I used the same value 300 as shields.io's npm version badge.

Seems to be fixed. Thanks!


Self hosted  Gitlab configuration issue

Hi
Could you tell me where to look since I couldn't find how to configure the token for a self hosted gitlab instance?

Certainly! Here's a more concise version that leverages GitHub's automatic linking for issues:
Hi @avicoder,
I've been working on a workaround for configuring Mergestat with self-hosted GitLab, which might be useful for you. It involves setting a custom base URL and ensuring the access token is correctly used. I've detailed this approach in issue #1161, where I also link to a fork with the applied changes.
This temporary solution could help while we await a more integrated feature from the devs. Check out issue #1161 for more details, and don't hesitate to ask if you have questions!
Thanks,
matnav

@avicoder,
I've been working on a workaround for configuring Mergestat with self-hosted GitLab, which you might find useful. It involves setting a custom base URL for the GitLab API and ensuring the access token is properly utilized. All the details of this approach have been outlined in issue #1161, along with a link to a fork where I've applied these changes.
This workaround could serve as a temporary fix while we await a more integrated solution from the Mergestat developers. Feel free to check out issue #1161 for more information. If you have any questions or need further clarification, I'm more than happy to help!


Benchmark the performance of int3 hooks as compared to thcrap breakpoints

On a CPU that already almost maxes out one core just running the base game, an int3 hook every might be a significant performance penalty, as opposed to thcrap breakpoints that are just a simple call into thcrap code. We'd have to make some sort of benchmark tool and send it to a bunch of people to compare performance across lots of different CPUs

Turns out the recent performance issues were just the UEHandler being called every time an int3 hook gets hit, and generating a crash dump multiple times per frame. I think this issue is redundant now, but benchmarking int3 hooks would still be nice


Mugen crashes when merging video towards the end

Description
It appears to be running out of RAM, but I have plenty and HTOP shows that it's running out of virtual RAM, and not using most of my 32gb.
Is it better to use 1 large video, or a bunch of small clips from a video?
Is there anyway to get a log of how/why it's failing?
When it fails, is there an option to save everything in the folder it tried to create? (Partial video, Segments, Rejected-Segements, etc?)
Platform
Vendor ID:                GenuineIntel
Model name:             12th Gen Intel(R) Core(TM) i9-12900KF
CPU family:           6
Model:                151
Mem:           31933        9583       17902         172        5083       22350
Swap:           9011        1589        7421
6.8.4-1-MANJARO
Python 3.9 in miniconda

Analyzing audio...
Events:
[<EventList 0-763 (764), type: Beat, selected: False>]
Generating music video from video segments and audio...
100%|?????????????????????????????????????????????????????????????????????????????????????????????????????????????| 765/765 [7:57:05<00:00, 37.42s/it]
Filter results:
0 segments failed filter not_is_repeat
0 segments failed filter not_has_low_contrast
0 segments failed filter not_has_text
0 segments failed filter not_has_cut
Writing music video '/home/mediaserver/Desktop/music_video_4/music_video_4.mkv'...
zsh: killed     mugen create --audio-source /srv/nfs/14TB/MugenProject/Khtdr.mp3

Hey @DooDip I think I've run into a similar issue occasionally in the past where it seems it was just struggling to stitch together all the segments at the end and was likely failing from needing too much memory. I think most of the videos I generated in the past were in the range of 300-400 segments. I'm guessing you're using a longer or faster BPM to get to 765 segments, so depending on the resolution of the video sources and the specs on your computer that may be beyond the capabilities of the program currently.
As for the number of videos, you should definitely avoid passing in a bunch of small clips. It's intended to be used in scenarios like passing in a movie file, or multiple movies, or a folder full of episodes from a series, or even multiple folders for multiple seasons, perhaps even combining a series with one or more movies and then setting weights for how often you want to sample from each. Unfortunately there appears to an effective limit on the number of videos you can pass in because the program will fail due to the computer's open file limit past 50+ or so videos, and I haven't gotten around to working on a workaround yet. Would likely mean having to drop the reliance on moviepy and doing some magic with ffmpeg directly to build the final video in increments rather than all at once, which would probably solve both the open file limit and the memory issues you can get when trying to generate larger videos.
In general if there was an error with the program you should see the output printed to the console directly. If you didn't see anything in particular that sounds to me like it was killed by the OS, probably for needing too much memory/being out of memory.
There are two option to save segments and rejected segments (--save-segments and --save-rejected-segments) but unfortunately savings segments runs at the very end, after generating the music video >.<
Wish I could help more here but hope the context is useful at least


You shouldn't re-host mods

What you've done over on https://github.com/HyperMC-mods/mod-pack is simple and easy, right? But according to the licenses of those mods, you can't do that. Any one of them would be in the right to send you a DMCA takedown for that. I would recommend instead to figure out how to get the files from the original site. For example, for optifine you could use an embedded browser that wait's for an event for a file download ending in .jar. That way the mod developer stays happy (They get ad revenue) and you're not breaking the TOS (and the law) for those mods.
Heck, if you ask the mod developers, they might even have an API you could query to get the latest versions, with download links!

Thank you for the feedback. I was not aware of this. We will try to get an API key from a Minecraft mod listing site. Thank you for the information.

if you saw, in the read me/download area, he says that is temporary, he is planning to use curseforge's API to fetch the mods, we might also add support to other mod loaders like fabric, but yeah, this isn't permanent.


Explore having Editor widget within Information panel

Editor widget can replace the Information panel while editing and the section can expand to full height.
Quick example, if we implement also the collapsible https://github.com/Esri/solutions-components/issues/266

This will work well for the Grid and the horizontal layouts, but will be a challenge for vertical.

Not sure if for this case, the Editor would need to show in a floating side panel, or if we split the Information section into two parts with Information on once side and Editor on the other... 🤔
cc @chris-fox

@avezina showing in that panel will be no problem. The main thing I don't know how to deal with is the fact that the editor doesn't seem to fire any event when you go to add a related record or if you cancel the adding of a related record. So I don't know how to tell if the back button should close the widget or go back to the main edit panel.
If add related record changed the state like when you go to add an attachment then it would not be an issue. I can show an example tomorrow if this isn't clear.

@avezina, yea I am not sure how useful the vertical layout is. Looks kind of weird with the information spread out all the way across the app like you said. Maybe more useful on a mobile device? We haven't been thinking about mobile a lot yet for Manager, but it is probably something we need to support.

@chris-fox

I am not sure how useful the vertical layout is. Looks kind of weird with the information spread out all the way across the app

Agreed. I feel like having the table full width is valuable, but you can still do that with the other 2 layouts by collapsing the left section. We can evaluate mobile device if needed: https://github.com/Esri/solutions-components/issues/274

@avezina anything seen as incomplete with this?

@jmhauck I think we're good on this, thanks!