Standalone Event Dispatcher

Hi,
The docs for the standalone event dispatcher need to be updated (I think). I trawled the code, and figured the following works (for me)
I'm aiming to send a 'ping' event to all services (just like the example in the events docs).
Is there an easier/more efficient way to do what I'm doing? or is this pretty much spot on?
from nameko.standalone.events import event_dispatcher
from nameko.dependency_providers import Config
from nameko_slack import rtm

class Slack:
    name = 'slackbot'
    config = Config()

    def dispatch(self, service_name, event_type, event_data):
        event_dispatcher(self.config)(service_name, event_type, event_data)

    @rtm.handle_message('status')
    def on_status(self, event, message):
        self.dispatch("monitor", "ping", event['channel'])

Incidentally - I am a massive fan of Nameko.

Hi Geoff,
Thanks 😀
Your code is valid, but perhaps isn't the best way of achieving your goal. Events are intended to be dispatched from an originating service, and handled in any "interested" subscribing services. The standalone dispatcher is a helper for "faking" that behaviour when needed (e.g. in tests) or to originate events from non-nameko services.
The code above will send a "ping" event claiming to originate from a "monitor" service. It is valid, but breaks the (implicit and undocumented!) intention that events are sourced at real services.
Assuming the aim is to get all services to do something when the "status" command is issued in slack, I would do it by dropping down to the lower-level "messaging" extensions that events are built on top of.
Nameko events are little more than a particular configuration of underlying elements of AMQP (the exchanges, queues, bindings, routing keys and consumers). For your use-case you probably want to configure these elements slightly differently.
I guess you want a single exchange that all services bind a queue to, and a consumer in each service instance. This is basically what you get with broadcast events, but doing it yourself you can control the exchange name, routing keys and queue names.
Something like this:
# slackbot
from nameko.messaging import Publisher
from kombu.messaging import Exchange

monitoring_exchange = Exchange(name="monitoring")

class Slack:
    name = 'slackbot'
    config = Config()

    publish = Publisher(exchange=monitoring_exchange)

    @rtm.handle_message('status')
    def on_status(self, event, message):
        self.publish(routing_key="ping", event['channel'])

# service_x.py
from nameko.messaging import consume
from kombu.messaging import Exchange, Queue

monitoring_exchange = Exchange(name="monitoring")

ping_queue = Queue(name="<unique-name>", routing_key="ping", exchange="monitoring")

class Service:
    name = "x"

    @consume(queue=ping_queue)
    def handle_ping(self, payload):
        pass

What an excellent answer, thanks Matt!

This issue was moved to https://discourse.nameko.io/t/standalone-event-dispatcher/310


sibling can be null - references #830

that's my guess - @Stift can you verify if this fixes the issue?

I can confirm, that this error is solved. :+1:

thanks @Stift for reporting the issue

no problem. That's we are here

Ha, I see you read @LincolnAtkinson's post


Request for template function for reversing IP addr

Request for template function for conversion IP address into reverse "in-addr.arpa" format
Something like in https://golang.org/src/net/dnsclient.go
Just don't known Go yet, but trying to use docker-gen for fully automated skynds2-based DNS.

And a little question: how to get current "-interval" value in template? (for ttl, for example)


change the output audiocodec

Add the ability to change the output audiocodec

Sounds like a sensible feauture, might you want to try implementing it and doing a PullRequest?

Can this be done via ffmpeg? I'll try, but it won't be fast.

In principle the audio codec is controlled in the function mux_slideshow_with_webcam and mux_slideshow. In both cases, I just copy the codec from the original source with the parameter -c:a to convert it to a different codec, you have to change this parameter.


Check conformance to NSFastEnumeration before iterating

This will now check that a collection conforms to NSFastEnumeration before iterating in RLMObjectBase.
Previously a __SwiftValue could run into an unrecognized selector exception. RLMAsFastEnumeration checks that the collection conforms to NSFastEnumeration. If it does, it returns. If it doesn't, it bridges the value.
This should allow something like:

The Dictionary case above this looks like it needs the same thing.


Implement TDWG-managed version of Dublin Core borrowed terms

This will eliminate manual editing of Dublin Core data that currently must be done in the rs.tdwg.org repo. See step 10 and 11 in the build workflow
from 2021-08-04 offline email:
Well, here's what I'm thinking. We already mint IRIs for "term lists". In the case of TDWG-issued terms, the term list IRI is the same as the namespace IRI. See
https://github.com/tdwg/rs.tdwg.org/blob/master/term-lists/term-lists.csv
for the full list.
For borrowed terms, there's an IRI for the term list in this form:
http://rs.tdwg.org/dwc/dc/    dc: terms borrowed by DwC
http://rs.tdwg.org/dwc/dcterms/ dcterms: terms borrowed by DwC
http://rs.tdwg.org/ac/dcterms/  dcterms: terms borrowed by AC
http://rs.tdwg.org/ac/xmpRights/ XMP terms borrowed by AC
http://rs.tdwg.org/ac/dwc/ DwC terms borrowed by AC

The first level subpath is the vocabulary that the term list is part of. The second level subpath represents the borrowed namespace and is usually the standard abbreviation used for it. So if one knows the pattern, one can know both the containing vocabulary and the borrowed namespace.
What I would do is just follow the same pattern that we use for TDWG-minted terms: https://github.com/tdwg/rs.tdwg.org/blob/master/README.md#patterns-versions
Here is how I'd denote the July 15, 2021 version of dcterms:references:
http://rs.tdwg.org/dwc/dcterms/version/references-2021-07-15

The assertion we'd make that is questionable is:
<http://rs.tdwg.org/dwc/dcterms/version/references-2021-07-15> dcterms:isVersionOf <http://purl.org/dc/terms/references>.

while a legitimate statement would be:
<http://dublincore.org/usage/terms/history/#references-003> dcterms:isVersionOf <http://purl.org/dc/terms/references>.

with the subject being the DCMI-minted version.
I'm not sure how illegitimate the questionable assertion actually is. I guess it depends on what you believe a "version" is. TDWG defines its own version model, so I guess we can just say that a version is whatever we want it to be. In any case, because this follows the same IRI patterns as for TDWG-minted terms, I think that all of the dereferencing would just work and the scripts would need only a minor tweak to make it work. There may be other ways to handle this but it's the first idea I've had that I think actually would work.

The semantics of 'version' is very variable. It is certainly used for a lot more than 'revisions', which was my earlier mistaken assumption. RDA had a whole Data Versioning working group (final report here https://doi.org/10.15497/RDA00042), who could/should have developed a taxonomy of version types ... or maybe not, since it would shade into a taxonomy of relationships (for which we have https://www.iana.org/assignments/link-relations and https://standards.iso.org/iso/19115/resources/Codelists/gml/DS_AssociationTypeCode.xml and https://id.loc.gov/vocabulary/relators.html already).
I guess 'version' is a subset of relations, being those that relate two endurant entities which have the same scope and similar intention and content.

Thanks for the thoughts and references here, @dr-shorthair


Component: LightboxMediaViewer and CTA - greyed out scrollbar is displayed on ratio 2:1 (1024*512)

Detailed description
Device : Windows
Browser : Chrome
Issue on LightboxMediaViewer and CTA sections.
Issue :- Scroll bar is displayed on ratio 2:1 (1024*512),  which is not required.
Expected : When the copy text is large the scroll option must be activated.
Additional information

@Praveen-sr Which storybook environment are you seeing this on? I tried both below and cannot reproduce in Windows Chrome.
http://ibmdotcom-react.mybluemix.net/?path=/story/components-lightboxmediaviewer--default
http://ibmdotcom-react-staging.mybluemix.net/?path=/story/components-lightboxmediaviewer--default

This issue is happening due to overflow, as it's set to auto, it's going to have some resolutions that will display a blank scrollbar, I don't know if this is a bug by itself.
cc: @kennylam @jeffchew

Hello @Praveen-sr, does this issue still apply? I tested but couldn't reproduce.

Hello @Praveen-sr, any update on this one?

@NSDrowned Re tested this on web components staging, still the issue exists. Scroll bar appears for 2:1 ratio

On React for 2:1

CC @RobertaJHahn

Closing based on the comments in the PR 5640.  Not a suitable fix.


Fixes lowercase lib update missing in tutorials

Q should be also in lowercase

done Q and fixed some bug/warning too in tutorials
On Tue, Jan 20, 2015 at 10:57 PM, Cedric Pinson<EMAIL_ADDRESS>wrote:

Q should be also in lowercase
—
Reply to this email directly or view it on GitHub
https://github.com/cedricpinson/osgjs/pull/230#issuecomment-70742524.

it seems to not merge maybe not rebased ?

sry, it is now rebased on latest develop


Update examples to new API

The examples should be updated to reflect some very small API changes which happened since 2.0.0

Most of them should be up to date. Feel free to leave a message in this thread if they do not work as expected!


how to config for next theme

i cannot display currently sequence use readme method

Could display currently with the default options?

@laosijizhongcai  Paste your config here.

i use next theme,i add sequence in _config.yml,but cannot display sequence.
my default options is:
sequence:
options:
theme: simple
css_class:

@laosijizhongcai  reinstall it with v1.0.3

npm install --save<EMAIL_ADDRESS>?

@laosijizhongcai correct

npm ERR! Darwin 16.5.0
npm ERR! argv "/usr/local/Cellar/node/6.2.0/bin/node" "/usr/local/bin/npm" "install" "--save"<EMAIL_ADDRESS>npm ERR! node v6.2.0
npm ERR! npm  v3.8.9
npm ERR! No compatible version found<EMAIL_ADDRESS>npm ERR! Valid install targets:
npm ERR! 1.0.2, 1.0.1, 1.0.0

@laosijizhongcai I forget to publish this version, and I have just publish it, pls try again.

Generate: [sequence]webrtc-source-api-diagram-0.png
phantom stdout: NETWORK_ERR: XMLHttpRequest Exception 101: A network error occurred in synchronous requests.
phantom stdout:   phantomjs://code/shim.js:1815 in send
phantomjs://code/shim.js:1815 in _start
phantomjs://code/shim.js:1842


Multiple Inputs connecting to same Output

Hey!
I recall reading somewhere that this doesn't support multiple connections to the same connector, but is this something that could be made possible?
I'm making a node system that will enable connecting several different inputs to the same output, so this is why I'm wondering.
Thanks!

According to @trustmaster this has been implemented and is called "Array Ports". I would also like to use this feature but can't find any examples. Could someone help me out please?

The test you are looking for is here: https://github.com/trustmaster/goflow/blob/master/network_test.go#L193 (see the component using it above, it's called rr).


Drop 32bit packages because g++-multilib is no longer available

As discussed in https://github.com/sass/sassc-ruby/issues/195, rake gem:native is currently broken, preventing a new release.
The error is:
Package g++-multilib is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'g++-multilib' has no installation candidate
rake aborted!

I looked around and apparently this package is outdated an no longer available. However it's used for cross compiling for 32bit packages.
If we looked at downloaded packages:

https://rubygems.org/gems/sassc/versions/2.1.0-x86_64-linux 500K downloads
https://rubygems.org/gems/sassc/versions/2.1.0-x86-linux (32bits) 756 downloads.

I think it's safe to say that close to nobody downloads the 32 bits binaries, and for the few people who do, AFAIK it should fallback somewhat nicely to compiling from source.
All that to say that I think it's OK to drop it.
cc @bolandrm @rafaelfranca

Additionally f26f2a1febf93165256fbbc58d1f9019fd05d26f removed precompilation for linux, so really the only precompilation left is x64-mingw32.
I tested it locally and it works:
$ ls pkg/
sassc-2.2.1-x64-mingw32     sassc-2.2.1-x64-mingw32.gem sassc-2.2.1.gem

Please fix https://github.com/rake-compiler/rake-compiler-dock/blob/5dacab741e04354107bc2fa51ed2b5f06aec422e/Dockerfile.mri.erb#L55 to install the right package instead

Scratch that, the correct fix is to remove this install command:
https://github.com/sass/sassc-ruby/blob/0cb5c9e635bf94707c920227d4bd20c51e37922a/Rakefile#L41
This is now handled in rake-compiler itself

Well, that's what this PR does.
I pushed a new commit that adds x86-mingw32 back.

Please update the commit message as well

Please update the commit message as well

RIght, good point. Done.

Thanks.  Will release tomorrow morning assuming i don't run into any issues.

Release complete, thanks for the help!


Redim LongPtr Array (Long vs. LongLong)

Just wanted to point this out. If it is not relevant or a non-issue please mark as resolved.
in tB we can do following:
Dim MyArrPtr() As LongPtr
ReDim MyArrPtr(0 To 10) As LongPtr

However, VBA7 will convert the ReDim ... As LongPtr into As Long or As LongLong (depending if office 32bit or 64bit is used)
I am wondering if this is a bug in VBA7 or a feature... and if that has any other implication for porting a code done in 32bit to a 64bit environment.

As in the VBE rewrites LongPtr to LongLong for you only in Redim statements? Yeah that doesn't seem like a useful or relied upon feature, I say scrap it as it ofc makes the code less portable between 32 and 64 bit compilation targets (the code would stop working on 32-bit).
Also, until we have TypeDef/ type aliasing support (where I can declare Public TypeAlias HWND As LongLong: Dim a As HWND), LongLong and LongPtr have different connotations IMO. So even if I'm exclusively targeting 64 bit, I would still use both LongPtr and LongLong depending on context; I don't want my LongPtr to be eagerly resolved to LongLong if my code is talking about pointers and memory addresses, the alias is more readable.

To expand on that, the VBA language spec stipulates that:

An implementation-defined LongPtr type alias is also defined, mapping to the underlying declared type the implementation will use to hold pointer or handle values. 32-bit implementations SHOULD map LongPtr to Long, and 64-bit implementations SHOULD map LongPtr to LongLong, although implementations MAY map LongPtr to an implementation-defined pointer type. The LongPtr type alias is valid anywhere its underlying declared type is valid.

So LongPtr semantically refers not to LongLong or Long, but rather an implementation-defined pointer type, so we must not assume LongLong and LongPtr are interchangeable in a 64 bit environment. Depending on the platform, tB is entitled within the rules of the language spec to use 32 bit pointers even in a 64 bit operating system - and VBA7 autocorrect behavior would then just be buggy.

Yes.
My workaround is to omit the As LongPtr in the ReDim line.
Dim MyArrPtr() As LongPtr
ReDim MyArrPtr(0 To 10)

IMO in tB it is correct that ReDim .. As LongPtr is allowed.
However, I think a compiler warning/information may be good to engage the user maybe to skip the As LongPtr to hint at this problem for VBA7.
This way we avoid new code snippets done in tB which would be troubling when porting to VBA7.


Fix bug: responsive home page for litmus exp docs

Signed-off-by: mehabhalodiya<EMAIL_ADDRESS>
Proposed changes
Earlier, the home page for Litmus Experiment Docs was not responsive for mobile screens.
I have fixed that bug.
Preview:
https://user-images.githubusercontent.com/73488906/144735875-04185551-693b-411b-b758-a4dcc17a5fdb.mp4
https://user-images.githubusercontent.com/73488906/144735910-7b92ac5a-80f7-45e5-9f57-977cb0b90f3d.mp4
Resolves:

#3268

Types of changes
What types of changes does your code introduce to Litmus?

[ ] New feature (non-breaking change which adds functionality)
[x] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the commit for DCO to be passed.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)

