conditional pattern matching in functions

Conditional pattern matching in a function's with/orwith blocks exposes variables used in the pattern match in the surrounding scope.  Consider,
load "io".

function foo with n %if n > 1 do
    return 1.
end

println (foo 2).
println n.

Here the variable n is exposed in the surrounding scope.

Fixed. Moved scope declaration n 'handle_call'.

Fixed. Moved scope declaration n 'handle_call'.


Stacked, column shows empty chart unless I use 'group_by'.

I get a blank graph if I use 'stacked: true' and type 'column' for my series.
Any ideas?

If there is a template when you open an issue, it's so that I have the right information to help you.
Without those, it's a bit hard.
Please share your config and version.


aclocal

hi
Excuse my ignorance but what's the best way forward?
@ make && make install
libtool: Version mismatch error.  This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.
make: *** [Makefile:180: php_blake2.lo] Error 63
As root, I ran aclocal and then the ./configure --enable-blake2
step again, but get same error.
Thanks, Ian

No matter, followed steps here a bit better and it seems to have worked.
https://github.com/phpredis/phpredis/issues/784


Nuget release <IP_ADDRESS>

This looks really cool!
Trying to implement it into my own Blazor Wasm project, but looks like the current <IP_ADDRESS> code is not released as a nuget.
Would it be possible to create a nuget with the current code?
Or maybe some instruction on how to build and use it locally in another project?

I am glad that you find it useful :)
I am sorry to say that <IP_ADDRESS> does not seem likely, because I am waiting on https://github.com/pamidur/aspect-injector/issues/222 for a very long time now.
As it is now, <IP_ADDRESS> is not good enough to be released as a NuGet.
You can still download the solution and include the projects in your solution. You should probably update the NuGet packages that I used, because they are old now.
You can also right click on the project in Visual Studio 2022 and choose Pack to build a NuGet locally and include that in your solution.


Load override proposal

Blocking P/Invoke.
Copied proposal to below for convenience.
Summary
Load overrides mean a way to override loading native addresses.
This is useful in the following scenarios:

P/Invoke / statically linked scenarios, mobile.
Advanced Performance scenarios, such as pre-loading to improve AOT / linking / R2R

While this API can be used by Hand and is available for public use it is not designed to be particularly user friendly.
It is designed with SilkTouch as the primary user. (See PInvokeTableAttribute)
This proposal also somewhat defines the currently loose timeline of how addresses are loaded.
Contributors

Kai Jellinghaus, Maintainer (at time of writing), open source community.

Current Status

[x] Proposed
[ ] Discussed with API Review Board (ARB)
[ ] Approved
[ ] Implemented

Design Decisions
There are two separate interfaces to allow maximum flexibility, but also to define exactly at which point slot information is lost.
Proposed API
Note that this API may be changed in the future to use function pointers directly instead of IntPtrs.
This deliberately doesn't use nint.
/// <summary>
/// Defines a Load override, capable of loading some entrypoints by name.
/// </summary>
/// <remarks>
/// Load overrides may not cache loads.
/// Load overrides have to be thread safe.
/// </remarks>
public interface INameLoadOverride
{
    /// <summary>
    /// The <see cref="INativeContext"/> used for loading
    /// </summary>
    INativeContext Context { set; }

    /// <summary>
    /// Attempt to load an entrypoint by name.
    /// </summary>
    /// <param name="entrypoint">The entrypoint name to load</param>
    /// <param name="address">The address that was loaded</param>
    /// <returns>
    /// Whether the load was successful.
    /// </returns>
    bool TryLoad(string entrypoint, out IntPtr address);
}

/// <summary>
/// Defines a Load override, capable of loading some entrypoints by slot.
/// </summary>
/// <remarks>
/// Load overrides may not cache loads.
/// Load overrides have to be thread safe.
/// </remarks>
public interface ISlotLoadOverride
{
    /// <summary>
    /// The <see cref="INativeContext"/> used for loading
    /// </summary>
    INativeContext Context { set; }

    /// <summary>
    /// Attempt to load an entrypoint by name.
    /// </summary>
    /// <param name="slot">The slot to load</param>
    /// <param name="address">The address that was loaded</param>
    /// <returns>
    /// Whether the load was successful.
    /// This will flush the cache / VTable.
    /// </returns>
    bool TryLoad(int slot, out IntPtr address);
}

Not a critical change, but would make sense to make the core easier to understand:
- public interface INativeContext
+ public interface IAddressLoader
 : IDisposable
{
-    IntPtr GetProcAddress(string proc);
+    IntPtr GetProcAddress(string entrypoint);
}

public abstract class NativeApiContainer
{
    /// <summary>
    /// Registers an <see cref="INameLoadOverride"/> to participate in loading.
    /// </summary>
    /// <remarks>
    /// This method is thread safe.
    /// This will flush the cache / VTable.
    /// </remarks>
    void RegisterOverride(INameLoadOverride override);
    /// <summary>
    /// Registers an <see cref="ISlotLoadOverride"/> to participate in loading.
    /// </summary>
    /// <remarks>
    /// This method is thread safe.
    /// This will flush the cache / VTable.
    /// </remarks>
    void RegisterOverride(ISlotLoadOverride override);
    /// <summary>
    /// Registers multiple <see cref="INameLoadOverride"/>s to participate in loading.
    /// </summary>
    /// <remarks>
    /// This method is thread safe.
    /// This will flush the cache / VTable.
    /// </remarks>
    void RegisterOverrides(IEnumerable<INameLoadOverride> overrides);
    /// <summary>
    /// Registers multiple <see cref="ISlotLoadOverride"/>s to participate in loading.
    /// </summary>
    /// <remarks>
    /// This method is thread safe.
    /// This will flush the cache / VTable.
    /// </remarks>
    void RegisterOverrides(IEnumerable<ISlotLoadOverride> overrides);

    // override address loader is thread safe.
    private sealed class OverrideAddressLoader
    {
        // this is loader falls back to the normal _loader, but first calls into overrides.
        // an instance is kept around and recreated whenever a new override is registered.
        // for performance reasons it may make sense to defer the creation of this to a Lazy<OverrideAddressLoader>

        public IntPtr Load(int slot, string entrypoint);
    }
}

Load overrides MAY NOT cache addresses.
These APIs work together with the IVTable, which is the caching solution.
Address loading timeline

NativeApiContainer.Load(int, string)

VTable

if cached, return the cached result
otherwise

OverrideAddressLoader.Load(int, string)

calls slot overrides in order, returning the first result.
if none were able to resolve the slot, calls entrypoint overrides in order, returning the first result.
if none were able to resolve the entrypoint, calls down to the given fallback loader.

result cached.

Open Questions

it's unclear how this would work with VTable preloading, we don't use that in Silk.NET right now, so not a problem (for now).
it's unclear how a user that manually swaps VTables (think Vulkan) would handle it if another user registered an override. there is no way to detect this. Likely, such a user would just not handle this.

Generally rejected proposals are kept in the repo.


Cannot transclude md-hint to md input between 2 components

Bug, feature request, or proposal:
Is this an angular problem ? or just md-input implementation ?
I created in my project an autocomplete component which has an md-input, and I want to make it work like md-inputs including md-hint, placeholder, suffix, preffix transclusion. The problem is that I cannot transclude the content between two components.
The first component is this one for exemple
<my-test>
  <md-hint>This is my hint</md-hint>
</my-test>

And the test component template looks like this
<div>
      <md-input placeholder="Test">
        <ng-content selector="md-hint"></ng-content>
      </md-input>
</div>

What is the expected behavior?
I would expect to transclude the content from my-test to md-input
What is the current behavior?
The content is not transcluded
What are the steps to reproduce?
Here is a plunker which reproduces the problem: https://plnkr.co/edit/ePMygDJa33Ev5H85wpNz?p=preview
What is the use-case or motivation for changing an existing behavior?
I want to have a generic form component. Here is the repository link for the exact case I want
. What I want to do is to create a generic behavior between forms so I can use this component over my applications. Besides material design components I want to add a few more which I think are usefull.
Which versions of Angular, Material, OS, browsers are affected?
Is there anything else we should know?
Package.json libraries versions.
"@angular/common": "^2.3.1",
"@angular/compiler": "^2.3.1",
"@angular/core": "^2.3.1",
"@angular/forms": "^2.3.1",
"@angular/http": "^2.3.1",
"@angular/material": "^2.0.0-beta.1",
"@angular/platform-browser": "^2.3.1",
"@angular/platform-browser-dynamic": "^2.3.1",
"@angular/router": "^3.3.1"

md-input-container looks for a view child <md-hint> in your example there is no view child <md-input> (only a content child one). in order to make something like this work you could do:
<my-test>
  <my-hint>This is my hint</my-hint>
</my-test>

<md-input-container>
        <input mdInput placeholder="Test">
        <md-hint><ng-content select="my-hint"></ng-content></md-hint>
</md-input-container>


add Alloy app

Towards: https://github.com/giantswarm/roadmap/issues/3524
This PR adds Alloy application into the observability bundle for it to be used as a logging agent in place of Promtail.

If it's alloy for logs, maybe we should name it alloy-logs?
Because we have one for the rules, one for the logs, maybe one for metrics later...
so we need to quickly understand which one does what.

I would prefer that we do not name this alloy at all but something like logging-agentso it's easier to change the implementation if we want to

If it's alloy for logs, maybe we should name it alloy-logs? Because we have one for the rules, one for the logs, maybe one for metrics later... so we need to quickly understand which one does what.

Good point, I renamed it to alloy-logs.

I would prefer that we do not name this alloy at all but something like logging-agentso it's easier to change the implementation if we want to

I don't think this make it easier for future change. There will be a need to transition from the old to the new agent, if we go through a toggle as we do now we need to have 2 distinct names. Also we can still rename this later if we want to, so I would rather continue with the current naming.

So I'm thinking long term here where we actually provide an api for customers and i don't think they should care about the name of the tool underneath. I find a bit weird that you talk about app name being useful for us but yet you use the same config name :D
IMO, we should strive to have our apps named:

logging-agent (to replace promtail)
cluster-agent for cluster level stuff like events
MAYBE metrics-agent

but it's not like I'll block here, we don't have an API yet

Are we fine with this then ?

No i am definitely not. But I definitely feel alone in that so I will not block but I will not approve

What are the implications of renaming it later?

probably references in docs and opsrecipes will have to be updated
does upgrade break anything?
if configmaps and secrets change name, it means logging-operator has to know about it as well, but it seems not

So, if I didn't miss anything, the only impact is on documentation.
And as we're not sure what would be the proper name, whatever we chose we may have to change it again in the near future, right?
What if we name it logging-agent but the app changes again?

we need a toggle to control when/where we do the switch
we don't have a clear interface there, and have no clue how we would manage it for now

