Add support for SNIHostName when using Java8+

Motivation:
Java8 added support for using SNIHostName with SSLParameters. We currently ignore it in OpenSslEngine.
Modifications:
Use reflection to support SNIHostName.
Result:
People using Java8 can use SNIHostName even when OpenSslEngine is used.

@Scottmitch @nmittler @trustin PTAL

@Scottmitch all comments addressed

@normanmaurer any thoughts on just requiring Netty be built with JDK >= 8?

We tried that before but got into trouble because of default methods

Am 17.06.2016 um 16:00 schrieb Nathan Mittler<EMAIL_ADDRESS>@normanmaurer any thoughts on just requiring Netty be built with JDK >= 8?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@normanmaurer - LGTM ... however i guess dropping support for older JDKs that have been EOL for a while now is on the list for the next major version (what ever that is)?


support for headless services for API server

support for headless services for API server (Type:clusterIP;clusterIP:None). In additon this feature also allow to use userdefined clusterIp type service, where user can specify the IP or let Kubernetes choose an IP.
In some scenarios API server can work with headless services.

/assign @pmorie

/ok-to-test

Thanks for review @nilebox. Pushed the suggested changes.

/lgtm


Why does clamAV detect code as Trojan Mirai?

I have downloaded this file

code-stable-1545156735.tar.gz

from https://code.visualstudio.com/#alt-downloads. When I scanned the extracted folder with ClamAV it shows:
VSCode-linux-x64/code: Unix.Trojan.Mirai-5932143-0 FOUND
----------- SCAN SUMMARY -----------
Known viruses: 6672559
Engine version: 0.100.2
Scanned directories: 513
Scanned files: 1195
Infected files: 1
Data scanned: 242.92 MB
Data read: 182.04 MB (ratio 1.33:1)
Time: 59.975 sec (0 m 59 s)
Does anyone also have this problem?

I've just downloaded that exact version and ran clamscan over it. The result was the following:
----------- SCAN SUMMARY -----------
Known viruses: 6756459
Engine version: 0.101.0
Scanned directories: 513
Scanned files: 1195
Infected files: 0
Data scanned: 164.75 MB
Data read: 182.04 MB (ratio 0.91:1)
Time: 25.714 sec (0 m 25 s)

Please make sure you have updated your clam DB.


Microsoft Azure

[Enter feedback here]

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

ID: 2687c250-ac81-3778-428d-7f6616e3d450
Version Independent ID: 265205f9-f472-1021-9684-ee7216ca37a5
Content: Create and Manage an Azure Virtual Machine Using C#
Content Source: articles/virtual-machines/windows/csharp.md
Service: virtual-machines-windows
GitHub Login: @cynthn
Microsoft Alias: cynthn

@BNstar3 thanks for reaching out. If you have specific feedback on this document, please open a new issue and explain how we can help.


libc/impure: Fix the inconsistence from the different toolchain

Summary
some toolchain provider remove const qualifier from global_impure_ptr
(e.g. Espressif) but other provider keep it(e.g. ARM or Cadence), so
let's define const to empty macro to pass the compile and more safety.
Impact
Minor
Testing
Pass CI

But such change influences the _REENT_SMALL case as well. Is that expected?

But such change influences the _REENT_SMALL case as well. Is that expected?

Yes, it's hard to remove const from some variables, but keep const on others. Since it's safe to change the const variables to mutable variables, it's reasonable workaround the compatibility.

But such change influences the _REENT_SMALL case as well. Is that expected?

Yes, it's hard to remove const from some variables, but keep const on others. But it's safe to change the const variables to mutable variables, so it's reasonable workaround the compatibility.

#define const seems to be needed only for reent.h, but can be removed in other places of the C-file. I mean why those are left?

Sorry, I can get your question.

@pkarashchenko let's ignore the wrong ci report, thanks.


Update stata.js

Added a few relatively new commands

Thank you! It's on my list to do a more comprehensive expansion of the command list (and also some day to add auto-complete and contextual help for commands to nbstata) but the more the merrier, meanwhile.


commonName required for AWS PCA

AWS PCA expects the commonName to be passed in as part of the CSR. Adding commonName: istiod.istio-system.svc in the Certificate.yaml file was all that was needed.
spec:
  dnsNames:
  - istiod.istio-system.svc
  uris:
    - spiffe://cluster.local/ns/istio-system/sa/istiod-service-account
  secretName: istiod-tls
  commonName: istiod.istio-system.svc
...

I don't mind creating a PR for this so let me know if that is preferred.

Thanks @bpotaczek! It is surprising to me that this works as the istio workloads themselves using the same Issuer don't have a CommonName set IIRC.

@bpotaczek Can help? I'm getting api error ValidationException: 1 validation error detected: Value '0' at 'validity.value' failed to satisfy constraint: Member must have value greater than or equal to 1 when using AWSPCAClusterIssuer as issuer. the cert manager works fine outside the istio-csr
can you please upload the certificate.yaml and is there any custom values except those?
   issuer:
      # -- Issuer name set on created CertificateRequests for both istio-csr's
      # serving certificate and incoming gRPC CSRs.
      name: private-root-ca
      # -- Issuer kind set on created CertificateRequests for both istio-csr's
      # serving certificate and incoming gRPC CSRs.
      kind: AWSPCAClusterIssuer
      # -- Issuer group name set on created CertificateRequests for both
      # istio-csr's serving certificate and incoming gRPC CSRs.
      group: awspca.cert-manager.io

Thanks

@assafmanzur that looks to be a different error. For testing you can use one of the example certs from the aws-pca project.
https://github.com/cert-manager/aws-privateca-issuer/blob/master/config/examples/certificates/rsa-2048.yaml

Thanks @bpotaczek !  it's actually what I did but maybe I'm missing something in the flow,
I've issuer running in istio-system:
aws-pca-issuer-1629722682-aws-pca-issuer-datorama-io-68d652z7pg
cert manager runs in cert-manger ns and when I'm generating a certificate it generates it successfully
Now, using helm install istio-csr with default setting and only update the values that I've mentioned in my previous comment.
still getting the same results.
failed to request certificate from PCA","certificaterequest":"istio-system/istio-csr-5v67m","error":"operation error ACM PCA: IssueCertificate, https response error StatusCode: 400, RequestID: 081d7ccf-7c23-42f1-b15b-c2aed42e6462, api error ValidationException: 1 validation error detected: Value '0' at 'validity.value

Seems like the format 1h was the issue.. after updating to 1h0m0s the certificate request was updated to true


[5.5] Allow Blade to render multiple verbatim and php blocks

Simple solution for this problem: https://github.com/laravel/framework/issues/21897#issuecomment-340852007
To allow Blade to render raw blocks (@verbatim and @php) in the right order.

This would change the behavior for every existing 5.5 installation that uses both these tags. Isn't this something that should target 5.6?

@sisve could you please proof how the behaviour would be change? Other than fixing the bug, of course.

The bugfix is the changed behavior; blocks are suddenly executed/parsed in another order. This new order may be the "correct" one, but it doesn't change the fact that existing sites will have their views rendered differently.

Is this fixing the literal case of stringing all that stuff on one line like that? Is that the only case we are fixing here?

@taylorotwell no, it can be multilines as well, I added another test to prove it.

@themsaid do you know of any problems with this?

@taylorotwell honestly I believe we'll never get this 100% right :) I don't have a specific problem against this PR but in general most times when we touch this area someone reports a breaking change.

In case it helps, I refactored the code a bit, to show the intention of adding a unique placeholder for each raw block vs the current version which adds the same placeholder for all of them relying they were going to be restored in order (which is no longer the case).

To show the process:
{{ $first }}

@php
    echo $second;
@endphp

@if ($conditional)
    {{ $third }}
@endif

@verbatim
    {{ $fourth }}
@endverbatim

@php echo $fifth; @endphp

Will be temporary transformed to:
{{ $first }}

@__raw_block_1__@

@if ($conditional)
    {{ $third }}
@endif

@__raw_block_0__@

@__raw_block_2__@

Then Blade will compile:
<?php echo e($first); ?>

@__raw_block_1__@

<?php if($conditional): ?>
    <?php echo e($third); ?>

<?php endif; ?>

@__raw_block_0__@

@__raw_block_2__@

Finally the raw blocks will be restored, but as each block has a unique ID placeholder they should be restored in the intended order:
<?php echo e($first); ?>

<?php
    echo $second;
?>
<?php if($conditional): ?>
    <?php echo e($third); ?>

<?php endif; ?>

    {{ $fourth }}

<?php echo $fifth; ?>

How does this work if someone @include another view in the middle of all this stuff?

@taylorotwell the same as @include is roughly a call to View::make and not a merge. I modified the test to prove it.

@dafonso It may be a bug, but it's not blowing things up. People run into it, chants something evil, and then codes a workaround of some kind. This is something the developer will detect when developing.
Changing this now, at 5.5.20 (I presume), is a breaking change that will affect people. I'm sure that I have do not have enough automatic tests that would detect these type of changes in the generated blade views. Do people expect a full manual testing round for the entire application in every 5.5.x release?
What if they didn't even mean to upgrade laravel/framework, but install the sqlite support according to the migration docs, or the ses support according to the mail docs, that tells them to execute composer update which will upgrade all packages?
That's why I think that this issue should target 5.6; there's a higher acceptance for breaking changes and those are documented in upgrade docs that tells people what changed and how to work around it. Those types of instructions are not present in a 5.5.x release, just an entry in a changelog.

@sisve people will expect bugs to be solved in minor releases. It's even in the description of Laravel:
Bug fixes for 2 years, security fixes for 3 years.
You shouldn't develop apps relying on behaviour provided by bugs. A workaround is something different. A woraround means not using the feature with problems, not relying on the bug, for example: using <?php ?> instead of @php @endphp and that has nothing to do with this fix.

@dafonso It may be a bug, but it's not blowing things up.

Yes, it is blowing things up... Why? I upgraded from 5.4 to 5.5.19 a few days ago and one of my views that had @php and @verbatim directives blew up... First I was completely lost as to why, then started debugging... and found the bug that I reported on #21897. Took me some hours to understand it... So I absolutely agree with @sileence last comment.

There is nothing in the docs that states that the current order is wrong. It's reasonable to believe that people will just shrug this off as a weird thing and keep coding. I base this on earlier discussion on the order of rendering/includes of views, sub-views and templates. Or perhaps I base this on the idea that blade comments cannot comment out everything, like @php directives. Or perhaps that blade comments aren't supposed to comment any larger text block at all. My point is that there are many odd things in Blade that you accept and just ignore and move on.
The current behavior was known at the release of Laravel 5.5.

[...] we we cannot rely on the verbatim / raw placeholders to be keep in place like before.

