Getting an error after register and try to login

Hello,
Any idea with this?
⨯ src\app[locale](auth)\login_action.tsx (38:18) @ $$ACTION_0
⨯ TypeError: (0 , next_auth_react__WEBPACK_IMPORTED_MODULE_5__.signIn) is not a function
at $$ACTION_0 (login/_action.tsx:56:70)
digest: "1084414913"
36 |   //signin
37 |   try {

38 |     await signIn("credentials", {
|                  ^
39 |       email,
40 |       password,
41 |       redirectTo: callbackUrl || DEFAULT_LOGIN_REDIRECT
POST /en/login 500 in 620ms

Doesn't work as well as a login via google/github

Same error here.


In vault-cluster-private, should the vault servers join Consul on startup?

In vault-cluster-private, should the vault servers join the Consul cluster when they start up? In my setup, they are not doing this. I'd like them to, but if this is not something built in I won't worry about it.
My Vault server instances are running this as their user_data script:
#!/bin/bash
 /opt/consul/bin/run-consul --client --cluster-tag-key consul-dev-servers --cluster-tag-value consul-development
/opt/vault/bin/run-vault --s3-bucket clearcover-vault-development --s3-bucket-region us-east-2 --tls-cert-file /opt/vault/tls/vault.crt.pem --tls-key-file /opt/vault/tls/vault.key.pem

The Consul agent running on each Vault server will join the Consul cluster as clients. Vault itself will just use those agents.

OK cool, thanks. I noticed the IAM instance profile in the Vault module doesn't have the DescribeInstance permissions it needs (the IAM profile in the Consul module does, however). I forked the repo and will submit a PR in the next couple of days. Thanks!


Will this plugin be able to work perfectly with Samsung Galaxy S4 Iris scanner?

I am developing an application for Samsung Galaxy S-series which support Iris recognition.
So, will this plugin can give me the captured information from the iris scanner?

No.


Support for non-square/non-power-of-two HeightMapShape3D

Opening an issue to discuss comment at https://github.com/godotengine/godot-proposals/issues/7308#issuecomment-1646151034:
For performance reasons I'm reluctant to support non-power of 2 / non-rectangular height fields. There are work arounds to support more dimensions:

You can round up dimensions to the next power of 2 and fill the remaining height samples with HeightFieldShapeConstants::cNoCollisionValue.
You can play around with HeightFieldShapeSettings::mBlockSize which doesn't need to be a power of 2 to reach resolutions that are not a power of 2 (and can combine this with the first trick).
You can create multiple HeightFieldShapes and combine them into a CompoundShape for non-square height fields.
You can convert a HeightMapShape3D to a MeshShape if none of the above are applicable (this is what we do when there many holes in the terrain so that a mesh uses less memory than a heightfield).

Do you know what the common patterns are for dimensions of height maps in godot? If there are, then perhaps I can support them.

Thank you for the suggestions. I'll give those a try when I have the chance.

Do you know what the common patterns are for dimensions of height maps in godot?

Until very recently I would have said this shape in general was largely forgotten about, as it's had some issues in Godot Physics and people don't seem to really use it much, presumably for that reason.
But just a couple of days ago there was a terrain extension released called Terrain3D, which implements clipmaps that utilize HeightMapShape3D, and for reasons that I'm not intimately familiar with they use power_of_two + 1 as their height map dimensions. So with their default "region size" of 1024, you end up with 1025 samples.
I got a question from @Dabnabbit about this exact thing the other day, who had run up against this same problem in Godot Jolt when trying to use his own clipmap solution, and from what I understand this extra row/column stems from somehow simplifying the process of being able to tile the regions, because the quads and pixels end up 1:1, or something like that. :)
So to answer your question I guess pretty much the only pattern I've run into so far is exactly that, power_of_two + 1, which I suppose your first suggestion should technically be able to accommodate for just fine.

If you create a terrain texture for rendering of NxN pixels you can see each pixel as the value at the center of each of the NxN quads of the terrain, this means you'll need (N+1)(N+1) vertices in order to get NN quads. We have chosen the opposite where we see the terrain texture as the values at the vertices rather than at the center of the quads and then it makes sense to have N*N vertices in the height field (where N is power of 2).
I'll see how difficult this is to support (but first soft body support).

Support for alternative dimensions would be great. Zylann's heightmap plugin also follows power_of_two + 1 rules for dimensions and provides their reasoning here: https://github.com/Zylann/godot_heightmap_plugin/blob/a481edb415d29eb01f7b0f220bde301e9052dcfb/addons/zylann.hterrain/hterrain_data.gd#L227

I was actually wondering about using chunk sizes that are not powers of two (for example 63 instead of 64), so that the terrain maps would not be 2^x+1, but instead N*2^x+1, where N is not power of two. Which means maps would fit within a power-of-two image, just not using the full image. I thought of that because I had the impression that forcing a texture to be non-power-of-two by just 1 above a power of two was going to waste memory on the graphics card, in case the driver worked around that by allocating the next power of two, wasting almost 75% of memory. I never really investigated whether that's true^^" But...

You can round up dimensions to the next power of 2 and fill the remaining height samples with HeightFieldShapeConstants::cNoCollisionValue.

Physics-wise, it would then mean as well that not as much memory would be wasted when using such a technique.
On top of that I was thinking if a terrain is already using tiles, non-power-of-two sizes don't seem to be much of a problem, since tiles can already help greatly in covering the "used space" of the game world.

If you create a terrain texture for rendering of NxN pixels you can see each pixel as the value at the center of each of the NxN quads of the terrain

Hi, I'm a Terrain3D coauthor. I wrote up a discussion about why we use 1025^2, which is not quite what is quoted above. I tried Jolt today after reducing down to 1024, I found it mostly works but there are two key issues. If I can get help resolving them, I have no problem reducing our collision down to 1024.
https://github.com/outobugi/Terrain3D/discussions/152

I just ran into this issue trying to implement Jolt in my game and then going down the rabbit hole on the error from Zylann's terrain plugin. Glad to know supporting non power of 2 is a planned feature! Thank you so much! Looking forward to release!

I just submitted a change that allows non-power of 2 height fields.

oh awesome i thought it was planned for 1.0 i saw .5 was out. I'll check it out!

@jrouwe meant with respect to Jolt itself, not Godot Jolt. I did just try this locally with Terrain3D's demo project though and everything seems to work, as far as I can tell, so expect this to be in for the next release, which should hopefully be out some time early next week.

@mihe You can enable debug collision in our settings then you can see it. Specific areas to look at are the borders between regions as that's where the heightmap shapes overlap. That's the +1.

When godot jolt gets updated to reflect this, don't forget to update the caveat in the readme.

I decided to also throw in preliminary support for non-square height maps, by just falling back to Jolt's MeshShape (i.e. ConcavePolygonShape3D) in those cases. I hadn't planned on doing anything about it during this first pass, but since I was already adding support for 2x2 and 3x3 height maps (yeah yeah, I know, but Godot supports it) through Jolt's MeshShape I figured why not. It's probably such a vanishingly small number of users that need non-square height maps that this should be fine for a while.
I also removed the error when you have a HeightMapShape3D with 0 heights in it, which seemed to be a thing that Terrain3D does at some point. I'm already forced to support having 0 faces in a ConcavePolygonShape3D, due to how CSGShape3D works, so this seemed like the right thing to do either way.
With all these changes, the Terrain3D demo project seems to work just fine without any errors. Although, I'll admit I haven't looked at it too closely.
I'll try to get a release out in the next few days, so you can try it for yourselves, if you don't feel like building from source.

Great, looking forward to trying it.

I also removed the error when you have a HeightMapShape3D with 0 heights in it, which seemed to be a thing that Terrain3D does at some point.

I wasn't aware that happens. Under what conditions? If there are no regions there shouldn't be any collision generated.  That's what I see in the code, it only makes heightmapshape3d if there's a region with data in it.

I wasn't aware that happens. Under what conditions?

From just looking at your code, you add the shape to the body before settings the shape data here, meaning you're adding an empty HeightMapShape3D to a live body, which will trigger a setup of the internals, but with 0 heights, and then you set the proper shape data, triggering the real setup of the internals. Flipping those two lines should prevent that.
Godot Physics silently lets this become an empty/invalid shape, like with so many other invalid shape configurations, but I had tried to be more aggressive about actually emitting errors in such cases. I guess there's some argument for 0 heights actually being a valid configuration though, hence the change.

Ah, I see. Most tasks in Godot allow one to create an empty resource when working in the inspector. I didn't see any errors or notice any problem, even when testing jolt before. We can swap the lines easily.

Just to clarify, this behavior is specific to how Godot Jolt deals with how the underlying Jolt shapes are rebuilt. I didn't mean to imply that what you're doing is somehow incorrect. Godot Physics doesn't care in which order these two lines happen, and will run its internal setup twice either way. Godot Jolt won't run the internal setup until the shape is actually set on at least one body that's also attached to a scene tree, which is what allows me to be a bit more picky about invalid configurations, since shapes should ideally be properly configured by that point.

I've just published 0.6.0-rc1, which includes the relaxed restrictions on HeightMapShape3D. I'd appreciate it if anyone here awaiting either of these changes could give it a try and confirm that it works for your particular use-case(s).

I'm happy to announce proper 1:1 working functionality matched against the original Godot API, with near identical calculation/generation times. Super awesome to the see the community come together to solve an issue like this in such a short amount of time!

Glad to hear it! Thank you @jrouwe for taking on the non-power-of-two stuff on your end by the way. I'll see about experimenting with the non-square compound shape stuff at some later point (before v1.0).
I'll probably let this release candidate sit for a couple of days until I publish the stable version.


[Bug] Do we able to modify the scheme or delete the probes

Hi team  I just want to do either delete or modify the liveness and readiness probes for the grafana container isn't possible ?
I want to change the scheme to https in liveness and readiness probes or else i want to delete that probes

Hey @mohan-nagandlla this is currently not possible. You can override some aspects of the probes, but not the scheme. I've linked a PR to address this.

Thank you for that

The pr have been merged so I close this issue


Accessing Style property of XSSFTable after settings StyleName fails with KeyNotFoundException

Accessing table.Style after settings table.StyleName will fail with KeyNotFoundException.
This example fails on the latest commit with the following stacktrace:
Unhandled exception. System.Collections.Generic.KeyNotFoundException:
The given key 'TableStyleMedium27' was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at NPOI.XSSF.Model.StylesTable.GetExplicitTableStyle(String name) in npoi\ooxml\XSSF\Model\StylesTable.cs:line 169
at NPOI.XSSF.Model.StylesTable.GetTableStyle(String name) in npoi\ooxml\XSSF\Model\StylesTable.cs:line 164
at NPOI.OOXML.XSSF.UserModel.XSSFTableStyleInfo..ctor(StylesTable stylesTable, CT_TableStyleInfo tableStyleInfo) in npoi\ooxml\XSSF\UserModel\XSSFTableStyleInfo.cs:line 26
at NPOI.XSSF.UserModel.XSSFTable.get_Style() in npoi\ooxml\XSSF\UserModel\XSSFTable.cs:line 418
at CreateTableInXlsx.Program.Main(String[] args) in Program.cs:line 31

It works on the latest nuget version (2.6.0).

No, it doesn't work, I don't know what fixed it last time, but I'm having this exception in two separate projects.

Nvm, seems to have been fixed in 2.6.1-rc1.


Work type selection modal should gracefully handle up to 20 work types

 Issue by vantuyls
Tuesday Nov 22, 2016 at 17:25 GMT
Originally opened as https://github.com/projecthydra/sufia/issues/2933

When the number of Work Types exceeds about 5, the work type selector interface starts to spill off the bottom of the page. I wonder if a matrix of work types, rather than a list, would help alleviate this problem. Or possibly, after 4 work types, new work types are listed in a second column?

 Comment by mjgiarlo
Tuesday Dec 20, 2016 at 21:43 GMT

This needs design and I'm not sure folks are likely to create 5 types of work off the bat, so I'm not going to make this a blocker. I suggest we take this up in Hyrax.

I won't spend time doing any mockups unless we feel it's necessary, but if and when we want to deal with the potential of longer lists of work types, I suggest we 1) flow the work types choices into two columns of equal width, and 2) ensure the modal window has scrollbars.