Dependency
Not any for now!

@mallick370 Will you PTAL?
Thank you.


v3 CypherCapabilities excption CALL not supported

Hi All,
I am using Neo4j.Driver 1.6.1 , Neo4jClient 3.01.21 and Neo4j server 3.5.1
I am getting exception when I ran the below code
using (var client = new GraphClient(new Uri("http://localhost:7474/db/data"), "neo4j", "*****"))
       {
           var resQuery = client.Cypher
           .Match("p=(e:Entity {Id:'1001'})-[r:KNOWS]->()")
           .With("COLLECT(p) AS ps")
           .Call("apoc.convert.toTree(ps) yield value")
           .Return<string>("value");

           return resQuery.ToString();
       }

System.InvalidOperationException
HResult=0x80131509
Message=CALL not supported in Neo4j versions older than 3.0
Source=Neo4jClient

is there a way to set the CypherCapabilities version  ?
what do I need to do ?
Thanks

Hey,
You need to .Connect() to the instance first, the error is wrong - it should be saying you need to be connected so that needs to be fixed. In essence your code would look like:
using (var client = new GraphClient(new Uri("http://localhost:7474/db/data"), "neo4j", "*****"))
{
    client.Connect();
     var resQuery = client.Cypher
           .Match("p=(e:Entity {Id:'1001'})-[r:KNOWS]->()")
           .With("COLLECT(p) AS ps")
           .Call("apoc.convert.toTree(ps) yield value")
           .Return<string>("value");

     return resQuery.ToString();
}

What I would heartily recommend is that you don't use the client within a using statement like this - as it's an expensive (cpu cycles wise) way to use it. When you call Connect() for example - a call is made to the DB to see what's happening, get the version etc - so for every one call you make you actually make 2.

Hi @cskardon ,
Thanks so much for your recommendation and  explanation of how it works,
Calling the Connect() method fixed my issue.


Ordering of conference dates seems weired.

@Lukangkang123 plz check~

The conference dates are listed directly in alphabetical order. Because most conference dates start with the month,  you can look up conferences by month. If you want to sort by year as a priority, you can sort by due date.


Fix path handling, respect XDG standard directory locations

Apply sensible defaults for configuration and cache paths, respecting the user's
preferences when specified.
See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Fixes #19

I tried to resolve the merge conflicts, should be fine now. If you see any errors, please raise an issue.


ELM-1430 give test access to civica and g4s servers

added test access for civica and g4s

@pricemg Terraform plan evalaution detected changes to resources that require approval from a member of @ministryofjustice/modernisation-platform

@pricemg Terraform plan evalaution detected changes to resources that require approval from a member of @ministryofjustice/modernisation-platform

@pricemg Terraform plan evalaution detected changes to resources that require approval from a member of @ministryofjustice/modernisation-platform

completed in https://github.com/ministryofjustice/modernisation-platform-environments/actions/runs/7729342783/job/21072891077


[BUG]: Power BI Admin Report shows over time data wrong

Describe the bug
I was looking at the data in the Power BI report and it shows me overtime data for Jul 2021 through Nov 2021 and it does not show me current data. I have attached the screenshot of my report. Based on my knowledge to should show current time data.
I have added @topness-msft since we discussed and he suggested me to tell you and get your thoughts on it.
Component (please tell us which flow or app you are experiencing issues with):

Solution [e.g. Core, Nurture]
Version [e.g. 1.29]
App or Flow [e.g. Sync Template (v2)]

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Additional context
Add any other context about the problem here.

Hello,
thanks for reporting this! Looks like we had a formatting issue in the MMM-YYYY part that caused this behaviour. Would you be able to try this report: https://github.com/microsoft/powerapps-tools/raw/master/Administration/CoEStarterKit/Individual Components/Dashboard-PowerPlatformAdminDashboard-2021-01-07.pbit
And let me know if that looks better?
Thank you
Manuela

Hello,
thanks for reporting this! Looks like we had a formatting issue in the MMM-YYYY part that caused this behaviour. Would you be able to try this report: https://github.com/microsoft/powerapps-tools/raw/master/Administration/CoEStarterKit/Individual Components/Dashboard-PowerPlatformAdminDashboard-2021-01-07.pbit
And let me know if that looks better?
Thank you
Manuela

Hi @manuelap-msft
This report looks better. Thank You so much for your help.

Hi @manuelap-msft
This report looks better. Thank You so much for your help.

Probably want to fix this issue in Overview - Power Automate Tab

Probably want to fix this issue in Overview - Power Automate Tab

Looks like the relationship between maker and flow dropped, can you try this file? https://github.com/microsoft/powerapps-tools/raw/master/Administration/CoEStarterKit/Individual Components/Dashboard-PowerPlatformAdminDashboard-2021-01-07.pbit

Looks like the relationship between maker and flow dropped, can you try this file? https://github.com/microsoft/powerapps-tools/raw/master/Administration/CoEStarterKit/Individual Components/Dashboard-PowerPlatformAdminDashboard-2021-01-07.pbit

issue resolved

issue resolved


Update minSdkVersion in v7 libs to rootProject.ext.minSdkVersion

Not sure why these v7 libs were requiring Lollipop :\

Yikes.


Expose CDK testing module