@dafonso Your example involves upgrading a major Laravel version, and things do break in those. As I've mentioned earlier, I believe people spend more time testing their applications in these upgrades than in a 5.5.x+1 upgrade.
Remember, this isn't a week or two after the release. Two months have now passed and we've had 18-19 minor releases since the release this . Do people expect it to change now? Can't it wait until 5.6?
I'm not saying that this isn't a bug, or that this should never be fixed. I'm pointing out the lack of analysis on how this affects existing Laravel 5.5 installations. That's what I do, I am bitter 24/7 and think of ways a PR may affect things that havn't been mentioned in the issue.
This is a breaking change; it can potentially cause other things to fail. That does not mean that it can not be targetting 5.5. That's up to a project manager to evaluate. Breaking changes aren't forbidden in minor releases, we just need to be clear of potential problems and make sure that those are communicated in proper forms (which in this case is at least the changelog).

This is why I cringe every time someone comes up with a shiny new blade directive they want to included the core. Blade has well known limitations and those become more obvious with each new directive. Usually a "fix" breaks something else. If I have code in a blade file that's a little complicated or hard to make work well with blade, I just ditch the directives and move on.
Just giving @sisve a thumbs up.

@sisve alright, it's easy to get lost in a discussion like this one and this could happen in virtually every PR to L5.5. I'd prefer if you or anyone else help having a look at the changes and trying to determine ways this could actually break functionality with actual code examples and tests?
I added several tests and even documented the process. I could still be making a mistake, that's true but in any case it helps if other people read the code, analyse the problem itself and the solution itself.

Can we show a real scenario of how this fix would break an existing Laravel 5.5 application?


Streams 278

resolves https://issues.apache.org/jira/browse/STREAMS-278
note that pigconvertertest.pig now uses StreamsProcessDatumExec rather than StreamsSerializerExec which has been deleted.

:+1:


Allow to set I2C address, reduce prints

Allows to avoid the scan by explicitly providing addr to constructor. Still does scanning by default.
Will only print in case scanning is done or there are failures. Unix style: silence means success, complain loudly on failure

Hi @antirez - any chance for a quick review on this? There should be no changes to default behavior, so should be quite safe to merge (imo)


Difference between SourceCache and SourceList

I read the readme over and over again.  Is this a correct understanding?
With SourceCache, I can add or update SourceCache.  With SourceList, I cannot add, I can only update?
Can someone give me a simple example of creating a SourceCache and subscribe to it so it will add a new item a grid in UI.  I always get a cross thread error.
Really like to use dynamicData, but get stuck here. Please help.

You can find a good description here:
https://dynamic-data.org/2015/08/12/observable-cache-at-a-glance/


_request function uses undefined attributes

BaseReddit does not define the following which appear to be used in _request:
E1101: 439,37: Instance of 'BaseReddit' has no 'refresh_token' member (no-member)
E1101: 442,34: Instance of 'BaseReddit' has no 'is_oauth_session' member (no-member)
E1101: 456,16: Instance of 'BaseReddit' has no 'refresh_access_information' member (no-member)
E1101: 534,46: Instance of 'BaseReddit' has no 'is_oauth_session' member (no-member)

While it works we shouldn't have these issues. The simplest way is to push these values into parameters of the _request method.

How would you go about making these into parameters? The whole thing about the auto-token-refresh is that it happens while you're working on another request. If you go from get_moderators -> request_json -> _request, there isn't any place you can sneak those parameters in without getting the same lint issue. You would have to pass through AuthenticatedReddit at some point or move some inheritance around so that BaseReddit knows about these names ahead of time.
Current thoughts?

Good point. Perhaps we need to do away with our mixin structure for the reddit object. I suppose that'll be fine anyway once everything is OAuth only.

The current class structure definitely helps for organization and searchability, the only problem is the inter-dependency we've created between BR and AR. I don't think there's anything wrong with keeping separate classes for each OAuth scope as long as the real request business is all in once place.
Maybe I misunderstood what you meant, but a mega-class would probably get pretty dense even with good docstrings.

Yes, we can leave the mixins for those that only add new methods. However, we should probably only have a single BaseReddit at some point that contains all the necessary attributes.

This is not a problem in PRAW4.


revisit log in UI

what happens
for me, log in UI is not clear in top left menu that inputting a NIP-05, or npub is expected, and that there is a text input field to the left of the log in button
suggestion
consider adding placeholder text where the text input field is

android:hint="Enter NIP-05 (e.g<EMAIL_ADDRESS>or npub123etc.."
https://stackoverflow.com/questions/8221072/android-add-placeholder-text-to-edittext

Thanks for that, but we're using Flutter! This was fixed yesterday before release


[atom-reason] fix several highlighting issues

Note this doesn't address #827 yet which I will respond to later.

handle more attributes/extension nodes
fix value highlighting in attributes
fix conditional operators in parens
move record paths to atomic expressions
allow prefix operators for function names
end record paths on operators with /
highlight raise
fix commas in record fields
fix tuple patterns in let bindings
improve highlighting for array indexing
allow ...Module.field for record fields
don't terminate case arm on ||

If only we could generate these from our existing tokenizer...


generate_from_jams doesn't respect custom sample rates

It looks to be an easy fix. I can submit a PR when I get a minute.
https://github.com/justinsalamon/scaper/blob/634ea13e5c8d8f66b70414a4e19d2479c0adee0a/scaper/core.py#L133
https://github.com/justinsalamon/scaper/blob/634ea13e5c8d8f66b70414a4e19d2479c0adee0a/scaper/core.py#L1397

Ah yes, I forgot to save self.sr in the sandbox (line 1397), and then forgot to load it into self.sr in generate_from_jams. Nice catch!
Happy to accept a PR, please note it should include not only the fix to the code, but also the necessary unit test(s) to ensure 100% test coverage is maintained. Thanks!

p.s - the PR should also include a version bump to 1.0.1 (short version stays on 1.0) :)


feat(napi/transform): align output SourceMap with Rollup's ExistingRawSourceMap

closes #5578

#5657  👈
main

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

Join @Boshen and the rest of your teammates on  Graphite


Direction issues when using Pointy Orientation

Summary
The angle values listed in the Direction documentation for pointy orientation are off by one (South should be pointy angle 0), as the documented angle values for pointy orientation do not match the coordinate change described for each Direction.
On top of this, there's a larger issue of lacking Pointy orientation Direction as directions such as NorthWest have different coordinate changes for each orientation.
Details
The Direction enum uses flat orientation for its naming, but the documentation for each direction states what equivalent direction it is for pointy orientation.  For example Direction::TopRight notes that in pointy orientation, it's equivalent of 0 radians, which would be East (assuming mathematical east-counterclockwise orientation).
The problem is, the coordinate change of TopRight in flat orientation is (1, -1), but the change for East in pointy orientation is (1, 0) (which is Bottom in flat orientation).
This becomes a problem when you start using Hex::all_neighbors() using pointy orientation, which actually starts at NorthEast instead of East.
This matters when storing data by Direction index (Direction as usize), as Direction::NorthEast acting as PointyDirection::East has index 0, but the actual transform (1, -1) leads to the cell to the north-east in pointy orientation.
To Reproduce
According to the documents Direction::TopRight is supposed to be equivalent to East when using pointy orientation, so this should pass:
pub type East = Direction::TopRight;
assert_eq!(Hex::new(0, 0) + East, Hex::new(0, 1));

Expected behavior
Honestly, I don't know.  Updating the documentation to change the angles to match the
direction coordinate changes in NEIGHBORS_COORDS would be a start.  Effectively Direction::South should be pointy angle 0.
However, this doesn't really resolve the overarching problem of having to mentally convert  the pointy direction East into flat direction South.  It gets even worse when you realize NorthWest in flat (-1, 1) is different from NorthWest in pointy (0, -1).
Perhaps specialization of Direction into PointyDirection and FlatDirection is the approach?
Screenshots Or Code snippet
Pointy orientation coordinate change:

Flat orientation coordinate change:

Bah, but even PointyDirection & FlatDirection wouldn't resolve the issue as Hex::all_neighbors() would need to know orientation to start at PointyDirection::East or FlatDirection::NorthEast because they have different coordinate changes.

I think the direction enum approach is not the way, I added it as a utility and a separate notion from Hex coordinates but ultimately it is confusing.
One solution could be to rename the variants in a more abstract way than cardinal directions, I tried finding different names without success.
Thank you for opening an issue, I've been thinking about it for some time now. #110 also had a direction related issue, so it will be my next priority.
@alice-i-cecile what do you think ?

I also haven't been able to come up with non-ambiguous names for each edge because of how much different they are.  If you do them by angle (0tau/6, 1tau/6, 2tau/6, ...) does the angle refer to the middle of the edge, or the start of the edge?
Although, we know angle 0 is East, and East is (1,0) in pointy orientation.  The equivalent direction (1,0) in flat orientation is SouthEast.  That would mean if naming were based on angle, then the angle would refer to the counter-clockwise end of the edge.  Horribly phrased, and probably even more confusing to visualize Direction::Zero in flat orientation goes SouthWest 😵💫.
This kind of leads me back to thinking splitting Direction into FlatDirection & PointyDirection makes sense, but perhaps it needs to bubble up to PointyHex and FlatHex with some sort of use hexx::pointy::*/use hexx::flat::* magic to allow for the use of Hex and Direction names.
This is the work-around I'm using for the moment just as an additional data point (below).  I defined a PointyDirection enum and a Hex::pointy_neighbors() method.  I am able to move forward using these, but the integration (PointyDirection::to_hex) isn't the smoothest.
/// Pointy orientation hex directions in east counter-clockwise order
#[repr(u8)]
#[derive(Debug, Clone, Copy, Default)]
pub enum PointyDirection {
    #[default]
    East = 0,
    NorthEast = 1,
    NorthWest = 2,
    West = 3,
    SouthWest = 4,
    SouthEast = 5,
}

impl HexDirection {
    pub fn as_hex(&self) -> hexx::Hex {
        match self {
            Self::East => hexx::Hex::new(1, 0),
            Self::NorthEast => hexx::Hex::new(1, -1),
            Self::NorthWest => hexx::Hex::new(0, -1),
            Self::West => hexx::Hex::new(-1, 0),
            Self::SouthWest => hexx::Hex::new(-1, 1),
            Self::SouthEast => hexx::Hex::new(0, 1),
        }
    }
}

// specialize the type of Direction we're using
pub type Direction = PointyDirection;

// add a trait so we can specify things on `Hex`
pub trait HexPointyDirections {
    fn pointy_neighbors(self) -> [(Direction, Hex); 6];
}