Currently the design we're implementing for work type selection (both for single works and for batch works) in advance of creating new works is a modal with styled radio buttons. This works fine for a small number of work types. The design should accommodate up to 20 work types.

@ggeisler Thanks! I'll remove from design needed for now. This is on the backlog for later consideration.

Is this an issue for current users?
@samvera/hyrax-repo-managers

No, we have 10 worktypes and it's fine. Closing.


fork button is gone

Operation System: ubuntu 17.04
Beaker Version: master latest
I'm not sure, if I messed something up with my build. ... But the "fork - button" is gone form the menu. ... "burn the mall" doesn't fix it. ... I probably missed something else.
to reproduce:

go to: dat://example-self-mutator-pfrazee.hashbase.io/#
open menu

Hey Mario!
We're actively building a new UI, but haven't perfected or documented it yet. (Master is the bleeding edge!)
You have two options to fork now. 1, you can use the context menu:

2, you can open the sidebar by clicking the panel button next to the hamburger menu. The fork button is there:

Sorry for the noise. ... Just found it :) ... thx
funny. .. I'm using "Inspect element" .. but didn't recognize the "fork button" ... So I probably don't see, what I don't expect :)

No worries, we keep changing the UI on you :)
On Tue, Jun 20, 2017 at 10:19 AM, Mario Pietsch<EMAIL_ADDRESS>wrote:

Sorry for the noise. ... Just found it :) ... thx
funny. .. I'm using "Inspect element" .. but didn't recognize the "fork
button" ... So I probably don't see, what I don't expect :)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/beakerbrowser/beaker/issues/551#issuecomment-309792928,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNhU8aVDu7SvvKrkshmg62AvF8QiAAOks5sF-MFgaJpZM4N_uA_
.


Power BI report was loading initial data, but I dont see any data in the dashboard, no errors

I downloaded Power BI template "MPARR - DLP General Overview Dic2023.pbit" and import it in Power BI Desktop.  I entered the workspace id. It started to load data:

After the loading of data is finished I see this empty dashboard:

What is going wrong?

Move the timeline, center at left.

Thank you, now it is working


Please help me basic sample

💬 Questions and Help
Hi,
I'm a student at university.  I have a project at Xamarin.
if it is possible, could you please, help me?
My project is a university radio app.
I read all your Xamarin tutorial. However it very complex for me.
My project sample: http://prntscr.com/okdd0o
it's very basic. is this possible?
can you prepare a basic example for me?

This is not how open source works. Look into the api because all of this is possible.


After pod install, iOS builds crash with Hermes error

Description
Freshly initialized React Native 0.71.10 apps crash on launch on iOS.
Initially the app builds and runs normally. After running cd ios && pod install without any code changes, subsequent builds crash on launch. XCode reports the following error:
dyld[2954]: Library not loaded: @rpath/hermes.framework/hermes
  Referenced from: <45A0F285-C9B4-3D3D-BAA8-C5DE3720BC5F> /private/var/containers/Bundle/Application/EC6701AD-7515-478C-8233-EEFAF7553CEB/AwesomeProject.app/AwesomeProject
  Reason: tried: '/usr/lib/swift/hermes.framework/hermes' (no such file, not in dyld cache), '/private/preboot/Cryptexes/OS/usr/lib/swift/hermes.framework/hermes' (no such file), '/private/var/containers/Bundle/Application/EC6701AD-7515-478C-8233-EEFAF7553CEB/AwesomeProject.app/Frameworks/hermes.framework/hermes' (no such file), '/usr/lib/swift/hermes.framework/hermes' (no such file, not in dyld cache), '/private/preboot/Cryptexes/OS/usr/lib/swift/hermes.framework/hermes' (no such file), '/private/var/containers/Bundle/Application/EC6701AD-7515-478C-8233-EEFAF7553CEB/AwesomeProject.app/Frameworks/hermes.framework/hermes' (no such file), '/System/Library/Frameworks/hermes.framework/hermes' (no such file, not in dyld cache)
(lldb)

React Native Version
0.71.10
Output of npx react-native info
System:
    OS: macOS 13.3.1
    CPU: (8) x64 Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz
    Memory: 27.77 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.2.0 - /var/folders/zv/sd_qzsgx6fn_v27yw7vgxk5r0000gn/T/yarn--1686277911697-0.0021091664228336526/node
    Yarn: 1.22.4 - /var/folders/zv/sd_qzsgx6fn_v27yw7vgxk5r0000gn/T/yarn--1686277911697-0.0021091664228336526/yarn
    npm: 9.6.6 - ~/.nvm/versions/node/v20.2.0/bin/npm
    Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK:
      API Levels: 28, 29, 30, 31, 33
      Build Tools: 30.0.2, 30.0.3, 31.0.0, 33.0.0
      Android NDK: Not Found
  IDEs:
    Android Studio: 2022.2 AI-222.4459.24.2221.9862592
    Xcode: 14.3/14E222b - /usr/bin/xcodebuild
  Languages:
    Java: 15.0.2 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.10 => 0.71.10
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce

Follow standard React Native CLI Quickstart instructions to initialize a fresh CLI app, e.g. npx<EMAIL_ADDRESS>init AwesomeProject
Open ios/AwesomeProject.xcworkspace and build the app.
The app builds and runs normally.
Do a pod install: cd ios && pod install
Build again.
The app crashes on launch.

Test device is iPhone Xs with iOS 16.4.1
Snack, code example, screenshot, or link to a repository
The example code is just a fresh RN app with no code changes. Repo here just in case:
https://github.com/bbalan/rn-hermes-bug

I was able to fix this by running bundle exec pod install instead of pod install.


[Feature Request]: Support for formulas

Is there an existing issue for the same feature request?

[X] I have checked the existing issues.

Is your feature request related to a problem?
No response
Describe the feature you'd like
When I am analyzing my scientific paper, I found amazingly that ragflow can recognize the formula. However, in the chat windows, the formulas in its answers seem not to be parsed correctly. Hope to add the support to parse the formulas.

Describe implementation you've considered
No response
Documentation, adoption, use case
No response
Additional information
No response

Looking forward to this feature.


use with TypeScript: TS2307 cannot find module 'glea'

Describe the bug
When using GLea in TypeScript, there are no type definitions found, also, the module cannot be found (maybe because the typedefs are not loaded?)
To Reproduce

open up codesandbox.io,
use the Vanilla + TS preset to create a new sandbox
add GLea as a dependency
add. import GLea from 'glea'; to src/index.ts.
note: the demo itself in codesandbox runs, but TS2307 is showing up

Additional resources
I created this example:
https://codesandbox.io/s/codesandbox-glea-helloworld-9b75f?file=/src/index.ts

Seems to work after a reload.  be a codesandbox issue.


Suggestion: consider using React "Native"

I was reading through the docs and intended feature support, and on first appearances I think the web version of React Native could be a good fit. And if there are rough edges that you come across, I'd be interested in smoothing them out.
There's a lot of out-of-box functionality and stronger guarantees. Automatic RTL layout of the chrome GUI (runtime toggle too). Styles are resolved deterministically; your current css-in-js library was based on RNW but doesn't provide this guarantee. The style mechanism also accounts for dynamic styles in the render function, and use outside of React via setNativeProps (roughly equivalent to using findDOMNode and mutating directly). The components also have built in mechanisms for measuring or responding to layout. And plenty more.
If you're interested in looking into it, or have any questions/feedback, I'd be happy to help