Bug, feature request, or proposal:
Feature request
What is the expected behavior?
When using the overlay, I want to test if it is closed after pressing ESCAPE. CDK has helper functions to dispatch keyboard events from an specific element, this way I can use the helpers to quickly simulate an ESCAPE press from document.body (just like it's done in the Dialog tests):
https://github.com/angular/material2/blob/abc3d38c57146443c848d5ba26fd2fab8ca185d6/src/cdk-experimental/dialog/dialog.spec.ts#L200-L210
What is the current behavior?
@angular/cdk/testing module is not exposed, so none of the helper functions can be used.
What are the steps to reproduce?
In a project that has CDK as dependency, add the following import:
import { dispatchKeyboardEvent } from '@angular/cdk/testing';

It fails with the message [ts] Cannot find module<EMAIL_ADDRESS>What is the use-case or motivation for changing an existing behavior?
It's easier to use the already existing event creation/dispatch code when writing user interaction tests.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular 6.0.4
@angular/cdk 6.2.1

Is there anything else we should know?

See https://github.com/angular/material2/issues/9531#issuecomment-359969115
Someone we'd like to do testing utilities, but current it is just our own in-project testing utilities.


clean localstorage & wait for toolbar

[x] clean localstorage (to reset ui)
[x] wait for toolbar to display after going to direct links
[x] do the new page creation test suite

:+1:


Error after unconverged KrylovKit.GMRES linear solve

It seems that on the newest version KrylovKit something broke: If we compute the fixed-point gradient fpgrad using KrylovKit.GMRES and it doesn't converge, I get the following conversion error:
ERROR: MethodError: Cannot `convert` an object of type
  CTMRGEnv{TensorMap{ComplexSpace,1,1,Trivial,Array{Complex{Float64},2},Nothing,Nothing},TensorMap{ComplexSpace,1,1,Trivial,Array{Complex{Float64},2},Nothing,Nothing}} to an object of type
  CTMRGEnv{TensorMap{ComplexSpace,1,1,Trivial,Array{Complex{Float64},2},Nothing,Nothing},TensorMap{ComplexSpace,3,1,Trivial,Array{Complex{Float64},2},Nothing,Nothing}}

Closest candidates are:
  convert(::Type{T}, ::T) where T
   @ Base Base.jl:84
  (::Type{CTMRGEnv{C, T}} where {C, T})(::Any, ::Any)
   @ PEPSKit ~/repos/PEPSKit.jl/src/environments/ctmrgenv.jl:7

Stacktrace:
  [1] setindex!(A::Vector{CTMRGEnv{…}}, x::CTMRGEnv{TrivialTensorMap{…}, TrivialTensorMap{…}}, i1::Int64)
    @ Base ./array.jl:1021
  [2] setindex!(b::KrylovKit.OrthonormalBasis{CTMRGEnv{…}}, i::CTMRGEnv{TrivialTensorMap{…}, TrivialTensorMap{…}}, q::Int64)
    @ KrylovKit ~/.julia/packages/KrylovKit/wPepJ/src/orthonormal.jl:42
  [3] _rmul!(b::KrylovKit.OrthonormalBasis{CTMRGEnv{…}}, G::LinearAlgebra.Givens{ComplexF64})
    @ KrylovKit ~/.julia/packages/KrylovKit/wPepJ/src/dense/givens.jl:34
  [4] rmul!(b::KrylovKit.OrthonormalBasis{CTMRGEnv{…}}, G::LinearAlgebra.Givens{ComplexF64})
    @ KrylovKit ~/.julia/packages/KrylovKit/wPepJ/src/dense/givens.jl:16
  [5] linsolve(operator::Function, b::CTMRGEnv{…}, x₀::CTMRGEnv{…}, alg::GMRES{…}, a₀::Int64, a₁::Int64)
    @ KrylovKit ~/.julia/packages/KrylovKit/wPepJ/src/linsolve/gmres.jl:114
  [6] fpgrad(∂F∂x::CTMRGEnv{…}, ∂f∂x::Function, ∂f∂A::PEPSKit.var"#∂f∂A#174"{…}, y₀::CTMRGEnv{…}, alg::GMRES{…})
    @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/peps_opt.jl:201
  [7] (::PEPSKit.var"#leading_boundary_pullback#172"{…})(Δenvs′::CTMRGEnv{…})
    @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/peps_opt.jl:128
  [8] #28
    @ ~/repos/PEPSKit.jl/src/utility/hook_pullback.jl:34 [inlined]
  [9] ZBack
    @ ~/.julia/packages/Zygote/nsBv0/src/compiler/chainrules.jl:211 [inlined]
 [10] (::Zygote.var"#kw_zpullback#53"{PEPSKit.var"#28#29"{…}})(dy::CTMRGEnv{TrivialTensorMap{…}, TrivialTensorMap{…}})
    @ Zygote ~/.julia/packages/Zygote/nsBv0/src/compiler/chainrules.jl:237
 [11] #2
    @ ~/repos/PEPSKit.jl/test/ctmrg/gradients.jl:63 [inlined]
 [12] (::Zygote.Pullback{Tuple{…}, Tuple{…}})(Δ::Float64)
    @ Zygote ~/.julia/packages/Zygote/nsBv0/src/compiler/interface2.jl:0
 [13] (::Zygote.var"#75#76"{Zygote.Pullback{Tuple{…}, Tuple{…}}})(Δ::Float64)
    @ Zygote ~/.julia/packages/Zygote/nsBv0/src/compiler/interface.jl:91
 [14] withgradient(f::Function, args::InfinitePEPS{TrivialTensorMap{ComplexSpace, 1, 4, Matrix{ComplexF64}}})
    @ Zygote ~/.julia/packages/Zygote/nsBv0/src/compiler/interface.jl:213
 [15] compute_grad(peps::InfinitePEPS{…}, envs::CTMRGEnv{…}, boundary_alg::CTMRG, alg_rrule::GMRES{…})
    @ Main ~/repos/PEPSKit.jl/test/ctmrg/gradients.jl:62
 [16] top-level scope
    @ ~/repos/PEPSKit.jl/test/ctmrg/gradients.jl:70

It turns out that this only happens on the newest version v0.7.1, whereas on the previous version v0.6.1 this was not a problem. For comparison, I currently use the following package versions:
(PEPSKit) pkg> status
Project PEPSKit v0.1.0
Status `~/repos/PEPSKit.jl/Project.toml`
  [7d9f7c33] Accessors v0.1.36
  [d360d2e6] ChainRulesCore v1.24.0
  [34da2185] Compat v4.15.0
  [0b1a1467] KrylovKit v0.7.1
  [bb1c41ca] MPSKit v0.10.2 `https://github.com/maartenvd/MPSKit.jl.git#master`
  [77e91f04] OptimKit v0.3.1
  [07d1fe3e] TensorKit v0.12.4
  [409d34a3] VectorInterface v0.4.5
  [e88e6eb3] Zygote v0.6.70
  [37e2e46d] LinearAlgebra
  [de0858da] Printf
  [9a3f8284] Random
  [10745b16] Statistics v1.10.0

Note that I added the master branch of MPSKit to resolve the KrylovKit dependency conflict. Here's a MWE that should reproduce the error where I intentionally prevent the linear solver from converging:
using Random
using PEPSKit
using TensorKit
using Zygote
using KrylovKit

Random.seed!(42039482038)
χbond = 2
χenv = 8
boundary_alg = CTMRG(;
    trscheme=truncdim(χenv), tol=1e-10, miniter=20, maxiter=100, verbosity=1
)
psi = InfinitePEPS(2, χbond)
env = leading_boundary(CTMRGEnv(psi; Venv=ℂ^χenv), psi, boundary_alg)

function compute_grad(peps, envs, boundary_alg, alg_rrule)
    E, g = Zygote.withgradient(peps) do psi
        envs2 = PEPSKit.hook_pullback(leading_boundary, envs, psi, boundary_alg; alg_rrule)
        return costfun(psi, envs2, H)
    end
    return only(g)
end

g = compute_grad(psi, env, boundary_alg, KrylovKit.GMRES(; tol=1e-16, maxiter=2, verbosity=3))

Maybe @lkdvos knows what's going on here?

I am not sure why this only ever happened when it does not converge, but this fix seems to at least solve the minimal example you added (thanks for that by the way, that made solving this so much easier!)

Thanks for the super quick fix!


uprobes with function names containing dollar sign fail

i think bpftrace encounters parsing difficulties with function names containing dollar signs ($). dollar signs are commonly used in mangled function names generated by rust complier.
https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html

for instance take a look at this:
$ bpftrace -l "uprobe:/tmp/qdrant:*

uprobe:qdrant:_ZN67_$LT$regex_syntax..hir..LookSet$u20$as$u20$core..cmp..PartialEq$GT$2eq17hbf472fe7f62896eaE
uprobe:qdrant:_ZN67_$LT$reqwest..tls..TlsBackend$u20$as$u20$core..default..Default$GT$7default17hdff9fd41950b9d49E
uprobe:qdrant:_ZN67_$LT$ring..aead..block..Block$u20$as$u20$core..ops..bit..BitXor$GT$6bitxor17h43947c2b18288922E
uprobe:qdrant:_ZN67_$LT$ring..agreement..Algorithm$u20$as$u20$core..cmp..PartialEq$GT$2eq17hfa52dffa2abf9b6fE
uprobe:qdrant:_ZN67_$LT$ring..arithmetic..bigint..N0$u20$as$u20$core..clone..Clone$GT$5clone17h5e86278622600d6bE
uprobe:qdrant:_ZN67_$LT$ron..de..value..ValueVisitor$u20$as$u20$serde..de..Visitor$GT$10visit_bool17ha4f828533b571352E
uprobe:qdrant:_ZN67_$LT$ron..de..value..ValueVisitor$u20$as$u20$serde..de..Visitor$GT$10visit_char17hd7380207f2b272e8E

also demangling is not a solution here. sometimes it's not possible to do that, so IMHO we should hack the parser in a way to support $ signs.

i found a temporary solution for my case. if I replace all those dollar signs with asterisk symbol it works perfectcly.

You should be able to quote the symbol names to have them go through the parser, like this:
uprobe:qdrant:"_ZN67_$LT$regex_syntax..hir..LookSet$u20$as$u20$core..cmp..PartialEq$GT$2eq17hbf472fe7f62896eaE" { }

To give a more complete response to the original request about changing the parser:

It'd make the parser more complicated, because uprobe:exe:$1 already has a distinct meaning - $1 is an argument passed in from the command line.
We don't really want to add specific syntax to support various languages, because where do we stop? C++, Rust, Go, Java, Haskell, Zig, Nim, ...? What if some languages uses colons (:) in its mangled names?

That's not to say that we don't want to support these languages, only that we shouldn't incorporate their specifics into bpftrace's syntax.
A similar issue has come up as we're currently adding support for understanding C++ types - how can we parse a type name like std::vector<int>?
The best solution we've got currently is to escape them in some way so that the parser doesn't try to understand them. That's where the quotes come in.


Added online SQLite browsers

Add SQLite viewer and ExtendsClass.

Nice! Thank you! :tada: :memo:

Thanks!


Implementation of the Arch Linux target in crouton

Hello, everyone.
I know that drinkcat already made a fork of crouton named chroagh, which does the exact thing thing, but wouldn't it be better to have the two projects merged? Since chroagh seems pretty darn efficient but needs to have its own script.

Duplicates https://github.com/dnschneid/crouton/issues/2367


Update bulma library

Very old bulma library. It is very recommendable update at least to 0.6.2 version.

nav tags are deprecated. Now navbar is more powerful option than nav
Dropdown doesn't support icons

I am going to help you to upgrade bulma library to 0.6.2 version.

Yeah I agree, that'd be awesome if you could help!

Why did you close this??
It is not solved... Please reopen it and wait until the issue is solved.
Usually the issue is closed with the commit message. You can write Fix #11 where 11 is the number of the issue and when you merge mi PR (Pull Request) with my changes, the issue will close automatically.


Add index.html to URLs as needed.

Add index.html to all URLs found in the documentation.
Also change the link found on the tour component.
Remember to make changes in gh-pages as well as the docs/meridian folder.

Confirmed following URL's were update and working....
https://localhost:3000/docs/meridian/index.html
"Download Meridian" button prompts download to Meridian like it should.
"View on GitHub" navigates to https://github.com/ozone-development/meridian
"Launch Meridian" launches Meridian Map in a new browser tab using URL - https://ec2-54-88-124-5.compute-1.amazonaws.com:3000/index.html
https://localhost:3000/docs/meridian/getting-started/index.html
https://localhost:3000/docs/meridian/getting-started/index.html#startedQuickly
https://localhost:3000/docs/meridian/getting-started/index.html#accessMeridian
https://localhost:3000/docs/meridian/getting-started/index.html#embedMeridian
https://localhost:3000/docs/meridian/getting-started/index.html#requirements
https://localhost:3000/docs/meridian/getting-started/index.html#withoutGrunt
https://localhost:3000/docs/meridian/getting-started/index.html#withGrunt
https://localhost:3000/docs/meridian/getting-started/index.html#resources
https://localhost:3000/docs/meridian/contribute/index.html
https://localhost:3000/docs/meridian/contribute/index.html#pullRequest
https://localhost:3000/docs/meridian/contribute/index.html#issues
https://localhost:3000/docs/meridian/contribute/index.html#styleGuide
https://localhost:3000/docs/meridian/examples/index.html
https://localhost:3000/docs/meridian/examples/index.html#starting
https://localhost:3000/docs/meridian/examples/index.html#startingExample
https://localhost:3000/docs/meridian/examples/index.html#components
https://localhost:3000/docs/meridian/examples/index.html#componentsRules
https://localhost:3000/docs/meridian/examples/index.html#componentsExamples
https://localhost:3000/docs/meridian/examples/index.html#messaging
https://localhost:3000/docs/meridian/examples/index.html#messagingRules
https://localhost:3000/docs/meridian/examples/index.html#messagingExamples
https://localhost:3000/docs/meridian/examples/index.html#sandBoxing
https://localhost:3000/docs/meridian/examples/index.html#sandBoxingExamples
https://localhost:3000/docs/meridian/examples/index.html#extensions
https://localhost:3000/docs/meridian/examples/index.html#extensionsRules
https://localhost:3000/docs/meridian/examples/index.html#extensionsExamples
https://localhost:3000/docs/meridian/examples/index.html#meridian
https://localhost:3000/docs/meridian/examples/index.html#demo
https://localhost:3000/docs/meridian/examples/index.html#source

That covers the actual page.
Also verify that the support component button called 'Meridian Docs" points to: https://localhost:3000/docs/meridian/index.html instead of https://localhost:3000/docs/meridian
Finally, verify the same links sone on your initial test but replacing https://localhost:3000/docs/meridian with http://ozone-development.github.io/meridian

Passed on develop.


put audio tag that unchanged when changing page

where can i audio tag  that mounting pages in vue doesnt affect audio tag and reset this element. saw answers in vue router but not worked in inertia

To do this see persistent layouts: https://inertiajs.com/pages#persistent-layouts
You may also find this talk helpful, as it covers exactly this: https://vimeo.com/showcase/7060635/video/452360085
This isn't really an issue, so I'm going to close this.


Upgrade netty version

Description
This PR upgrades netty version to a patched version - CVE: https://github.com/advisories/GHSA-p979-4mfw-53vg
Fixes: #6058
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[x] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

@blueorangutan package

@nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 2767

@blueorangutan test

@nvazquez a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-3497)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 31659 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr6059-t3497-kvm-centos7.zip
Smoke tests completed. 92 look OK, 0 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File