impl HexPointyDirections for Hex {
    // similar to all_neighbors(), but pointy and include direction
    fn pointy_neighbors(self) -> [(Direction, Hex); 6] {
        [
            // This can be switched to use `self + Direction::to_hex`
            (Direction::East, self + Hex::X),
            (Direction::NorthEast, self + Hex::new(1, -1)),
            (Direction::NorthWest, self + Hex::NEG_Y),
            (Direction::West, self + Hex::NEG_X),
            (Direction::SouthWest, self + Hex::new(-1, 1)),
            (Direction::SouthEast, self + Hex::Y),
        ]
    }
}

The thing is that the directions are identical no matter the orientation you are using. The orientation is purely for layout purposes, all arithmetic is the same either way, even the angles would be the same as they are relative to a purely virtual axis.
Therefore it would not be a good solution to duplicate the orientation concept in directions as it would become error prone, and redundant data-wise.
The confusion comes from the naming, and I even think that the enums should be entirely removed.
Just like in square grids, any coordinate can represent a point or a vector. Hex should be able (and is) to represent both.
The neighbours of the origin are the direction vectors already! But it's a bit harder to grasp because of the strangeness of the hexagonal coordinate system.
The fact than you can convert a direction to a coordinate vector is proof of the redundancy in my opinion.
I created the direction enums to represent wedges just like what the redblobgames article represents, but I think it was a naive implementation. I don't have the perfect solution in mind yet, but I think there is potential in some kind of normalize method which could transform any coordinate to its "unit" wedge direction vector.
Therefore we could easily identify directions, don't be confused by naming them, and "reduce" coordinates to their wedge vector.
What would you think about such a solution ?

I like that last solution: I think that this is a much clearer way to approach the fundamental problem being solved here without coupling as tightly to "what direction is the camera facing".

So I keep coming back to this. It seems like the simple solution to just remove the concept of Direction from hexx is the right answer, but does that actually remove the need for Direction in projects using hexx?
If it doesn’t, removing Direction means projects need to implement their own Direction, which will be largely similar across all of the projects.
I’m hung up on trying to determine common scenarios where direction is needed.
I know for my use case, I absolutely need direction as I’m doing non-Euclidean tricks so each cell has a set of exits ordered by direction. This is an edge case that most people won’t need.
One possibly common situation is napping dual-axis input into a hex movement direction. Actually I think even if we remove direction this scenario has the same problem when using vectors.
What vector does 31 degrees map to? The answer is different if you’re pointy oriented or flat.

I want to remove the direction enums, not the direction concept.
I will open a PR next week and we will discuss what could be missing. I don't want to reduce the amount of features from hexx, only the confusion.
The point on the direction/angle is noted, I'll keep in mind to have iso functionality

Re: The direction enum naming. My personal use for the Direction enum was for a Depth First Search where I needed to keep going "forward". (Here is the untested code )
the same functionality could've been gained by 6 constants in the Hex struct.  You can rotate them just fine with the existing functionality in Hex, but you don't need the enum for that.
Which brings me to the X, Y etc constants in Hex, which are perplexing to use tbh, and their utility isn't clear to me, (especially that Z is defined as Neg_Y). My idea of a better naming scheme for directions, independently of cardinal directions, is to mark which coordinate is stationary and which is increasing (out of X, Y, Z).
So the direction currently marked with:

X, (1, 0) would be YX to indicate Y doesn't change but X increases
Neg_X (-1, 0) would be YZ
Y (0, 1) would be XY
Neg_Y (0, -1) would XZ
Which leaves (1, -1) as ZX
and (-1, 1) as ZY.

just an idea.

Re: The direction enum naming. My personal use for the Direction enum was for a Depth First Search where I needed to keep going "forward". (Here is the untested code )
the same functionality could've been gained by 6 constants in the Hex struct. You can rotate them just fine with the existing functionality in Hex, but you don't need the enum for that.

I agree that the enum is not very useful in that case (You can also rotate the Hex coordinate), but I didn't find a better way to represent non zero normalized directions because of the Diagonal Directions, which are quite tricky and also have specific features like finding the adjacent directions and vice versa.
There are two solutions I think:

Either remove the enums and have an other way to represent unit directions and diagonal directions (maybe a wrapper, through some Hex::normalize_to_dir and Hex::nornalize_to_diag methods)
Rename the enums to remove the subjective directional language

Maybe something like
XNegY, // (1, -1)
NegY, // (0, -1)
NegX, // (-1, 0)
NegXY // (-1, 1)
Y // (0, 1)
X // (1, 0)

But I'm not sure if it's really more clear this way anyway

Which brings me to the X, Y etc constants in Hex, which are perplexing to use tbh, and their utility isn't clear to me, (especially that Z is defined as Neg_Y). My idea of a better naming scheme for directions, independently of cardinal directions, is to mark which coordinate is stationary and which is increasing (out of X, Y, Z).
So the direction currently marked with:
* `X`, (1, 0) would be `YX` to indicate `Y` doesn't change but `X` increases

* `Neg_X` (-1, 0) would be `YZ`

* `Y` (0, 1) would be `XY`

* `Neg_Y` (0, -1) would be `XZ`

Which leaves
* (1, -1) as `ZX`

* (-1, 1) as `ZY`.

just an idea.

The const values are indeed not very clear, should Hex::X represent the x axis or a unity vector increasing X, same for Y and Z. Which bring the Z issue, which can be represented by different vectors to increase or decrease in the Z axis.

You should consider the edges and corners directions of Hex, sometimes we want to get the position of corners.
If you research this, you will find:
The edge directions of pointy hex are the corners direction of flat hex.
Because of this, we can define the enum of Direction contains 8 direction. And define 2 array [Direction; 6], they can be used for pointy and flat hex's edges and corners, respectively.

You should consider the edges and corners directions of Hex, sometimes we want to get the position of corners. If you research this, you will find: The edge directions of pointy hex are the corners direction of flat hex. Because of this, we can define the enum of Direction contains 8 direction. And define 2 array [Direction; 6], they can be used for pointy and flat hex's edges and corners, respectively.

In world space it is indeed correct, but Hex coordinates and directions are the same in either pointy or flat orientation. The arithmetic is identic, it's just the world/pixel representation that changes.
This confusion is why the current enums are a problem as they represent cardinal directions and not what they should represent: Hex unit vectors

OK, if you delete the enum Direction, replace Direction with (X, Y...), my suggestion is:

if X is related to Pointy hex's Top angel and Flat hex's edge, you should write the necessary comments with "///".
Implement the enum Direction in example code, it will help someone who want to implement the Direction by himself.

I'm still not sure what the ideal solution is, but I won't remove the directions, they may not be an enum anymore but the feature will stay. But tbh I'm not sure what is the best way to handle this in a good way, all solutions I mentioned in this issue have flaws

Yea, having DiagonalDirection for pointy orientation does seem like the best available solution. Users of the crate can type alias whichever one they need to Direction.

What do you mean ? DiagonalDirection is not related to orientation

Ah, I misread the diff on #144 when it closed this issue. Thought you just broke out a second enum for pointy directions and just used an odd name.

Aha no, I still haven't figured out a good new approach for the direction enums, they are such a useful abstraction over Hex. So I justed added some expressive const values that might be useful until then

If I might suggest: the current Directions are confusing because they depend on the layout too much while being too generic in their use.
Moving them behind the layout whould IMO solve this issue and provide a very useful api.
Rough attempt usign traits:
trait GridLayout {
    fn get_north_offset(&self) -> Option<Hex>;
}

struct PointyLayout;
impl GridLayout for PointyLayout {
    fn get_north_offset(&self) -> Option<Hex> {
        None
    }
}

struct FlatLayout;
impl GridLayout for FlatLayout {
    fn get_north_offset(&self) -> Option<Hex> {
        Some(hex(0, 0))
    }
}

impl Hex {
    fn get_north(&self, layout: &dyn GridLayout) -> Option<Hex2> {
        if let Some(offset) = layout.get_north_offset() {
            Some(offset + *self)
        }
        None
    }
}

This opens a lot of useful access to other coordinates too : diagonal neighbors, edges, vertexes, ...

Direction and orientation are unrelated, the naming of the direction variants is confusing

Not entirely sure I get what you mean, it would seem that cardinal points and grid orientation are dependent ?
'Going north' in Flat means following the [(0,0) ; (0,-1)] vector
'Going north' in Pointy means following the [(0,0) ; (+1,-2)] vector

Pointy and flat orientation is a purely visual concept, meaning a 30 degrees rotation.
Coordinate wise there is no impact. You can check the documentation for Direction and DiagonalDirection for more details.
This issue is about finding another way to represent directions, without cardinal names which create this confusion

I agree with the coordinates being orientation-agnostic yes
My suggestion was indeed not on the main issue here (the way to represent directions) but rather a way to keep the cardinal names (which can be useful in some circumstances) by having an explicit dependancy on orientation, as an alternative to entirely removing them like you mentioned

We can always add orientation specific cardinal constants

@dmlary @f-hoenix @asibahi Could you review #156 ? I think it's a good solution to the direction problem

@dmlary @f-hoenix @asibahi Could you review #156 ? I think it's a good solution to the direction problem

I’ve been trying to get to this, but won’t have time until this weekend. It’s still on my plate.


Fix dequeueProposalIfReady() for expired proposals.

Description
Because this introduces a tiny bug which allows expired PRoposals to enter into the dequeued list. Those just need to be deleted w/o entering the list!
Thanks to @pahor167  for extra pointing this out.
Reverts celo-org/celo-monorepo#10268
Tested
Unit test.
Related issues

Fixes #10091

Documentation
no need

Can you update the title of this PR?

woo


Bug/bi 2126

Description
BI-2126 Env year missing from dataset view
Now the Env Year is fetched on the back-end and passed to the front-end in the additional_Info element of each Observation Unit.
Dependencies
bi-api: bug/BI-2126 branch
Testing

Vew any experiment.
EXPECTED RESULT

The correct Env Year should be displayed for each Observation Unit.

Checklist:

[x] I have performed a self-review of my own code
[x] I have tested my code and ensured it meets the acceptance criteria of the story
[ ] I have tested that my code works with both the brapi-java-server and BreedBase
[ ] I have create/modified unit tests to cover this change
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to documentation
[ ] I have run TAF: <please include a link to TAF run>

Tested and working


GEOMESA-1134 Adding avro compression and tools output compression

Signed-off-by: Emilio Lahr-Vivaz<EMAIL_ADDRESS>Note: stacks on top of #835

This covers GEOMESA-1129 now too

looks pretty good. waiting on stacked commit then will merge

5570684449cb4ad67b0c655940e4d14d93bb40bf


[Bug?] Hidden terrain is not calculated