Hey @necolas. Thanks for the input. I'm definitely open to it. I actually did some research into react-native-web early on, but ended up deciding to just use React at first because it felt like a more trodden path and just a more basic place to start. Not exactly a super deep technical analysis.
My main concerns with react-native-web are related to support and ecosystem. Will we have access to the same features that come out on standard React? Also, I'm still not super clear on the exact problems it solves assuming we don't care about rendering on mobile. So yeah, I guess I'm interested, but to justify using something other than the mainstream React I need a really clear understanding of the benefits. The deterministic CSS stuff is interesting but seems solvable on its own. Maybe I should take a deeper look. Maybe you can help me understand your view of the trade-offs as well.

Thanks very much for the thoughtful reply. I will indeed give it a closer look. The benefits you mention to indeed sound compelling to me.

And FWIW, I understand that trying new react tools isn't the priority for xray. But as someone who understands the specific requirements of xray, I would be interested in hearing any further thoughts you have, or any issues you might identify, even if it's just exploring in your own time and not for xray. Thanks!

This might be interesting alternative too.
It's a GPU-based (webrender) and there is absolutely no DOM or CSS involved. It's currently a subset of react-native with aim to be react-friendly cross-platform UI for desktop applications (not there yet at all).


Custom Biomes O Plenty Trees Drop Incorrect Saplings - Sapling Metadata not read properly?

Hi there! Firstly, thank you for providing us with this super useful mod. My players and I love it.
Bonsai Trees version: bonsaitrees-1.1.2-b144
Forge version: forge-1.12.2-<IP_ADDRESS>38-universal
I am not using Optifine: Not using OptiFine
Screenshot (if possible):
Description of the problem including expected versus actual behavior:
Currently there is support for most BoP trees, but I'm trying to add support for the Sacred Oak and the Ethereal Tree. However, I'm having some issues with them dropping the incorrect saplings.
I expect the Ethereal Tree to drop Ethereal Saplings, but it's dropping Yellow Autumn Saplings. I expect the Sacred Oak Tree to drop Sacred Oak Saplings, but it's dropping Origin Saplings.
It seems to me like the "data" field below the "sapling" > "name" field isn't being correctly read. The Sacred Oak Sapling is "biomesoplenty:sapling_1:7," and the Origin Sapling is "biomesoplenty:sapling_1." The same goes for the other - the Ethereal Sapling is "biomesoplenty:sapling_0:7" and the Yellow Autumn Sapling is "biomesoplenty:sapling_0." All the other drops correctly read the "data" field, but for some reason the sapling doesn't seem to. Or I've done something wrong, which is entirely possible.
Steps to reproduce:
Use the following scripts to add support for the saplings:
Ethereal Tree Type: https://pastebin.com/ttaMiCX1
Ethereal Tree Shape: https://pastebin.com/eYjcwV5b
Sacred Oak Type: https://pastebin.com/w1ZySrAu
Sacred Oak Shape: https://pastebin.com/sspim5vm (I need to redo the model so it's smaller and less janky, this is a wip)
Then, place them in a Pot and wait for them to drop Saplings.
Thanks for your help!

Hey, so both of those saplings have 7 as meta-data.
Both your type definitions say they drop the sapling with 0 as meta-data, so you get the wrong saplings.
It should work once your type.jsons say "data": 7 for the saplings.

Oh my goodness I'm a big ol dummy, I see the issue. I configured the top sapling data correctly but totally spaced on the dropped sapling. facepalm I really need a second pair of eyes, haha.
Thanks so much for your help, I'm very sorry to trouble you with my mistake.


Support of an alternative transactional email services? (Post Mandrill)

Hi,
since Mandrill will close down soon, I wanted to ask if you consider supporting an alternative transactional email service?
I love Djrill and it has done an awesome service for the last few years! Would love continue using it with an alternative service.

The short answer is, yes!
I started looking at this a few days ago. I think it's possible to create a set of interchangeable Django email backends that make it (relatively) easy to switch between transactional ESPs. The new backends would provide a normalized Django API to some common ESP functionality, like attaching metadata to a message, delivery webhooks, etc.
Initially, I'm looking at Mailgun, Postmark and SendGrid (as well as continuing support for Mandrill, to the extent possible). It looks like all of those ESPs support:

All of the standard email features (from & reply-to, to/cc/bcc, subject, custom headers, html/text bodies, attachments, inline images)
Some level of tagging and attaching metadata to sent messages
Delayed sending (Mandrill's send_at)
Open tracking and (except for Postmark) click tracking
Delivery webhooks (e.g., sent, bounced, rejected)
Event tracking webhooks (e.g., opened)
Inbound email webhooks

So I think the new email backends can easily offer all those features.
Templates will be a little trickier. All the ESPs support some version of templates and merge vars, but there's a lot of variation in approaches. Some support per-recipient merge vars, some support global merge vars (substituted in all messages in the batch), and some support both models. The new backends can normalize some of this, but using templating across ESPs won't be as easy as with the other features listed earlier.
Also, each ESP uses its own template syntax, so moving your templates to another ESP will require some manual porting. (Of course, if you've used Django templates for your Djrill email, none of this will be a problem.)
I'm pulling the basic project together now, and expect to have something people could start playing with (and contributing to) by early next week. Given the short timeframe in Mandrill's announcement, my goal is to get the new backends to at least beta quality as quickly as possible.
In the meantime, for any Djrill users reading this, it would help to know if:

there are specific Djrill features you rely on that I didn't mention above
you're using a version of Django earlier than 1.8
there are other transactional ESPs you'd consider important for the initial release

:heart: :heart: :heart:

For me, the best alternative is the Sendgrid, because it is free with 12k emails and have almost the same features, i will be using it for now in my non-django projects.

thanks for the great news @medmunds!
For me personally any of the mentioned providers are fine. I have no personal preference. Almost all of them have a free quota which I haven't max out yet. I have only a low volume of emails and these are usually template free account confirmation / password reset mails...
I would be happy to beta test and provide feedback!

just to chime in, I'd like to throw in another vote to prioritize the sendgrid backend

OK, it took a little longer than I intended, but an initial version of django-anymail is up on GitHub and PyPI. Thanks for your patience.
Anymail should feel pretty familiar to Djrill users. There are a few notes on migrating in the docs.
Right now, Anymail supports Mandrill and Mailgun, simply because they're both requests-based APIs. A lot of the heavy refactoring was covered by that work, so I hope the other ESPs can go quicker.
I'm starting the SendGrid implementation even as we speak.
Suggest we take further discussion over to that project. I've started sequencing some of the remaining work into milestones in Anymail's issues, and there are at least a couple of areas where additional input would be helpful.

SendGrid support is now up on PyPI.

This is really really amazing, thank you!

Thanks, appreciate it.
Postmark support is up now, too, and I'm feeling (perhaps foolishly) confident enough to call Anymail an 0.1 release. (You know, without the "dev" part.)
I'm also dogfooding Anymail on my own side project. I'm using SendGrid (they seem to have a lot of the analytics features that I liked from Mandrill), but after digging in deep while implementing Mailgun and Postmark in Anymail, I really don't think you could go wrong with any of those three.

Thank you for doing this @medmunds!! I don't mind paying for things but $40 a month for low volume transactional email usage is just silly. Glad to see the flexibility with this well-designed backend.

Continuing this discussion over at django-anymail.


Unnecessary options in jest configuration file

https://github.com/pankod/next-boilerplate/blob/02230f3cbfcf5a1cf796c5c6789baaa8ff9ae527/jest.config.js#L2
https://github.com/pankod/next-boilerplate/blob/02230f3cbfcf5a1cf796c5c6789baaa8ff9ae527/jest.config.js#L3
these rules are set by default by jest configuration, and are more inclusive in some cases if you use the __test__ pattern folder or if you reference the json file in any of your tests.
moduleFileExtensions [array]
Default: ["js", "json", "jsx", "ts", "tsx", "node"]
testMatch [array]
(default: [ "**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).[jt]s?(x)" ])

@cristian05 Hi,
Thank you for reaching us! You are right, we've fixed. (8acebc337fc3954421ca7669aba1e9a59bd8fcb2)


Add voltage measurements from envoy

It also reads the individual lines, if the're there.


Encourage py3.x instead of py2.x installation

On one of the first few pages of newcoder.io , it suggests py2.7 installation. It would be great if new coders starts with py3.x instead. It's a radical move but it's a step towards PEP 0404 and  http://blog.startifact.com/guido_no.jpg =)

@alvations this would require a complete update for all the tutorials as they were originally written for 2.x.
I'm going to go ahead and close this since there are a few issues to already track 3.x development.


Results page doesn't scroll anymore

After adding collapsible sections, the ability to scroll is gone.

@jack-elliott I'm not able to replicate this bug. Can you let me know which phone this is happening on?

The current version/phone I am using seems to be scrolling. I don't know if it was user error or what but I'll keep you posted if it shows back up.


Evaluate GENAPP Customer Lookup REST APIs

@torimcc commented on Thu Nov 05 2020
Looking to see if the GENAPP REST APIs supports patient eligibility check and claims submissions

@dixonwhitmire commented on Fri Jan 15 2021
Issue moved to LinuxForHealth/connect #352 via ZenHub

We will review the "customer lookup" API that ships with the default GenApp installation. We can use this API to do a simple lookup which we can integrate within our eligibility demo.

We will review the "customer lookup" API that ships with the default GenApp installation. We can use this API to do a simple lookup which we can integrate within our eligibility demo.

We have located the "lookup by id" endpoint and are checking to see if the API supports a demographic field based search.
It would be helpful if we could search by first name, last name, and birth date, as that models a "real world" eligibility check. If this type of search is not supported, I will do a bit of mapping and parsing so that we can use the x12 270 member id as lookup for the GenApp customer ID.

We have located the "lookup by id" endpoint and are checking to see if the API supports a demographic field based search.
It would be helpful if we could search by first name, last name, and birth date, as that models a "real world" eligibility check. If this type of search is not supported, I will do a bit of mapping and parsing so that we can use the x12 270 member id as lookup for the GenApp customer ID.


Add optional parameter for window height

If g:clam_winheight is set, the output buffer will resize itself
horizontally to the desired height.

Merged, thanks (Github isn't showing it because hg-git screwed up somewhere, but it's there).
I also added g:clam_winwidth because I always use vertical splits.


handle servers that omit a space after a colon in response headers

Example URL: "http://ice2.somafm.com/dronezone-128-mp3"
$ curl -i http://ice2.somafm.com/dronezone-128-mp3
HTTP/1.1 200 OK
Content-Type: audio/mpeg
Date: Wed, 03 Jul 2024 21:17:04 GMT
icy-br:128
...

If possible please tag a release after merging this example, it's required for an in progress guide.

Should we add a test, to make sure it doesn't accidentally get reset?


core.missing typing

I have not finished the following yet. I am posting this as a draft PR to solicit feedback about typing philosophy/style, in particular about the balance between permissive typing (Union[...]) versus overloading versus substantive code changes.

[ ] Adding type hints + mypy comments to missing.py
[ ] Code-affecting changes to core/missing.py module to create type consistency
[ ] Adding/editing typing comments of modules called by missing.py (as guided by mypy) but no code-affecting changes
[ ] Adding Pandas to mypy ignore

Lots of type hints are np.ndarray, have you checked if this is indeed the only allowed argument and no Duckarrays or > Thank you for this PR. This topic is a complicated endeavor, trying to type such deeply internal stuff.
Unfortunately I think some more work had to be put into it. The pandas stubs are just one part. Lots of type hints are np.ndarray, have you checked if this is indeed the only allowed argument and no Duckarrays or dask Arrays etc. are allowed?

Thanks for the detailed feedback! I think I have a big-picture question about how typing is intended to develop. I was viewing this PR as a delta towards there being more documentation of this module, subject to maybe the behaviors in the documentation and testing modules. However if type hints are going to be viewed as a contract to which future users/developers will ascribe a high degree of credence, or if adding them can break things in some way that I'm not aware of, I'm not in a position to provide that.

I didn't want to discourage you, we are able to help and guide you in this PR. I'm currently on mobile only, so it might take some weeks from my side.
Unfortunately many developers are not super familiar with static typing and the past has shown that there are rarely any changes on existing type hints on internal stuff.
This means we should try to get it as right as possible on the first try, otherwise it will lead to issues later on when people try to adhere to the type hints not knowing that the method actually can do more (e.g. support dask Arrays when the type hints says np.ndarray only).
If any other developer disagrees with that statement, please say so.
So again, we appreciate this PR and are willing to support you to get this in shape.

Thanks, that makes sense. Appreciate the support and feedback!

@headtr1ck Thanks again for your help with this. I had two additional questions.

I'm trying to use DuckArrays (T_DuckArray) when only DuckArray methods are required for the function to run, however it seems that python rejects covariant types as function parameters for functions that are not methods I guess due to dangers of corrupting any resulting generic types. So I'm not sure the best way to indicate that Duck Arrays are supported.

There are also some instances where Vairable, DataArray, and Dataset are all supported but not more numpy-like arrays, can't find an alread-defined class that describes this behavior. I guess the shared behavior has something to do with support for indexing?


Add support for realtime log config to ordered_cache

what
This PR adds realtime log config support for additional cache behaviours (Similar to #162 which added default cache behaviour)
references
#162 - Added realtime_log_config_arn for default cache behaviour

/terratest

Sorry, @mschfh , it looks like the README needs to be rebuilt. Please run
make init
make readme

and push the updated *.md files.

/terratest


What is the exe_path property used for?

I'm trying to upload a Mac build but there's no exe. When I used .app, Steam SDK fails:
Couldn't read file 'E:\InstalledPrograms\UnityCloudBuildSteamUploader\Steamworks_SDK\content\academia_academia-mac_content\Academia.app'
DRM wrap failed with EResult 9 (File Not Found)

As a work around, I made a new publish batch file and removed DRM wrapping in it. I then used this file in Upload-SteamContent.ps1.

Hi @marnel-estrada thanks for the bug report. The exe_path is used by the Steam DRM wrapper. I'm guessing for mac builds you could provide the .app file, but I haven't tried. I think removing the DRM functionality with a new script makes sense.
If you'd like to work with me to come up with a more data-driven, generic solution I'd love your help.

For Mac builds, the .app is not really a file. It's a folder. I don't know how DRM wrapping works in Mac.
Maybe provide an option to opt for DRM wrapping or not. This could just be added in BuildUploader.Console.exe.config. A boolean variable will suffice.

I've removed DRM support from the latest version as it seems the command line options changed. If you'd like to contribute some changes to improve mac support more generally, that'd be great!


Fix start Docker on boot and no sudo

fixes docker service on node restart and adds Vagrant user to the Docker group. fixes #22
Signed-off-by: Kendrick Coleman<EMAIL_ADDRESS>

Perfect, thank you!


Unable to deactivate workflow when its deployment has an incident

Should likely be done by clearing the incident and stop the running instance. Not really require deactivating it. However, deactivation is prevented when there is an incident of a running instance.
NOTE
This issue has been mitigated by the ability to remove incidents from workflow instances in the camunda dashboard.

This is solved in mod-workflow via: https://github.com/folio-org/mod-workflow/pull/95


31 all inputs rerender on values change

Closes #31
Changes

remove form values/errors/keys from context
configure a react native friendly event emitter
create a useFormField hook

Steps to Test

[ ] add console logs to the example web Input component
[ ] verify that when a single input changes, other inputs are unimpacted

@mauleb do you still want me to review this lol


serialization: add flag with gnark version in serialized objects

add check at deserialization to ensure version matches.

This concern all gnark objects (constraint system, proving / verifying keys) --> if the data structure changes or some underlying serialization protocol is updated, there is currently no way to gracefully migrate or detect it.

Fixed in feat/debugstack


fix type checking with qcodes 019 and pyvisa 1.11

@farbo this should get the ci to pass with the newest qcodes version

Thanks @jenshnielsen

@farbo can you review and approve?

@jenshnielsen
Sure

@jenshnielsen
LGMT


Recommend user to use "G17" for round-trip converting for double numbers.

Today we're suggesting user to use "R" for round-trip converting for double numbers.
https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings (See The Round-trip ("R") Format Specifier)
https://msdn.microsoft.com/en-us/library/kfsatb94(v=vs.110).aspx
However, double.ToString("R") will introduce a bug caused by its design: https://stackoverflow.com/questions/24299692/why-is-a-round-trip-conversion-via-a-string-not-safe-for-a-double
Generally speaking, "R" specifier tries to convert double to string in 15 digits precision first. If the precision is not enough for round tripping, it goes to convert in 17 digits precision. However, for some numbers (e.g. 0.84551240822557006) it would wrongly pick 15 digits precision (we should pick 17 digits), which cannot guarantee round-trip.
The documents listed above have warnings for users and suggest users to use "G17" if the code compiled using /platform:x64 or /platform:anycpu. This is less useful for real-world users. Because users are almost going to use "R" at first time. Later when they find a bug on production they would be frustrated.
After discussed in https://github.com/dotnet/coreclr/pull/13140 , considering the comparability, we decide to not change the current behavior of "R" specifier, but we need to update the document to RECOMMEND user to use "G17" for round-tripping instead of using "R".

I'm not opposing your suggestion, in fact, I highly welcome adding this detail, knowing that I have, on different occasions, fallen for the trap of using only "R".
However, I would like to suggest adding a note, or even a code example, that shows how to get the minimal exact representation. That is, try 15 digits precision, test roundtrip, if fail, try 16 digits precision, if fail, try 17 digits precision (always succeeds).
It may also be worth mentioning that there is no built-in way to get a minimal roundtrippable representation in scientific notation (both "R" and "G" only switch to scientific if they have to). The above solution can be used to find a similar value with the "E" format specifier.
As an example, the number in your post, 0.84551240822557006, is roundtrippable with 16 digits of precision: 0.8455124082255701, which you will get with "R16" or "E15" (the latter is one lower, as it the number 15 here indicates the number of digits after the decimal point). An example that is only roundtrippable with 17 digits of precision is 1.0000000000000002.
It may be worthwhile to include such numbers as examples.

try 15 digits precision, test roundtrip, if fail, try 16 digits precision, if fail, try 17 digits precision (always succeeds).

Do we have a real world example that needs to find the exactly minimal round-trippable precision for a specific number?

An example that is only roundtrippable with 17 digits of precision is 1.0000000000000002.
It may be worthwhile to include such numbers as examples.

It would be good to describe the reason why we choose G17 specifier to guarantee the roundtrip. cc
@rpetrusha who is working on this issue.

Do we have a real world scenario that needs to find the exactly minimal round-trippable precision for a specific number?

I can think of at least two. My own real-world scenario, writing compilers. Some language specifications require this (in my case XSLT/XPath). The other one being that it is often required to show a number in the shortest form possible. This is also reflected by the need for specifiers like "G" in the first place (which returns a scientific notation or decimal notation, whichever is shorter).
A third one is, obviously, educational: showing users how this works or can work also shows users how they can implement this for other precisions.
Personally, I have never understood why there is no format specifier that can do this, or why "R" skips from 15 to 17, not testing 16 digits precision. After all, the sum of all numbers requiring 17 digits is exponentially smaller than the sum of all numbers requiring 16 digits. We should not strive to default to the exceptional case, but strive to default to the common case.
Finally, this argument is the same for whether you would return "1.220" or "1.22": the "R" specifier already returns the shortest form in all scenarios, except for 15-17 digits numbers. So adding such an example is basically filling the gap left by a less-than-optimally working "R" format specifier.
Anybody who does not care about "shortest form", but only about roundtrippability, does not need "R" to begin with, they can just use "E50" or something (though obviously, "E16", returning 17 digits precision, is enough).

I've opened PR #3101 to change the recommended format string for round-tripping from "R" to "G17".
Determining the minimal exact representation is outside the scope of the Standard Numeric Format Strings topic, @abelbraaksma. If you feel strongly that you'd like one to be published, please open a separate issue. And if you'd be interested in writing it yourself, contributions are certainly welcome.


Fixing tab character on patent tutorial

Docs Build status updates of commit c5ca972:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

academic-services/graph/tutorial-azure-search-org-patents.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[BUG] Space at the end of replacement string, is not recognized.

Description
Space at the end of replacement string, like in "y ", is not recognized. What appears is "y" instead.
To Reproduce
Use these as trigger:
    {trigger: "x", replacement: "y ", options: "mA"},

Expected Behavior
If we type x we expect it to be replaced with y , but instead it's replaced with y.
Additional Info

The same issue is still present even with regex, ie with "rmA".
This bug mattered because I was interested in a snippet that activates when I press a space, maybe I the trigger alpha  to be replaced with \alpha  for instance, rather than \alpha which would force me to press space twice.

Solution/Workaround
A single final space in replacement, gets turned into zero final spaces.
But two final spaces in replacement, get turned into one final space.
So for example the first snippet here doesn't work, but the second
    // This doesn't work. "x" gets replaced "y".
    {trigger: "x", replacement: "y ", options: "mA"},
    // This fixes it. "z" gets replaced with "w ". Notice the two spaces in the replacement string below.
    {trigger: "z", replacement: "w  ", options: "mA"},

This does not seem to work in regex mode, "rmA", though.

Please see here: https://github.com/artisticat1/obsidian-latex-suite/discussions/222


fix: avoid recording duplicate metrics

Problem:
All metrics are recorded by incrementing counters in a shared dictionary.
As the number of metrics increase, so does the contention among Nginx
worker process to increase those counters increases leading to higher
CPU utilization and potentially will result in a drop in peak RPS.
This also affects the collection phase of metrics where the shared
dictionary needs to be locked for a longer time.
Solution:
Since half of the metrics being recorded are duplicate anyways, those
metrics can be dropped. This doesn't result in any loss functionally
since these metrics can be easily in Prometheus.

Are there any other imminent plans for change? If not should this or include a version bump as well?

@p0pr0ck5
There are plans in the works to introduce a couple of other enhancements in features/performance, which would be nice to include in 0.2.0 (since this one is a breaking change anyway).
It's not yet decided when we will tag a new release, so it's probably better to keep versioning out of scope of this PR.

@p0pr0ck5 Thanks for the review!


Can't find css file and loading js file with css contents - integrating with fullPage.js

Application to reproduce: https://github.com/rafaelsales/rails-assets-fullpage-js-issue
rails-assets and fullpage.js bower package are not working together
How I tried to setup:

Added the following content on Gemfile:

source 'https://rails-assets.org' do
gem 'rails-assets-fullpage.js'
end
```

Added the fullpage.js bower package name on both application.js and application.css

Tried to access localhost on browser and got:

Removed the entry from application.css to see if the js entry at least was working, but got:

Notice it's actually loading the css content in a file that was supposed to be a js

@sheerun could you help me figuring out this?

Hey. Maybe try *=require fullpage.js.js

Doesn't work either. I moved the contents of app/assets of the generated gem rails-assets-fullpage.js to my application and the issue persists. I believe it's an issue on Sprockets. I'm closing this...


ntttcp: init at 1.4.0

Motivation for this change
Packaging a useful network throughput testing tool not currently in nixpkgs.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 137643 run on x86_64-linux 1

1 package built:

ntttcp


Don't override global warnings filter

Description
Currently import mxnet causes warnings.filterwarnings('default', category=DeprecationWarning) to be executed.
This is very bad, as there are valid use cases where our users may have decided to filter out DeprecationWarning and we should not overwrite their configuration.
It is also not always possible for users to change the warnings filter after mxnet has changed it. Consider a package that relies on mxnet (such as https://github.com/dmlc/gluon-nlp ) but also imports third-party packages that may raise warnings. If now gluon-nlp is imported, mxnet will overwrite the warnings filter and the user has no option to change it back to whatever settings he needs before gluon-nlp goes on to import other packages that may raise warnings.
Changes

[X] Don't overwride global warnings.filterwarnings filter

Comments
@szha This breaks our notebooks for KDD18
@Roshrini  Can we get this into mxnet 1.3 please?

This was added in https://github.com/apache/incubator-mxnet/commit/a2730787b1fca896934b61999210fd2445dd87ee
@piiswrong do you mind if we remove it now (ie. merge this PR) given the issues it is causing?


Have 2 checkboxes in the signal settings for each signal: 1 for overview, 1 for the asset details

The publisher profile view should take the "detail view" setting for the publisher, but the "list view" setting for the assets.

This was done


Release file name is wrong

I've gone into releases and found that there is not gost archive but instead it is called go-cve-dictionary.

This PR(https://github.com/vulsio/gost/pull/82) will be revised to gost in the next release.


option '--issue-line-labels' raise an error

I am using version 1.15.2
% github_changelog_generator --version
Version: 1.15.2
I launch the following command line:
% github_changelog_generator --user NASA-PDS --project validate --token TOKEN --configure-sections '{"improvements":{"prefix":"Improvements:","labels":["Epic"]},"defects":{"prefix":"Defects:","labels":["bug"]},"deprecations":{"prefix":"Deprecations:","labels":["deprecation"]}}' --no-pull-requests --issue-line-labels ALL
Using these options:
:date_format=>"%Y-%m-%d"
:output=>"CHANGELOG.md"
:base=>"HISTORY.md"
:issues=>true
:add_issues_wo_labels=>true
:add_pr_wo_labels=>true
:pulls=>false
:filter_issues_by_milestone=>true
:author=>true
:unreleased=>true
:unreleased_label=>"Unreleased"
:compare_link=>true
:exclude_labels=>["duplicate", "question", "invalid", "wontfix", "Duplicate", "Question", "Invalid", "Wontfix", "Meta: Exclude From Changelog"]
:summary_labels=>["Release summary", "release-summary", "Summary", "summary"]
:breaking_labels=>["backwards-incompatible", "Backwards incompatible", "breaking"]
:enhancement_labels=>["enhancement", "Enhancement", "Type: Enhancement"]
:bug_labels=>["bug", "Bug", "Type: Bug"]
:deprecated_labels=>["deprecated", "Deprecated", "Type: Deprecated"]
:removed_labels=>["removed", "Removed", "Type: Removed"]
:security_labels=>["security", "Security", "Type: Security"]
:configure_sections=>"{"improvements":{"prefix":"Improvements:","labels":["Epic"]},"defects":{"prefix":"Defects:","labels":["bug"]},"deprecations":{"prefix":"Deprecations:","labels":["deprecation"]}}"
:add_sections=>{}
:issue_line_labels=>["ALL"]
:max_issues=>nil
:simple_list=>false
:ssl_ca_file=>nil
:verbose=>true
:header=>"# Changelog"
:merge_prefix=>"Merged pull requests:"
:issue_prefix=>"Closed issues:"
:summary_prefix=>""
:breaking_prefix=>"Breaking changes:"
:enhancement_prefix=>"Implemented enhancements:"
:bug_prefix=>"Fixed bugs:"
:deprecated_prefix=>"Deprecated:"
:removed_prefix=>"Removed:"
:security_prefix=>"Security fixes:"
:http_cache=>true
:require=>[]
:user=>"NASA-PDS"
:project=>"validate"
:token=>"hidden value"
Found 24 tags
Fetching tags dates: 24/24
Sorting tags...
Received issues: 196
Filtered issues: 95
Fetching events for issues and PR: 95
Fetching closed dates for issues: 95/95
Fetching SHAs for tags: 24
Associating PRs with tags: 0/0
Generating entry...
Traceback (most recent call last):
13: from /usr/local/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/bin//github_changelog_generator:5:in <main>' 	12: from /usr/local/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator.rb:35:in run'
11: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:56:in compound_changelog' 	10: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:121:in generate_entries_for_all_tags'
9: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:121:in each_pair' 	 8: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:123:in block in generate_entries_for_all_tags'
7: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:92:in generate_entry_between_tags' 	 6: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:39:in generate_entry_for_tag'
5: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:120:in generate_body' 	 4: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:120:in map'
3: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:29:in generate_content' 	 2: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:29:in each'
1: from /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:30:in block in generate_content' /Library/Ruby/Gems/2.6.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:52:in get_string_for_issue': undefined method `line_labels_for' for #GitHubChangelogGenerator::Section:0x00007fef38a03398 (NoMethodError)
I will search if I can correct that in a PR but I don't have prior knowledge of ruby so that might not be easy for me, although the error may not be difficult to correct.

It works in the RubyMine IDE with a fork of the repo. So the error might be related to my deployment or it has been corrected since the version I was using.
I deployed with:
sudo gem install github_changelog_generator

Do you think there is a change that someone can look at this error ? I am not familiar with ruby so that makes it difficult for me to understand what the issue is.
I am having the error on my laptop deployment (macOS) as well as on github action with 'ubuntu-latest' image.
To install, I run the command:
sudo gem install github_changelog_generator
On github action the error message is:
/var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:52:in get_string_for_issue': undefined method line_labels_for' for #GitHubChangelogGenerator::Section:0x00007f40a8857268 (NoMethodError)
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:30:in block in generate_content' 	from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:29:in each'
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:29:in generate_content' 	from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:120:in map'
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:120:in generate_body' 	from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:39:in generate_entry_for_tag'
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:92:in generate_entry_between_tags' 	from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:123:in block in generate_entries_for_all_tags'
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:121:in each_pair' 	from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:121:in generate_entries_for_all_tags'
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:56:in compound_changelog' 	from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator.rb:35:in run'
from /var/lib/gems/2.5.0/gems/github_changelog_generator-1.15.2/bin/github_changelog_generator:5:in <top (required)>' 	from /usr/local/bin/github_changelog_generator:23:in load'
from /usr/local/bin/github_changelog_generator:23:in `'

Hi @tloubrieu-jpl , I'm a novice user of this tool and while looking for documentation came across your issue.
There was a PR that was merged to resolve this, but I also duplicated your error when I used the version from gem install github_changelog_generator.
However, when I forked and cloned the fork, then did the build from my repo and generated the following changelog for your repo--does this look right to you?
# Changelog

## [Unreleased](https://github.com/NASA-PDS/validate/tree/HEAD)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.23.1...HEAD)

**Closed issues:**

- The tool shall verify bundle directories adhere directory naming standards [\#239](https://github.com/NASA-PDS/validate/issues/239) [[requirement](https://github.com/NASA-PDS/validate/labels/requirement)] [[requirement:general-validation](https://github.com/NASA-PDS/validate/labels/requirement:general-validation)]

## [v1.23.1](https://github.com/NASA-PDS/validate/tree/v1.23.1) (2020-05-16)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/1.24.0-SNAPSHOT...v1.23.1)

Improvements:

- Packed\_Data\_Fields and bit fields do not validate as expected [\#209](https://github.com/NASA-PDS/validate/issues/209) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

Defects:

- Incorrect validation of number of records [\#220](https://github.com/NASA-PDS/validate/issues/220) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [1.24.0-SNAPSHOT](https://github.com/NASA-PDS/validate/tree/1.24.0-SNAPSHOT) (2020-05-08)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.23.0...1.24.0-SNAPSHOT)

## [v1.23.0](https://github.com/NASA-PDS/validate/tree/v1.23.0) (2020-05-08)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.22.4...v1.23.0)

Defects:

- validate v1.22.3 has large performance degradation on products with many tables [\#219](https://github.com/NASA-PDS/validate/issues/219) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Software raises a field\_value\_overlap error on Table\_Binary Packed data fields [\#177](https://github.com/NASA-PDS/validate/issues/177) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[medium](https://github.com/NASA-PDS/validate/labels/medium)] [[requirement-needed](https://github.com/NASA-PDS/validate/labels/requirement-needed)]

**Closed issues:**

- Reduce error messages for overlapping fields [\#222](https://github.com/NASA-PDS/validate/issues/222) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[requirement-needed](https://github.com/NASA-PDS/validate/labels/requirement-needed)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Throw warning when data exists after number of records [\#215](https://github.com/NASA-PDS/validate/issues/215) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[requirement-needed](https://github.com/NASA-PDS/validate/labels/requirement-needed)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]

## [v1.22.4](https://github.com/NASA-PDS/validate/tree/v1.22.4) (2020-05-01)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/1.23.0-SNAPSHOT...v1.22.4)

## [1.23.0-SNAPSHOT](https://github.com/NASA-PDS/validate/tree/1.23.0-SNAPSHOT) (2020-04-18)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.22.3...1.23.0-SNAPSHOT)

## [v1.22.3](https://github.com/NASA-PDS/validate/tree/v1.22.3) (2020-04-18)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.22.2...v1.22.3)

Defects:

- Update software to check number of records specified in label matches the records in the table [\#149](https://github.com/NASA-PDS/validate/issues/149) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.22.2](https://github.com/NASA-PDS/validate/tree/v1.22.2) (2020-04-11)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.22.1...v1.22.2)

Improvements:

- Validate Table\_Character groups and their specified lengths match the specified group\_length [\#63](https://github.com/NASA-PDS/validate/issues/63) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)] [[requirement](https://github.com/NASA-PDS/validate/labels/requirement)]

Defects:

- validate outputs an extra '.' [\#214](https://github.com/NASA-PDS/validate/issues/214) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Validate incorrectly fails ASCII\_Integer field that is space-padded \(empty\) in Table\_Character [\#206](https://github.com/NASA-PDS/validate/issues/206) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Assembly plugin non-fatal errors on Windows [\#203](https://github.com/NASA-PDS/validate/issues/203) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Schematron doesn't fire if \<?xml-model ...\> has an extra space at the end [\#201](https://github.com/NASA-PDS/validate/issues/201) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]

## [v1.22.1](https://github.com/NASA-PDS/validate/tree/v1.22.1) (2020-03-28)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.22.0...v1.22.1)

## [v1.22.0](https://github.com/NASA-PDS/validate/tree/v1.22.0) (2020-03-28)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.21.0...v1.22.0)

Improvements:

- Fix schematron parsing bug introduced during performance improvements [\#175](https://github.com/NASA-PDS/validate/issues/175) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Add validated product counter to pass/fail reporting and end summary [\#132](https://github.com/NASA-PDS/validate/issues/132) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

**Closed issues:**

- Change behaviour for printing of "dots" to show progress [\#197](https://github.com/NASA-PDS/validate/issues/197) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Improve installation procedure [\#195](https://github.com/NASA-PDS/validate/issues/195) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Update validate-bundle to include report filepath flag [\#194](https://github.com/NASA-PDS/validate/issues/194) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- CCB-282: Revert validation checks on strict file naming requirements [\#192](https://github.com/NASA-PDS/validate/issues/192) [[high](https://github.com/NASA-PDS/validate/labels/high)] [[pending-scr](https://github.com/NASA-PDS/validate/labels/pending-scr)]
- Update documentation to include more details about how/where to file bug reports [\#187](https://github.com/NASA-PDS/validate/issues/187) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Upgrade to Saxon 9.9.1-7 to fix Schematron bug [\#182](https://github.com/NASA-PDS/validate/issues/182) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.21.0](https://github.com/NASA-PDS/validate/tree/v1.21.0) (2020-03-11)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.20.0...v1.21.0)

Improvements:

- Enhance validate performance to average \<1 second with content validation enabled [\#123](https://github.com/NASA-PDS/validate/issues/123) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)]

**Closed issues:**

- Document new test case for I&T and deliver to I&T engineer [\#130](https://github.com/NASA-PDS/validate/issues/130)
- Document new performance benchmarks [\#129](https://github.com/NASA-PDS/validate/issues/129)
- Develop validate-bundle script for Validation performance improvements using parallelization approach [\#128](https://github.com/NASA-PDS/validate/issues/128) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.20.0](https://github.com/NASA-PDS/validate/tree/v1.20.0) (2020-02-03)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.19.0...v1.20.0)

Defects:

- Memory leak issue has returned after Saxon downgrade [\#183](https://github.com/NASA-PDS/validate/issues/183) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.19.0](https://github.com/NASA-PDS/validate/tree/v1.19.0) (2020-01-31)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.18.2...v1.19.0)

Defects:

- Fix multi-threading bug where reporting finishes prior to threads completing execution [\#180](https://github.com/NASA-PDS/validate/issues/180) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[medium](https://github.com/NASA-PDS/validate/labels/medium)]
- Improve performance when content validation is disabled [\#178](https://github.com/NASA-PDS/validate/issues/178) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.18.2](https://github.com/NASA-PDS/validate/tree/v1.18.2) (2020-01-22)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.18.1...v1.18.2)

Defects:

- Bug with \#149 fix: Product counter is invalid and does not reset after each collection [\#173](https://github.com/NASA-PDS/validate/issues/173) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.18.1](https://github.com/NASA-PDS/validate/tree/v1.18.1) (2020-01-21)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.18.0...v1.18.1)

## [v1.18.0](https://github.com/NASA-PDS/validate/tree/v1.18.0) (2020-01-21)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.17.5...v1.18.0)

Improvements:

- L5.PRP.VA.42	The tool shall average less than 1 second execution time when content validation is disabled. [\#124](https://github.com/NASA-PDS/validate/issues/124) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]

Defects:

- Update validate to allow for empty fields in delimited tables [\#170](https://github.com/NASA-PDS/validate/issues/170) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Content validation multi-threading issue [\#167](https://github.com/NASA-PDS/validate/issues/167) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Spot check bug throws internal\_error when record number is multiple of spot check number [\#165](https://github.com/NASA-PDS/validate/issues/165) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Remove erroneous timing messages from log output [\#160](https://github.com/NASA-PDS/validate/issues/160) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Fix string == comparison issues per vulnerability scan [\#144](https://github.com/NASA-PDS/validate/issues/144) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[low](https://github.com/NASA-PDS/validate/labels/low)] [[security](https://github.com/NASA-PDS/validate/labels/security)]

**Closed issues:**

- Update POM to use PDS Parent POM [\#158](https://github.com/NASA-PDS/validate/issues/158) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Introduce label and array timing metrics logging [\#156](https://github.com/NASA-PDS/validate/issues/156)
- Document new test case for I&T and delivery to I&T engineer [\#127](https://github.com/NASA-PDS/validate/issues/127)
- Document new performance benchmarks [\#126](https://github.com/NASA-PDS/validate/issues/126)
- Implement validation performance improvements [\#125](https://github.com/NASA-PDS/validate/issues/125)
- Validate that Table\_Character/Table\_Binary fields match the field length definitions in the label [\#56](https://github.com/NASA-PDS/validate/issues/56) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.17.5](https://github.com/NASA-PDS/validate/tree/v1.17.5) (2019-10-25)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.17.4...v1.17.5)

Defects:

- Suppress INFO messages related to initial fix for JAXB vulnerability [\#2](https://github.com/NASA-PDS/validate/issues/2) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[low](https://github.com/NASA-PDS/validate/labels/low)] [[security](https://github.com/NASA-PDS/validate/labels/security)]

## [v1.17.4](https://github.com/NASA-PDS/validate/tree/v1.17.4) (2019-10-22)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.17.3...v1.17.4)

Defects:

- Update parent LID integrity checking to fix bug introduced for collection integrity checking [\#146](https://github.com/NASA-PDS/validate/issues/146) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Incorrect help information for --spot-check-data flag [\#145](https://github.com/NASA-PDS/validate/issues/145) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[low](https://github.com/NASA-PDS/validate/labels/low)]

**Closed issues:**

- Validate operational release for Build 10a [\#106](https://github.com/NASA-PDS/validate/issues/106) [[release](https://github.com/NASA-PDS/validate/labels/release)]

## [v1.17.3](https://github.com/NASA-PDS/validate/tree/v1.17.3) (2019-10-16)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.17.2...v1.17.3)

Defects:

- Revisit PDS-605: L5.PRP.VA.36: Check that the LID for a product has the LID of its parent collection product as its base [\#139](https://github.com/NASA-PDS/validate/issues/139) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]

## [v1.17.2](https://github.com/NASA-PDS/validate/tree/v1.17.2) (2019-10-16)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.17.1...v1.17.2)

Defects:

- Update delimited table handling to allow for empty fields [\#137](https://github.com/NASA-PDS/validate/issues/137) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]

## [v1.17.1](https://github.com/NASA-PDS/validate/tree/v1.17.1) (2019-10-15)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.17.0...v1.17.1)

**Closed issues:**

- Update config to include telescopes and facilities telescopes and facilities [\#135](https://github.com/NASA-PDS/validate/issues/135) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]

## [v1.17.0](https://github.com/NASA-PDS/validate/tree/v1.17.0) (2019-10-15)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.15.3...v1.17.0)

Improvements:

- Check that referenced context products are valid [\#45](https://github.com/NASA-PDS/validate/issues/45) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[requirement](https://github.com/NASA-PDS/validate/labels/requirement)]
- Enhance content validation to decrease validation time to \<=50% of current benchmark [\#30](https://github.com/NASA-PDS/validate/issues/30) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Improve pds4.bundle validation performance [\#29](https://github.com/NASA-PDS/validate/issues/29) [[Epic](https://github.com/NASA-PDS/validate/labels/Epic)] [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]

Defects:

- Update Validate error/warning counts per ATM regression testing [\#118](https://github.com/NASA-PDS/validate/issues/118) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[low](https://github.com/NASA-PDS/validate/labels/low)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Registered context product resource lists only one of multiple instrument or target multiple types [\#107](https://github.com/NASA-PDS/validate/issues/107) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Fix bug introduce by --skip-context-validation feature [\#99](https://github.com/NASA-PDS/validate/issues/99) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Update Validate to allow specification of schema/schematrons in config file [\#84](https://github.com/NASA-PDS/validate/issues/84) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Context validation needs to be updated to include all possible product type use cases [\#62](https://github.com/NASA-PDS/validate/issues/62) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Update content validation to fail when the value of an ASCII\_Integer is all spaces [\#9](https://github.com/NASA-PDS/validate/issues/9) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Large Data File Uncaught Exception Error [\#8](https://github.com/NASA-PDS/validate/issues/8) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[low](https://github.com/NASA-PDS/validate/labels/low)]
- JAXB warning message with Java 9+ [\#3](https://github.com/NASA-PDS/validate/issues/3) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[low](https://github.com/NASA-PDS/validate/labels/low)]

**Closed issues:**

- Deprecate --no-data-check to --skip-content-validation to fall in line with other argument naming [\#133](https://github.com/NASA-PDS/validate/issues/133) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Revert name/type checks from context validation until discussed with TWG [\#120](https://github.com/NASA-PDS/validate/issues/120)
- Validate release candidate for Build 10a [\#105](https://github.com/NASA-PDS/validate/issues/105)
- Update context name check to throw WARNING instead of ERROR [\#102](https://github.com/NASA-PDS/validate/issues/102) [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Create new "error message decoder ring" for common validate issues and how to solve them [\#97](https://github.com/NASA-PDS/validate/issues/97) [[high](https://github.com/NASA-PDS/validate/labels/high)] [[triage-needed](https://github.com/NASA-PDS/validate/labels/triage-needed)]
- Update context checks to include data\_to\_investigation [\#90](https://github.com/NASA-PDS/validate/issues/90) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Update validate to apply catalog file and local schemas to discipline schema resolution [\#87](https://github.com/NASA-PDS/validate/issues/87) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Update validate to apply catalogs/schemas used as input across all ingested schemas [\#86](https://github.com/NASA-PDS/validate/issues/86)
- Test and document benchmark metrics from improved content validation [\#80](https://github.com/NASA-PDS/validate/issues/80)
- Implement content validation performance improvements [\#79](https://github.com/NASA-PDS/validate/issues/79)
- Investigate and determine potential content validation performance improvements [\#78](https://github.com/NASA-PDS/validate/issues/78)
- Add new target-manifest flag for user to provide a manifest \(file\) of file/directory paths to validate [\#50](https://github.com/NASA-PDS/validate/issues/50) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[requirement](https://github.com/NASA-PDS/validate/labels/requirement)]
- Add flag to temporarily disable context validation [\#47](https://github.com/NASA-PDS/validate/issues/47) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Document multi-threaded architecture for maximized performance [\#43](https://github.com/NASA-PDS/validate/issues/43) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Perform benchmarking on validate to enable documenting of system requirements [\#41](https://github.com/NASA-PDS/validate/issues/41) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Improve documentation about usage of flags in config file with latest flags [\#20](https://github.com/NASA-PDS/validate/issues/20) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Verify that all name/type attribute values correspond to names denoted context products [\#15](https://github.com/NASA-PDS/validate/issues/15) [[requirement](https://github.com/NASA-PDS/validate/labels/requirement)]

## [v1.15.3](https://github.com/NASA-PDS/validate/tree/v1.15.3) (2019-08-20)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.15.2...v1.15.3)

Defects:

- Validate execution script throws arguments error with v1.15.1 [\#74](https://github.com/NASA-PDS/validate/issues/74) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

## [v1.15.2](https://github.com/NASA-PDS/validate/tree/v1.15.2) (2019-08-19)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/v1.15.1...v1.15.2)

Defects:

- Catalog file flag expects a List of files requiring it not be the last argument [\#72](https://github.com/NASA-PDS/validate/issues/72) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Unable to use catalog file after update to always force remote schemas [\#71](https://github.com/NASA-PDS/validate/issues/71) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]

**Closed issues:**

- Update pom to exclude additional SLF4J bindings [\#70](https://github.com/NASA-PDS/validate/issues/70)
- Complete engineering point build 1.15.1 [\#64](https://github.com/NASA-PDS/validate/issues/64) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Add capability to pds4.bundle validation to ignore product-level validation [\#42](https://github.com/NASA-PDS/validate/issues/42) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]

## [v1.15.1](https://github.com/NASA-PDS/validate/tree/v1.15.1) (2019-08-08)

[Full Changelog](https://github.com/NASA-PDS/validate/compare/6703364685bd0f55e3521491f29589cd801fa6f6...v1.15.1)

Defects:

- Content validation does not work properly [\#55](https://github.com/NASA-PDS/validate/issues/55) [[bug](https://github.com/NASA-PDS/validate/labels/bug)]
- Incorrect package declarations under gov.nasa.tools.web.ui [\#52](https://github.com/NASA-PDS/validate/issues/52) [[bug](https://github.com/NASA-PDS/validate/labels/bug)]
- JAVA Path does not handle whitespaces in MAC as it used to [\#37](https://github.com/NASA-PDS/validate/issues/37) [[bug](https://github.com/NASA-PDS/validate/labels/bug)]
- Add missing core.properties dependency [\#34](https://github.com/NASA-PDS/validate/issues/34) [[bug](https://github.com/NASA-PDS/validate/labels/bug)] [[high](https://github.com/NASA-PDS/validate/labels/high)]
- Validation succeeds despite throwing exception [\#33](https://github.com/NASA-PDS/validate/issues/33) [[bug](https://github.com/NASA-PDS/validate/labels/bug)]

**Closed issues:**

- Update Maven docs to refer to Github release assets [\#65](https://github.com/NASA-PDS/validate/issues/65) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Investigate and fix memory leak causing validate crash on large bundles [\#39](https://github.com/NASA-PDS/validate/issues/39) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Prepare repository for Maven Central deployment [\#31](https://github.com/NASA-PDS/validate/issues/31) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Add capability for user to input JSON file with additional context products [\#28](https://github.com/NASA-PDS/validate/issues/28) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Update build per pds4-tools rename and open source [\#26](https://github.com/NASA-PDS/validate/issues/26) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Update context check to retrieve and use latest context products from EN Registry [\#24](https://github.com/NASA-PDS/validate/issues/24) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)] [[requirement](https://github.com/NASA-PDS/validate/labels/requirement)]
- Deprecate -f and -m flags [\#23](https://github.com/NASA-PDS/validate/issues/23) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Update pom and readme to reference public docs [\#21](https://github.com/NASA-PDS/validate/issues/21) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]
- Remove references to PDS Maven Repo and update packages to build without it [\#19](https://github.com/NASA-PDS/validate/issues/19) [[enhancement](https://github.com/NASA-PDS/validate/labels/enhancement)]

\* *This Changelog was automatically generated by [github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)*

Thanks @jason-upchurch . Actually I expected a changelog with labels from the github issues to appear directly in the md file thanks to the option  --issue-line-labels ALL
My full command is the following:
% github_changelog_generator --user NASA-PDS --project validate --token TOKEN --configure-sections '{"improvements":{"prefix":"Improvements:","labels":["Epic"]},"defects":{"prefix":"Defects:","labels":["bug"]},"deprecations":{"prefix":"Deprecations:","labels":["deprecation"]}}' --no-pull-requests --issue-line-labels ALL
That is when I had this option that the error was raised.
If you have the chance to look at that again, let me know if you used the option --issue-line-labels ALL in your test. I will also try again on my side.
Thanks again. That is very nice of you to have tried that.

@tloubrieu-jpl did you preview the rendered markdown from my post? When I preview it, I see the following with the labels included in brackets:

I used the same command with my own GitHub token inserted, but everything else was the same. I think the issue is with the version available in the default gem, but honestly that's a total guess. I only got it working by building and installing locally.

Oh, thank you very much, that is perfect. Actually I missed to scroll horizontally to see the label in your initial post. Sorry about that.
So, now, I am using the changelog tool in github actions, so I would need to deploy the tool from the source on git to make that work instead of using the gem install utility.
Is the fact this option does not work with gem install due to the pull request merged is not available yet in a released package ?
Thanks again,
Thomas

@tloubrieu-jpl,
No problem at all! I'm glad it worked :) I'm  finding the tool useful and mainly just trying to figure it out as well.

Is the fact this option does not work with gem install due to the pull request merged is not available yet in a released package ?

I'm not a maintainer/contributor,  but that was exactly my question too. Release of the package may not be timed with merging to master?
The workflow I think I used was to clone the repo and
github-changelog-generator$ gem build github_changelog_generator.gemspec

then
validate$ gem install --local <path to .gem file created from prior step>
If this doesn't work, maybe we could iterate in this issue to document a workaround for others.

@tloubrieu-jpl I also opened this issue to ask the higher-level question:
https://github.com/github-changelog-generator/github-changelog-generator/issues/885
--Jason

Thanks @jason-upchurch .  I think our solution might include the creation of a custom github-action which in this case will do the git clone and everything needed after.
This github action will be re-usable (possibly published on the github market place) but it will likely contain some other stuff which can be more specific to our project (and less interesting for others).
I'll let you know on this ticket how it goes.

Hello, gentlemens. Thank you for a productive conversation. I'm happy that you found a workaround.
I will have a look into the released version and will update it new few das (not with my own dev laptop right now).
ps. if someone can help to deploy github action: I would be much appreciated.

Hello @skywinder! I just checked, and it appears that the problem still occurs--just a side note that I think this project is awesome and I use and promote it! Nice work!
I'm not sure how your deploy pipelines work, but it seems to me (perhaps naively) that the fixed code on the master branch is not not in sync with what is installed with gem install github_changelog_generator (I opened issue #885 to ask about that).
$~/projects/validate$ gem install github_changelog_generator
Successfully installed github_changelog_generator-1.15.2
Parsing documentation for github_changelog_generator-1.15.2
Done installing documentation for github_changelog_generator after 0 seconds
1 gem installed
$~/projects/validate$ github_changelog_generator --user NASA-PDS --project validate --token $GITHUB_TOKEN --configure-sections '{"improvements":{"prefix":"Improvements:","labels":["Epic"]},"defects":{"prefix":"Defects:","labels":["bug"]},"deprecations":{"prefix":"Deprecations:","labels":["deprecation"]}}' --no-pull-requests --issue-line-labels ALL
Using these options:
:date_format=>"%Y-%m-%d"
:output=>"CHANGELOG.md"
:base=>"HISTORY.md"
:issues=>true
:add_issues_wo_labels=>true
:add_pr_wo_labels=>true
:pulls=>false
:filter_issues_by_milestone=>true
:author=>true
:unreleased=>true
:unreleased_label=>"Unreleased"
:compare_link=>true
:exclude_labels=>["duplicate", "question", "invalid", "wontfix", "Duplicate", "Question", "Invalid", "Wontfix", "Meta: Exclude From Changelog"]
:summary_labels=>["Release summary", "release-summary", "Summary", "summary"]
:breaking_labels=>["backwards-incompatible", "Backwards incompatible", "breaking"]
:enhancement_labels=>["enhancement", "Enhancement", "Type: Enhancement"]
:bug_labels=>["bug", "Bug", "Type: Bug"]
:deprecated_labels=>["deprecated", "Deprecated", "Type: Deprecated"]
:removed_labels=>["removed", "Removed", "Type: Removed"]
:security_labels=>["security", "Security", "Type: Security"]
:configure_sections=>"{\"improvements\":{\"prefix\":\"Improvements:\",\"labels\":[\"Epic\"]},\"defects\":{\"prefix\":\"Defects:\",\"labels\":[\"bug\"]},\"deprecations\":{\"prefix\":\"Deprecations:\",\"labels\":[\"deprecation\"]}}"
:add_sections=>{}
:issue_line_labels=>["ALL"]
:max_issues=>nil
:simple_list=>false
:ssl_ca_file=>nil
:verbose=>true
:header=>"# Changelog"
:merge_prefix=>"**Merged pull requests:**"
:issue_prefix=>"**Closed issues:**"
:summary_prefix=>""
:breaking_prefix=>"**Breaking changes:**"
:enhancement_prefix=>"**Implemented enhancements:**"
:bug_prefix=>"**Fixed bugs:**"
:deprecated_prefix=>"**Deprecated:**"
:removed_prefix=>"**Removed:**"
:security_prefix=>"**Security fixes:**"
:http_cache=>true
:require=>[]
:user=>"NASA-PDS"
:project=>"validate"
:token=>"hidden value"

/usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/faraday-1.0.1/lib/faraday/dependency_loader.rb:21: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/faraday-http-cache-2.2.0/lib/faraday/http_cache.rb:102: warning: The called method `initialize' is defined here
Found 26 tags
Fetching tags dates: 26/26
Sorting tags...
Received issues: 199
Filtered issues: 99
Fetching events for issues and PR: 99
Fetching closed dates for issues: 99/99
Fetching SHAs for tags: 26
Associating PRs with tags: 0/0
Generating entry...
Traceback (most recent call last):
	15: from /usr/.rbenv/versions/2.7.1/bin/github_changelog_generator:23:in `<main>'
	14: from /usr/.rbenv/versions/2.7.1/bin/github_changelog_generator:23:in `load'
	13: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/bin/github_changelog_generator:5:in `<top (required)>'
	12: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator.rb:35:in `run'
	11: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:56:in `compound_changelog'
	10: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:121:in `generate_entries_for_all_tags'
	 9: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:121:in `each_pair'
	 8: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:123:in `block in generate_entries_for_all_tags'
	 7: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/generator.rb:92:in `generate_entry_between_tags'
	 6: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:39:in `generate_entry_for_tag'
	 5: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:120:in `generate_body'
	 4: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/entry.rb:120:in `map'
	 3: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:29:in `generate_content'
	 2: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:29:in `each'
	 1: from /usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:30:in `block in generate_content'
/usr/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/github_changelog_generator-1.15.2/lib/github_changelog_generator/generator/section.rb:52:in `get_string_for_issue': undefined method `line_labels_for' for #<GitHubChangelogGenerator::Section:0x00007f2411c28af8> (NoMethodError)

Hello @skywinder! I tried going through the documentation in CONTRIBUTING.md but I don't think I know enough to release the fixed version. But I can see by the current CHANGELOG.md that @dusan-dragon 's fix for line_labels_for does not appear to be released yet.
If either of you could walk me through how to contribute by releasing, I would be more than happy to spend time either via video, chat, or messaging here. Please let me know what I can do to help.
Thank you!


Full-screen display (F11 shortcut)

Ok the editor has a distraction free mode with shift+ctrl+2. But I'm still distracted with menu & tabs bar as well as other parts of the window. Why not just add F11 full-screen feature which you are left only with your workspace on the screen? Besides, I use a 13.3" ultrabook and I need every extra pixel of the screen for better handling the screen.

Duplicate of #11594. Should be possible with little fiddling of brackets-shell and updated CEF.

Closing duplicate


Add Travis CI

Travis has to be enabled for the project first a project owner. This PR should do the rest.
gem install travis
travis init

@knrz it would seem that Travis CI hasn't been enabled for this project, yet. I would love to improve the test suite (e.g. by testing on different Elixir versions) but I cannot activate CI as a non-maintainer/-collaborator. Is there any change you could active the project on Travis anytime soon?

Hey dude, how would I add you as a collaborator?

Hey dude, how would I add you as a collaborator?

Much appreciated, thanks!
I just tried it out. Sadly, it doesn't work: not allowed to update service hook for knrz/geocoder. Could you try the following steps? Should only take 1 minute.
$ gem install travis
Successfully installed travis-1.8.8
1 gem installed
$ travis init --force
Main programming language used: |Ruby|  # Chose Ruby. It doesn't recognize Elixir :(
.travis.yml file created!
$ git checkout .travis.yml              # we're using our version

Done amigo :) :+1: Let me know if you need me to do anything else :shipit:

Thanks man 🥇 Travis CI still says it's not active, yet: https://travis-ci.org/knrz/geocoder – can you activate it on that website? (Use the + next to "My repositories")

All set!

Whoop whoop, it works!


Add fixed shadow and dropped pickup positions

Fix enemy shadow position.
Make enemies drop pickups at their origin point, not bounding box centerpoint.

I've tested this branch, and I did not see any meaningful issue.
I saw some anomalies of low importance through that may be related or not to the task of this branch.

When the TR5 Hydra dies, its blob shadow remains in the place. (Hidra code bug?)
When the Big_Scorpion kills a troop, the troop's drop appears under the scorpion. (Animation asset setup?)
When the Small_Scorpion is killed in a 1 click space, it can drops objects there, where Lara can't reach. (Up to the Builder avoid that case)

From my point of view, this could get the green light.