What if we end up with one more level of abstraction, and we have a logging-agent that points to alloy-logs but it's already named alloy-logs? (oops, that may be not clear, but it's not in my head either :sweat_smile: )
It's not clear to me how we should phase it, especially because AFAIK there's no plan for this interface yet.
But whether it's named alloy-logs or logging-agent now, I'm fine with both.

I'm reacting "a chaud" si i'll digest this and try to explain my thoughts and reasoning tomorrow :)

What are the implications of renaming it later?

probably references in docs and opsrecipes will have to be updated
does upgrade break anything?
if configmaps and secrets change name, it means logging-operator has to know about it as well, but it seems not

So, if I didn't miss anything, the only impact is on documentation.

Well, not only, this means we will have to be more careful when we rename the app and be careful with bundle versionning once again.

And as we're not sure what would be the proper name, whatever we chose we may have to change it again in the near future, right?

That is true, maybe this will become node-observability-agent later on, we cannot know for sure in the long long run. I think naming tools via their feature instead of their names makes it easy to switch the underlying technology as long as the protocol stays the same. This is one of the reason otel is a good standard for instance. My current thinking is we probably should not have a mimir ingress but a monitoring ingress at the installation level so we sould not have had to switched it when we moved from Prometheus from Mimir for instance) and that I why I'm getting more interested in naming things right

What if we name it logging-agent but the app changes again?

we need a toggle to control when/where we do the switch
we don't have a clear interface there, and have no clue how we would manage it for now

What if we end up with one more level of abstraction, and we have a logging-agent that points to alloy-logs but it's already named alloy-logs? (oops, that may be not clear, but it's not in my head either 😅 ) It's not clear to me how we should phase it, especially because AFAIK there's no plan for this interface yet.
But whether it's named alloy-logs or logging-agent now, I'm fine with both.

This "API" and naming convention is a different topic by itself and is out of scope for this PR. I suggest we move on with this PR and take this topic into a separate issue and go through this altogether in a meeting.

We should probably make this an epic cc @Rotfuks

We should probably make this an epic cc @Rotfuks

I added it to the roadmap.
Naming and Caching...right? :D I honestly have no stakes here - I don't think at this point in our implementation the name of the component makes a difference, because we also name it grafana app and mimir and loki and all :)


atf: Rework the way to provide RCAR_BL33_EXECUTION_EL

To start CPU cores in EL2 mode we need to compile IPLs with the
option RCAR_BL33_EXECUTION_EL=1. But original recipe has
complilation of loaders separated into two different functions:
do_compile() and do_ipl_opt_compile().
do_compile() produces binaries for early versions of boards and
is not used by our products.
do_ipl_opt_compile() produces IPLs for newer boards and it uses
variable flags like H3ULCB[4x2g] and H3[2x2g] to specify
compiler options.
This patch appends  RCAR_BL33_EXECUTION_EL=1 to required
varFlags, so we will have EL2 mode.

I'm perfectly fine with this approach, but I'm not sure that you need anonymous Python function

Tested build for

h3ulcb-kf
salvator-x
m3

After test with M3 I found that we still need to use ATFW_OPT_append for boards without memory variants.

Reviewed-by: Volodymyr Babchuk<EMAIL_ADDRESS>

RB is added.
The patch is tested for H3, H3ULCB and M3.
@iusyk could you please merge?


Positional arguments by default

First, thanks for this library. I was looking for an alternative to Typer and ran into this. Just great !
Currently I am playing around with it a bit and have a question:
When using the dataclass approach, is it possible to consider each property which doesn't have a default value as a positional value?
See also the below code:
from dataclasses import dataclass
from typing import Annotated

import tyro
from tyro import conf

@dataclass
class Car:
    """A car class"""

    name: Annotated[str, conf.Positional]  # <-- this seems to be only way to indicate some property is positional.
    """The name of the car."""

    color: str
    """The color of the car."""

if __name__ == "__main__":
    result = tyro.cli(Car)

Hi, sorry for missing this!
The short answer is not a clean one.
If you want something shorter, you can drop the Annotated[]:
@dataclass
class Car:
    """A car class"""

    name: conf.Positional[str]
    """The name of the car."""

    color: conf.Positional[str]
    """The color of the car."""

if __name__ == "__main__":
    result = tyro.cli(Car)

You can also apply Positional to all arguments, but this will include ones with defaults:
@dataclass
class Car:
    """A car class"""

    name: str
    """The name of the car."""

    color: str
    """The color of the car."""

if __name__ == "__main__":
    result = tyro.cli(conf.Positional[Car])

Marking positional arguments in a function with / could also work:
def main(name: str, color: str, /, [kwargs]) -> None:
    ...

tyro.cli(main)

Or you can move the positional arguments into a separate class:
@dataclass
class Positional:
    """A car class"""

    name: str
    """The name of the car."""

    color: str
    """The color of the car."""

@dataclass
class Args:
    """A car class"""

    positional: Annotated[Positional, conf.arg(name=""), Positional]
    # keyword arguments here

tyro.cli(Args)

No problem man!
Thanks for the elaborate writeup!
These are really valuable examples. I'll have a look which one will fit me best.
Personally I see value in a config flag which you put into the tyro.cli() call which will make all required arguments (the ones without default value in your @dataclass a positional one.
Not sure if that fits the overall design of tyro, but if you think so, I am willing to invest time in investigating that.

Definitely interested in what you end up converging to!
For putting an option that automatically marks required arguments as positional: I could be convinced (especially if you have time for a PR!), but would be interested in your thoughts on the solutions above first. The main thing for me is weighing the extra complexity + maintenance effort against the relative usability gain.

From the examples above I would definitely go for your first example:
@dataclass
class Car:
    """A car class"""

    name: conf.Positional[str]
    """The name of the car."""

    color: conf.Positional[str]
    """The color of the car."""

if __name__ == "__main__":
    result = tyro.cli(Car)

I understand. And playing around with tyro some more I don't really know how I would implement this.
My first idea is to have some global setting where you do something like : arg_without_default__set_as_positional.
This would fit better with my thinking about a normal function call where, arguments without defaults are positional and with defaults are keyword arguments.
def enter_name(
    name: str,  # <-- positional
    last_name: str|None = None  # <-- keyword

But I don't think that will play nice with the already existing options of setting positional arguments.
More in general I think tyro needs some mind-shift in usage when coming from -for example- ArgParse or Click.
By that I mean the handling of subcommands for example, where in Tyro this is kind of hard to do:
git branch list

in Tyro this becomes (if you go for the dataclass approach at least)
git branch cmd:list

One option is we can follow the current tyro.conf pattern and enable something like tyro.cli(conf.PositionalRequiredArguments[YourArgsStructure]). Implementation would not be too hard, I'm just not sure it's a better enough experience over existing options to warrant existing.
What was your issue with this pattern?
def enter_name(
    name: str,  # <-- positional
    /,  # mark end of positional arguments
    last_name: str | None = None  # <-- keyword
)

Also, to enable this:
git branch list

You can wrap your Union with tyro.conf.OmitSubcommandPrefixes[].

One option is we can follow the current tyro.conf pattern and enable something like tyro.cli(conf.PositionalRequiredArguments[YourArgsStructure]). Implementation would not be too hard, I'm just not sure it's a better enough experience over existing options to warrant existing.

I guess it's a design choice (of which I only have little knowledge of the context in which it is made). But in my (narrow) context I would have preferred positionals by default for arguments which have no default value.
So my preferred implementation would be a flag to set such behaviour globally, but that might be difficult in combination with the current implementations (?)

What was your issue with this pattern?
def enter_name(
    name: str,  # <-- positional
    /,  # mark end of positional arguments
    last_name: str | None = None  # <-- keyword
)

Nothing wrong with that pattern, but for me the beauty of tyro lies in its usage of dataclasses  (or in my case pydantic classes) for cli creation.

Also, to enable this:
git branch list

You can wrap your Union with tyro.conf.OmitSubcommandPrefixes[].

I am sure I tried that but failed. I'll try again and report back.

The tyro.conf.OmitSubcommandPrefixes are for removing prefixes on the arguments of a subcommand. Not on the subcommand itself.
from dataclasses import dataclass
import tyro
from tyro import conf

@dataclass
class List:
    verbose: bool = True

    def main(self) -> None:
        print(self)

@dataclass
class Create:
    name: str

    def main(self) -> None:
        print(self)

@dataclass
class Branch:
    cmd: tyro.conf.OmitSubcommandPrefixes[List | Create]

    def main(self) -> None:
        print(self)
        self.cmd.main()

if __name__ == "__main__":
    result = tyro.cli(Branch)

The subcommand in Branch still needs to be called by cmd:list or cmd:create. But the arguments for -for example- cmd:list don't have the cmd: prefix anymore. (--verbose instead of --cmd:verbose).

So my preferred implementation would be a flag to set such behaviour globally, but that might be difficult in combination with the current implementations (?)

It seemed quick, so I gave implementing the tyro.cli(conf.PositionalRequiredArgs[YourArgsStructure]) pattern I suggested a try in #66; do you have time to give it a try? The PositionalRequiredArgs configuration "marker" would be applied recursively to all fields inside of YourArgsStructure, and any required arguments would become positional. This seems consistent with what you're describing.
For the prefixing: sorry for my confusion; tyro.conf.subcommand(prefix_name=False) will do what you're asking about (docs). It's unfortunately verbose, but here's a runnable example:
import dataclasses
from dataclasses import dataclass
from typing import Annotated, TypeVar, Union

import tyro
from tyro import conf

T = TypeVar("T")
RemovePrefix = Annotated[T, conf.subcommand(prefix_name=False)]

@dataclass
class List:
    verbose: bool = True

    def main(self) -> None:
        print(self)

@dataclass
class Create:
    name: str

    def main(self) -> None:
        print(self)

@dataclass
class Branch:
    cmd: tyro.conf.OmitSubcommandPrefixes[RemovePrefix[List] | RemovePrefix[Create]]

    def main(self) -> None:
        print(self)
        self.cmd.main()

if __name__ == "__main__":
    result = tyro.cli(Branch)

I did a quick test on the required as positional. This seems to work ! Thanks for making this work so quickly.
I'll be able to check in more detail, and the subcommand example later this weekend. Thanks a 1000!


ARC-278 Added push SQS queue [DRAFT]

This PR is currently a draft

Currently testing it in staging.
Ready for review, however a few things which I am still going to add in this PR:

[ ] tests for sqs push handler
[ ] consider if we can have a flag to disable the handler reading from sqs

I've added tests in a separate PR https://github.com/atlassian/github-for-jira/pull/884


Fix Ui bugs related to listView

Will make the testcases later if no objections

Have tried it out and it works! Thanks for the fix :)


WOF table Override file for 30BC Processor

This change is limited to FW1050.10 for a customer POC. And this change will not effect existing customer because this processor is not Generally Available.  Wof override bin tar file for 30BC processor sort for 1050.10 target.

Verified that the WOF binary in Everest-MRW.WofSetBins.tar.gz is correct for this Everest 30BC specific override.

Defect Opened
https://jazz07.rchland.ibm.com:13443/jazz/web/projects/CSSD#action=com.ibm.team.workitem.viewWorkItem&id=595589


fix: wrong module path on pulse source in main.rs

I ran into this when trying to build this project with the pulseaudio feature enabled.

thanks a lot for catching this!


updaters are not creating for pointer types

subj,
SetField() was not created for pointer types fileds

thank you, fixed


added test for osm files

Pull Request Test Coverage Report for Build 3153

12 of 12 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 89.455%

Totals

Change from base Build 3149:
0.2%

Covered Lines:
7779

Relevant Lines:
8696

💛  - Coveralls

I am unsure about the merge conflicts. Perhaps this PR is obsolete?

merge conflict resolved


Upgrade Arrow Java project to JPMS Java Platform Module System

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

This is roughly comparable to where #13072 got to, minus the actual module-info.java files.
With the following additions:

Built on the current state of main
Updated gRPC to a module-friendly version (1.59).
Updated plugin dependencies to module-friendly versions.
Staged to compile the codebase with Java 8, with the exception of module-info files which will use a custom plugin (to be added. this is already implemented at https://github.com/Bit-Quill/maven-module-info-compiler-plugin and needs to get integrated to the Arrow build).

@davisusanibar @lidavidm @danepitkin
Next up will be adding the maven plugin, then adding the module-info files from #13072, then modularizing other modules such as algorithm, adapters, ...

This suggests that we need to install JDK 9+ on some of the build agents:
https://github.com/apache/arrow/actions/runs/6982068919/job/19000467907?pr=38876#step:6:791

This failure is happening for somewhat complicated reasons:
https://github.com/apache/arrow/actions/runs/6983421948/job/19004513065?pr=38876#step:6:2511
Before refactoring, the allocator used by this test would be the Netty module's DefaultAllocationManagerFactory since TestBaseAllocator lived in the Netty module. This one correctly returns a non-zero value when given a zero-allocation.
After refactoring, TestBaseAllocator lives in memory-core, and uses the dummy DefaultAllocationManagerFactory in memory-core's tests.  This one however does return zero when given a zero-allocation. This might itself be a bug unrelated to the refactoring. This calls MemoryUtil.UNSAFE.allocateMemory(), which calls sun.misc.Unsafe.allocateMemory(), which is supposed to return a non-zero value.

I'm not sure what's happening in this CI failure after the Netty refactoring.
This test was in TestBaseAllocator before, but that test class got moved to memory-core. This test got separated into its own test class, moved back to Netty core (because it has Netty dependencies and wouldn't build in memory-core), and now throws a ConcurrentModificationException.

Error:  org.apache.arrow.memory.netty.TestNettyAllocator.testMemoryUsage  Time elapsed: 0.317 s  <<< ERROR!
java.util.ConcurrentModificationException
at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1604)
at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129)
at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:632)
at org.apache.arrow.memory.netty.TestNettyAllocator.testMemoryUsage(TestNettyAllocator.java:56)