Not sure if it's an error to report here on on other modules but, when a terrain polygon is visible, if a token is dragged over it, the rule shows the correct multiplies values (based on the difficult terrain).
However, if the terrain is hidden, the ruler doesn't take it into account and doesn't apply the multiplier.
I want to be able to add difficult terrain but not show it to the players because the map already has a nice representation of the difficult terrains and it would be a shame for the players to have to see a bland dashed area instead of the cool map.
Maybe the difficult terrain could have a separate visible/invisible option that only control the visibility to players and another separate enabled/disabled option that controls if the terrain should or not be considered in the movement/ruler calculation?
Note: I'm using Enhanced Terrain Layer to place implement my difficult terrain
https://foundryvtt.com/packages/enhanced-terrain-layer
Thanks.

Enhanced Terrain Layer has two options to "hide" difficult terrain. There's the purple eye-button in the toolbar on the left that says "Enable/Disable Terrain". If that is turned off, the terrain won't be shown, but will still affect terrain calculation. Then there is the mystery-man button that says "Toggle Visibility State" that appears when you right click a terrain. That button actually disables the Terrain for the calculation (and hides it from the players). Those buttons are incorrectly labeled and I informed the Enhanced Terrain Layer author about this. It should be fixed in the next release of Enhanced Terrain Layer.

it has been sorted, thanks
https://github.com/ironmonk88/enhanced-terrain-layer/issues/27


Fix tests on SAP HANA

add optional row/column modifier to the expected create schema statement

org.hibernate.test.schemaupdate.AlterTableQuoteDefaultSchemaTest
org.hibernate.test.schemaupdate.AlterTableQuoteSpecifiedSchemaTest

@vladmihalcea didn't we decide to only enable these tests for some named dialects? It seems that you have committed the version where it's enabled for all dialects supporting schema creation?

@gsmet I think it's better to have the tests enabled and find out if there are problems with certain DBs because of the latest Hibernate code changes.

@breglerj When I try to run the test on HANA, I still get this:

17:59:54,952 ERROR SqlExceptionHelper:142 - SAP DBTech JDBC: [386]: cannot use duplicate schema name: default-schema: line 1 col 15 (at pos 14)

How is it working for you?

@vladmihalcea It's most likely a permission issue.
A schema named "default-schema" created by the Jenkins test DB user still exists, because the test cleanup doesn't work without specifying CASCADE in the drop statement or deleting the table first.
When you try to execute the test with a different user, that user is not allowed to drop the existing schema and consequently the following recreation of the schema fails.
Executing the test as the Jenkins test DB user should work.
I've pushed a new commit that adds an explicit drop of the entity table. That should fix the test failure for you.

I restricted the tests for H2, PostgreSQL and SQL Server as otherwise, the test would have become way too complicated and hinder long-term maintenance.

Thanks Vlad, I think that's best.


SFTTrainer:  element 0 of tensors does not require grad and does not have a grad_fn

System Info

transformers version: 4.45.1
Platform: Linux-5.10.225-213.878.amzn2.x86_64-x86_64-with-glibc2.35
Python version: 3.10.14
Huggingface_hub version: 0.24.5
Safetensors version: 0.4.4
Accelerate version: 0.34.2
Accelerate config:    not found
PyTorch version (GPU?): 2.1.0 (True)
Tensorflow version (GPU?): 2.15.0 (True)
Flax version (CPU?/GPU?/TPU?): not installed (NA)
Jax version: not installed
JaxLib version: not installed
Using distributed or parallel set-up in script?: SFTTrainer, FSDP

Who can help?
@BenjaminBossan @sayakpaul
Information

[ ] The official example scripts
[X] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder
[X] My own task or dataset (give details below)

Reproduction
Script executed with Amazon SageMaker, instance type g5.12xlarge (4 GPUs):
from accelerate import Accelerator
from huggingface_hub import login
from peft import AutoPeftModelForCausalLM, LoraConfig, get_peft_model, prepare_model_for_kbit_training
from sagemaker.remote_function import remote
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, set_seed
from trl import SFTConfig, SFTTrainer
import transformers

def train_fn(
        model_name,
        train_ds,
        test_ds=None,
        lora_r=8,
        lora_alpha=16,
        lora_dropout=0.1,
        per_device_train_batch_size=8,
        per_device_eval_batch_size=8,
        gradient_accumulation_steps=1,
        learning_rate=2e-4,
        num_train_epochs=1,
        fsdp="",
        fsdp_config=None,
        max_seq_length=2048,
        gradient_checkpointing=False,
        merge_weights=False,
        seed=42,
        token=None
):

    set_seed(seed)

    accelerator = Accelerator()

    if token is not None:
        login(token=token)

    tokenizer = AutoTokenizer.from_pretrained(model_name)

    # Set Tokenizer pad Token
    tokenizer.pad_token = tokenizer.eos_token

    def tokenize(text):
        result = tokenizer(
            text['text'],
            max_length=max_seq_length,
            padding="max_length",
            truncation=True
        )
        result["labels"] = result["input_ids"].copy()
        return result

    with accelerator.main_process_first():
        lm_train_dataset = train_ds.map(tokenize, remove_columns=["text"])

        print(f"Total number of train samples: {len(lm_train_dataset)}")

        if test_ds is not None:
            lm_test_dataset = test_ds.map(tokenize, remove_columns=["text"])

            print(f"Total number of test samples: {len(lm_test_dataset)}")
        else:
            lm_test_dataset = None

    bnb_config = BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_use_double_quant=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_compute_dtype=torch.bfloat16,
        bnb_4bit_quant_storage=torch.bfloat16
    )

    model = AutoModelForCausalLM.from_pretrained(
        model_name,
        trust_remote_code=True,
        quantization_config=bnb_config,
        attn_implementation="flash_attention_2",
        torch_dtype=torch.bfloat16,
        use_cache=False if gradient_checkpointing else True,
        cache_dir="/tmp/.cache"
    )

    #model = prepare_model_for_kbit_training(model, use_gradient_checkpointing=gradient_checkpointing)

    if gradient_checkpointing:
        model.gradient_checkpointing_enable()

    # get lora target modules
    modules = find_all_linear_names(model)
    print(f"Found {len(modules)} modules to quantize: {modules}")

    config = LoraConfig(
        r=lora_r,
        lora_alpha=lora_alpha,
        target_modules=modules,
        lora_dropout=lora_dropout,
        bias="none",
        task_type="CAUSAL_LM"
    )

    model = get_peft_model(model, config)
    print_trainable_parameters(model)

    trainer = SFTTrainer(
        model=model,
        train_dataset=lm_train_dataset,
        eval_dataset=lm_test_dataset if test_ds is not None else None,
        args=SFTConfig(
            per_device_train_batch_size=per_device_train_batch_size,
            per_device_eval_batch_size=per_device_eval_batch_size,
            gradient_accumulation_steps=gradient_accumulation_steps,
            gradient_checkpointing=gradient_checkpointing,
            gradient_checkpointing_kwargs={
                "use_reentrant": True if gradient_checkpointing else False
            },
            logging_strategy="steps",
            logging_steps=1,
            log_on_each_node=False,
            num_train_epochs=num_train_epochs,
            learning_rate=learning_rate,
            auto_find_batch_size=False,
            batch_eval_metrics=False,
            bf16=True,
            bf16_full_eval=False,
            fp16=False,
            fp16_full_eval=False,
            ddp_find_unused_parameters=False,
            fsdp=fsdp,
            fsdp_config=fsdp_config,
            save_strategy="no",
            output_dir="outputs"
        ),
        peft_config=config,
        packing=True,
        tokenizer=tokenizer,
        dataset_text_field="text",
        dataset_kwargs={
            "add_special_tokens": False,
            "append_concat_token": False,
        }
    )

    trainer.train()

    if trainer.is_fsdp_enabled:
        trainer.accelerator.state.fsdp_plugin.set_state_dict_type("FULL_STATE_DICT")

    if merge_weights:
        if accelerator.is_main_process:
            output_dir = "/tmp/model"

            # merge adapter weights with base model and save
            # save int 4 model
            trainer.model.save_pretrained(output_dir, safe_serialization=False)
            # clear memory
            del model
            del trainer

            torch.cuda.empty_cache()

            # load PEFT model in fp16
            model = AutoPeftModelForCausalLM.from_pretrained(
                output_dir,
                low_cpu_mem_usage=True,
                torch_dtype=torch.float16,
                cache_dir="/tmp/.cache"
            )

            # Merge LoRA and base model and save
            model = model.merge_and_unload()
            model.save_pretrained(
                "/opt/ml/model", safe_serialization=True, max_shard_size="2GB"
            )
    else:
        trainer.model.save_pretrained("/opt/ml/model", safe_serialization=True)

    if accelerator.is_main_process:
        tokenizer.save_pretrained("/opt/ml/model")

model_id = "meta-llama/Meta-Llama-3.1-8B-Instruct"

train_fn(
    model_id,
    train_ds=train_dataset,
    test_ds=test_dataset,
    per_device_train_batch_size=4,
    per_device_eval_batch_size=1,
    gradient_accumulation_steps=4,
    gradient_checkpointing=True,
    num_train_epochs=3,
    fsdp="full_shard auto_wrap offload",
    fsdp_config={
        "backward_prefetch": "backward_pre",
        "forward_prefetch": False,
        "use_orig_params": False,
        "cpu_ram_efficient_loading": True
    },
    merge_weights=True,
    token="<HF_TOKEN>"
)

train_dataset:
Dataset({
    features: ['text'],
    num_rows: 140
})

train_dataset[0]["text"] (mock):
<|begin_of_text|><|start_header_id|>user<|end_header_id|>What dimensions of the Llama 3.2 model are available?<|eot_id|><|start_header_id|>assistant<|end_header_id|>Llama 3.2 offers several model dimensions to cater to different use cases and computational requirements: Text-Only Models 1\ 1B parameter model: This is the smallest Llama 3.2 model, designed for lightweight text processing tasks and on-device applications 2\ 3B parameter model: A slightly larger text-only model that still maintains efficiency for edge devices and mobile applications. Multimodal Vision Models: 1\ 11B parameter model: This is the smaller of the two vision-capable models, suitable for efficient deployment and development on consumer-grade GPUs 2\ 90B parameter model: The largest Llama 3.2 model, designed for large-scale applications and advanced image reasoning tasks<|end_of_text|><|eot_id|>

Error returned:
Cell In[26], line 151, in train_fn()
    110 print_trainable_parameters(model)
    112 trainer = SFTTrainer(
    113     model=model,
    114     train_dataset=lm_train_dataset,
   (...)
    148     }
    149 )