upload template/iso from local are tested ok.


"Passwords don't match" was displayed for 1 sec

And then everything was processed normally

Still an issue on Firefox


Omnicored hangs when making rpc calls from Python

I'm running omnicored in daemon mode on Windows Server 2016.  I have a python script that uses the bitcoinrpc python library to make multiple rpc calls.    However, within 200 to 300 calls in a row, omnicored freezes.  I then can't make any calls using omnicore-cli (no response), including stopping omnicored.   I eventually have to kill the process through task manager, which then results in omnicored not being able to find a persistent state when I start the process up again (and the subsequent lengthy scanning process). Below is the debug file snippet.
Any thoughts?  Thanks!
2018-05-15 00:31:24 UpdateTip: new best=000000000000000000285c8fd41b5945983f89cb939fa70429ba5c2358cbfc32 height=522709 version=0x20000000 log2_work=88.805933 tx=316358386 date='2018-05-14 23:58:59' progress=0.999995 cache=265.8MiB(201135tx)
2018-05-15 00:31:28 UpdateTip: new best=000000000000000000278076841fa340803244aa5d31eb3ba44de2c72184a501 height=522710 version=0x20000000 log2_work=88.805981 tx=316358924 date='2018-05-15 00:02:47' progress=0.999996 cache=266.7MiB(201568tx)
2018-05-15 00:33:23 ProcessMessages: advertising address <IP_ADDRESS>:8333
2018-05-15 00:33:23 receive version message: /Satoshi:0.15.1/: version 70015, blocks=522710, us=<IP_ADDRESS>:44628, peer=10
2018-05-15 00:33:23 AdvertiseLocal: advertising address <IP_ADDRESS>:8333
2018-05-15 00:38:44 ProcessMessages(version, 113 bytes) FAILED peer=11
2018-05-15 00:39:56 UpdateTip: new best=00000000000000000039acd511d26a9b4952783268e51dc7fef6eef3864b5127 height=522711 version=0x20000000 log2_work=88.806028 tx=316362094 date='2018-05-15 00:39:42' progress=1.000000 cache=270.5MiB(205672tx)
2018-05-15 00:40:45 UpdateTip: new best=00000000000000000006321548653034025e9f4807ce5b0281bac012e3a712d9 height=522712 version=0x20000000 log2_work=88.806075 tx=316363445 date='2018-05-15 00:40:36' progress=1.000000 cache=271.2MiB(207704tx)
2018-05-15 00:47:33 AdvertiseLocal: advertising address <IP_ADDRESS>:8333
2018-05-15 00:55:27 ProcessMessages: advertising address <IP_ADDRESS>:8333
2018-05-15 00:55:27 receive version message: /Satoshi:0.13.2/: version 70015, blocks=522712, us=<IP_ADDRESS>:16320, peer=12
2018-05-15 00:55:27 AdvertiseLocal: advertising address <IP_ADDRESS>:8333
2018-05-15 00:56:03 ProcessMessages: advertising address <IP_ADDRESS>:8333
2018-05-15 00:56:03 receive version message: /Satoshi:0.16.0/: version 70015, blocks=522712, us=<IP_ADDRESS>:12739, peer=13
2018-05-15 00:56:03 AdvertiseLocal: advertising address <IP_ADDRESS>:8333
2018-05-15 00:59:22 UpdateTip: new best=0000000000000000003d857ca1be5f8eccc38411696753236fe44ac8f3ea882b height=522713 version=0x20000000 log2_work=88.806123 tx=316365788 date='2018-05-15 00:59:17' progress=1.000000 cache=272.9MiB(211267tx)
2018-05-15 01:00:46 UpdateTip: new best=0000000000000000001be0157c683b4992b00c3b74cad6ed8a9a7ad85ec34023 height=522714 version=0x20000000 log2_work=88.80617 tx=316365869 date='2018-05-15 01:00:04' progress=1.000000 cache=272.9MiB(211455tx)
2018-05-15 01:01:04 ProcessMessages: advertising address <IP_ADDRESS>:8333
2018-05-15 01:01:04 receive version message: /Satoshi:<IP_ADDRESS>/: version 70015, blocks=522714, us=<IP_ADDRESS>:25823, peer=14
2018-05-15 01:01:04 AdvertiseLocal: advertising address <IP_ADDRESS>:8333
2018-05-15 01:09:03 socket send error An operation was attempted on something that is not a socket.  (10038)
2018-05-15 01:09:03 ProcessMessages: advertising address <IP_ADDRESS>:8333
2018-05-15 01:09:03 receive version message: /Satoshi:0.15.1/: version 70015, blocks=522714, us=<IP_ADDRESS>:4185, peer=15
2018-05-15 01:09:03 AdvertiseLocal: advertising address <IP_ADDRESS>:8333
2018-05-15 01:19:27 Pre-allocating up to position 0xc00000 in rev01260.dat
2018-05-15 01:19:28 UpdateTip: new best=0000000000000000003e0b5ef353c3c544c9147974a5094d2e0cb1de7dec156d height=522715 version=0x20000000 log2_work=88.806218 tx=316368244 date='2018-05-15 01:19:16' progress=1.000000 cache=275.0MiB(214518tx)
2018-05-15 01:22:25 UpdateTip: new best=000000000000000000333ae63b5622db7f3d12de71fadef9a8f4688087e01508 height=522716 version=0x20000000 log2_work=88.806265 tx=316368583 date='2018-05-15 01:22:14' progress=1.000000 cache=275.8MiB(215171tx)
2018-05-15 01:34:28 tor: Thread interrupt
2018-05-15 01:34:28 net thread interrupt
2018-05-15 01:34:28 torcontrol thread exit
2018-05-15 01:34:28 addcon thread interrupt
2018-05-15 01:34:28 scheduler thread interrupt
2018-05-15 02:26:18 CloseSocket(hListenSocket) failed with error WSAStartup cannot function at this time because the underlying system it uses to provide network services is currently unavailable.  (10091)
2018-05-15 02:26:18 CloseSocket(hListenSocket) failed with error WSAStartup cannot function at this time because the underlying system it uses to provide network services is currently unavailable.  (10091)
2018-05-15 02:26:29

Hi @mv1929,
thanks for reporting this!
Did you run your script while synchronizing or when the client was fully synced?

It was fully synced, though still online and updating as new blocks came in.  I was thinking of running the script with the network turned off to see what happens (after I get an external hard drive to make a backup).
Below is the snippet of my omnicore.log from this same time period, if it helps:
2018-05-15 01:19:32 parseTransaction(block=522715, 2018-05-15 01:19:16 idx= 2089); txid: 09c7b7de390a4bacaf3d6bc1343180b8547cfce2215fbc3a7a3bef7ed6681bb7
2018-05-15 01:19:32 	------------------------------
2018-05-15 01:19:32 	         version: 0, class C
2018-05-15 01:19:32 	            type: 0 (Simple Send)
2018-05-15 01:19:32 	        property: 31 (SP token: 31)
2018-05-15 01:19:32 	           value: 9985.00000000
2018-05-15 01:19:32 update_tally_map(197tjueV72Vkc9ryRPfH7GB4gujPCKMEPt, 31=0x1F, -998500000000, ttype=0): before=998500000000, after=0
2018-05-15 01:19:32 update_tally_map(168o1kqNquEJeR9vosUB5fw4eAwcVAgh8P, 31=0x1F, +998500000000, ttype=0): before=24458358890805166, after=24459357390805166
2018-05-15 01:19:32 recordTX(09c7b7de390a4bacaf3d6bc1343180b8547cfce2215fbc3a7a3bef7ed6681bb7, valid=YES, block= 522715, type= 0, value=<PHONE_NUMBER>00)
2018-05-15 01:22:25 ____________________________________________________________________________________________________________________________________
2018-05-15 01:22:25 parseTransaction(block=522716, 2018-05-15 01:22:14 idx= 74); txid: 3b69356b7abe81d637fb64de3e76656d1744f28f34799ab5f92a72d2162a4188
2018-05-15 02:24:18
Omni Core shutdown completed
2018-05-15 02:24:18 Shutdown time: 2018-05-15 02:24:18
2018-05-15 02:25:55
Omni Core shutdown completed
2018-05-15 02:25:55 Shutdown time: 2018-05-15 02:25:55
2018-05-15 02:29:11
Initializing Omni Core v0.3.0 [main]
2018-05-15 02:29:11 Startup time: 2018-05-15 02:29:11
2018-05-15 02:29:46 Loading feature activations from levelDB
2018-05-15 02:29:50 Loading freeze state from levelDB
2018-05-15 02:29:51 Seed block filter active - 82372 blocks will be parsed during initial scan.
2018-05-15 02:29:52

I found that if I use a firewall to block omnicored from making network calls, the issue goes away.

That's interesting. So you resolved the issue?

We're suffering from a similar bug. I think this error trace stack is just what you generally get when there are consensus header disagreements on the last block of the reindex, which can occur for any number of reasons, and that after the reindex is complete general syncing isn't so compromised. There's definitely a fixable bug in here, the firewall may have prevented new block headers from hitting the node while the reindex completed...
But then in our case it's probably due to the header format changing in Litecoin 0.16
The July 2017 Litecoin build also runs into the same issue so there's merit to that theory.

@patrickdugan: have you found any fix or workaround yet?


Fix outdated file name in README

Could you update the name of the class as well? It also changed from Actor to Agent at some point 😄


changedstylingofcontactpage

Closes
Closes #1183
Description
changed the contacts page footer and also the page your numbers were not visible changed that color to white
Screenshots

Note to reviewers

Checklist:

[x] I have linked the PR to the correct issue.
[x] I have read the Contribution Guidelines
[x] I have built and tested the changes, and they do not break or show any errors.

can you please review my pr @Vaishnavi-Patil2211

can you please review my pr @Vaishnavi-Patil2211


Add a productivity > CLI Assistants category?

First, thanks for this! It's a great resource of what's out there!
I am developing a set of open benchmarks for DevOps AI Assistants. I noticed that the AI assistants I evaluated aren't on this list and might be nice to add. However, it feels like this would require a new subcategory...basically:

Productivity

CLI Assistants

OpsTower.ai (AWS)
Release.ai (AWS)
Kubectl-GPT
Kubectl-gpt

Happy to formalize in a PR. Thoughts?