I'm not sure what's happening in this CI failure after the Netty refactoring.
This test was in TestBaseAllocator before, but that test class got moved to memory-core. This test got separated into its own test class, moved back to Netty core (because it has Netty dependencies and wouldn't build in memory-core), and now throws a ConcurrentModificationException.

Error:  org.apache.arrow.memory.netty.TestNettyAllocator.testMemoryUsage  Time elapsed: 0.317 s  <<< ERROR!
java.util.ConcurrentModificationException
at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1604)
at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129)
at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:632)
at org.apache.arrow.memory.netty.TestNettyAllocator.testMemoryUsage(TestNettyAllocator.java:56)

This didn't happen in my last test run and all I did was change the module info computer plugin to inherit its version. So this is probably a threading issue. Maybe extracting this test from other TestBaseAllocator tests is causing them to run in parallel when they weren't before.

This failure is happening for somewhat complicated reasons: https://github.com/apache/arrow/actions/runs/6983421948/job/19004513065?pr=38876#step:6:2511
Before refactoring, the allocator used by this test would be the Netty module's DefaultAllocationManagerFactory since TestBaseAllocator lived in the Netty module. This one correctly returns a non-zero value when given a zero-allocation.
After refactoring, TestBaseAllocator lives in memory-core, and uses the dummy DefaultAllocationManagerFactory in memory-core's tests. This one however does return zero when given a zero-allocation. This might itself be a bug unrelated to the refactoring. This calls MemoryUtil.UNSAFE.allocateMemory(), which calls sun.misc.Unsafe.allocateMemory(), which is supposed to return a non-zero value.
I'm going to @ignore this test for now.
Should these allocation manager factorys return a non-zero address when the user asks for an empty allocation? I would assume so since C-allocators have this property.
@davisusanibar , did you see anything like this? @lidavidm @danepitkin , any thoughts around this?

Thanks for pushing this feature, James. I am observing changes. Does this problem persist?

This failure is happening for somewhat complicated reasons: https://github.com/apache/arrow/actions/runs/6983421948/job/19004513065?pr=38876#step:6:2511
Before refactoring, the allocator used by this test would be the Netty module's DefaultAllocationManagerFactory since TestBaseAllocator lived in the Netty module. This one correctly returns a non-zero value when given a zero-allocation.
After refactoring, TestBaseAllocator lives in memory-core, and uses the dummy DefaultAllocationManagerFactory in memory-core's tests. This one however does return zero when given a zero-allocation. This might itself be a bug unrelated to the refactoring. This calls MemoryUtil.UNSAFE.allocateMemory(), which calls sun.misc.Unsafe.allocateMemory(), which is supposed to return a non-zero value.
I'm going to @ignore this test for now.
Should these allocation manager factorys return a non-zero address when the user asks for an empty allocation? I would assume so since C-allocators have this property.
@davisusanibar , did you see anything like this? @lidavidm @danepitkin , any thoughts around this?

Thanks for pushing this feature, James. I am observing changes. Does this problem persist?

Yes this still happens. I have marked the test as ignored to get past it.
It's not clear if this is a new bug or if it is exposing a bug from the memory-core test version of DefaultAllocationManagerFactory.

I'm looking for some ideas on how to fix up a maven issue. I've rigged the general build configuration in the parent POM to continue to use JDK 8 and exclude module-info.java files. I've also shut off using the module path for dependencies.
In the memory-netty build, I need a profile (that runs on JDK9) that compiles using the module-path for dependencies (using the  flag added to maven-compiler-plugin 3.11.0). It needs to run an extra command to patch code from another JAR into some of the packages that Netty modules export. I'd also like to compile module-info.java for this.
I likely need two executions for the Netty build. One that compiles everything in JDK8 except module-info.java, and one that uses JDK 9, compiles module-info.java and does the patch command. I don't want to compile anything else with JDK9 since I need to generate JDK8 bytecode for everything else (or I can compile everything in JDK9, then recompile everything except module-info.java in 8)
The problem I'm seeing is that setting the flag for setting the  flag in the profile's configuration isn't taking effect. This problem happens when both when it's an execution-level configuration or a plugin-level configuration. It does take effect when set on the parent POM.

The test errors in memory-core have this cause:
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field long java.nio.Buffer.address accessible: module java.base does not "opens java.nio" to module org.apache.arrow.memory.core
I've addressed this is in maven by adding --add-opens java.base/java.nio=org.apache.arrow.memory.core, but perhaps I haven't covered a profile that CI is using. If anyone has any ideas on what else might need to be edited that'd be really helpful.

This PR has alot of changes. Perhaps we handle other modules (such as Flight, algorithm, dataset) in a separate PR so that this one can close.

These changes are requiring alot of patching/add-opens calls to work (see the changes It is very unfriendly for the user.
https://github.com/apache/arrow/pull/38876/files#diff-d8225ebcfc11b480a6e4f54e183b67c3ead51635a167c106d928c2abf1f9ef66R892
The patch-module call is particularly difficult because we, and the user, do not necessarily know where their JARs are.

I'm not going to be able to review this for a while.
FWIW, I would be fine deferring other modules for another PR, and I would also be fine saying that arrow-memory-netty is just not supported when using modules because of the patching it does.

Given how new this is, I would even be OK saying that the only supported memory implementation is the Java 21+ one to begin with and we can see if there is even demand to use memory-unsafe or memory-netty.
Finally, if there's need to reorganize which package files live in, maybe we could split some of that into another PR.

Only looking at the memory changes, they seem reasonable.
Is there a way to get rid of the classes declared in Netty's namespace? Or is what we're trying to do still not possible with just the public APIs?

The classes in the Netty namespace need to stay there. They call package-private functions on Netty classes.


Make the hero Section Look like the mockup

ill be working on this

I finished working in it

@UnderDaHood if it is finished, make sure the pr is linked to the issue


Suggestion: auto-generate RESET animation

Not a big deal as this plugin is only about two tracks: Frame and Animation which are easy to generate RESET tracks for using:
click on the first key of every unique track > right-click > Add Reset Value(s)
However, because of https://github.com/godotengine/godot/issues/85781 we must also remember to set interpolation mode to Discrete of both RESET tracks to avoid warnings. Do this for many animated entities and that's a lot of extra boilerplate work.
So if the plugin was able to detect unique tracks and add them to the RESET animation, it would be great.
We'd need to decide what the RESET values would be though. Maybe we could add a parameter field besides AnimatedSprite2D/3D Node, "RESET animation" which would be "default" by default. Or we could just pick the first value we find across animations, but then we'd have to print Output to remember user to customize the RESET values manually if needed after Import.
Note: RESET animation is not required, but my code explicitly refreshes animation by playing Reset because of this bug: https://github.com/godotengine/godot-proposals/issues/6417

I think just using the first animation in the SpriteFrame resource should be good enough, most people probably have that animation as their "idle" or starting animation.

Maybe we could add a parameter field besides AnimatedSprite2D/3D Node, "RESET animation" which would be "default" by default.

If we go this route ideally it would be a drop-down list of options based on the currently selected animation player, but this might be a bit complicated.
I'm okay with both solutions, if you plan on implementing this I'll leave it up to you.


Trim whitespace before applying text formatting during markdown export

When typing and combining different text-format's on text nodes, i.e. "bold italic" it's easy to break the markdown export as it currently applies the formatting characters around included whitespace.
i.e. "  foo  " becomes "**  foo  **" when we actually want it to be "   **foo**   "
This PR fixes that

Before:

After:

closes #2250

Unless I'm mistaken, I think these test failures are flakey and not a result of my PR


Reduce the amount of DHCP log spam

Now that we're using a short lease we generate a lot of logs: one
line per BOOTREQUEST and BOOTREPLY every half (?) lease interval.
This patch logs the first BOOTREQUEST and first BOOTREPLY as info
rather than debug since these are genuinely useful things to see
in the logs. Subsequent BOOTREQUEST and BOOTREPLY messages are
suppressed. Other message types are logged as info.
Signed-off-by: David Scott<EMAIL_ADDRESS>

I'd like to update D4M/D4W today to get more testing of the previous patches. I'll merge this to avoid complaints about log-explosions, but feel free to raise objections to this and I'll address them retrospectively.


Can't use validated formula field for current step value

Tried to use the following text formula field for the current step value:
If( ISBLANK(TEXT({!recordId.Contract_Status__c})), "Not Started", TEXT({!recordId.Contract_Status__c}) )
When I ran the flow, I received the following error:
Conditional visibility rule error on currentContractStatusFormula field: Field recordId.Contract_Status__c is a picklist field. Picklist fields are only supported in certain functions. Tell me more.
I've verified the output of the formula is the string I need for the current step.

Hi @jameskbw - interesting, thanks for posting.  Your formula seems like proper syntax, but maybe it's not the formula.  The error message seems to be about using the formula in a conditional visibility rule for showing/hiding a component on the screen.  Are you using it in that way?  I ask because the error message doesn't seems related to the functioning of the LWC itself.

I am using a visibility filter on the dynamic flow progress component, but that is not the issue as it's not related to the formula field and it works fine once I change the current step to something other than the formula. The only time I get an error is when I use the formula field in the current step input.
I changed it to a text variable, and that works fine but is less ideal.


[Bug] LocalizationResourceManager.Current.CurrentCulture crashes app

Description
When using XCT with LocalizationResourceManager I get weird crashes when I set a new culture on language switch in the settings page:
LocalizationResourceManager.Current.CurrentCulture = cult;
When I restart the app, the same line is used on App startup and then I see the correct language. This worked before.
All the latest libraries and iOS version. Will test later on Android and with a test project.
Stacktrace
In App center I see this, not sure if it's related:

0x0000000102c74000 + 62754000
SIGABRT: *** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0]