--> 151 trainer.train()
    153 if trainer.is_fsdp_enabled:
    154     trainer.accelerator.state.fsdp_plugin.set_state_dict_type("FULL_STATE_DICT")

File [/opt/conda/lib/python3.10/site-packages/trl/trainer/sft_trainer.py:434](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/trl/trainer/sft_trainer.py#line=433), in train()
    431 if self.neftune_noise_alpha is not None and not self._trainer_supports_neftune:
    432     self.model = self._trl_activate_neftune(self.model)
--> 434 output = super().train(*args, **kwargs)
    436 # After training we make sure to retrieve back the original forward pass method
    437 # for the embedding layer by removing the forward post hook.
    438 if self.neftune_noise_alpha is not None and not self._trainer_supports_neftune:

File [/opt/conda/lib/python3.10/site-packages/transformers/trainer.py:2052](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/transformers/trainer.py#line=2051), in train()
   2050         hf_hub_utils.enable_progress_bars()
   2051 else:
-> 2052     return inner_training_loop(
   2053         args=args,
   2054         resume_from_checkpoint=resume_from_checkpoint,
   2055         trial=trial,
   2056         ignore_keys_for_eval=ignore_keys_for_eval,
   2057     )

File [/opt/conda/lib/python3.10/site-packages/transformers/trainer.py:2388](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/transformers/trainer.py#line=2387), in _inner_training_loop()
   2385     self.control = self.callback_handler.on_step_begin(args, self.state, self.control)
   2387 with self.accelerator.accumulate(model):
-> 2388     tr_loss_step = self.training_step(model, inputs)
   2390 if (
   2391     args.logging_nan_inf_filter
   2392     and not is_torch_xla_available()
   2393     and (torch.isnan(tr_loss_step) or torch.isinf(tr_loss_step))
   2394 ):
   2395     # if loss is nan or inf simply add the average of previous logged losses
   2396     tr_loss += tr_loss [/](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/) (1 + self.state.global_step - self._globalstep_last_logged)

File [/opt/conda/lib/python3.10/site-packages/transformers/trainer.py:3518](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/transformers/trainer.py#line=3517), in training_step()
   3516         scaled_loss.backward()
   3517 else:
-> 3518     self.accelerator.backward(loss, **kwargs)
   3520 return loss.detach() [/](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/) self.args.gradient_accumulation_steps

File [/opt/conda/lib/python3.10/site-packages/accelerate/accelerator.py:2196](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/accelerate/accelerator.py#line=2195), in backward()
   2194     self.lomo_backward(loss, learning_rate)
   2195 else:
-> 2196     loss.backward(**kwargs)

File [/opt/conda/lib/python3.10/site-packages/torch/_tensor.py:492](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/torch/_tensor.py#line=491), in backward()
    491 def register_hook(self, hook):
--> 492     r"""Registers a backward hook.
    493
    494     The hook will be called every time a gradient with respect to the
    495     Tensor is computed. The hook should have the following signature::
    496
    497         hook(grad) -> Tensor or None
    498
    499
    500     The hook should not modify its argument, but it can optionally return
    501     a new gradient which will be used in place of :attr:`grad`.
    502
    503     This function returns a handle with a method ``handle.remove()``
    504     that removes the hook from the module.
    505
    506     .. note::
    507         See :ref:`backward-hooks-execution` for more information on how when this hook
    508         is executed, and how its execution is ordered relative to other hooks.
    509
    510     Example::
    511
    512         >>> v = torch.tensor([0., 0., 0.], requires_grad=True)
    513         >>> h = v.register_hook(lambda grad: grad * 2)  # double the gradient
    514         >>> v.backward(torch.tensor([1., 2., 3.]))
    515         >>> v.grad
    516
    517          2
    518          4
    519          6
    520         [torch.FloatTensor of size (3,)]
    521
    522         >>> h.remove()  # removes the hook
    523     """
    524     if has_torch_function_unary(self):
    525         return handle_torch_function(Tensor.register_hook, (self,), self, hook)

File [/opt/conda/lib/python3.10/site-packages/torch/autograd/__init__.py:251](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/opt/conda/lib/python3.10/site-packages/torch/autograd/__init__.py#line=250), in backward()
    204 def grad(
    205     outputs: _TensorOrTensors,
    206     inputs: _TensorOrTensors,
   (...)
    212     is_grads_batched: bool = False
    213 ) -> Tuple[torch.Tensor, ...]:
    214     r"""Computes and returns the sum of gradients of outputs with respect to
    215     the inputs.
    216
    217     ``grad_outputs`` should be a sequence of length matching ``output``
    218     containing the "vector" in vector-Jacobian product, usually the pre-computed
    219     gradients w.r.t. each of the outputs. If an output doesn't require_grad,
    220     then the gradient can be ``None``).
    221
    222     .. note::
    223
    224         If you run any forward ops, create ``grad_outputs``, and[/or](https://ahwj8sa5y2ar84p.studio.us-east-1.sagemaker.aws/or) call ``grad``
    225         in a user-specified CUDA stream context, see
    226         :ref:`Stream semantics of backward passes<bwd-cuda-stream-semantics>`.
    227
    228     .. note::
    229
    230         ``only_inputs`` argument is deprecated and is ignored now (defaults to ``True``).
    231         To accumulate gradient for other parts of the graph, please use
    232         ``torch.autograd.backward``.
    233
    234     Args:
    235         outputs (sequence of Tensor): outputs of the differentiated function.
    236         inputs (sequence of Tensor): Inputs w.r.t. which the gradient will be
    237             returned (and not accumulated into ``.grad``).
    238         grad_outputs (sequence of Tensor): The "vector" in the vector-Jacobian product.
    239             Usually gradients w.r.t. each output. None values can be specified for scalar
    240             Tensors or ones that don't require grad. If a None value would be acceptable
    241             for all grad_tensors, then this argument is optional. Default: None.
    242         retain_graph (bool, optional): If ``False``, the graph used to compute the grad
    243             will be freed. Note that in nearly all cases setting this option to ``True``
    244             is not needed and often can be worked around in a much more efficient
    245             way. Defaults to the value of ``create_graph``.
    246         create_graph (bool, optional): If ``True``, graph of the derivative will
    247             be constructed, allowing to compute higher order derivative products.
    248             Default: ``False``.
    249         allow_unused (bool, optional): If ``False``, specifying inputs that were not
    250             used when computing outputs (and therefore their grad is always zero)
--> 251             is an error. Defaults to ``False``.
    252         is_grads_batched (bool, optional): If ``True``, the first dimension of each
    253             tensor in ``grad_outputs`` will be interpreted as the batch dimension.
    254             Instead of computing a single vector-Jacobian product, we compute a
    255             batch of vector-Jacobian products for each "vector" in the batch.
    256             We use the vmap prototype feature as the backend to vectorize calls
    257             to the autograd engine so that this computation can be performed in a
    258             single call. This should lead to performance improvements when compared
    259             to manually looping and performing backward multiple times. Note that
    260             due to this feature being experimental, there may be performance
    261             cliffs. Please use ``torch._C._debug_only_display_vmap_fallback_warnings(True)``
    262             to show any performance warnings and file an issue on github if warnings exist
    263             for your use case. Defaults to ``False``.
    264     """
    265     t_outputs = cast(Tuple[torch.Tensor, ...], (outputs,) if is_tensor_like(outputs) else tuple(outputs))
    266     t_inputs = cast(Tuple[torch.Tensor, ...], (inputs,) if is_tensor_like(inputs) else tuple(inputs))

RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn

requirements.txt:
transformers==4.45.1
peft==0.13.0
accelerate==0.34.2
bitsandbytes==0.44.0
evaluate==0.4.1
safetensors>=0.4.3
sagemaker==2.232.1
trl==0.11.1
tokenizers>=0.19.1
py7zr

Expected behavior
The script was adapted from run_fsdp_qlora.py, which seems to work. Switched to SFTConfig as recommended in the documentation.
Expected behavior is to execute successfully the training script.

The error message is quite strange, since it's pointing to a docstring, which somehow suggests that the code was changed on the fly. Not sure what is going there.
Regardless of that, a couple of things you could try:

Don't call get_peft_model, instead pass the lora_config to SFTTrainer as peft_config=lora_config argument.
Instead of using modules = find_all_linear_names(model), pass target_modules="all-linear" to LoraConfig.
Uncomment the prepare_model_for_kbit_training call.

Could you please check if any of these changes (or a combination of them) fixes the issue?

Thanks @BenjaminBossan , issue solved.


build: don't regenerate/copy files that have not changed

When building my static site a lot of files (assets) are copied into the dist folder, that have not changes what so ever. This makes it hard to deploy a site efficiently (for example via rsync).
It would be great to avoid such updates and just overwrite files that have changed.

It would be!

@KajKandler I just merged a PR that will help quite a bit with this. There are still some improvements that could be made here, but now Blurry won't copy files into the build/dist folder if those files are already there
https://github.com/blurry-dev/blurry/pull/98


feat: Add Aurora chain support

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


String formatting '%[d]s' (explicit argument indexes) syntax: highlighting broken

When using the Go fmt package one has the option to format a string with 'explicit argument indexes'.
(https://golang.org/pkg/fmt/): ctrl+f search 'Explicit argument indexes:'
The syntax highlighting for a string using this feature is incorrect, displaying the '%' character in the same formatting as an erroneous usage of the '%' character, rather than the formatting for the correct usage.

This is an upstream issue here: https://github.com/sublimehq/Packages/issues/48
It doesn't look like Sublime wants to maintain the syntax highlighting packages...

Ah no worries! Thanks! :+1:

No problem, maybe if you go upstream and post your support for fixing that issue something will happen? I'm not hopeful, maybe I'll learn the new syntax language and do it myself soon.


Windows

Hi Anthony,
I just did a new install, as I did not remember the current status...
Compile worked, however with install:
H:\src\lisp\ocicl\src>make install
mkdir -p H:/src/lisp/ocicl//bin || true ;
Installing for Windows...
cp ocicl.exe H:/src/lisp/ocicl//bin
sbcl --load install.lisp oras/oras_1.0.1_windows_amd64.gz H:/src/lisp/ocicl//bin/ocicl-oras.exe
This is SBCL 2.3.2, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

; file: H:/src/lisp/ocicl/src/deflate.lisp
; in: DEFUN PARSE-ZLIB-HEADER
;     (OCICL::PARSE-ZLIB-CHECKSUM OCICL::INPUT-STREAM)
;
; caught STYLE-WARNING:
;   undefined function: OCICL::PARSE-ZLIB-CHECKSUM
;
; compilation unit finished
;   Undefined function:
;     PARSE-ZLIB-CHECKSUM
;   caught 1 STYLE-WARNING condition

; file: H:/src/lisp/ocicl/src/deflate.lisp
; in: DEFUN PARSE-GZIP-HEADER
;     (OCICL::PARSE-GZIP-EXTRA OCICL::INPUT-STREAM)
;
; caught STYLE-WARNING:
;   undefined function: OCICL::PARSE-GZIP-EXTRA

;     (OCICL::PARSE-GZIP-MTIME OCICL::INPUT-STREAM)
;
; caught STYLE-WARNING:
;   undefined function: OCICL::PARSE-GZIP-MTIME

;     (OCICL::PARSE-GZIP-STRING OCICL::INPUT-STREAM)
;
; caught STYLE-WARNING:
;   undefined function: OCICL::PARSE-GZIP-STRING
;
; compilation unit finished
;   Undefined functions:
;     PARSE-GZIP-EXTRA PARSE-GZIP-MTIME PARSE-GZIP-STRING
;   caught 3 STYLE-WARNING conditions

debugger invoked on a SB-C::INPUT-ERROR-IN-LOAD in thread
#<THREAD "main thread" RUNNING {234E0001}>:
  READ error during LOAD:

    Package SB-POSIX does not exist.

      Line: 39, Column: 14, File-Position: 1478

      Stream: #<SB-INT:FORM-TRACKING-STREAM for "file H:\\src\\lisp\\ocicl\\src\\install.lisp" {226FCEA1}>

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT   ] Abort loading file "H:\\src\\lisp\\ocicl\\src\\install.lisp".
  1: [CONTINUE] Ignore runtime option --load "install.lisp".
  2:            Skip rest of --eval and --load options.
  3:            Skip to toplevel READ/EVAL/PRINT loop.
  4: [EXIT    ] Exit SBCL (calling #'EXIT, killing the process).

(SB-C:COMPILER-ERROR SB-C::INPUT-ERROR-IN-LOAD :CONDITION #<SB-INT:SIMPLE-READER-PACKAGE-ERROR "Package ~A does not exist." {23852319}> :STREAM #<SB-INT:FORM-TRACKING-STREAM for "file H:\\src\\lisp\\ocicl\\src\\install.lisp" {226FCEA1}>)
0]

Did you receive the presentations? What do you think?
Marc

I don't have access to a Windows system, but I'd like to help.
sb-posix isn't available on Windows. That's why you're landing in the debugger. In the long run we should guard the :depends-on clause of the system with features expressions, but in the short term and to get you running would you apply this patch and report back, please?
diff --git a/Makefile b/Makefile
index 7e50d2e..af154a4 100644
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,7 @@ ifeq ($(detected_OS),Windows)
 	@echo "Installing for Windows..."
 	cp ocicl.exe ${DESTDIR}/bin
 	sbcl --load install.lisp oras/oras_1.0.1_windows_amd64.gz ${DESTDIR}/bin/ocicl-oras.exe
+	${DESTDIR}/bin/ocicl.exe setup
 else ifeq ($(detected_OS),Darwin)
 	@echo "Installing for macOS $(UNAME_M)..."
 	cp ocicl ${DESTDIR}/bin ;
@@ -35,13 +36,14 @@ else ifeq ($(detected_OS),Darwin)
 			echo "Unsupport macOS type: $(UNAME_M)"; \
 	esac; \
 	mv /tmp/oras ${DESTDIR}/bin/ocicl-oras
+	${DESTDIR}/bin/ocicl setup
 else
 	@echo "Installing for Linux..."
 	cp ocicl ${DESTDIR}/bin ;
 	tar xvf oras/oras_1.0.1_linux_amd64.tar.gz -C /tmp oras > /dev/null 2>&1;
 	mv /tmp/oras ${DESTDIR}/bin/ocicl-oras
-endif
 	${DESTDIR}/bin/ocicl setup
+endif

 clean:
diff --git a/install.lisp b/install.lisp
index c852a88..d165c39 100644
--- a/install.lisp
+++ b/install.lisp
@@ -36,4 +36,4 @@
 (let ((argv sb-ext:*posix-argv*))
   (gunzip (second argv) (third argv)))

-(sb-posix:exit 0)
+(sb-ext:quit)

Thanks. I've fixed this.


Missing Reports - Thermostats and Intermittently Schlage Lock

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
NO, my problem is NOT within Home Assistant or the ZWave JS integration
Is your problem within ZWaveJS2MQTT?
NO, my problem is NOT within ZWaveJS2MQTT
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
What causes the bug?
Any updates that should be reported to the console - i.e. change in current room temperature on the thermostat. Additionally in the case of the door locks, the updates seem to be ok when first starting, but will eventually erode it seems. 2 of the exact same thermostat exhibiting the exact same behavior as well, so even less likely a fluke in one of the pairings.
What do you observe?
I can see that no update is made to the thermostat temperatures. When checking Home Assistant, I can see a long history of the temperature never having changed. If I poll or refresh the device using the ZWaveJS2MQTT interface, the value will update almost instantly. I have also validated that ZWaveJS2MQTT does not show an updated value either, so it is assumed ZWJS is not actually receiving these updates at all.
What did you expect to happen?
I expect to see temperature updates be populated in the console after they change. Instant would be nice, but even within a few minutes would be an improvement over never changing.
Steps to reproduce the behavior:
No real steps, as mentioned its a matter of actual missing information being reported - I can't manually reproduce anything. Even trying to get the temp to change and monitor the logs on ZWaveJS is difficult to try and tackle and I've not been able to catch it lately as the temp generally stays relatively the same. (Thanks efficient heating/cooling systems!)
I've also tried the troubleshooting steps for reviewing the logs, I've attempted to re-interview the node, and I've restarted the system many a times. The door lock will usually come back when rebooting, then fade away over time again. Not as concerned with the lock at the moment as it's a fairly unimportant lock - but the thermostats are key for driving certain automations.
Something else of note - not sure if it's just my lack of knowing all the intricate details of these devices and what makes up the configs - but the node JSON has iterations of a "Scene Actuator Configuration" Command Class that I don't see in the spec of the device and has property names of "dimmingDuration" with numbers up to 255. It almost seems like it's being assigned a litany of class features for each individual brightness level of a dimming bulb, which I found quite odd.
Device information
Manufacturer: Trane
Model name: XL 624 Thermostat
Node ID in your network:
Node ID 10 and 37 (there are 2 thermostats, both exhibiting the exact same issue)
How are you using node-zwave-js?

[ ] zwavejs2mqtt Docker image (latest)
[ ] zwavejs2mqtt Docker image (dev)
[ ] zwavejs2mqtt Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[X] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[ ] Other (please describe)

Which branches or versions?
HomeAssistant OS: core-2021.12.9 / supervisor-2021.12.2
ZWaveJS version: 8.10.2
ZWaveJS2mqtt: 6.3.1
node-zwave-js branch:
zwavejs2mqtt branch:

Did you change anything?
no
If yes, what did you change?
No response
Did this work before?
Yes (please describe)
If yes, where did it work?
These thermostats worked under the old ZWave legacy integration. I had a system that was running that was a bit outdated, and while I did update the HASS version within the last 6 months, I was still running the old integration and hadn't converted over yet. I then decided to upgrade the Stick to the Aeotec Gen5 from Gan4, and move to a new HASS instance and start a bit fresh. So a lot has changed from when it was working, but these didn't require anything special on the old configuration as they don't even use Security.
Attach Driver Logfile
Example of Node10 sending a temperature change command successfully. They always seem to work with receiving commands. But I believe I've also noticed that the temperature will stay wrong, even when sending that command as well.
Node10 Output for Change Temp.log
Output of the Node Debug Info for Node10: (please change back to JSON extension, GH wouldn't allow JSON)
node_10.txt

Thank you in advance to the folks who might be able to help me isolate the issue here. I apologize if there is something blatant I've missed, but I'm happy to try and get any additional details that can help. I wish there were more useful logs to go off, but I can certainly dump any other info you need from the ZWave Configs to the HASS configs, etc.

There's a difference communication when the controller initiates it (querying values) vs. when the node initiates it (unsolicited reports). In controller-initiated communication, the controller knows a route to the node and the node will reply using that route. In node-initiated communication, the node will use its last known route(s), which may change over time if previous attempts fail.
To me this sounds like the connectivity between the controller and nodes isn't the best and the nodes are forgetting the working routes over time because of intermittent errors. I'm not sure if you've already followed this part of the guide https://zwave-js.github.io/node-zwave-js/#/troubleshooting/connectivity-issues?id=general-troubleshooting - but if you haven't do that first, so we're not chasing ghosts.

@AlCalzone Thank you, I totally understand and that makes sense. Short version of a background - I'm quite technical in nature and work as a sales engineer, I just don't know ZWave to that level - but if you give me snippets of explanation, I can totally comprehend and interpret pretty easily. All that to say - what you said makes total sense, and I found a way to validate as well that the device is not able to send the reports back. I made manual change at the thermostat of temperature and then again of mode - none of which were observed in the logs in realtime, and used a control of a light switch which did in fact send its messages in that same time period.
Relative to the troubleshooting, while I can certainly try to move the Stick further - as mentioned this WAS working on an older setup with the older legacy ZWave integration. The placement of my stick is in a USB extension outside of the server rack to the highest point in the basement above the rack - aka away from metal, away from electronics, and away from USB3 devices. I have tried waiting, I have restarted the machine (HASS on a Pi4) - I have not tried unplugging and re-plugging the stick, but I don't see a difference between that and power cycle anyway. Not sure if the soft reset will do anything else in the stick itself that would be worth trying, but I can certainly do that just in case.
I do know this should not be a 700 series device (Aeotec Gen5 Stick) and it is not security enabled, so those should not be issues relative to the communication. Additionally, all other nodes in the home it seems, are working ok (we can ignore the lock for now as I haven't fully isolated that as an issue with ZWaveJS) and communicate fine.
I've thought about the idea of unpairing and then re-pairing as a final troubleshooting option - not specifically called out, but attributes to the 1st rule of computer troubleshooting in general of restarting it fresh. I just hate the atomic option in this scenario being the troubleshooting step as it means having to muck with HASS configs as well to make it all right after it's done. But if you believe that is a better step before taking other actions that might be available - by all means let me know and I'll do it. This one is mildly important overall to my automation needs, so I really do want to fix this and/or share whatever could be going wrong here as necessary.

Let's get one thing out of the way:

as mentioned this WAS working on an older setup with the older legacy ZWave integration

I read this often when communication issues are involved. It is simply impossible that swapping the host software, which simply tells the stick to do things, has any influence on the physical connection from other devices to that stick.
Under OZW you likely didn't notice because it used to actively poll devices for their status to a much larger extent. Z-Wave JS only does in some very specific situations and definitely not regularly like OZW did. This means even if the devices didn't "call in" their status, they were asked for it.

I've thought about the idea of unpairing and then re-pairing as a final troubleshooting option

Not sure where you got that - re-pairing is only necessary when you've lost the security keys for the device. Or for some device configuration changes that update capabilities.
The whole issue reads like the controller location is generally fine, especially if it is limited to these specific devices. Have you tried healing the network yet like the troubleshooting guide mentions? Maybe they "just" need some good routes to work with.
Otherwise, zwavejs2mqtt is getting tools to measure connection quality soon. Might also be worth a try when they are available.

I read this often when communication issues are involved. It is simply impossible that swapping the host software, which simply tells the stick to do things, has any influence on the physical connection from other devices to that stick.

That makes sense to me, I just wasn't sure if it's possible there were maybe different driver functions/capabilities that were/n't being enabled under the hood. I figured there shouldn't be (like you said, the hardware is what is actually connecting/driving the communication with the device) but wanted to make the comparison to ensure I provide the best detail.

Not sure where you got that - re-pairing is only necessary when you've lost the security keys for the device. Or for some device configuration changes that update capabilities.

Just me thinking of all options to try and "reset" myself to basics and ensure I didn't mix anything up or have some communication issue like the locks. I know I had one lock with that issue initially. Had to re-pair it like 3 times until I figured out what needed to happen to secure include right.

The whole issue reads like the controller location is generally fine, especially if it is limited to these specific devices. Have you tried healing the network yet like the troubleshooting guide mentions? Maybe they "just" need some good routes to work with.

Healing was my first choice. I figured with 2 devices recently disabled and failed (outside plugs for xmas lights) I would try healing the network so I could be sure none of them were using those plugs as part of their path. I'll try it again, just for giggles to ensure something funky didn't happen last time.

Otherwise, zwavejs2mqtt is getting tools to measure connection quality soon. Might also be worth a try when they are available.

Ok, I'll be sure to look out for em. Is it something I might be able to find beta or early code to compile on a separate device to test? I also still have my old stick, that I could try using in all this for any extraneous testing. Wouldn't be fun having to unpair then re-pair to a different stick - but I can certainly do that if needed to run any diagnostic or testing needed.
AND PS - thank you for the thoughtful replies and effort in helping me sort this - I know the OSS Automation community is vast with a lot of specialty, but thankfully they're all quite helpful.

@1activegeek If you want to give that a try use test tag on docker instead of latest

Sounds good @robertsLando. Do you know offhand if that's easily possible using HassOS? If not, I'll look at creating a VM dummy To test it or I'll see about enabling the local access on HassOS and doing it manually. I just know host access is a complicated setup for HassOS.

@1activegeek I have no clue as I don't use hass but I think it could be possible using portainer someway

I'll see what I can do over the weekend - may be a bit more difficult than anticipated - since I'm using js2mqtt, they bundle the ZWJS inside of their container I believe - so I can't directly alter to use a different container. I'll have to disconnect, re-adjust to use straight ZWJS, then try adjusting the container version.
Looks like it's doable, just a bunch of steps, and need to make sure I make proper backups first! 😊

So I didn't get to try and run the tests using the new health functions using the latest tag, since it wasn't as easy or straightforward figuring out which versions were matching up proper relative to HassOS plugins versions, JS2mqtt version, and zwave-js version. That said, it looks like in that timeframe there was already a merge into master, and the latest version I updated to looks to have the health option.
So I ran the test on both thermostats, though it does look like the health always checks THROUGH another node in the network. I can't just click the specific thermostat, and then test that thermostat - I have to select one device (not my target) then choose my target and it will test. So in my case I've got ~40 devices that I could test that connection - not sure I understand why I can't just run a health check from the stick? Maybe I just don't know enough about what it's doing.
All this to say - it all comes out healthy (10/10 pings and low interference dB levels) on all 5 checks each time. I've manually forced a heal 2 or 3 times since then. And I'm still stuck with no reports coming in from the thermostats. I have noticed that these devices DONT have the lifeline configuration that I know some devices do. I wish I had a sample of what their config was on my old setup to compare.
Thoughts?

Is it possible I need to look at using this option: SERVICE ZWAVE_JS.REFRESH_VALUE for these devices? I believe I do need to turn this on for a few of my dimmer switches that did use something like this previously as a fix for dimmer switches that would immediately report their state as it started to turn off as being something like 67% vs 1100% (on) and would change to off from the command, but quickly change back to a "dimmed" state of 67 where it caught it during the dim to off (HomeSeer dimmer switches). Is it just possible these thermostats are missing something that will require this also?

@1activegeek about the health check question in order to check the health connection of a node with the controlle simply select the required node in mesh, press check health and select the controller node as target
About your other question it seems more something related to HASS integration and zwavejs, maybe @blhoward2 @AlCalzone could help

I have noticed that these devices DONT have the lifeline configuration that I know some devices do. I wish I had a sample of what their config was on my old setup to compare.

The device manual should describe this. If the lifeline association is missing it could be that the devices are not Z-Wave+ and we don't have the information in the config file. Or there was a problem/timeout during the interview, so the lifeline couldn't be set up correctly.

Thanks @robertsLando for the clarification, think I get it now. Makes sense. I ran these checks again with that insight, and it looks ok overall. I've attached the 2 reports for the devices in question.
@AlCalzone according to the ZWaveAlliance data, I don't believe it does actually have the lifeline support. It is definitely not ZWave+ I know that, but I don't see anything about lifeline on the ZWA spec page: https://products.z-wavealliance.org/products/837?selectedFrequencyId=2 - due to the lack of any Association details where it is ordinarily documented.
So back to no good leads at the moment. Should I look at trying to utilize the Refresh Value option (https://www.home-assistant.io/integrations/zwave_js/#service-zwave_jsrefresh_value) to try and at least get some sort of polling to happen more frequently?
Alternatively - is there a pointer as to what I would need to find in the old ZWave integration code that maybe I can go diving for to find what might be set differently? As I said the only real lead I have at this moment is that it did in fact work on the OLD ZWave integration (not OpenZWave, previous to that one) successfully. Happy to go code diving if it would help.

Is there a way in particular I can re-open this issue? There never was a solution, but I'm not sure what I can do next for troubleshooting.


Add script and documentation for vanilla kube (kind) deployment.

We were relying on OpenShift specifics to generate and inject a cert for
hiveadmission's webhooks. Add a script for devs looking to deploy on
kind which uses Kubernetes CSRs to request a cert, and then uses the
kube CA.crt for the webhooks.

This isn't quite right as we're triggering a "openshift 3.11" path to add the CAs to the webhooks, which is misleading, and I'm also not sure yet if adding those CAs is required.
This PR does however work.

Implementation ideas from: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/

Clarified the code, the CA injection does appear to still be required, and added a section in the dev docs on how to use kind + local insecure registry.
Ready for review.

Hmm, seems with KIND, hive admission pod failed to start with following errors:
Events:
  Type     Reason       Age                   From                        Message
  ----     ------       ----                  ----                        -------
  Normal   Scheduled    5m24s                 default-scheduler           Successfully assigned hive/hiveadmission-dd7fb688f-d2hb4 to ocp-control-plane
  Warning  FailedMount  74s (x10 over 5m24s)  kubelet, ocp-control-plane  MountVolume.SetUp failed for volume "serving-cert" : secret "hiveadmission-serving-cert" not found
  Warning  FailedMount  64s (x2 over 3m21s)   kubelet, ocp-control-plane  Unable to mount volumes for pod "hiveadmission-dd7fb688f-d2hb4_hive(7f6908a5-fc80-11e9-9247-024231d31907)": timeout expired waiting for volumes to attach or mount for pod "hive"/"hiveadmission-dd7fb688f-d2hb4". list of unmounted volumes=[serving-cert]. list of unattached volumes=[serving-cert hiveadmission-token-46hfj]

The steps that I did is as follows:
kind create cluster --name hive

create a pv for ClusterDeployment

make deploy

@dgoodwin I did not found a place where the secret hiveadmission-serving-cert was created from source code, can you show some light for this? Thanks!

@gyliu513 the ./hack/hiveadmission-dev-cert.sh script will create that secret for you.
The kind create command is contained into the script in this PR as well which layers in the setup for the local insecure registry which is really handy for quickly building an image and deploying. It currently creates cluster1, I will change that to hive.
What was the PV for, log gathering? I thought I'd seen that work without doing anything, but I would have to verify.
In a followup I hope to split the scripts into on that sets up the registry and configures localhost, and one that creates a hive cluster with a given name and configures it for the registry.

I split the scripts into two, one to create the local insecure registry, and one to create a kind cluster with a given name and configure it to talk to the registry. The latter can be used to create or recreate as many clusters as you want.

@dgoodwin the pv was introduced by https://github.com/openshift/hive/pull/610/files , and it is used by the ClusterDeployment to persist the installation logs.

@dgoodwin the update looks good to me, thanks!

@dgoodwin the pv was introduced by https://github.com/openshift/hive/pull/610/files , and it is used by the ClusterDeployment to persist the installation logs.

I have to check, I thought I've seen the log gathering work out of the box with a bare kind cluster. If not I will add this step, thanks!

@dgoodwin is this PR ready to merge?

It is yes.

/lgtm


Semantic Versioning?

https://semver.org/
For example, the latest version can be written as:
~fabric-1.20.2-1.3.1~ → 1.3.1+fabric.1.20.2
For pre-releases:
1.4.0-beta+fabric.1.20.5
1.4.0-alpha+fabric.1.20.5
This will also prevent a warning in the log for Fabric versions, 'to use SemVer'.

Thanks for the suggestion the latest version uses it.


Move workspaces under packages

This PR moves tooling playground and docs under packages/ and moves the packages already there into a design-system folder.
This is so we can get rid of some modular patches

So there will now be 4 packages: design-system, docs, playground and tooling? That makes sense to me 👍 For my own curiosity, which modular patches are you trying to get rid of and why?

So those aren't really packages just workspaces under the "packages" folder. The packages are still core, lab etc.

Closing for now


PR: Generalice previous is_instance test to search others avoided patterns

Fixes #4161

I added the test but there's a lot of prints in the code, should I change them?
I put this in the 4.0 milestone because the is_instancetest was merged in master

You need to skip test files from your search

Also, could we backport these changes to the 3.1.x branch?

Could you rebase this PR against 3.1.x instead? I think it's very important to have this test working on our bugfix branch instead.

Could you rebase this PR against 3.1.x instead? I think it's very important to have this test working on our bugfix branch instead.

Yes, I'll do it
Also this is missing something, the max_allowed variable isnt the best way to skip that wanted prints, instead I'm going to add a comment # spyder: test_skip to lines that should be skipped

Ok, good idea!

@ccordoba12 This is ready, I open other PR backporting these changes to 3.1.x
@goanpeca I didn't tokenize for detecting prints into string, I improve the regex instead.

I'm closing this one in favor of #4226 because that one is created against our lowest branch.
Once #4226 is merged, I'll merge it against 3.x and master on my side and push changes directly to Github (that's what I'm doing for all PRs so far).


napari (installed using conda) appears as 'python3.9' in macOS

In macOS, napari (installed using conda) appears as 'python3.9' in the app menu (left side of the menu bar) and dock icon. It would be a nice touch to see 'napari' there!
PS: maybe it's better in the bundled app (which I haven't tried yet).

Yes, this little issue should be fixed in the new bundles!

@jaimergp Can it also be changed when launching from the terminal or ipython in a non-bundle install?

@psobolewskiPhD It's tricky... 😂 It took me a while to find out where MacOS takes the app name from and if there's no .app shortcut, it takes the process executable name. One reliable way is to copy the python executable to napari and then do napari -m napari but that's super hacky. Symlinks did not work, IIRC.

as @jaimergp said, the name "python3.9" is the executable's name, which cannot be changed as far as I am aware. I want to write more on where this python3.9 is picked up from.
when a package that defines a console_script (or gui_script) is installed via pip, pip generates a shebang script that maps the command to the specified entry point in setup.cfg, etc. This shebang script looks like this:
#!/opt/homebrew/anaconda3/envs/napari-pyside/bin/python3.9
# EASY-INSTALL-ENTRY-SCRIPT: 'napari','console_scripts','napari'
...
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(load_entry_point('napari', 'gui_scripts', 'napari')())

The executable name "python3.9" is picked up from this shebang script. The only way to change the displayed name seems to be having pip compiling this file to an executable binary that does not infer the python executable with a shebang approach.

Possible solution in #4989!


package.json library updates

Updated all libraries to the latest version (to prevent people cloning ancient versions of libraries and the citizenfx types) as well as removed a deprecated library 'eslint-loader', replacing it with its new version, 'eslint-webpack-plugin'. Tested building a resource on my end with all these updates in place and built successfully.

Aha it appears i forgot to push the package-lock.json file hence the build failure

Have you checked if building with webpack 5.0 works fine and runs on FiveM? I have had many issues with upgrading to 5.0 as well as other people.

Have you checked if building with webpack 5.0 works fine and runs on FiveM? I have had many issues with upgrading to 5.0 as well as other people.

I will double check these things with you this afternoon and get back to you

Have you checked if building with webpack 5.0 works fine and runs on FiveM? I have had many issues with upgrading to 5.0 as well as other people.

I will double check these things with you this afternoon and get back to you

Ok so after further testing, Webpack 5 seems to work for me at least if i build my resources locally (Tested on 2 resources coded myself) and then just chuck the fxmanifest and the dist folder into a resource folder and run it. However having FXServer build it automatically does seem to cause errors triggering a build failure. Perhaps you could try building a resource locally with Webpack 5 and seeing if it works for you?


Version 1.2.0 - Cosmetic updates

[ ] Standard one tab open
[ ] Schema valid indicator (green / red)
[ ] Close tab when collection query (when opened in tab) gets deleted
[ ] Improve creation / selection environment flow
[ ] Change back button label to close
[ ] Put Collection / History buttons in segmented control
[ ] Put Project / Environment / Query / Documentation buttons in segmented control
[ ] Improve query list presentation

Do you happen to have a timeline for this yet?  These all seems like great features!


Implementation Notes
TODO: Add links to relevant resources, specs, related issues, etc...
Contribution Guidelines
Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity.

I see the error in travis: https://travis-ci.org/spacemeshos/go-spacemesh/jobs/540953880

pod_name = 'client-upn29-2znqc', name_space = 'upn29', time_out = 20
def wait_for_pod_to_be_ready(pod_name, name_space, time_out=None):
total_sleep_time = 0
while True:
resp = client.CoreV1Api().read_namespaced_pod(name=pod_name, namespace=name_space)
if resp.status.phase == 'Running':
print("Total time waiting for pod {0}: {1} sec".format(pod_name, total_sleep_time))
break
time.sleep(1)
total_sleep_time += 1
        if time_out and total_sleep_time > time_out:

          raise Exception("Timeout waiting to pod to be ready")

E               Exception: Timeout waiting to pod to be ready
Looking at the cluster logs I see:
2019-06-04 00:34:09.000 IDT
pod triggered scale-up: [{https://content.googleapis.com/compute/v1/projects/spacemesh-198810/zones/us-east1-b/instanceGroups/gke-spacemesh-lab1-test-pool-d06160ad-grp 24->25 (max: 100)}]
So I guess the time out is too short.
I'll submit a PR with increased timeout. Let's see if we reconstruct it.

Not happen anymore. closing the ticket


Bump Hugo to 0.56.1

Signed-off-by: Michael Smith<EMAIL_ADDRESS>

The right way to fix this is automate deploying the website. But for now we may need to frequently bump Hugo version in Travis (and our workstations) to keep up-to-date.


Add gemspec files to allow bundler to run from the gem

/cc @jkeiser

@tyler-ball Hey - I'm getting a travis failure that I'm pretty sure is unrelated to my change.   My branch is hitting similar things.

@ksubrama :+1: anyway, it won't make it worse and youth should be able to get this endeavor off your mind! Consider this a :+1: (and a taking of the blame) for any other remaining repositories.


[MRG] Add events/annotations tutorial

From the whish list in #5201 it mainly addresses point 4.

@massich do we need this for 0.17? If so it's likely to be one of the last blockers for release

yes, we need this one. And goes after #5695

From the whish list in #5201 it mainly addresses point 4 which is the urgent part to get in 0.17. (So I'll edit the PR description)

rendered https://10162-1301584-gh.circle-artifacts.com/0/html/auto_tutorials/plot_events_and_annotations.html

There's still one broken link.

I don't understand why this link does not work
ref:`sphx_glr_auto_tutorials_plot_artifacts_correction_rejection.py`

its the same as this is linking to. But here renders properly. I don't get it.

One thing I noticed -- orig_time is stored as float in mne.Annotations and tuple of int everywhere else (as meas_date). Did we make this property public this cycle? If so we should probably change it to be consistent. If not then we'll have to live with it I guess.

I think I've addressed everybody's concerns. What I did not manage is to link to the annotations attributes. (ie: :attr:orig_time <mne.Annotations.orig_time>) To do so, the Annotations parameters should be replicated under the title Attributres ('cos we need them as Parameters and Attributes) but even then the corssreferencing was not working for me. So I gave up. If someone is more skilled than me please push in this branch or make a PR in my fork.
@larsoner yes, they are inconsistent. I did not check if the inconsistency was released already. But I was certainly planning to correct it after the release due to #5699. And maybe find a better name for _handle_meas_date and expose it.
Please, give a read to the tutorial. Thx a lot.

Onsets no longer match:
[42.95597088 44.95597088 51.95597088]
[42.955971 44.955971 51.955971]

we should round at the microsecond

I pushed a commit that at least makes things pass on both systems. Had to use assert_allclose though. Maybe rounding is better

Pushed a better version that did not necessitate using assert_allclose (https://github.com/mne-tools/mne-python/pull/5699/commits/760640e75fff0c03735c608712fa4b3771640989)

It should be able to go in once green.

@jasmainak feel free to merge when you are happy

Looks really nice. Thanks @massich and @agramfort for the teamwork !

great !

please send a quick PR.

@agramfort sure thing, I have some other small suggestions. :)


Cannot receive pong with event handler

I've implemented my pong event handler like so
      self.socket.event.pong {
            print("PONG")
            self.dm.pongReceived = true
        }

except whenever I send a pong to this swift client, PONG is never printed to the console and thus, the event handler is never called. Is there anything I can do to fix this? I'm fairly sure my server is sending pongs correctly.

Looks like you are missing some syntax.
self.socket.event.pong = { _ in
    print("PONG")
    self.dm.pongReceived = true
}

I'm closing this issue for now. Please feel free to reopen if are still running into problems. Thanks!


Add @defgroup to define doxygen groups in graph.hpp

Also added @ingroup to some relevant concept, template alisas and function header docs to get an idea of how this works. This is experimental right now.
Changed doxygen comment style in a couple of places.

Error occurred  in Mac build. Unsure what that's about. I've only made changes to comments, so I'm going to merge.


Plan has invalid associations

I just installed and configured koudoku -- how do you pronounce that anyway? -- and found the Plan model has the following:
belongs_to :user
belongs_to :coupon

but the schema does not contain neither coupon_id nor user_id:
  create_table "plans", force: :cascade do |t|
    t.string   "name",          limit: 255
    t.string   "stripe_id",     limit: 255
    t.float    "price",         limit: 24
    t.string   "interval",      limit: 255
    t.text     "features",      limit: 65535
    t.boolean  "highlight",     limit: 1
    t.integer  "display_order", limit: 4
    t.datetime "created_at",                  null: false
    t.datetime "updated_at",                  null: false
  end

Thanks for pointing this out.
I'll have a look at the source code. Did you use the repository at andrewculver/koudoku/master or  rubygems?

I am using master. Thanks for looking in to this.

On Feb 16, 2015, at 1:18 AM, yas4891<EMAIL_ADDRESS>wrote:
Thanks for pointing this out.
I'll have a look at the source code. Did you use the repository at andrewculver/koudoku/master or rubygems?
—
Reply to this email directly or view it on GitHub.

@snowmoonsoftware Fixed this in the latest master. Thanks for reporting!


Plans for library improvements

Following our discussions on the standard libraries, could it be interesting to list libraries that would be important for usability and use this thread to keep track of it ?
Clobbering the standard libraries with many exotic modules is probably not a good idea but it may be an opportunity to add new features in the ucontrib folder. But maybe not, it is probably somewhat related to #691.
There seems to be consensus on the need for:

A complete library for String manipulation
Enough I/O mechanisms to write tests and debug in F* easily

How about:

Float support (#651) ?
System calls support ? Typically for Kremlin, @fournet underlined that  readv and writev can be really useful for buffer management.

Also:

bitvector library: @ProjectYoung has written one that can mapped in bijection with machine integers, where should it go ?

What else ?

Regarding I/O, support for marshalling/serialisation would be cool!


Cleanup load balance

Just renames variables to be more accurate and adds a comment explaining the intended use.
I actually cant think of how you would write a shotover config to make use of the "cloning = new connection" design, but that does seem to be the intended design.

"Connections" between transforms? Or upstream connections? Maybe max-connections gives the wrong idea when going upstream isn't necessarily one to one? 🤔
Just a random thought.