Hi @itsderek23 and thank you for your interest in this repo !
I intend this repo to have categories based on features more than human-computer interaction. But! It is a great idea to add this distinction and that's why emojis are here.
I suggest to add the following emojis based on the way to interact with the cited software :

:hash: for CLI-interfaced software
🖥 for browser-interfaced software
👨💻 for IDE-interfaced software

If some assistants do all of these features, only one must be mentioned: the one the product is the most recognized for.

Here they are : b7e6d5dccb37e6039c91f3ee6aa4435504e9bbd9
Don't hesitate to contribute with relevant technologies not yet in this repo!

@flavienbwk - I added the 2 most robust DevOps AI Assistants from the benchmarks in #4.


Tasks that need an Internet connection should wait until we have an Internet connection before executing

We can implement this via a needsInternet property on SYNQueueTask.
Then we can inject a dependency for the task that waits for reachability to return with a valid connected status before completing.
This can help us do things like web requests that are queued then assured to be completed the next time we have Internet, rather than just errororing out after retries run out.

The queue should not have any concept of what the Internet is. It's a common use case, but we need a more generic solution.

It could just be a generic "DependancyBlockProtocol" with a simple method that returns a bool based on if a condition is met or not. Then depending on the return value, on true it would go ahead and execute the actual task and on false it would postpone it and try to call this block of code again in idk x seconds?
This would be a "pull" model. Could be adapted to make it work with events/callbacks instead. Idk, just an idea. I definitely can see myself using this lib but with an internet connection dependancy.

@jyounus Thanks for the feedback! I like that idea, but like you said it needs to be based on a callback because we don't want to keep polling for it (would a false returned from it be considered a failure?).
I completely agree that an internet connection dependency is necessary and it's a top priority.


Nesting more than one slot component in a layout component makes $page lose reactivity

Describe the bug
It all started with a discord user asking a simple question https://discord.com/channels/457912077277855764/1119224594910412862/1119224594910412862
This user had a problem with stores so we helped him to create a derived store. But than we went back again with another problem...it didn't seemed to work as intended (https://discord.com/channels/457912077277855764/1119224594910412862/1119289050013118625)
Poking around that example i wasn't able to understand why it didn't worked and i kinda got nerdsniped. My first toguht was that it was a problem with konsta but it didn't seemed like they were doing anything fancy. Modifing the konsta components to make them as barebone as possible inside the node modules i went ahead and deleted everything leaving just the slots...the problem still occured.
So apparently if you have a situation like this where the slot for the layout is nested inside a component that has a slot inside another component with a slot $page stop being considered dirty (i also checked that this is the case with a step by step debugger in chrome).
Reproduction

Go to https://www.sveltelab.dev/hndxsmadcbwegdj
Navigate to /auth/login
Observe that the $path.url.pathname outside  is in sync with the one inside
Click the link to Forgot
Observe that the $path.url.pathname outside  is out of sync with the one inside

Logs
No response
System Info
System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.1.0
    @sveltejs/kit: ^1.5.0 => 1.20.4
    svelte: ^3.54.0 => 3.59.2
    vite: ^4.0.0 => 4.3.9

Severity
serious, but I can work around it
Additional Information
I also checked for navigating to see if that was a problem of all sveltekit stores and it didn't seem like that was the case

I believe this is a duplicate of #10116 - would be great to put your reproductions/findings in that issue :pray:

I believe this is a duplicate of #10116 - would be great to put your reproductions/findings in that issue 🙏

Ups...I tried to find similar issues but found nothing...I'll report back there even tho their findings are pretty similar to mine


Update README.md

Update README.md to include reference to React on Rails.
This is currently a popular solution with over 1.7M downloads and it's on over 1400 sites.
https://publicwww.com/websites/"react-on-rails"++-undeveloped.com/

I think a better place to mention this project would be on the Rails webpacker repo if people are looking for a server rendered option.


CCLA Signature Query Error

Summary
We have an issue in PROD when querying the CNCF signatures.
Background
17:22:40
2020-01-10T17:22:40 INFO cla: Requested: POST /v2/check-prepare-employee-signature application/json
2020-01-10T17:22:40 INFO cla: Requested: POST /v2/check-prepare-employee-signature application/json
17:22:41
2020-01-10T17:22:41 DEBUG cla: Check and prepare employee signature for project: d8cead54-92b7-48c5-a2c8-b1e295e8f7f1, company: 40f2d23b-fd1e-4f5d-acc1-d9ed425adf54, user: 729b1a99-b747-4745-a70f-5b7b83a0bcbb
17:22:41
2020-01-10T17:22:41 DEBUG cla: Project exists for: project: d8cead54-92b7-48c5-a2c8-b1e295e8f7f1, company: 40f2d23b-fd1e-4f5d-acc1-d9ed425adf54, user: 729b1a99-b747-4745-a70f-5b7b83a0bcbb
17:22:41
2020-01-10T17:22:41 DEBUG cla: Company exists for: project: d8cead54-92b7-48c5-a2c8-b1e295e8f7f1, company: 40f2d23b-fd1e-4f5d-acc1-d9ed425adf54, user: 729b1a99-b747-4745-a70f-5b7b83a0bcbb
17:22:41
2020-01-10T17:22:41 DEBUG cla: User exists for: project: d8cead54-92b7-48c5-a2c8-b1e295e8f7f1, company: 40f2d23b-fd1e-4f5d-acc1-d9ed425adf54, user: 729b1a99-b747-4745-a70f-5b7b83a0bcbb
17:22:41
2020-01-10T17:22:41 INFO cla: Loading signature by project for project_id: d8cead54-92b7-48c5-a2c8-b1e295e8f7f1
17:22:41
2020-01-10T17:22:41 INFO cla: Loaded signature by project for project_id: d8cead54-92b7-48c5-a2c8-b1e295e8f7f1
17:22:42
2020-01-10T17:22:42 INFO cla: <IP_ADDRESS> - - [2020-01-10 17:22:42.933196] POST /v2/check-prepare-employee-signature 200 OK - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
17:22:42
[ERROR] TypeError: 'NoneType' object is not iterable Traceback (most recent call last):   File "/var/task/wsgi_handler.py", line 108, in handler     return serverless_wsgi.handle_request(wsgi_app, event, context)   File "/var/task/serverless_wsgi.py", line 173, in handle_request     response = Response.from_app(app, environ)   File "/var/task/werkzeug/wrappers/base_response.py", line 287, in from_
[ERROR] TypeError: 'NoneType' object is not iterable
Traceback (most recent call last):
  File "/var/task/wsgi_handler.py", line 108, in handler
    return serverless_wsgi.handle_request(wsgi_app, event, context)
  File "/var/task/serverless_wsgi.py", line 173, in handle_request
    response = Response.from_app(app, environ)
  File "/var/task/werkzeug/wrappers/base_response.py", line 287, in from_app
    return cls(*_run_wsgi_app(app, environ, buffered))
  File "/var/task/werkzeug/test.py", line 1119, in run_wsgi_app
    app_rv = app(environ, start_response)
  File "/var/task/hug/api.py", line 502, in api_auto_instantiate
    return module.__hug_wsgi__(*args, **kwargs)
  File "falcon/api.py", line 274, in falcon.api.API.__call__
    raise
  File "falcon/api.py", line 269, in falcon.api.API.__call__
    responder(req, resp, **params)
  File "/var/task/hug/api.py", line 356, in version_router
    request, response, api_version=api_version, **kwargs
  File "/var/task/hug/interface.py", line 946, in __call__
    raise exception
  File "/var/task/hug/interface.py", line 917, in __call__
    self.call_function(input_parameters), context, request, response, **kwargs
  File "/var/task/hug/interface.py", line 839, in call_function
    return self.interface(**parameters)
  File "/var/task/hug/interface.py", line 129, in __call__
    return __hug_internal_self._function(*args, **kwargs)
  File "/var/task/cla/routes.py", line 1235, in check_and_prepare_employee_signature
    return cla.controllers.signing.check_and_prepare_employee_signature(project_id, company_id, user_id)
  File "/var/task/cla/controllers/signing.py", line 100, in check_and_prepare_employee_signature
    return get_signing_service().check_and_prepare_employee_signature(str(project_id), str(company_id), str(user_id))
  File "/var/task/cla/models/docusign_models.py", line 382, in check_and_prepare_employee_signature
    signature_reference_id=company.get_company_id()
  File "/var/task/cla/models/dynamo_models.py", line 1947, in get_signatures_by_project
    for signature_model in signature_generator:
  File "/var/task/pynamodb/pagination.py", line 183, in __next__
    item = self._map_fn(item)
  File "/var/task/pynamodb/models.py", line 533, in from_raw_data
    kwargs[attr_name] = attr.deserialize(attr.get_value(value))
  File "/var/task/pynamodb/attributes.py", line 973, in deserialize
    for v in values:
END RequestId: aa1f4275-dd21-4511-b6b0-b3f145f2a9db

Expected behavior
The query should run without error.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
PROD

Environment: PROD

Additional Context
Add any other context about the problem here.
Acceptance Criteria
Resolve the database query error. Push changes to DEV, STAGING, and PROD.

Unit Tests added and running in CI
Functional Tests updated to cover feature, if applicable
Demonstrate the set of capabilities to the product team while the code is running in the STAGING environment.

References
Product Support Ticket: https://jira.linuxfoundation.org/servicedesk/customer/portal/4/SUPPORT-839

Use case:

Create PR for CNCF project
EasyCLA bot Fails the PR
User clicks through to EasyCLA
User selects Corporate CLA
User searches and selects their company
UI spins while performing the CCLA signature lookup


Hessian-vector products

In the original paper, the authors claimed that MAML needs second gradient and Hessian-vector products. Could you explain how do you implement this or Pytorch just do this automatically? Thanks!
referenced https://github.com/dragen1860/MAML-Pytorch/issues/18

PyTorch can compute the second derivatives automatically. See these lines for how it's done in this codebase: https://github.com/katerakelly/pytorch-maml/blob/master/src/inner_loop.py#L53-L77


Feat: Added the search functionality on people page

Fixes Issue #25: Enable Search Functionality on People Page
This pull request implements search functionality on the people page, addressing Issue #25.

Proposed Changes
Search Functionality: Users can now search for people based on username.
Implementation: The search leverages Appwrite's query filtering capabilities when available. As a fallback, it filters locally through the user list if Appwrite search fails.
File Changes: Modifications were made to the following files:
AllUsers.tsx: Added search bar component and logic for handling user input and updates.
api.ts: modifications to interact with Appwrite for search queries.
queriesAndMutations.tsx: modifications to fetch and handle search results using Appwrite.
queryKey.ts:  modifications to define query keys for search functionality.

Screenshots
https://github.com/Nishitbaria/OpenGrame/assets/125805624/a07c4827-8ccf-4539-b047-1046f5d2b13f

Note to reviewers
I've thoroughly tested the changes to ensure they don't introduce unintended side effects. If you have any questions or suggestions for improvement, please feel free to leave comments in the code review.

Hey @tuwid-Ashish
There are some issues I found

Ideally, all users should be visible. However, when a search is performed, only the search results should be displayed.

see the responsive search bar in the explore section I want a similar design currently your design is not align with that

Hii @Nishitbaria ,
I will fix these issues as soon as possible. Thanks for reviewing


Ninja garb should hide player name

Task description
Currently the ninja garb armour doesn't actual hide the display name of a player wearing it like it's item description says.
This item is intended to allow players to maintain anonymity so they can attempt surprise attacks/assassinations on other players without fear of repercussion later when they aren't wearing it.
References/notes
This should be done on the server side to avoid players being able to manually show the display name for a player entity on the client.
Where player display name is retrieved from the player entity: https://github.com/Arcanorum/dungeonz/blob/master/server/src/entities/classes/destroyables/movables/characters/Player.js#L195
Similar name change functionality (add this to the ninja garb item for when it is equipped/unequipped): https://github.com/Arcanorum/dungeonz/blob/master/server/src/entities/classes/destroyables/movables/characters/Player.js#L504
Acceptance criteria