Last Exception Backtrace

    CoreFoundation
    __exceptionPreprocess
    libobjc.A.dylib
    objc_exception_throw
    CoreFoundation
    _CFThrowFormattedException
    CoreFoundation
    -[__NSPlaceholderArray initWithObjects:count:]
    CoreFoundation
    -[__NSPlaceholderArray initWithObjects:count:]
    CoreFoundation
    +[NSArray arrayWithObjects:count:]
    MyApp.iOS
    0x0000000102c74000 + 62754000
    MyApp.iOS
    0x0000000102c74000 + 51190856
    MyApp.iOS
    0x0000000102c74000 + 51184416
    MyApp.iOS
    0x0000000102c74000 + 51184124
    MyApp.iOS
    0x0000000102c74000 + 51182116
    MyApp.iOS
    0x0000000102c74000 + 55589680
    MyApp.iOS
    0x0000000102c74000 + 77179188
    MyApp.iOS
    0x0000000102c74000 + 77160952
    MyApp.iOS
    0x0000000102c74000 + 77178864
    MyApp.iOS
    0x0000000102c74000 + 71633152
    UIKitCore
    -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:]
    MyApp.iOS
    0x0000000102c74000 + 62680232
    MyApp.iOS
    0x0000000102c74000 + 55144896
    MyApp.iOS
    0x0000000102c74000 + 2052236
    MyApp.iOS
    0x0000000102c74000 + 11417056
    MyApp.iOS
    0x0000000102c74000 + 123453168
    MyApp.iOS
    0x0000000102c74000 + 124216992
    MyApp.iOS
    0x0000000102c74000 + 124242344
    MyApp.iOS
    0x0000000102c74000 + 123314908
    MyApp.iOS
    0x0000000102c74000 + 125316604
    MyApp.iOS
    0x0000000102c74000 + 2047696

A bit more info: after the crash I directly see this in de device output:
2022-04-04 21:19:09.077973+0200 MyApp.iOS[34052:341665] Xamarin.iOS: Unable to locate assembly 'MyApp.resources' (culture: 'es-ES')
2022-04-04 21:19:09.090994+0200 MyApp.iOS[34052:341665] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N10__cxxabiv116__shim_type_infoE, id, N10__cxxabiv117__pbase_type_infoE.

This was posted 2 days ago by someone else about something iOS native, so maybe it has to do with some iOS change in recent version?
https://developer.apple.com/forums/thread/703309

@jtorvald,
Could you attach a small repro?

@pictos I'm trying to reproduce in a separate repo, but guess what: it works there. I will dig a bit deeper this week to see if I can find the cause.

Thank you @jtorvald

@pictos After hours of debugging to see what changed I came to the point where the crash happens because of a TabView being used in an active page in shell (not the current page but still in the background). Not sure how relevant but that tabview is used within a StateView.
In the sample project I use now the culture change works, but that is probably because it happens on the same page. So I would need to create a separate settings screen there in the same way to see if I can reproduce the error then. No time for that at this moment so... to be continued.

@jtorvald no problem, take your time. I can there's a lot of elements in the equation, having a repro will help a lot, thanks for moving this forward

@jtorvald Have you been able to solve this issue?


Unable to match different label types in one Flow

Describe the bug:
We are using different label types in our cluster.
kubernetes.label.app: foo
kubernetes.label.app.kubernetes.io/name: bar

Trying to match mixed type labels with one flow fails. The following flow definition results in no matched messages.
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: flow-sample
  namespace: default
spec:
  localOutputRefs:
    - es-output
  match:
    - select:
        labels:
          app: foo
          kubernetes.label.app.kubernetes.io/name: bar

Expected behaviour:
Messages should match regardless of label type.
Steps to reproduce the bug:

deploy two apps with different type labels to one namespace.
Try to match both labels in a flow with a label selector.

Additional context:
There are several issues reported around label type mismatch in EFK stack.
https://github.com/elastic/beats/issues/12638
https://discuss.elastic.co/t/filebeats-auto-mapping-of-kubernetes-labels-causing-big-issues/154718
Possibly it is worth adding dedot filter for labels and anotations to fluentbit configuration and as well generate fluentd config using dedoted labels
Environment details:

logging-operator version 3.9.5

/kind bug

if you mean an OR you need to create another  select block:
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: flow-sample
  namespace: default
spec:
  localOutputRefs:
    - es-output
  match:
    - select:
        labels:
          app: foo
    - select:
        labels:
          kubernetes.label.app.kubernetes.io/name: bar

See documentation: https://kube-logging.github.io/docs/configuration/log-routing/#example-6-multiple-labels---or

thanks @genofire for clarifying, closing this now


[Bug] Server crashes after leaving

After updating from 1.16.5 to 1.17 using the same world everytime my gf leaves it crashes the server. Nothing happens when i leave though (merling). Unsure whether it has to do with the third-party origin she's using (vampire from Haema mod) or something else.
crash.txt
If you need any additional info i'll try my best to provide you with it

I don't know what could be causing this. The crash seems to come from the getSpawn method, but I'm unsure why that would be called when a player leaves the server. Do you have a list of other mods you have installed? Maybe there is some mod that does something with your spawn on logout (e.g. teleport you to the spawn for logout? Idk...).


add R script for fetching gridmet

This is the quick script that I have used to pull gridMET data for point locations. It's written in R and relies on the climateR package. I haven't formally incorporated it in the snakemake file as we might revisit in the future, but I wanted to get it on the repo

Merging this huge pull request and then I will revert the commits that actually need review


Added deepseek and antropic keys, but don't see deepseek and antropic models in dropdown

how to look Claude 3.5 sonnet and DeepSeek coder?

oh ;) sorry just scroll up by mouse


[WIP] p and hp refinement support [p-refinement-dev]

Work in progress on variable order FE collections and spaces.
Early comments welcome.
TODO:

[x] Variable order FiniteElementCollection and H1_FiniteElementCollection
[x] Multiple sets of DOFs on edges and faces
[x] p-FEM constraints in P matrix in 2D
[x] Variable order L2_FiniteElementCollection
[x] Visualize variable order solution (prolong to max order for the time being)
[x] hp-FEM constraints in P matrix in 2D
[x] Variable orders in 3D (faces)
[x] hp cases in 3D
[ ] hp demo miniapp - get correct convergence on benchmark problems
[ ] Save/load variable order Space
[ ] Update GLVis for var. order spaces?
[ ] Parallel space
[ ] Update ND and RT collections
[ ] Other updates/fixes in the collections
[ ] Update CHANGELOG

p refinement seems to work in 2D:

Solution:

Modest first attempts at hp-refinement (the easy case):

The hard case (slave edges are lower-order) of course has cracks:

Although when increasing the order (e.g., 3rd + 2nd) they quickly become less noticeable:

The pictures look great! 🎉
Regarding the cracks: these maybe just fine -- did you try to test convergence with uniform refinement of such mesh?

I think I figured out a simple way to handle the "hard" case, which might not be that hard after all. Since in p-FEM we already have to handle multiple sets of DOFs on each edge (several elements of different orders can meet at an edge, hence the new table edge_dof), and already in p-FEM the lowest order DOFs constrain all the higher order variants within the same edge, we can do something similar in the hp-case. A master edge wil have its natural DOFs assigned but also DOFs corresponding to the lowest degree slave (but still for the complete edge). The lowest order DOFs on the master edge will be the true DOFs (it doesn't matter they don't correspond to any element), that will contrain both the higher order DOFs on the master edge (as in p-FEM) and all the slave DOFs on the refined side.

So it seems to work. The deal.ii paper probably confused us unnecessarily. It's all really simple in the end: an edge can have multiple sets of DOFs assigned. If it's a conforming mesh, the lowest order DOFs are the true DOFs and the higher order sets interpolate the true DOFs. In case of hp-refinement, we check the orders of slave elements and add the lowest order DOFs to the master edge, if lower than the standard master edge DOFs (the master edge will thus have two sets of DOFs, even though it's directly shared by one element only (in 2D)). The lowest order DOFs are then interpolated by both the other master edge DOFs and all the slave DOFs.
Random mesh and orders in ex1:

One of the basis functions:

Since it's a simple matter of adding or not adding the lowest slave order to the master face DOFs, I added an option to FiniteElementSpace for the user to choose if they want strict conformity, or if the relaxed (discontinous) interpolation is OK:
fespace->SetRelaxedHpConformity(false) (the default):

fespace->SetRelaxedHpConformity(true) (same mesh and orders):

fespace->SetRelaxedHpConformity(false) (the default):

This solution doesn't looks quite right, or at least it looks worse than the second one?

Awesome job, @jakubcerveny!
I don't quite follow the edge->dofs associations you describe: I guess I don't understand how the variable order case is supported even on a conforming mesh. One approach I see, is to introduce cuts in the space along edges/faces where the orders differ (even if the mesh itself is not cut). This way the extraction of element dofs from a GridFunction does not require any transformation/interpolation, just extraction of a sub-vector. The interpolation becomes part of the conforming prolongation -- just like the non-conforming case with fixed order (the difference being that the mesh in that case it topologically cut). Is that how the variable order case is handled? Maybe the edge->dofs association you mentioned is the data you need in the FE space to construct the variable-order prolongation?
By the way, introducing cuts in the FE space independent of the mesh can allow us to handle the nodes of a periodic mesh with less data duplication, compared to using an L2 space (which is cut everywhere).

This solution doesn't looks quite right, or at least it looks worse than the second one?

I agree, it does look a little strange but maybe it is just "too constraint". The simpler (to implement) "RelaxedHpConformity" option maybe also be the better (for the solution) option in this case.

Yes, I introduce cuts on edges and faces if the orders of the adjacent elements differ and then add interpolation constraints in the P matrix. I reuse the machinery already present for NC meshes, I just needed to add one block of code in BuildConformingInterpolation().
 I'm convinced the solution is correct and I plan to post the pictures of all the basis functions to prove it.

Here is one more example, with basis functions.
The mesh looks like this:

The fully H1 conforming solution has dimension 36 and looks like this:

The 36 basis functions are here:

When relaxing the constraints the dimension goes up to 39 and the large edges are no longer linear, but cracks appear:

It seems 3D constraints won't be as simple as I thought. Adding lower order face DOFs according to the lowest order slave is OK, but the multiple sets cause trouble if there are indirect constraints.
In this example there are two master faces, where the horizontal is partially constrained by the vertical one. On the horizontal face, we add order 3 DOFs to constrain the native order 4 DOFs, but these should at the same time be constrained by the vertical face. This constraint is skipped which leads to the discontinuity. I may have to rethink the handling of the strict continuity constraints...

Meanwhile I'm trying to make the relaxed case work correctly, but there is some bug too. I'm pretty certain the relaxed case should work, but I haven't found the bug yet.

After some more debugging and inspecting the dependencies of the DOFs, it's clear that 3D is much more complex. Consider this situation on the middle edge of the top face of the domain:

the vertical master face has order 3 DOFs
the large vertical slave face has order 2 DOFs directly dependent on the order 3 master DOFs (I'm using relaxed conformity here)
the top edge holds two sets of DOFs, orders 2 and 3 (since elements of order 2 and 3 meet there)
as in 2D, the higher order DOFs (3) on the edge depend on the lowest order DOFs (2), but this creates a circular dependency between the two sets!

Maybe when adding face constraints, we only need to reference the inner face DOFs and skip the edges, which will be handled separately. But in the current implementation this would miss edge-face constraints. I'm still trying to wrap my head around this.

After a discussion with Tzanio I tried to skip edges when processing face constraints, unless the edges lie in the interior of the master face. The idea is to process the edges by edge constraints only, if possible. This helped somewhat, and I can now construct relatively complex P matrices without circular constraints.
The following case still fails, but at least it indicates that edges and faces need to be treated completely separately.
These are the element orders, purple is cubic and blue is quadratic:

Here is the numbering (IDs) of edges:

The problem is that edge 22 (circled) is quadratic, but it also holds cubic DOFs because of the smaller cubic element (I'm going for full conformity here). However the face constraint (left half of the big master face) constrains the cubic DOFs, not the quadratic one, which is left unconstrained.
But explicitly doing the face-edge constraints, while limiting the face constraints to interior DOFs only, should fix this problem.

Separating edges when processing face constraints helped. There might still be some problems but it's starting to work...

It seems that we need a method that checks for conformity at certain sets of points (maybe random?) on faces and edges. Visual inspection has its limitations -- it will still be very helpful once you know where precicely to look for a problem. 😄
The pictures here: https://github.com/mfem/mfem/pull/1423#issuecomment-635349331 looked very convincing but I guess there was still an issue.

A conformity checking tool would be nice :-)  So far I managed to reveal problems just by cutting and browsing the volume while having the contours on in GLVis. In fact I had a version of that screenshot above which showed a problem, I just didn't upload it :-)  But it's fixed now with the propagation.

We have some first hp-adaptation results on the 2D inner layer problem. It's not as good as it should be yet (the refinement decisions and the convergence should be better), but I'll post a picture anyway:

BTW we have encountered the problem that if we add nodal interpolation for those extra master edge/face true DOFs in the R matrix, this messes up the code that determines which true DOFs are essential (R->BooleanMult). We had to keep the R matrix as is, and add a third "Q" matrix which is similar but contains interpolation for the special DOFs. Maybe there is a better solution, like nodal-projecting Coefficients directly to the special DOFs, not interpolating them from already interpolated data.

Somehow we can't get proper convergence out of the hp meshes... I wonder if it's because of the simple approach (only two choices (h, p+1), (h/2, (p+1/2))). Also there still might be some problem in the P matrix (see kinks in the curve).

Finally some improvement in the hptest miniapp. It seems nodal interpolation is not sufficient to estimate whether to h- or p- refine. Now I do the following:

Solve for the current mesh.
Solve for a h-refined mesh with orders (p+1)/2.
Solve for a p-refined mesh (p+1).
Calculate the exact per-element error for the current mesh (to know which elements to refine).
Compare per-element error in the (h+1, (p+1)/2) and (h, p+1) meshes, select either h- or p- refinement simply by looking at which error is lower.

This way I get the following mesh which has error 0.00102267 at 43476 DOFs:

Which corresponds roughly to the red dot in the graph from the AMR paper (unfortunately I lost the Hermes2D convergence data, I'll need to rerun it). This is still not as good as the Hermes result, but I guess it is to be expected with such a simplistic strategy. To get a better convergence one has to try to save DOFs by carefully distributing the orders in the h-refinement. We can try to solve once more for (h+1, (p+1)/2 + 1) (or -1?) and test more options.

I'm trying to catch remaining bugs in the 2D and 3D hp spaces. We have a tool, ex1_hp_check, which creates a random mesh with random orders >= 2 and solves the Poisson problem with a simple solution, x^2 + y^2:

Element orders:

Since the exact solution lies in the FE space, the problem is solved exactly. The residual is very small:

But there is a problem with the SetRelaxedHpConformity option. When set to true, the small quadratic edges no longer interpolate the cubic master edge exactly. However, the solution should still lie in the discrete space and the problem should be solved exactly. Unfortunately this is not the case, now the residual is large:

This is caused by one of the basis functions looking like this:

This is the large master edge constraining the smaller master edge. Since the basis function is not continuous, the solution will also not be perfectly continuous, no matter what happens on the smaller master edge. I didn't expect this, and thought the basis function is wrong, but in fact the P matrix does what we want on the quadratic slaves - the midpoint values are tied to the cubic function:

I'm beginning to doubt that the "relaxed" option is correct...

Some more tests regarding the above solution of x^2 + y^2.
I solve the problem and calculate the exact L2 error. I also project the exact coefficient to the space, multiply with R and P, and calculate the L2 error. Finally I plug the projection into the linear system and calculate the residual.
For the fully conforming case, I get all zeros, which is correct:
FE solution L2 error: 3.3055e-16
Nodal projection L2 error: 1.83885e-16
|Az - B|: 9.75162e-15

With SetRelaxedHpConformity however, I get the wrong solution, even though the projection lies in the FE space:
FE solution L2 error: 0.000336285
Nodal projection L2 error: 1.88453e-16
|Az - B|: 0.0158918

The FE solution has a small discontinuity which is even visible on the contour lines in GLVis...

Here are the basis functions that contain the 4th-order master edge, for the relaxed hp mode. They seem correctly constructed in the sense that the quadratic slaves interpolate them 4th-order function values in the right points.

What do you think about this @v-dobrev ?

Thinking more about https://github.com/mfem/mfem/pull/1423#issuecomment-656153747, the result is actually not unexpected -- the discretization in the RelaxedHpConformity case is non-conforming because the space is not a subspace of H^1. The approximation is probably still OK (needs to be estimated with Strang's Lemmas, cc: @pazner) but we can't expect to recover the exact solution.
Specifically:

On continuous level we have (∇u,∇v) = (f,v) for all v in U=H^1 with u=x^2+y^2 and f=-4. (What about boundary conditions?)
On discrete level we have (∇u_h,∇v_h) = (f,v_h) where u_h	and v_h are in the conforming subspace given by U_h = Range(P).
If u is in U_h and U_h is a subspace of U, we do indeed get u_h=u since we can simply set u=u_h and v=v_h in the continuous weak form. This is what happens in the conforming prolongation case.
In the RelaxedHpConformity case we still have that u is in U_h, but U_h is a subspace of Uand so we can get only part of the v_h orthogonality.

Does this make sense?

The approximation is probably still OK (needs to be estimated with Strang's Lemmas, cc: @pazner) but we can't expect to recover the exact solution.

I haven't thought carefully about this specific case, but it might be necessary to add DG-like penalty terms in order to recover the proper convergence rates. This is actually trivial to do in the current implementation — just add the DG diffusion integrators, and it will work automatically.

Another perspective on this: if you print the "energy" of the state u, E(u) = 1/2 a(u,u) - (b,u) (which is minimized by the solution), you should see that the energy of the non-conforming discrete solution is smaller than the one for the exact solution.
If the non-conforming mesh/space is refined uniformly in h, this will introduce more conformity (in particular, the refined space will not contain the coarse space) and the energy of the discrete solution should increase and (probably?) tend to the energy of the exact solution.

Thanks everyone for the comments, I think you are right.
I was trying to calculate the energy for the x^2 + y^2 problem, but had trouble obtaining a reasonable value because of the nonzero Dirichlet BC. I would probably need to use the uneliminated system.
To make things easier, I used the exact solution u = x(1-x)y(1-y). For this problem we have
du/dx = y(1-y)(1-2x), du/dy = x(1-x)(1-2y) and \Delta u = 2x(x-1) + 2y(y-1) = -f.
Then a(u,u) = Integrate[x^2 (1-x)^2 (1-2y)^2 + y^2 (1-y)^2 (1-2x)^2, {x,0,1}, {y,0,1}] = 1/45 and l(u) = \int -f u = Integrate[-(2x(x-1) + 2y(y-1)) x(1-x) y(1-y), {x,0,1}, {y,0,1}] = 1/45.
So the energy E(u) = 1/2 a(u,u) - l(u) = -1/90 = -0.011111111.
This is exactly what I get from ex1_hp_check for the fully conforming case:
FE solution L2 error: 3.80965e-17
Nodal projection L2 error: 1.01771e-17
|Az - B|: 8.82835e-16
(1/2 w'Aw - B'w): -0.0111111

Many times it works like this with SetRelaxedHpConformity as well, but eventually I found a random mesh that fails to recover the exact solution, and the energy really is lower as Veselin says:
FE solution L2 error: 4.75943e-05
Nodal projection L2 error: 1.10661e-17
|Az - B|: 0.0044145
(1/2 w'Aw - B'w): -0.0111146

(When I refine once, the energy grows to -0.011113)
The solution has a visible discontinuity:

(the large element has order 6 and the two smaller ones are order 2)
It took me some time to accept that the energy really is lower for this solution (the linear term is to blame), but as Tzanio says, when we derive the weak formulation, we assume the H1 space. The relaxed space is bigger than H1 and accepts discontinuous solutions like this, and also the weak formulation is wrong, because when doing the Green Theorem we don't include the jump terms. We should probably add the DG diffusion integrators as Will suggests.

We have an interesting result from the hp miniapp (we're trying to get proper convergence for two benchmark problems).
Lenka tried the other problem, Babuska's L-shaped domain problem. Here it's critical that the hp adaptive strategy makes good decisions at the corner with the singularity.
Consider this mesh with order 4 elements around the corner, it has 97 DOFs and total error 0.0365:

Since we have the exact solution we can test a number of refinement candidates, and the best ones in this particular case (errors are evaluated locally) are two p refinements and one h-refinement with orders distributed like this:

The problem is that even though the refinements, when evaluated individually, are very good, together they influence each other and the total error in fact grows to 0.0825. If all three refinements were p-refinements to order 5, the error would have been 0.02696.
This is because of the full conformity and the degradation of the 5-th order edges to 2nd order, due to the h-refined quadratic elements. I believe this is the reason we have been struggling to get nice convergence curves. In the following graph the second best curve ("hp - max 8, more candidates") is the best we could get with full conformity:

Then we tried enabling "relaxed conformity" and even though the curve is not perfect (probably because of the oscillations discussed in previous comments), it finally looks like a straight line with a nice slope that's better than simple h-adaptivity with constant p.
The mesh even looks like what we were used to seeing in Hermes2D -- large high order elements in the smooth regions and gradually smaller elements with lower degrees towards the singularity:

So it seems "relaxed hp" will actually be important in practice and we should make sure we include the necessary interface integrals.
(As a side note, in our old Hermes2D code we didn't have this problem, because the master edge always stayed at its native order. The high order in fact spilled to the adjoining lower degree slaves because the slaves had special constrained edge shapes (this is not possible in MFEM). The mathematicians were suspicious because it wasn't clear what spaces we defined on the individual mesh elements, but it worked well in practice.)

@jakubcerveny, it seems like it may be worth considering if we can support the Hermes2D approach as well, e.g. as a third "conformity" mode. For that, we'll probably need to introduce enriched FEs where a standard p-order element is enriched by edge and face (in 3D) bubble basis functions extended suitably to the whole element.
Do you think this will complicate things a lot?

If I understand correctly the "Hermes" approach will require us to to introduce finite elements that support different polynomial orders on each of their faces and edges. This sounds disruptive to me, but I agree we should keep it in mind for the future if the current two approaches run into difficulties.

I reworked the DOF assignment on edges and faces and finally all cases now work in 3D -- tested thousands of random configurations like this:

FE solution L2 error: 4.00109e-14
Nodal projection L2 error: 4.43681e-16
|Az - B|: 1.55111e-13

Lenka cleaned up the hptest miniapp and ran both problems (L-shape, inner layer) again with the best strategy so far. It finally looks reasonable, even with the occasional kinks caused by the relaxed_hp oscillations.

This looks like a mistake, why was this merged in master?

shoot... wrong PR

Was this "merged" because the last commint here is part of #1817?

As @v-dobrev said, it looks like the commits here were subset of #1817 and that's why GitHub lists it as merged.
Can we delete this branch and PR now?

The only thing left of value here is the hpfem miniapp (and the comments in the PR, but those will still be accessible). I put the miniapp in a separate branch, hpfem-miniapp-dev. I'll delete this branch now.

Dear developers, any progress of the parallel version variable order space?


Consider joining Hacktoberfest

More info here.
To do so, it should be sufficient to add the hacktoberfest label to the GitHub repository.

I was inclined not to join because the quality of PRs last year was not the best, but since you proposed, I've add the topics to the repository. Thanks.

Thank you for taking this into considerarlon. I understand last year was a real mess for maintainers, unfortunately. If you feel like the issue is occurring again, I would support you in withdrawing again.


kirkstone support

Hello,
Do you have any plans to support the current Yocto LTS (Kirkstone) in the near future?
Thanks

We are investigating it now. There are some recipe syntax changes needed for Dunfell->Kirkstone.
The current idea is to post a more simple Kirkstone meta-renesas layer for users to use as refence while the official BSP remains Dunfell.

Is there any milestone to release for supporting Kirkstone now?
Thank you.

We do not have a release date yet. We are still in the process of porting over the current Dunfell recipes.

I think this bsp layer is too difficult to use, why not refer to meta-freescale or meta-st-stm32mp.
If you plan to support Kirkstone, please be sure to align it with the yocto community.
Feedback and complaints from your customers.

We are investigating it now. There are some recipe syntax changes needed for Dunfell->Kirkstone.
The current idea is to post a more simple Kirkstone meta-renesas layer for users to use as refence while the official BSP remains Dunfell.

You can use the convert-overrides.py to convert to new syntax

According to VLP_support_version_overview, seems that Dunfell will be kept till a migration to Scarthgap (after 2025)?

According to VLP_support_version_overview, seems that Dunfell will be kept till a migration to Scarthgap (after 2025)?

Yes, that is correct.
There is a Kirkstone based Yocto build here: https://github.com/renesas-rz/rz-community-bsp
However, it is not an official release and some features are missing.


Request: Clearer Build Instructions

Hi, sorry if this is not something on the radar right now. I'm trying to build the randomizer file here so I can play and do some testing / bug reports /etc, but as someone who's never used Docker, the steps in the read-me as is are not quite doing the job.
It mentions needing the OOT/MM rom files in a "ROMS" folder, but doesn't mention anything else about file structure. Also not mentioning how the Docker application is meant to be used to actually create the randomizer file. it has a simple command to plug in, sure, but again it doesn't mention how to set up to that point.
Any assistance on this would be peachy. I was looking for a Discord as well to check there for clearer info, but a link provided to someone else in another Issue is apparently an expired invite.

Update -- I managed to figure out how to use Docker to build the file (still think the instructions could be cleared up a bit), however now I'm getting an error when trying to run. I'm pretty sure both of my OOT and MM files are full header, but I'll double-check that in case that's contributing to the error.
failed to solve: executor failed running [/bin/sh -c apt-get update   && DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends --assume-yes curl gnupg ca-certificates   && curl https://practicerom.com/public/packages/debian/pgp.pub | apt-key add -   && echo deb http://practicerom.com/public/packages/debian staging main >/etc/apt/sources.list.d/practicerom.list   && apt-get update   && DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends --assume-yes     build-essential     n64-ultra     nodejs     npm     git   && useradd -ms /bin/bash ootmm]: exit code: 100

Same problem

I found a web generator of it that works. Its at https://ootmm.com/

Awesome, thanks! The GitHub page was the only thing that came up when I was googling, so I completely missed the webpage and discord.
Probably wouldn't be a bad idea to add those to the ReadMe so people like me don't just run into a dead end here.

Not a huge priority right now - you can get help on how to build on the discord.


bctls-jdk15on_1.65: AbstractTlsContext#exportKeyingMaterial() checks for securityParametersConnection for null

The method AbstractTlsContext#exportKeyingMaterial()  checks  securityParametersConnection
for null and throws IllegalStateException. However  securityParametersConnection is always set to null in method handshakeComplete().
May be should consider to use getSecurityParameters() instead.
    public byte[] exportKeyingMaterial(String asciiLabel, byte[] context_value, int length)
    {
        SecurityParameters sp = getSecurityParametersConnection();
        if (null == sp)
        {
            throw new IllegalStateException("Export of key material unavailable before handshake completion");
        }
        if (!sp.isExtendedMasterSecret())
        {
            /*
             * RFC 7627 5.4. If a client or server chooses to continue with a full handshake without
             * the extended master secret extension, [..] the client or server MUST NOT export any
             * key material based on the new master secret for any subsequent application-level
             * authentication. In particular, it MUST disable [RFC5705] [..].
             */
            throw new IllegalStateException("cannot export keying material without extended_master_secret");
        }

        if (TlsUtils.isTLSv13(sp.getNegotiatedVersion()))
        {
            // TODO[tls13]
            TlsSecret exporter_secret = null; // exporter_master_secret

            return exportKeyingMaterial13(exporter_secret, asciiLabel, context_value, length);
        }

        byte[] seed = TlsUtils.calculateExporterSeed(sp, context_value);

        return TlsUtils.PRF(sp, sp.getMasterSecret(), asciiLabel, seed, length).extract();
    }

    synchronized void handshakeComplete(TlsPeer peer, TlsSession session) throws IOException
    {
        if (null == securityParametersHandshake)
        {
            throw new TlsFatalAlert(AlertDescription.internal_error);
        }

        this.session = session;

        securityParametersConnection = securityParametersHandshake;

        peer.notifyHandshakeComplete();

        securityParametersHandshake = null;
    }

I think you're misreading something. securityParametersConnection begins as null, then gets set to the handshake parameters once a handshake successfully completes. It is never reset to null.
If you are seeing NPE it is more likely to be coming from the master secret having been nulled after handshakeComplete(...) returns. It is intended that client code export keying material (only) during the "peer.notifyHandshakeComplete()" callback.

Please refer to https://github.com/cmeng-git/atalk-android class DtlsPacketTransformer.java
Yes you are right, the problem is due to master secret being null. I incorrectly reported the problem.
During the aTalk implementation and testing of DTLS features, aTalk also faced the exact same problem as reported in DTLS Can't exportKeyingMaterial after handshake completed (DTLS fails) #203. As recommended, aTalk was trying to use the notifyHandshakeComplete() callback.
However I found that the parameter masterSecret derived during the callback, its 'byte[] data' array contains no data?; but not the case when the masterSecret is retrieved from the sessionParameters.
Personally no sure if the 'byte[] data' is actually being used. Coupled that aTalk DTLS implementation flow also uses byte[] keyingMaterial to derive the srtpTransformer.
To avoid major changes to the aTalk (forked from jitsi) source, I decided to use the masterSecret from the sessionParameters, and call via below method with tlsSecret as pass-in parameter.

TlsUtils.PRF(context, tlsSecret, asciiLabel, seed, length).extract();

Following up with your comment, I just realize that the problem is not due to getSecurityParametersConnection(), but getSecurityParametersHandshake() as used in

PRF(context.getSecurityParametersHandshake(), secret, asciiLabel, seed, length);

May be this is where it should be changed to i.e. context.getSecurityParametersConnection()
aTalk was changed to call using

TlsUtils.PRF(sp, tlsSecret, asciiLabel, seed, length).extract();

I retest the callback notifyHandshakeComplete() for both the TlsClientImpl and TlsServerImp, and confirmed that 'byte[] data' does contain the data. Not sure if the previous problem experienced was due to my incorrect test setup.

Happy to hear it.

Following up with your comment, I just realize that the problem is not due to
getSecurityParametersConnection(),
But getSecurityParametersHandshake() as used in

PRF(context.getSecurityParametersHandshake(), secret, asciiLabel, seed, length);

May be this is where it should be changed to i.e. context.getSecurityParametersConnection()

Did you verify and confirm the correctness on the comment I have on:

PRF(context.getSecurityParametersHandshake(), secret, asciiLabel, seed, length);

TlsUtils.PRF(TlsContext, ...) just calls TlsUtils.PRF(SecurityParameters, ...) with the handshake SecurityParameters. If you for some reason want to use the connection SecurityParameters instead, you would just call the other PRF method directly.
However, during a notifyHandshakeComplete call, both SecurityParameters reference the same instance anyway (neither is null), so I'm unclear why you thought there was a problem.

There is no problem when an app calls the method during the notifyHandshakeComplete() callback.
However the method is defined as general method, a developer may not aware this method must never be used outside notifyHandshakeComplete();  as context.getSecurityParametersHandshake() will return null. Actually aTalk fallen into this trap during srtp earlier implementation when notifyHandshakeComplete() was not used.
May be the team would consider to change context.getSecurityParametersConnection instead so the method works at all time.
    public static TlsSecret PRF(TlsContext context, TlsSecret secret, String asciiLabel, byte[] seed, int length)
    {
        return PRF(context.getSecurityParametersHandshake(), secret, asciiLabel, seed, length);
    }

We have now deprecated this method to avoid any confusion.


i don't get a confirmation with bitcoin core its not working

Expected behavior

Actual behavior

To reproduce

System information

This issue tracker is for technical issues with Bitcoin Core. For usage questions, try stack exchange, or IRC.


Translation to portuguese

Hi!
This PR add a new file with the translation to pt-br. :wink:

Hi Raphael,
Thanks for the pull request. I will let some portugees speaker look at this. When it is aproved i will add it into the module.
Regards,
Rik
Adyen

Thanks Rik!
:)
Em seg, 7 de set de 2015 07:38, Rik ter Beek<EMAIL_ADDRESS>escreveu:

Hi Raphael,
Thanks for the pull request. I will let some portugees speaker look at
this. When it is aproved i will add it into the module.
Regards,
Rik
Adyen
—
Reply to this email directly or view it on GitHub
https://github.com/Adyen/magento/pull/400#issuecomment-138267050.

--
Raphael Porto.

Hi Raphael,
I am going to merge your pull request to our module but i am going to make these changes to it:
6 - +"Authorize Only","Somente Autorizar”
17 - +"The payment is REFUSED by Adyen.", “O Pagamento foi RECUSADO pela Adyen."
19 +"Your payment failed, Please try again later",”Sua tentativa de pagamento falhou. Por favor, tente novamente.”
44 +"The payment is PENDING by Adyen.","O pagamento está PENDENTE pela Adyen.”
45 +"The payment is AUTHORIZED by Adyen.","O pagamento foi AUTORIZADO pela Adyen.”
48 +"You will be redirected to Adyen website when you place an order.”,”Você será redirecionado ao site da Ayen quando realizar a compra.”
54 +"Remember these details”,"Armazenar estes dados"
Regards,
Rik
Adyen

:+1:


acronym_generate_scene.py

Why is the cup under the table？

Shouldn't it be at the bottom of the table?


Cannot install jenkins-x in GKE - error: object does not implement the Object interfaces

Run this command:
MacBook-Pro-Dmitry:~ dzolotnikov$ kubectl apply --recursive -f /var/folders/l6/cd8nfjx512d9xqw1yrwn2kwr0000gn/T/helm-template-workdir-321465091/jenkins-x/output -l jenkins.io/chart-release=jenkins-x --namespace jx --validate=false
deployment.extensions "jenkins-x-chartmuseum" configured
persistentvolumeclaim "jenkins-x-chartmuseum" unchanged
secret "jenkins-x-chartmuseum" unchanged
service "jenkins-x-chartmuseum" unchanged
role.rbac.authorization.k8s.io "cleanup" unchanged
rolebinding.rbac.authorization.k8s.io "cleanup" unchanged
serviceaccount "cleanup" unchanged
clusterrole.rbac.authorization.k8s.io "controllerbuild-jx" configured
clusterrolebinding.rbac.authorization.k8s.io "controllerbuild-jx" configured
deployment.apps "jenkins-x-controllerbuild" configured
role.rbac.authorization.k8s.io "controllerbuild" unchanged
rolebinding.rbac.authorization.k8s.io "controllerbuild" unchanged
serviceaccount "jenkins-x-controllerbuild" unchanged
clusterrole.rbac.authorization.k8s.io "controllercommitstatus-jx" configured
clusterrolebinding.rbac.authorization.k8s.io "controllercommitstatus-jx" configured
deployment.apps "jenkins-x-controllercommitstatus" configured
role.rbac.authorization.k8s.io "controllercommitstatus" unchanged
rolebinding.rbac.authorization.k8s.io "controllercommitstatus" unchanged
serviceaccount "jenkins-x-controllercommitstatus" unchanged
clusterrole.rbac.authorization.k8s.io "controllerrole-jx" configured
clusterrolebinding.rbac.authorization.k8s.io "controllerrole-jx" configured
deployment.apps "jenkins-x-controllerrole" configured
role.rbac.authorization.k8s.io "controllerrole" unchanged
rolebinding.rbac.authorization.k8s.io "controllerrole" unchanged
serviceaccount "jenkins-x-controllerrole" unchanged
clusterrole.rbac.authorization.k8s.io "controllerteam-jx" configured
clusterrolebinding.rbac.authorization.k8s.io "controllerteam-jx" configured
deployment.apps "jenkins-x-controllerteam" configured
role.rbac.authorization.k8s.io "controllerteam" unchanged
rolebinding.rbac.authorization.k8s.io "controllerteam" unchanged
serviceaccount "jenkins-x-controllerteam" unchanged
clusterrole.rbac.authorization.k8s.io "controllerworkflow-jx" configured
clusterrolebinding.rbac.authorization.k8s.io "controllerworkflow-jx" configured
deployment.apps "jenkins-x-controllerworkflow" configured
role.rbac.authorization.k8s.io "controllerworkflow" unchanged
rolebinding.rbac.authorization.k8s.io "controllerworkflow" unchanged
serviceaccount "jenkins-x-controllerworkflow" unchanged
configmap "jenkins-x-docker-registry-config" unchanged
deployment.extensions "jenkins-x-docker-registry" unchanged
persistentvolumeclaim "jenkins-x-docker-registry" unchanged
secret "jenkins-x-docker-registry-secret" unchanged
service "jenkins-x-docker-registry" unchanged
configmap "exposecontroller" unchanged
role.rbac.authorization.k8s.io "expose" unchanged
rolebinding.rbac.authorization.k8s.io "expose" unchanged
serviceaccount "expose" unchanged
clusterrole.rbac.authorization.k8s.io "gcactivities-jx" configured
clusterrolebinding.rbac.authorization.k8s.io "gcactivities-jx" configured
cronjob.batch "jenkins-x-gcactivities" unchanged
role.rbac.authorization.k8s.io "gcactivities" unchanged
rolebinding.rbac.authorization.k8s.io "gcactivities" unchanged
serviceaccount "jenkins-x-gcactivities" unchanged
cronjob.batch "jenkins-x-gcpods" unchanged
role.rbac.authorization.k8s.io "gcpods" unchanged
rolebinding.rbac.authorization.k8s.io "gcpods" unchanged
serviceaccount "jenkins-x-gcpods" unchanged
cronjob.batch "jenkins-x-gcpreviews" unchanged
deployment.extensions "jenkins-x-heapster" unchanged
service "heapster" unchanged
deployment.extensions "jenkins-x-mongodb" configured
persistentvolumeclaim "jenkins-x-mongodb" unchanged
secret "jenkins-x-mongodb" unchanged
service "jenkins-x-mongodb" unchanged
configmap "jenkins-x-monocular-api-config" unchanged
deployment.extensions "jenkins-x-monocular-api" unchanged
service "jenkins-x-monocular-api" unchanged
deployment.extensions "jenkins-x-monocular-prerender" unchanged
service "jenkins-x-monocular-prerender" unchanged
configmap "jenkins-x-monocular-ui-config" unchanged
deployment.extensions "jenkins-x-monocular-ui" unchanged
service "jenkins-x-monocular-ui" unchanged
configmap "jenkins-x-monocular-ui-vhost" unchanged
configmap "nexus" unchanged
deployment.extensions "jenkins-x-nexus" configured
persistentvolumeclaim "jenkins-x-nexus" unchanged
secret "nexus" unchanged
service "nexus" unchanged
role.rbac.authorization.k8s.io "committer" unchanged
clusterrolebinding.rbac.authorization.k8s.io "jenkins-x-team-controller" configured
configmap "jenkins-x-team-controller" unchanged
secret "jenkins-docker-cfg" unchanged
configmap "jenkins-x-devpod-config" unchanged
configmap "jenkins-x-docker-registry" configured
configmap "jenkins-x-extensions" unchanged
configmap "jenkins-x-pod-templates" unchanged
secret "jx-basic-auth" unchanged
role.rbac.authorization.k8s.io "jx-view" unchanged
secret "jenkins-maven-settings" unchanged
secret "jenkins-npm-token" unchanged
role.rbac.authorization.k8s.io "owner" unchanged
secret "jenkins-release-gpg" unchanged
secret "jenkins-ssh-config" unchanged
role.rbac.authorization.k8s.io "viewer" unchanged
error: object does not implement the Object interfaces

So, I have this error:
error: object does not implement the Object interfaces
So seems Jenkins-X has been installed partially:
This command doesn't show me anything:
jx open
Name URL

Pods are running at the same time.
MacBook-Pro-Dmitry:~ dzolotnikov$ kubectl -n jx get pods
NAME                                               READY     STATUS      RESTARTS   AGE
build-controller-677948565-tc2wp                   1/1       Running     0          16m
buildnum-c5c8b9889-z6d62                           1/1       Running     0          15m
crier-7b9bc4c849-sj2m9                             1/1       Running     0          15m
deck-5fbbdc9478-6qv5x                              1/1       Running     2          15m
deck-5fbbdc9478-q9kjf                              1/1       Running     1          15m
hook-84674dfd46-9kq22                              1/1       Running     0          15m
hook-84674dfd46-plmj9                              1/1       Running     0          15m
horologium-65d4c68b96-cv8jc                        1/1       Running     0          15m
jenkins-x-chartmuseum-5687695d57-6jb8b             1/1       Running     0          14m
jenkins-x-controllerbuild-776c6d5c-lttqg           1/1       Running     0          14m
jenkins-x-controllercommitstatus-6546b4995-g6bgh   1/1       Running     0          14m
jenkins-x-controllerrole-7fb7666454-k4bjl          1/1       Running     0          14m
jenkins-x-controllerteam-f64ff5bd5-d7sxd           1/1       Running     0          14m
jenkins-x-controllerworkflow-856954cc6f-zt5t6      1/1       Running     0          14m
jenkins-x-docker-registry-7b56b4f555-654q9         1/1       Running     0          14m
jenkins-x-gcactivities-1551702600-xmbsf            0/1       Completed   0          2m
jenkins-x-gcpods-1551702600-mtpk9                  0/1       Completed   0          2m
jenkins-x-heapster-65fd697bb-d98zw                 2/2       Running     0          14m
jenkins-x-mongodb-6bfd5d9c79-pjdg6                 1/1       Running     1          14m
jenkins-x-monocular-api-f98b447d7-x9qdq            1/1       Running     2          14m
jenkins-x-monocular-prerender-5848c74fdc-4xwj8     1/1       Running     0          14m
jenkins-x-monocular-ui-68774c6cb8-d7r9h            1/1       Running     0          14m
jenkins-x-nexus-695cc97bd6-nv848                   1/1       Running     0          14m
pipeline-66cf49b747-q8t8d                          1/1       Running     0          15m
plank-79d5bcc96b-gt5lg                             1/1       Running     0          15m
prow-build-56c9d49579-kjcnb                        1/1       Running     0          15m
sinker-c95fc86b5-mmj6x                             1/1       Running     0          15m
tide-b99fd65b6-slhhj                               1/1       Running     0          15m

MacBook-Pro-Dmitry:~ dzolotnikov$ kubectl -n kube-system get pods
NAME                                                  READY     STATUS    RESTARTS   AGE
event-exporter-v0.2.3-85644fcdf-4nhzq                 2/2       Running   0          19m
fluentd-gcp-scaler-8b674f786-crg6s                    1/1       Running   0          19m
fluentd-gcp-v3.2.0-f8z5z                              2/2       Running   0          18m
fluentd-gcp-v3.2.0-qp9hv                              2/2       Running   0          18m
fluentd-gcp-v3.2.0-rv899                              2/2       Running   0          18m
heapster-v1.6.0-beta.1-85c9b4c958-q2dsd               3/3       Running   0          18m
jxing-nginx-ingress-controller-6f7798b5f8-qvt2m       1/1       Running   0          17m
jxing-nginx-ingress-default-backend-7f5c759f7-s9qw4   1/1       Running   0          17m
kube-dns-6b98c9c9bf-8z9jt                             4/4       Running   0          18m
kube-dns-6b98c9c9bf-96qp7                             4/4       Running   0          19m
kube-dns-autoscaler-67c97c87fb-fz7qj                  1/1       Running   0          19m
kube-proxy-gke-jx-default-pool-00d43c81-5d66          1/1       Running   0          18m
kube-proxy-gke-jx-default-pool-00d43c81-bb10          1/1       Running   0          18m
kube-proxy-gke-jx-default-pool-00d43c81-bbpg          1/1       Running   0          18m
l7-default-backend-7ff48cffd7-kfcrp                   1/1       Running   0          19m
metrics-server-v0.2.1-fd596d746-fzvzx                 2/2       Running   0          18m

Cluster has been created using this command:
jx create cluster gke  -n jx   --zone us-central1-a   --min-num-nodes 3   --max-num-nodes 3    --default-admin-password=admin  --prow  --no-tiller -b

Same error as above

Me too...  but on EKS :/

Same issue occurs on AKS.

Same issue when trying to install with the latest version 2.0.88

$ jx version
NAME               VERSION
jx                 2.0.38
jenkins x platform 2.0.108
Kubernetes cluster v1.11.8-eks-7c34c0
kubectl            v1.10.11
helm client        Client: v2.13.1+g618447c
git                git version 2.20.1 (Apple Git-117)
Operating System   Mac OS X 10.14.3 build 18D42

same issue. trying to deploy Serverless Jenkins with GitOps on EKS

Same error while trying to install with version 2.0.61 on minikube.

This error popped up with version: 2.0.768 installing on GKE with k8s at 1.12

I think its due to old kubectl versions. Could you try a newer version? say 1.14.x or later?

Updated to kubectl 1.15.0 and that fixed the issue. Thanks!

I've just added a PR to verify CLI versions which should help catch these kinds of things  https://github.com/jenkins-x/jx/pull/4698 if you type jx version


Provide storage section for writable flash memory

This may be getting a bit too complex to call "minimal", but to support applications that require some permanent storage there needs to be a section defined for that. This probably requires adding the flash page size into memory.x, then having a section something like
.storage BLOCK(_page_size) (NOLOAD) :
{
    FILL(0xFF)
    *(.storage .storage.*)
    . = ALIGN(_page_size);
} > FLASH

If possible, aligning in between each .storage.* section would be wonderful to allow having separately erasable sections (although, I don't know any way to do so).
(Note, I have only used flash storage on the nrf51, I assume other cortex-m devices behave similarly, but this may not be general enough).

@Nemo157 you can try your idea without modifying the cortex-m-rt crate. You can write a standalone linker script, e.g. named storage.x, and then pass that as a -Tstorage.x argument to the linker (cf. cargo/config).

If possible, aligning in between each .storage.* section would be wonderful to allow having separately erasable sections (although, I don't know any way to do so).

I don't think you can do that using just linker scripts but if what will be placed in .storage are static variables you may be able to do something like this:
#[link_section = ".storage"]
static PAGE: Page = Page { bytes: [0xff; 512] };

#[repr(align = "1024")] // or w/e the page size is
struct Page {
    bytes: [u8; 512],
}

You can write a standalone linker script

Yep, that's my current plan. Unfortunately you cannot have multiple SECTIONS defined in different linker scripts, so that requires copying the full link.x into the application.
It will be a little while till I get round to actually using something like this in my current project, once I do I'll see if I can come up with something that is usable in this crate (although, I think generally writing to flash will require accessing a vendor specific memory controller, so I don't know if there's some abstraction that could live here or not).

Unfortunately you cannot have multiple SECTIONS defined in different linker scripts, so that requires copying the full link.x into the application.

Is that right? It seems to work for me after a quick test. I got no linker error and the new linker section I created is there.

Hmm, you may be right. I'm sure I tested this earlier and had it ignore the sections specified in link.x when I added some extras, but it looks like it's working when I test it now.

Triage: This seems too specific to add to cortex-m-rt.
Flash memory is generally only writeable after performing some chip-specific steps, and some flash controllers might not support writes to the flash addresses at all (instead funneling writes through a single MMIO register, or via RAM-to-controller DMA without CPU intervention), so the use of this seems limited to only some chips.
Also, I would like to see HALs experiment with possible solutions for this before we consider adding this to cortex-m-rt.


fix(cocoapods) : fix to pass cocoapods podspec validation

Before pushing to cocoapods, we need to run pod lib lint
And this enlightened that.... the project does not compile if not in SPM context (typically, for Cocoapods)
To fix that, I had to :

change the SwiftGen configuration for Fonts and Icons
add the swift version in podspec (5.3)

The validation now passes, so once this PR merged, I will be able to push it to Cocoapods trunk repo
After discussion with @lauthieb , I also modified the README to encourage users to use an exact version of Vitamin in their project (with SPM and Cocoapods)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


In the plinko game written with the matter.js engine library, how to make the ball always fall into the pre-planned position

take the following code as an example. How can I make the ball always fall seemingly randomly every time into the third space position in the bottom?
What I can think of is to constantly judge its collision position during the falling process of the ball, and let the ball move towards the target, but how to make the moving process appear natural and random stumps me.`

Plinko

点击黑色区开始游戏

`

you can view it in :https://codesandbox.io/s/charming-sunset-t7s794?file=/index.html

These games probably don't relly in a real physics engine at all, since the values are evidently manipulated.


Errors in lnxUuid.cpp fail the build of amdvlk-2022.Q3.2

Tried to make a package for openSUSE and got this for both gcc-12 and clang-14:
[ 2332s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.2/pal/src/util/lnx/lnxUuid.cpp:68:8: error: variable has incomplete type 'tm'
[ 2332s]     tm FixedPoint = {0, 0, 0, 1, 2, 2021};
[ 2332s]        ^
[ 2332s] /usr/include/wchar.h:83:8: note: forward declaration of 'tm'
[ 2332s] struct tm;
[ 2332s]        ^
[ 2332s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.2/pal/src/util/lnx/lnxUuid.cpp:80:47: error: use of undeclared identifier 'CLOCK_MONOTONIC'
[ 2332s]     bool clockGettimeSuccess = (clock_gettime(CLOCK_MONOTONIC, &time) == 0);
[ 2332s]                                               ^
[ 2332s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.2/pal/src/util/lnx/lnxUuid.cpp:90:47: error: use of undeclared identifier 'CLOCK_REALTIME'
[ 2332s]     bool clockGettimeSuccess = (clock_gettime(CLOCK_REALTIME, &time) == 0);

Interesting that it fails on openSUSE but compiles on most other systems (I checked for me locally, time.h is included indirectly through string.h).
Anyway, this should be easy to fix. I guess that adding an #include <time.h> at the top of src/util/lnx/lnxUuid.cpp makes it build?

Anyway, this should be easy to fix. I guess that adding an #include <time.h> at the top of src/util/lnx/lnxUuid.cpp makes it build?

Indeed, it got built with:
diff --git a/pal/src/util/lnx/lnxUuid.cpp b/pal/src/util/lnx/lnxUuid.cpp
index 603db2a..f8a2c8b 100644
--- a/pal/src/util/lnx/lnxUuid.cpp
+++ b/pal/src/util/lnx/lnxUuid.cpp
@@ -30,6 +30,7 @@

 #include <random>
 #include <unistd.h>
+#include <time.h>

 namespace Util
 {

Hi.
At OpenMandriva we hit same issue.
Few weeks ago we fixed it by include time.h as above.
https://github.com/OpenMandrivaAssociation/AMDVLK/commit/98f4d773fc7f196d97cac763788067629d7f1c4b
Issue first time appear with 2022.Q2.3 and in pal commit a40241a1e6f5970a9313efe686a79c0a429ea5eb

Thanks for confirming @v-fox! This is fixed internally now, so it should appear in the next release (or the one after that, not sure when the cut-off is/was).

@AngryPenguinPL, I’ve been glancing over the OpenMandrive build script and noticed that you package spvgen (which was also part of earlier official ubuntu amdvlk packages).
spvgen.so is only needed for the offline amdllpc shader compiler and not for the driver (actually not even more for that as it’s linked statically now). So, it doesn’t need to be part of the package, amdvlk*.so and amd_icd*.json are enough.
That also means you don’t necessarily need to fetch spvgen’s dependencies (glslang, spirv_tools, spirv_headers and spirv_cross).
Also, -DBUILD_WAYLAND_SUPPORT=ON has been the default since a while (though it doesn’t hurt to specify it explicitly) :)

The fix made it in into the 2022.Q3.4 release, so I think this can be closed. (https://github.com/GPUOpen-Drivers/pal/blob/master/src/util/lnx/lnxUuid.cpp#L32)

The fix made it in into the 2022.Q3.4 release, so I think this can be closed. (https://github.com/GPUOpen-Drivers/pal/blob/master/src/util/lnx/lnxUuid.cpp#L32)

Yep.