When a ninja garb is equipped, that player's display name should be hidden from all players in range.
When a player with a ninja garb equipped comes into view of a player, their display name should be hidden.
When a player wearing a ninja garb unequips it, their display name should be made visible to all players in range.
When a player wearing a ninja garb sends a chat message, the name of the player in the chat box should be shown as "???".

I'd like to give this a shot.

Sure


Resource not accessible by integration

Getting the following issue:
with:
    repo-token: ***
    silent: false
    tour-path: .tours/
    fail-on-missing-tour-updates: false
RequestError [HttpError]: Resource not accessible by integration
    at /home/runner/work/_actions/pozil/codetour-watch/v1.6.[3](https://github.com/yt-project/yt/actions/runs/3426987744/jobs/5839717454#step:3:3)/node_modules/@octokit/request/dist-node/index.js:86:21
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async commentPr (/home/runner/work/_actions/pozil/codetour-watch/v1.6.3/src/index.js:171:9)
    at async run (/home/runner/work/_actions/pozil/codetour-watch/v1.6.3/src/index.js:75:13) {
  status: [4](https://github.com/yt-project/yt/actions/runs/3426987744/jobs/5839717454#step:3:4)03,

Hi @jzuhone, looking at your logs I believe that you made a mistake in the version tag.
The line is missing the patch version (the last digit of the version number):
at /home/runner/work/_actions/pozil/codetour-watch/v1.6.

@jzuhone please disregard my last comments.
Based on the error message and the source code (index.js:71), the GitHub token that is provided to the action does not allow it to create a comment.
await octokit.rest.issues.createComment(commentInfo);

You may need to change your repo settings to allow this comment or provide a personal access token to the action.


Not able to run ctakes-web-client war deployment in tomcat

I downloaded the ctakes-web-client from this git hub repo and built ctakes-web-client.war using maven build. Then I downloaded this web app in tomcat. The deployment was successful and was  able to access the index page without any errors. But when I click on submit button after enter text in textbox, it gives the following error:
javax.servlet.ServletException: org.apache.uima.resource.ResourceInitializationException: Initialization of annotator class "org.apache.ctakes.dictionary.lookup2.ae.DefaultJCasTermAnnotator" failed.  (Descriptor: )
org.apache.ctakes.web.client.servlet.DemoServlet.init(DemoServlet.java:70)
javax.servlet.GenericServlet.init(GenericServlet.java:158)
I m using 64 bit Java 1.8.0_131-b11.
Please help me out in resolving this issue.Thanks in advance.

Can anyone help me out on this?

Finally managed to resolve this issue and its related to HSQL InMemory DB with tomcat deployment.

Could you elaborate how you solved this problem. I am also getting same problem when I am running a ctakes.war on my docker with 64 bit  Java 1.8.0_151 , tomcat 8.

I moved away from HSQL db to MySQL. But if u r still using HSQL, just check all HSQL related files are in place in exploded war


[BUG] open_path fails on API calls

Software Versions:

Operating System: Linux x64 (Ubuntu 22.04)
Python version: 3.10.5
BusyLight version: 0.21.1

General Type of Problem

[x] Web API

Describe the Problem
When starting the web API, a DEBUG message appears stating:
2022-07-17 14:11:06.670 | DEBUG    | busylight.lights.usblight:update:670 - Embrava Blynclight Standard@1-4:1.0 write_strategy returned 9 sent<PHONE_NUMBER>0080ff22

and then, when attempting to access any API endpoint, the following error appears:
2022-07-17 14:17:38.406 | ERROR    | busylight.lights.usblight:acquire:629 - open_path failed with open failed
2022-07-17 14:17:38.408 | ERROR    | busylight.lights.usblight:all_lights:202 - Blynclight LightUnavailable: 2c0d:000c path=b'1-4:1.0'

Light commands seem to work (on/off, at least), but not much information about the light returns in /light/0/status (missing serial_number, manufacturer_string, usage, perhaps?):
{
  "light_id": 0,
  "name": "Embrava Blynclight Standard",
  "info": {
    "path": "1-4:1.0",
    "vendor_id": 11277,
    "product_id": 12,
    "serial_number": "",
    "release_number": 1,
    "manufacturer_string": "",
    "product_string": "Blynclight Standard",
    "usage_page": 0,
    "usage": 0,
    "interface_number": 0
  },
  "is_on": false,
  "color": "black",
  "rgb": [
    0,
    0,
    0
  ]
}

Perhaps the open_path error is limiting the information obtained from the light? Unsure.
Expected Behavior
No errors to occur.
Error Output
Full log from busyserve start:
2022-07-17 14:11:04.963 | INFO     | busylight.__main__:serve_http_api:380 - serving http api
INFO:     Will watch for changes in these directories: ['/']
INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
INFO:     Started reloader process [1] using StatReload
2022-07-17 14:11:06.364 | INFO     | busylight.api.busylight_api:__init__:63 - Set up authentication, if environment variables set.
2022-07-17 14:11:06.365 | INFO     | busylight.api.busylight_api:__init__:71 - Did NOT find user credentials in environment.
2022-07-17 14:11:06.365 | INFO     | busylight.api.busylight_api:__init__:72 - Access authentication disabled.
INFO:     Started server process [8]
INFO:     Waiting for application startup.
2022-07-17 14:11:06.659 | INFO     | busylight.lights.usblight:all_lights:203 - BlinkStick found 0 lights
2022-07-17 14:11:06.670 | DEBUG    | busylight.lights.usblight:update:670 - Embrava Blynclight Standard@1-4:1.0 write_strategy returned 9 sent<PHONE_NUMBER>0080ff22
2022-07-17 14:11:06.671 | INFO     | busylight.lights.usblight:all_lights:203 - Blynclight found 1 lights
2022-07-17 14:11:06.680 | INFO     | busylight.lights.usblight:all_lights:203 - Busylight found 0 lights
2022-07-17 14:11:06.687 | INFO     | busylight.lights.usblight:all_lights:203 - Flag found 0 lights
2022-07-17 14:11:06.697 | INFO     | busylight.lights.usblight:all_lights:203 - Mute found 0 lights
2022-07-17 14:11:06.705 | INFO     | busylight.lights.usblight:all_lights:203 - Orb found 0 lights
2022-07-17 14:11:06.714 | INFO     | busylight.lights.usblight:all_lights:203 - MuteMe found 0 lights
2022-07-17 14:11:06.724 | INFO     | busylight.lights.usblight:all_lights:203 - Status_Indicator found 0 lights
2022-07-17 14:11:06.732 | INFO     | busylight.lights.usblight:all_lights:203 - Blink1 found 0 lights
2022-07-17 14:11:06.733 | INFO     | busylight.lights.usblight:all_lights:195 - USBLight found 1 lights total
2022-07-17 14:11:06.735 | DEBUG    | busylight.lights.usblight:update:670 - Embrava Blynclight Standard@1-4:1.0 write_strategy returned 9 sent<PHONE_NUMBER>0080ff22
INFO:     Application startup complete.
2022-07-17 14:17:38.389 | INFO     | busylight.lights.usblight:all_lights:203 - BlinkStick found 0 lights
2022-07-17 14:17:38.406 | ERROR    | busylight.lights.usblight:acquire:629 - open_path failed with open failed
2022-07-17 14:17:38.408 | ERROR    | busylight.lights.usblight:all_lights:202 - Blynclight LightUnavailable: 2c0d:000c path=b'1-4:1.0'
2022-07-17 14:17:38.410 | INFO     | busylight.lights.usblight:all_lights:203 - Blynclight found 0 lights
2022-07-17 14:17:38.424 | INFO     | busylight.lights.usblight:all_lights:203 - Busylight found 0 lights
2022-07-17 14:17:38.437 | INFO     | busylight.lights.usblight:all_lights:203 - Flag found 0 lights
2022-07-17 14:17:38.451 | INFO     | busylight.lights.usblight:all_lights:203 - Mute found 0 lights
2022-07-17 14:17:38.464 | INFO     | busylight.lights.usblight:all_lights:203 - Orb found 0 lights
2022-07-17 14:17:38.477 | INFO     | busylight.lights.usblight:all_lights:203 - MuteMe found 0 lights
2022-07-17 14:17:38.491 | INFO     | busylight.lights.usblight:all_lights:203 - Status_Indicator found 0 lights
2022-07-17 14:17:38.504 | INFO     | busylight.lights.usblight:all_lights:203 - Blink1 found 0 lights
2022-07-17 14:17:38.505 | INFO     | busylight.lights.usblight:all_lights:195 - USBLight found 0 lights total
INFO:     <IP_ADDRESS>:39376 - "GET /light/0/status HTTP/1.1" 200 OK

What you are seeing here is an artifact of the busylight_api class checking to see if there have been any new lights added to the USB bus(es) since the last endpoint was serviced. The busylight_api instance will call update which then calls USBLight.all_lights() which calls the all_lights class method for all supported lights. The busylight_api instance has a list of lights that it currently knows about and are held open to disallow another process from writing to them while they are under control of busylight_api. So when the update happens and we try to open the light a second time, open_path will fail. This lets us know that it isn't a new light we have to initialize in the update.  In the output above:
2022-07-17 14:11:06.733 | INFO     | busylight.lights.usblight:all_lights:195 - USBLight found 1 lights total
...
2022-07-17 14:17:38.505 | INFO     | busylight.lights.usblight:all_lights:195 - USBLight found 0 lights total

The first line indicates one light was found, the second indicates that no new lights were found.  Which is expected if you haven't attached any new lights in the interval between the two calls.
The light/N/status endpoint is doing the best it can :)
Most USB lights are essentially "write-only" and all but a few return zeros when read. The info section of the status response is the initial information read from the device via hid.enumerate.  The USB standard(s) have a list of possible values that devices "should" implement but are not strictly required. So the empty fields in info are fields the manufacturers decided not to populate.
All the other information in the status response is state maintained in busylight_api (one reason to keep all the lights open exclusively is to keep other processes from modifying the state of the light, causing state information of the light to become incomplete).
One thing I could do here is reduce the default logging level for the webapi which hide some of these distressing messages, but given the output you provided I don't see any evidence of a bug.

Ah, I understand now. Thanks for explaining! This is not a bug - closing the issue.

I appreciate you giving it a work out and calling me on anything that's confusing. I've spent so much time looking at this stuff that it's difficult for me to see how this code looks from a fresh perspective.

I'm glad to help! I've just published a repository called busylight-docker which is a way to run busyserve in a Docker container (I have all my lights connected to a single server on my desk :) )


Revisit development status

Currently we have the development status marked as beta, but maybe we should revisit this.
https://github.com/zarr-developers/numcodecs/blob/e929c96edb4692fe50afb9b1cc0c5186505d00be/setup.py#L324
xref: https://github.com/zarr-developers/numcodecs/pull/382#discussion_r1015923512
cc @joshmoore

Thanks, @jakirkham. With all the recent cleanups, I wonder if it even makes sense to target the magical 1.0... :smile:

Not sure. There were other changes we discussed, which would entail breakage. Given we could get them wrong and need to follow up with additional breaking changes to fix any fallout, would prefer to give us a bit more flexibility and stick to 0.x for now. Maybe after some time we could revisit


New Schema Generation 1/n: Building Type Graph

Part 1 of N, implementing a solution for #3663
This creates a graph representation based on this example behavior.
Includes initial unit tests to prove graph is created correctly.
Cleaned up git log from #3711

Something I didn't anticipate: The Wasm integration tests are failing right now for a few reasons, the biggest of which is that we now no longer generate schemas that are not referenced in particles. Tomorrow, I'll work on patching the tests given the new approach -- assuming this is one we want to pursue.

There's a simple workaround (which may also just be the approach we want to keep): add a dummy particle to schema.arcs that just collects the top-level schema defs:
particle Dummy
  in Foo h1
  in Data h2
  in Empty h3
  in RenderFlags h4
  in ServiceResponse h5
  in SpecialFields h6

Hey @alxrsngrtn, @mykmartin will help you get the entity generation changes landed. I'll remove myself from the PR, hope that's ok, Myk has more context than I do with WASM with understanding C++ requirements, which is my achilles heel.

Status of the PR
After speaking with Piotr, we are going to table this thread of development. This takes a more exploratory approach towards a complete solution, whereas we are really in need of a short-term fix.
I've merged a parallel path of development from Myk into this branch. This can serve as the starting point when we have the capacity to take the polymorphic entity generation approach.

Closing PR. Issue addressed in #3785


Mcmmo error

You forgot to also set the "get" event of "[mcmmo] %skilltype% level of %offlineplayer%" syntax to be compatible with offlineplayers.

protected Integer[] get(Event e)
{
return new Integer[] { Integer.valueOf(ExperienceAPI.getLevel((Player)this.p.getSingle(e), ((SkillType)this.s.getSingle(e)).toString())) };
}

Stacktrace: https://pastebin.com/raw/7AawUbsE
I built the latest sharpsk ( McMMO: Added Offlineplayer support for most syntaxes.) with the latest mcmmo commit with maven.

Thanks, should be fixed with my next commit


FEAT-#3: Add cluster_resources in API

Signed-off-by: Alexey Prutskov<EMAIL_ADDRESS>What do these changes do?
PR adds new API cluster_resources which allows info about workers resources in the form {node_ip: {resource: value}, ..}. For now only resource CPU is supported.

[x] passes flake8 .
[x] passes black .
[x] signed commit with git commit -s
[x] Resolves #3
[x] tests added and passing
[x] module layout described at docs/developer/architecture.rst is up-to-date

The implementation should be checked on the cluster. I'll notify about results.

The PR is successfully tested on aws cluster.

LGTM


Android: Portrait images have wrong orientation (Titanium 9.1.0 + Android 10)

Currently debugging a strange problem with my app and Ti 9.1.0 (nightly build).
Some of my images (taking from the gallery or taking it with the camera) in portrait mode are rotated to landscape.
Device: Pixel 4, Android 10
Ti SDK: 9.1.0 (nightly)
Image should have exif: top right and is in portrait mode.
It is working with 9.0.3.GA. Already built a new glide version (they've updated the exif library) + module but still having the same issue. If I use the normal imageview it has the correct orientation but of course no aspect_fill.
var window = Ti.UI.createWindow({
	title: "Image Test"
});

var AvImageview = require("av.imageview");
var imageView =AvImageview.createImageView({
	width: Ti.UI.FILL,
	height: 200,
	top: 0,
	contentMode: AvImageview.CONTENT_MODE_ASPECT_FILL,
});
window.add(imageView);
var dl = Ti.UI.createButton({
	title: "open image",
	bottom: 10,
});
dl.addEventListener("click", function(e) {
	Ti.Media.openPhotoGallery({
		success: function(e) {
			var w = e.media.width;
			var h = e.media.height;

			var r = h / w;
			w = 1024;
			h = r * w;

			var imageBlob = e.media.imageAsResized(w, h);
			imageView.image = imageBlob;
		}
	});
});

window.add(dl);
window.open();

(allow permissions to gallery manually)

https://github.com/appcelerator/titanium_mobile/pull/11999
That will help to fix it in Titanium.


Merging 1.3.x changes to 2.0.x

Description
Merging 1.3.x to 2.0.x
Overview of Changes

See commit history

Type of Change

[ ] New feature
[X] Merge
[ ] Bug fix
[ ] Refactor/Technical Debt
[ ] Documentation Update
[ ] Test case change
[ ] This change requires a documentation update
[ ] Other

Test Details

See existing test cases

Additional Notes
N/A

You did it @lopezton-anthem!
Thank you for signing the Anthem Opensource Software CLA.

You did it @lopezton-anthem!
Thank you for signing the Anthem Opensource Software CLA.

You did it @lopezton-anthem!
Thank you for signing the Anthem Opensource Software CLA.


MessagePack support?

I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern languages, and there are plenty of the libraries available for the other ones.

What about MessagePack? It has libraries for almost every language out there and is relatively easy to use - plus it'd be a considerably faster interop considering a lot of what might be transferred are buffer contents.

I came to suggest just that.
I might hack up a patch and do some benchmarks to show how much could be gained by using MsgPack.

That'd be awesome!

If we really care about encode/decode performance, MessagePack is better, but not better enough to beat JSON in this project.
Both JSON and MessagePack both are schema-less, both need parsing. though MP is easier/faster than JSON.
I recommend cap-n-proto or Google's FlatBuffer, which is really faster than schema-less encoder/decoder, and fit perfectly for static-typed-language.
JSON -> work with plugins based on dynamic typed languages: JS/Python/Lua
CapnProto -> work with plugins based on static typed languages: Rust/C#/Java

I benchmarked serde_json vs https://github.com/3Hren/msgpack-rust and they are pretty equal in both encode and decode perf.

But since JSON libraries are so popular and get optimized to infinity, it probably won't make much difference.

That's theoretically impossible. Also, you still have to parse JSON. With MsgPack the data is right there. What did you do to benchmark?

I wrote a whole testsuite petting the various rust serialization libraries against each other.
I'll publish a blog post and the code tomorrow, probably.

A few comments. I'm not surprised that MsgPack is not significantly faster than JSON. About the only thing that's really worse is the string quoting, and that can be made pretty fast.
In my day job, I've been working with fidl quite a bit. It's an appealing binary format, optimized for IPC. So far, the xi core is still based on JSON and streams, but it's tempting to make the fidl integration deeper. The only problem with fidl is that it's (no longer) portable to systems other than Fuchsia.
A much more important factor for overall performance is minimizing what actually gets sent over the wire. If you analyze performance right now, when syntax highlighting is on, every span has a style object specifying foreground color and so on. Also, moving the cursor around sends the entire "lines" array. I'll be reworking the update protocol for minimal invalidation, and also doing a more efficient encoding, where styles are sent separately and then referenced by an integer index.

The only problem with fidl is that it's (no longer) portable to systems other than Fuchsia.

That sounds like a pretty serious problem for this project if it's going to be particularly useful outside Google's OS project. 😛

Msgpack is great if you have array and integer heavy data.  I've purposely designed RPC protocols around this constraint so that I could have super fast and compact serialization using msgpack.  I don't know what could be done here though without some pretty heavy redesigning of the protocol.

Just as a reference, here is the test suite: https://github.com/theduke/rust-serialization-benchmarks
Just do git clone and then cargo run --release.
I'd appreciate anyone sharing their results.

On the performance point; CPU isn't the bottleneck, memory is. Being able to access nested objects without parsing the entire message is a huge leap forward. Also, dont forget the most interesting feature: capabilities. Speed performance gains a lot, but it's actually the least interesting part of using those newer protocols (capnp in particular).

Flatbuffer also allows reading in place without parsing first.  And if you do want the msgpack route, CBOR has become a great option lately with it's standards track and clean design.

Reading in place without buffers just sounds like passing structs around with a type enum header, like the good old days of protocol design :) Also a viable option because pointer aliasing just works. That's the theoretically fastest way to pass data around.

I considered binary formats, but the actual improvement in performance would be completely in the noise.

Just realized the original author wrote this. Mindboggling!
Ok! I'll give you a pointer to a 10GB JSON data-object, and another pointer to the same data in a binary format, say CBOR, with schema; you only need a small piece of data somewhere in there. Oh and the computer has very little ram. Run that test in your head and let me know if that looks like noise.

The context was sending small, RPC-style messages, in which context it is much closer to just being in the noise. Later experience than the original made it clear that the trade-offs were worse than originally assumed for various reasons (mostly architectural, but also with parsing in certain environments), but certainly no one was thinking about using it in the context you’re suggesting.

Most people value computing power as much as they value plastic cups.  The false Gods are all the rage nowadays. Ave Caesar!


Home Assistant new Get weather forecast service

Hello,
Thank you for all your work on this. Home Assistant has created a new service in the latest release 2023.9 called weather.get_forecast. Can please update the home assistant integration to reflect this change?
Thank you Again

You might be interested to know that AstroWeather recently updated their integration to support the new service mode.

Since this is a HA specific issue, I'm also going to transfer this over to that repo, but I'll keep you updated there with progress!

FYI, this is still broken and will break the integration completely in a few months.

pirateweather::PirateWeather implements the forecast property or sets self._attr_forecast in a subclass of WeatherEntity, this is deprecated and will be unsupported from Home Assistant 2024.3. Please create a bug report at https://github.com/alexander0042/pirate-weather-ha/issues

Fixed in v1.3! It's listed a pre-release at the moment, but assuming there aren't any showstopping bugs I'll push it public next week!
Since there's already discussion of this in https://github.com/alexander0042/pirate-weather-ha/issues/136, I'm going to close this issue for now. Feel free to reply there about any problems though!

upgraded to 1.3 and it fails to load now.

Ok, well that's not good, but why I pushed this as a pre-release! Anything in the logs here?

Mine is working, but I don't see the forecast entities.

I thought you were looking for testing?  I am not seeing anything in the logs from what I can tell

@markmghali , very much looking for testing, so I appreciate this report!
@mermelmadness , good to know your update worked. The only change to the user side of this if you see both the daily an hourly forecasts for the weather entity on the dashboard, There shouldn't be any changes to the sensors at all

Well, yes, it works, but the old attribute sensors for forecast are gone.  This is expected with the new changes to weather integrations, but I thought that they would populate as individual sensors or entities with their own attributes.  I did add 0,1,2,3,4,5,6,7 to the configuration of the Sensors portion and I see them there with good data.  But missing are the forecast condition and temperatures, even though they are listed.

Alas, they won't populate on their own unless sensors are selected. This is a bit of a controversial decision: https://community.home-assistant.io/t/petition-dont-delete-the-forecast-attribute/609298, but seems set in stone, so such is life.
However, if you add those sensors in, they should show up! Can you try only using the temperature and condition sensors?

Note that for daily sensors, you need to use "Temperature High" and "Temperature Low". Maybe I should document this better in the config? i.e. having "daily monitored conditions" and "hourly monitored conditions"

Note that for daily sensors, you need to use "Temperature High" and "Temperature Low". Maybe I should document this better in the config? i.e. having "daily monitored conditions" and "hourly monitored conditions"

Ahh, yes, I selected those to be safe and they are now appearing, though it's annoying that I have to manually remove the sensors that I disabled (not your fault, just HA being HA).  I think this looks good, though now I have to go through a lot of automations and modify my MQTT scripts:
service: mqtt.publish
data:
  topic: wled/Weather/api
  payload: >-
    {"seg":[{"id":6,"n":"{{state_attr('weather.pirateweather','forecast')[1].temperature}}/{{state_attr('weather.pirateweather','forecast')[1].templow}}"}]}

Ideally I would base this off some other integration that creates sensors and allows them to be configured, but I couldn't find one that works. Also agree that this is going to be a big change, so not thrilled about the amount of work you'll have to go though. I don't know if there's a way around it though, and judging by the comments on that link I don't know if there is any other option other than sensors

Yea, I'd love to find a way to git rid of them automatically, but I couldn't figure it out!

No worries, and I figured out the MQTT command conversion relatively easily.
OLD:
service: mqtt.publish
data:
  topic: wled/Weather/api
  payload: >-
    {"seg":[{"id":6,"n":"{{state_attr('weather.pirateweather','forecast')[0].temperature}}/{{state_attr('weather.pirateweather','forecast')[0].templow}}"}]}

NEW:
service: mqtt.publish
data:
  topic: wled/Weather/api
  payload: >-
    {"seg":[{"id":5,"n":"{{states('sensor.pirateweather_daytime_high_temperature_0d') | round(0) }}/{{states('sensor.pirateweather_overnight_low_temperature_0d') | round(0) }}"}]}

Ahh, one thing missing was in the old forecast attribute it gave the date of the forecasted day.  The new sensors lack that.  I'll have to figure out something else, then, to get the actual date of the forecasted day instead of just 2d or 5d
I used it in this script:
service: mqtt.publish
data:
  topic: wled/Misc/api
  payload: >-
    {"seg":[{"id":0,"n":"{{
    (state_attr('weather.pirateweather','forecast')[2].datetime)[:10] |
    regex_replace('^(\\d{4})-(\\d{2})-(\\d{2})$', '\\2/\\3')}}"}]}

Would it help to have a "time" sensor that provided the datetime for something? So there would be a "time_2d" sensor with a datetime value?

Great. They're easy enough to add in, so I'll push a 3.0.1 that adds them as an option

Thank you.
A note to others making the change over.  The verbiage of the old condition attribute, which is now called summary or daily_summary has changed slightly.  sunny is now Clear, rainy is now Rain, cloudy is now Cloudy, and partlycloudy is now Partly Cloudy

I think icon should give you the previous values- the summary will one day be a text summary, while icon is meant for more machine readable stuff

I think icon should give you the previous values- the summary will one day be a text summary, while icon is meant for more machine readable stuff

Hmm, interesting.  The icon entities seems like it lines up with the MDI versions.  Will have to observe for a while to see which would work best.

Sorry, side question.  Since this YAML configuration is now deprecated, where can we set the scan interval, or does it just default and hard code to 15 minutes?
  - platform: pirateweather
    api_key: NwO2w3mtm64kF6eLQrZL97TUeP641t8g7KoVv0Wt
    scan_interval: '00:02:15'
    monitored_conditions:
      - temperature
      - precip_probability
      - precip_type
      - humidity
      - cloud_cover
      - nearest_storm_distance
      - precip_intensity
      - wind_speed

Good question, another thing I should add to the docs. It imports it in from the yaml, so if it's in there you should be good to go. Otherwise you can set it when you first create the integration from the GUI. I don't believe there's a way to change it after the fact, but I can look into this

Just installed v1.3.1.  Not sure what to make of this time entity value...

The pirateweather custom integration is using deprecated weather forecast
This stops working in version 2024.3.0. Please address before upgrading.
The custom integration pirateweather implements the forecast property or sets self._attr_forecast in a subclass of WeatherEntity.
Please create a bug report at https://github.com/alexander0042/pirate-weather-ha/issues.
Once an updated version of pirateweather is available, install it and restart Home Assistant to fix this issue.

@FARKIr have you been following the thread?

Stable version released. Thank you to everyone who tested the pre-release version.


Migrations not supported on CockroachDB

When running diesel setup from the getting started example with CockroachDB beta-20161201, I get this error:
thread 'main' panicked at 'Error creating timestamp helper functions for Pg: DatabaseError(__Unknown, "syntax error at or near \"OR\"\nCREATE OR REPLACE FUNCTION diesel_set_updated_at() RETURNS trigger AS $$\n       ^\n")', ../src/libcore/result.rs:788

This is because CockroachDB doesn't support stored procedures. We can probably add a skip-timestamp-helpers feature or something and just not generate those functions.


Add mouse events to overlay layers

Similar to how annotation feature elements, hook up overlay elements to mouse events.

@manthey I added a test. Could you take a look at it when you get a chance?


add prepare_model_param

use preset_params and prepare_model_param

[x] resnet
[x] vgg
[x] senet
[x] faster_rcnn_vgg
[x] faster_rcnn_fpn
[x] ssd
[x] yolo
[x] segnet
[x] pspnet
[x] fcis
[x] mask_rcnn_fpn
[x] deeplab

Now we use preset_params in all models

pfnCI, test this please

@knorth55 Can you separate this PR into the following parts?

Add prepare_model_param and use it in models
Improve/Refactor examples/tests

move to #869 #871 and #872


Add Travel Advice Subscriber Lists

Add a migration which provides a mapping from GovDelivery Topic IDs to country slugs.
https://trello.com/c/zdbzUecF/511-create-email-alert-api-subscriber-lists-for-all-travel-advice-topics

Note: the all countries list doesn't currently work as the way we match on document_format doesn't have the right boolean logic.

The fix for the all countries list is going to be hairier than I thought - rescoping this PR to just include the individual countries (which works fine).

:+1: looks good


need npm publish in CI for node sdk (hfc)

Description
Currently, as I understand, we are manually publishing the hfc module (node sdk) to npm. This needs to be an automated function of CI, when the module is actually changed.
Describe How to Reproduce
https://www.npmjs.com/package/hfc currently reflects Keith Smith as publisher. Also, seems like we should align the release identifier, or explicitly note in the Hyperledger Fabric release notes which version matches with which release.
@rameshthoomu @smithbk @ghaskins @rjones-lf - this module also needs to be published under the 'hyperledger' account rather than an account owned by an individual as currently is the case.

@smithbk could you transfer this to the hyperledger org? https://www.npmjs.com/org/hyperledger I will work with you to make this happen, I don't know how to do it myself. chat with me on slack if you would like

@angrbrd is working on similar setup. Issue# https://github.com/hyperledger/fabric/issues/2050

lets all get on same page - we need to have formal hosting under hyperledger but I also want to have the process documented  for npm and dockerhub - thanks

@christo4ferris Chris, is there a single or group of CI machines?  The challenge here is we either:

Store a password in github to use for npm publish/update
Do an "npm adduser" once on all CI machines so the npm publish will just work
Maybe there are other options of which I am not aware.
Thoughts?

@smithbk our CI VMs are instantiated, used once, and discarded. That doesn't mean we can't run npm adduser every time we instantiate a machine. Jenkins has the ability to securely store passwords - this is what we do for pushing to dockerhub, for example

@rjones-lf Are you working on this?  Feel free to slack me if you have any questions.  Thanks.

@smithbk
@rameshthoomu and myself are looking at this. It will be done separately from issue #2050 as it will be implemented as a CI script, which will run upon merge. I will touch base with you today regarding which credentials we need to use for this to publish the package.

@smithbk as I noted in https://github.com/hyperledger/fabric/issues/2066#issuecomment-229459087 there is a process to follow to transfer the code to the new npm org I set up for hyperledger

@smithbk @christo4ferris @rjones-lf
@rameshthoomu and I discussed the way we could make this process work smoothly and this is what we came up with. Please let us hear any comments so we may put this in place.
Thanks!
(1) When a developer makes any node sdk related change, they will add [x] in the PR stating that they have modified sdk code and what the new version number is. (We will modify the PR template to add another checkbox for this.) The developer will update the package.json appropriately to include the new version. For example if the developer updates it from version 0.0.1 to 0.0.2.
(2) Whenever the PR is being reviewed, the reviewer will confirm that the version update is appropriate for the code changes. I.e. if the person is submitting a small change it should be a patch (0.0.2) as opposed to a minor/major change (0.1.0 or 1.0.0). The reviewer/maintainer must confirm this, as otherwise people submitting code may change it inappropriately.
(3) If the reviewer is OK with the new version (and other changes), they merge the change. If the reviewer requires the dev to change the version, they tell them to modify package.json appropriately and update the PR.
(4) The change gets merged. Upon merge the CI script runs all of the automation, including the following commands:
cd /fabric/sdk/node
npm publish
(5) If the version inside package.json has been modified in the incoming code, the npm package will be published to NPM. If not, it will simply return an error and not publish anything: You cannot publish over the previously published version 0.0.2.

Could we automate the CI post merge to handle the version progression? Seems rather involved to have maintainers going back and forth with devs on the correct version, and if there are multiple PRs that will be merged in roughly the same timeframe, how do we manage which gets merged first etc?

Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Open TechnologyIBM Cloud, Open Technologiesemail<EMAIL_ADDRESS>@christo4ferrisblog: https://developer.ibm.com/opentech/author/chrisfer/phone: +1<PHONE_NUMBER>

----- Original message -----From: "Mr. Angry"<EMAIL_ADDRESS>hyperledger/fabric<EMAIL_ADDRESS>Christopher B Ferris/Waltham/IBM@IBMUS, Mention<EMAIL_ADDRESS>Re: [hyperledger/fabric] need npm publish in CI for node sdk (hfc) (#2066)Date: Fri, Jul 8, 2016 6:09 PM
@smithbk @christo4ferris @rjones-lf
@rameshthoomu and I discussed the way we could make this process work smoothly and this is what we came up with. Please let us hear any comments so we may put this in place.
Thanks!
(1) When a developer makes any node sdk related change, they will add [x] in the PR stating that they have modified sdk code and what the new version number is. (We will modify the PR template to add another checkbox for this.) The developer will update the package.json appropriately to include the new version. For example if the developer updates it from version 0.0.1 to 0.0.2.(2) Whenever the PR is being reviewed, the reviewer will confirm that the version update is appropriate for the code changes. I.e. if the person is submitting a small change it should be a patch (0.0.2) as opposed to a minor/major change (0.1.0 or 1.0.0). The reviewer/maintainer must confirm this, as otherwise people submitting code may change it inappropriately.(3) If the reviewer is OK with the new version (and other changes), they merge the change. If the reviewer requires the dev to change the version, they tell them to modify package.json appropriately and update the PR.(4) The change gets merged. Upon merge the CI script runs all of the automation, including the following commands:
cd /fabric/sdk/nodenpm publish
(5) If the version inside package.json has been modified in the incoming code, the npm package will be published to NPM. If not, it will simply return an error and not publish anything: You cannot publish over the previously published version 0.0.2.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

Note that even if no files under fabric/node/sdk are changed, the node SDK needs to be republished with a new version number when the proto files are changed.  But the developer updating the proto files shouldn't have to think this and it should be handled automatically during CI.  I also agree that maintainers shouldn't need to worry about version numbers.
I suggest that we do the following in automation ...
During CI pre-merge:
if any files under fabric/sdk/node OR any proto files were modified
    if version in fabric/sdk/node/package.json was NOT modified
         cd fabric/sdk/node
         npm version patch  // this increments patch where version equals <major>.<minor>.<patch>
    fi

fi
During CI post-merge:
if any files under fabric/sdk/node OR any proto files were modified
cd fabric/sdk/node
npm publish
fi
This means that before merging, if anything changes which requires an npm publish, then we assume that by default it will be a patch update.  The person updating one of the proto files (or something in the the node SDK itself) doesn't have to remember to update the version number in sdk/node/package.json.  It will be automatically handled for them.  The only time that the developer needs to manually update the version number in package.json is when they want to increment the version's major or minor number.
Note that the version update must be done BEFORE merging to make the version in github master match the version published to npm.

PR# 2312 is created to publish npm packages after execute node-sdk-unit-tests but $ghprbActualCommit (to know the list of files changed in PR commits) environment variable is not accessible as we moved to gerrit from github.  I am working on gerrit trigger option to achieve this and will submit patch by today EOD.