Support for Swagger 2.0 Tags

Swagger 2.0 supports tags: https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md
would be great to have some annotation in the DSL for that!

If you go to: http://editor.swagger.io/ -> File menu -> Open example -> select default.yaml .. you'll see tags on the right side.. they're annotated with tags: ["list", "of", "tags"] .. allows you to filter out endpoints..

btw, I'd like to dive into goa and contribute some things, would this feature be approcheable for a newcomer ?

One question I had wrt tags support was whether it needed its own DSL or whether the existing Metadata function could be reused. I like the idea of reusing Metadata because that's really what tags are: they don't affect the actual API behavior. So maybe you can take a look at the Swagger generator and see whether encoding Swagger tags in goa Metadata makes sense? Thanks for volunteering!

oh yeah.. that'd be great.. maybe with some sort of namespacing ? Metadata(swagger:"tags", []string{"one", "two", "three"}) and the swagger generator could pick those up.. ?

or simply, a could of metadata keys could have a special effect.. if it's documented, it could work.. maybe we could even implement the security things this way.. at least temporarily

One thing to consider too is that Swagger tags are not just strings, they can have a description and link to documentation. Where I left it at when I last looked at it was something like:
Metadata("tags", `[{"name": "foo", "description": "bar", "docs": "http://example.com/docs.html"}]`)

but I wasn't too thrilled by having to write that JSON by hand.

Why not have some Metadata objects.. that Metadata() could receive ?
type TagMetadata struct {
    Name string
    Description string
    Docs string
}

couldn't we make Metadata accept interface{} as a second argument ? so generators could poke at the type.. would keep things structured, and optional as need be.
Would look like:
Metadata("tags", TagMetadata{Name: "hello world"})

Maybe the Metadata function calls json.Marshal on the given object? that object is then free to implement its own custom marshaler. Also it would probably have to be a variadic function to allow for multiple tags.

well.. I can imagine certain generators that would want the raw data.. and not necessarily dealing with JSON.. certainly we could make sure TagMetadata fits the JSON Swagger model..
For the Swagger generator, I can see also that if Docs and Description are empty, it could be rendered as a simple list of strings too.. so I'd implement the logic in the generators, with structured data being passed around, so decisions like that can be taken down the pipe.
Having a variadic seems good too.. would build a sort of url.Values underneath ?

OK I was trying to avoid having to break existing use of metadata (e.g. in gorma) but I agree that in the long run being able to pass the raw data is probably better (and the fix pretty easy). +1 on the sort of url.Values (map[string][]interface{}).

we don't have to fail metadata if the json included doesn't parse

PR #229 Added the ability to generate Swagger tags. The syntax is:
Metadata("swagger:tag=SomeTag", "tag description", "tag doc URL", "tag doc description")

where all the parameters but the first are optional.


Possible spec compatible way to allow out of spec tweaks to protocol for approving subscriptions

I'm new to WebSockets and Ratchet. I created an issue yesterday to ask about ways of approving/denying subscriptions rather than just adding them. I closed the ticket once I understood why you didn't pursue this originally.
I found that things didn't work well and that there wasn't enough exposed members to do what I wanted to do using it with a modified version of autobahn.
Rather than creating a pull request, I'll just post a link to the commit in my fork as an example. Long story short, it would be a breaking change in that people would need to create a method and rename another, but it would still work normally with WAMPv1 while allowing for out of spec modifications.
The conversion to stay in spec would be to rename your onSubscribe to onSubscribeApprove, create an onSubscribeRequest that just returns true, and create an onSubscribeDecline that does nothing.
Anyway, I hate to fork things but I don't want to be the "gimme stuff for free" sort of guy either. So, I'm just putting this here in case you might consider it. I saw some comments that you'd tried the same thing and not pursued it since Autobahn was already out.
If you're interested, great, and if not, I completely understand.
So here goes:
https://github.com/BrettTrotter/Ratchet/commit/5f3182324e7b99c13ba429f97330d989532b1769

Thanks for sharing this! A better place to post would be the message boards as I like to keep the GitHub issues curated only leaving un-resolved problems open.
I do believe your code could be made into a component and standalone library that could work with Ratchet instead of forking and altering the project.


User anonymous references when inserting inline links

Hi, thanks for creating this extension!
When using an inline link, you usually want to use
an anonymous reference, not a named one.

With a single trailing underscore, the reference is named and the same
target URI may be referred to again. With two trailing underscores, the
reference and target are both anonymous, and the target cannot be
referred to again. These are "one-off" hyperlinks. For example:

https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#embedded-uris-and-aliases
This avoids unexpected collisions with other explicitly named references.

Thanks. 🙇


module showing "Loading...". config.js has the needed items

Hi there,
I have created an API-account and got an API code, I have my user and my system ID filled in correctly, yet the module doesn't work.
Do I need to connect my Enphase system to that API account to?
If so...how?

Did you ever get this working. Pretty sure I've got everything set right, and I've allowed the api app in my account. Just see "Loading...". I do see that the last changes to this module were 3 years ago, so wondering if they changed something and the module just hasn't been updated with some new hooks.

Hi @wesdonohue did you ever get yours working?  I've got my API key, system ID, User ID and authorized the app.  I don't even get a "Loading..." my mirror just boots up and has a cursor displayed and nothing else.  If I comment out the module in config.js everything boots up normally.

Same here.
Just shows loading...
Gonna try to look at code.


new-command: spo report activityuserdetail

implements #1242

Coverage remained the same at 100.0% when pulling 307970aec9ded250cc51f3d7e8b90243a0156d21 on plamber:report-sharepointactivityuserdetail into f62e1ef8c7df7d30ab2e5898f036c4e999016f2b on pnp:dev.


Add Flake for NixOS

Edit bromeon: copied description from https://github.com/godot-rust/gdnative/issues/1068
Case
So, after spending 4 whole days to make the bindgen and the gdnative work on my NixOs i came with a flake that i want to share.
i got fundamental help of my super NixOs-User  @storopoli.
Flake
#https://github.com/jaoleal/Uni9Jogo/commit/3dcc053b103f4418c6d1365df6e7251edd203c98
Its not perfect and theres some diferences of the official one in the book
Cons

Does not have support for non-nixos nix environment since it does not include NixGL

Pros

Does not have NixGL
Will not break with rust updates(the old one did)

Feel free to help improve it

Relevant book page: https://godot-rust.github.io/gdnative-book/recipes/nix-build-system.html
I'm not sure if the repo is the right place for this, especially now that we have it in two places (book + here).
Could you elaborate more concretely how the existing Flake caused problems or what this improves? You mentioned brief pros/cons, but a bit more details would be nice.

Could you elaborate more concretely how the existing Flake caused problems or what this improves? You mentioned brief pros/cons, but a bit more details would be nice.

Well, if you run a NixOs you can try the old one... iven cargo will have some problems because some out of date hardcoded deps, that is the point of the problem that i ran. The flake will do most of the work.

I'm not sure if the repo is the right place for this, especially now that we have it in two places (book + here).

You don't have a Flake. You have a suggested Nix shell that uses the system nixpkg which is not reproducible.

Ah, right. I was confused by this, which implied an existing Flake 🙂

Flake
Its not perfect and theres some diferences of the official one in the book

EDIT: Sure, the root of the project isnt the best place for it, so i made the PR directly to the book.

Thanks, also for the elaboration! I'll close this then, let's continue there.


Null Pointer Exception in KeyProviderCryptoExtension due to Class Not Found Exception

Description of PR
https://issues.apache.org/jira/browse/HADOOP-19338
A null pointer exception occurs in KeyProviderExtension when trying to close a null CryptoCodec object. If supplied with an invalid class name for hadoop.security.crypto.codec.classes.aes.ctr.nopadding getClassbyName throws a ClassNotFound exception and consequently the CryptoCodec object is not created.
How was this patch tested?
(1) Set hadoop.security.crypto.codec.classes.aes.ctr.nopadding to org.apache.hadoop.crypto.OpensslAesCtrCryptoCodec/
(2) Run test: org.apache.hadoop.crypto.key.TestKeyProviderCryptoExtension#testReencryptEncryptedKeys
Instead of throwing NPE, the test now throws a new IO exception which informs that the CryptoCodec object is null.
For code changes:

[x ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
11m 55s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
44m 14s

trunk passed

+1 :green_heart:
compile
17m 42s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
16m 14s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
checkstyle
1m 18s

trunk passed

+1 :green_heart:
mvnsite
1m 45s

trunk passed

+1 :green_heart:
javadoc
1m 16s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 54s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
2m 39s

trunk passed

+1 :green_heart:
shadedclient
37m 12s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  0s

the patch passed

+1 :green_heart:
compile
16m 43s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
16m 43s

the patch passed

+1 :green_heart:
compile
16m 20s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
javac
16m 20s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m 15s

the patch passed

+1 :green_heart:
mvnsite
1m 42s

the patch passed

+1 :green_heart:
javadoc
1m 13s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 55s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
2m 46s

the patch passed

+1 :green_heart:
shadedclient
36m 52s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
20m 30s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
1m  5s

The patch does not generate ASF License warnings.

236m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7166/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/7166

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux d768da0906fa 5.15.0-122-generic #132-Ubuntu SMP Thu Aug 29 13:45:52 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / aa9126e2bc323340acf8a1edae2fdead589ca2f8

Default Java
Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7166/1/testReport/

Max. process+thread count
1430 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7166/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

I am confused why here will throw NPE, do you mean to mis-config the hadoop.security.crypto.cipher.suite? Thanks.


Fix for invalid RRULES returned by the Google calendar API

Apply a fix for invalid RRULES returned by the Google calendar API
Example invalid rule:

DATE;TZID=Europe/Warsaw:20230818T020000,20230915T020000,20231013T020000,20231110T010000,20231208T010000

Codecov Report

Merging #327 (a05fbed) into main (8b2da81) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #327      +/-   ##
==========================================
+ Coverage   97.03%   97.07%   +0.03%
==========================================
  Files           9        9
  Lines         912      923      +11
==========================================
+ Hits          885      896      +11
  Misses         27       27

Files
Coverage Δ

gcal_sync/model.py
97.57% <100.00%> (+0.07%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Combine std.algorithm.isSorted and ordered to isOrderd{,Strictly}

Hey I was wondering myself the entire time why we have separate methods for isSorted, isStrictlyMonotonic, ordered, strictlyOrdered - especially because the headers are clearly defined to be distinctive: isSorted/isStrictlyMonotonic uses just one argument whereas.ordered, strictlyOrdered uses two or more arguments.

I think that having three different names isSorted, isStrictlyMonotonic, ordered for the same functionality is confusing (even @andralex - the author of ordered got confused himself)
I added a new range trait hasComparableElements (it's set private for the time being) that checks whether we can compare the elements in the range
In contrast to isStrictlySorted isStrictlyOrdered is defined precisely
I used isOrdered instead of ordered to stick with the usual naming scheme of boolean method in Phobos (e.g. isPartitioned in the same package)

As you can see in this PR this is pretty-straightforward.
-> One sorted to rule them rule them all!
This also contains the commit of #4110 as it already got approval and adds alias & deprecation warning for isSorted, isStrictlyMonotonic, ordered, strictlyOrdered.

no one interested in merging those functions?

pinging randomly @schveiguy @burner @jmdavis @9il @quickfur - please have a look.
The idea is that isOrdered (requires >= 2 args) and isSorted (1 arg) do the same thing and this PR combines them into one function.
Even @andralex (who merged isOrdered into Phobos) was confused by the existence of isOrdered and isSorted. For more details see my text above.

Rebased to master as #4110 (isStrictlyMonotonic) is now in ;-)

deprecated("Please use isOrdered")
alias isSorted = isOrdered;

deprecated("Please use isStrictlyOrdered")
alias isStrictlyMonotonic = isStrictlyOrdered;

deprecated("Please use isOrdered instead")
alias ordered = isOrdered;

deprecated("Please use isOrdered instead")
alias orderedStrictly = isStrictlyOrdered;

No. Just no. Sorry. Let's go forth and do great new things instead of finding every so better names for old things. Thanks.


zeal: startup = segfault

Zeal does not work, it segfauls when starting.

/cc maintainer @svenkeidel. BTW, it's good to have maintainer attrname equal to github username, so I can easily find out whom to ping ;-)

@vcunat :+1:

I will take a look at it. Sorry for the dealy

Cannot reproduce.

Which channel do you use?

unstable. It works now. Maybe the latest update fixed this.
Thanks you for your patience!

No problem, it probably was a problem with one of the dependencies of zeal. Thanks for reporting.

Reopening this because zeal segfaults again.
$ nix-shell -p zeal --run zeal
/run/user/1000/nix-shell.fHgdoF/rc: Zeile 1:  4450 Segmentation fault      zeal

On unstable at
$ nixos-version
16.03pre73316.93d8671 (Emu)

Cannot reproduce on a fairly recent master (16.03.git.c3bb681M)

Cannot reproduce on latest unstable as well. Closing again.


Elasticsearch.Net.UnexpectedElasticsearchClientException

While performing load testing using JMeter with 500 user with the ramp up time of 30 seconds, we are getting below exception after some successful request :
Elasticsearch.Net.UnexpectedElasticsearchClientException: The operation was canceled. ---> System.OperationCanceledException: The operation was canceled.
at System.Net.Http.HttpClient.HandleFinishSendAsyncError(Exception e, CancellationTokenSource cts)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)    at Elasticsearch.Net.HttpConnection.Request[TResponse](RequestData requestData)    at Elasticsearch.Net.RequestPipeline.CallElasticsearch[TResponse](RequestData requestData)    at Elasticsearch.Net.Transport1.Request[TResponse](HttpMethod method, String path, PostData data, IRequestParameters requestParameters)
--- End of inner exception stack trace ---
at Elasticsearch.Net.Transport1.Request[TResponse](HttpMethod method, String path, PostData data, IRequestParameters requestParameters)    at Elasticsearch.Net.ElasticLowLevelClient.IndicesExists[TResponse](String index, IndexExistsRequestParameters requestParameters)    at Nest.LowLevelDispatch.IndicesExistsDispatch[TResponse](IRequest1 p)
at Nest.ElasticClient.Nest.IHighLevelToLowLevelDispatcher.Dispatch[TRequest,TQueryString,TResponse](TRequest request, Func3 responseGenerator, Func3 dispatch)
We are using Elasticsearch.Net 6.4.0 and NEST 6.4.0 versions.
Could anyone here help us or provide any suggestion to fix the issue?
Thanks in Advance

Hi
Before we dig in further can you repeat the JMeter run with the latest version:
https://www.nuget.org/packages/Elasticsearch.Net/6.8.3
The 6.8.x version has been tested against all previous Elasticsearch 6.x versions.

We’re experiencing the same exact issue.  Elasticsearch 7.5.1 with a matching driver version running in .NET Core 2.1.  Our test client fine for a while, then starts throwing this exception when we ramp up the traffic.  We have also tried this on our old cluster running 6.4 with a 6.8 driver.  Same behavior (both from .NET Core 2.1 running on Kestrel).  Our clusters are  on-prem behind a firewall but all HTTP ports are open.

A small project that reproduces the issue seen would be extremely helpful in identifying if there is an issue, and what it might be

@Crazy1van @nishantj261989 just to cover all the obvious causes: are you reusing ConnectionSettings as per:
https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/lifetimes.html
Also is this on Linux? or Windows?
@nishantj261989 is this on Asp.NET Core as well?

@russcam I'm trying to reproduce this consistently but so far no luck.  This happens sporadically and usually takes a while (1-2 hours) for the errors to start appearing.  Putting the web service under heavy load doesn't seem to trigger this behavior.
@Mpdreamz
It's running on Windows Server 2016.  The Elastic client is a static instance in a static class (reused by all threads in our web api).  I tried many options including increasing connection timeout and retry count, and retry timeout.  None of them seem to make a difference.
I am not seeing any corresponding error logs on the cluster so it seems the .NET code is where it's failing.  I will try with another version of .NET Core.

@Mpdreamz Yes we are also using ASP.NET Core and its on Windows. This exception is occurring very frequently when we are performing load testing with only 500 users.

Possibly related: https://stackoverflow.com/questions/60284951/net-core-with-elasticsearch-in-docker-blocked-by-connection-limit
Sorry to keep prodding can you share a bit more about the way Kestrel is hosted @nishantj261989 and @Crazy1van ?
Do these timeouts coincide with response times increasing from the server?

Do you have any further info, @Crazy1van / @nishantj261989, that might help in being able to narrow down a root cause?

Yes, sorry for the late reply.  I ended up narrowing it down to a specific root cause.  The web API code I was using was indeed written in .NET Core 2.1, but it was using a .NET Framework 4.7.2 library for all of the Elastic functionality (I forgot about that).  I did some testing and it appears that .NET Framework (at least 4.7.2) has some sort of a serious bug with their HttpClient implementation.  Once I converted the library to .NET Core 2.1, the problem went away.  Our code has been running rock solid for months with very high TPS.
I would suggest that anyone else experiencing this issue should try to switch to .NET Core 2.1 or later.  It is worth noting that this issue may never manifest itself for some users.  We only experienced this during bursts of high traffic.  I hope this helps.

Thanks for reporting back @Crazy1van. Happy to hear that the issue has been addressed by moving to .NET Core 2.1 🙂
These kinds of issues can often be tricky to debug and perform a root cause analysis to identify the underlying issue, to determine if it's something in the client that can be addressed.
I'm going to close this issue. @nishantj261989, if there's a repro that can reliably reproduce the issue, please feel free to add additional information and we can look at reopening this.


Incorrect error message w.r.t. gcc requirement + installing at SLAC

I have installed Corrfunc on the machines at SLAC. The stock gcc was 4.4.7. I was able to switch to an up to date gcc by doing scl enable devtoolset-3 bash (for anyone in the future that tries this install).
More importantly, the error Corrfunc was giving when I was installing was that it thought I was using an unrecognized CPU that didn't have x86 architecture. This was uninformative, and it took some time to realize that it was the compiler that was the issue. Ideally, if gcc is out of date then the error message should reflect that.

Thanks for reporting this. I think this is at least the second time I have heard about the old default compiler at SLAC. The fix could be to add a check for the version (in common.mk) and warn for a really old version but I am not sure how to provide a general solution for the range of compilers in place.
@tmcclintock Do you mind taking a stab at the solution? Happy to work with you...

Sure I'll take a look.

Fyi I haven't forgotten about this. The SLAC machines are down until January 8. I'll be able to diagnose this after that.

@tmcclintock Thanks!

@tmcclintock Did you have a fix for this issue? Otherwise, are you okay if I close this issue (at least for now)

I don't have a fix. Closing now.


Combiner Cloud Function should support node 12

The combiner library has a dependency on node 12 to build; however the cloud function that we deploy the combiner to uses node 10 engine. This is a pain to switch back and forth locally, but also prevents us from deploying automatically from the CI process. Investigate increasing the cloud function engine to node 12.

This has been completed


Reverse Proxy cannot connect to Bar Assistant

Hopefully this is just a config issue on my end but I am hoping you might be able to clarify for me.  So I setup the docker build provided in your documentation and got everything working as required and I was able to login using the server URL [http://myserver.local:8080].  When I setup my reverse proxy and pointed to said address and I go to the site I get:
Bar Assistant server:
http://myserver.local:8000
Status: Not available
However the URL http://myserver.local:8080 works just fine.  I am guessing there is some special configuration that I need to apply to allow access to port 8000 for the bar-assistant server.
Also a couple of notes about your Complete Docker Install.

The default login that is listed doesn't work.  I registered a user and then from the server side promoted that user to admin.
Not sure why but when I specified localhost in the environment variables I got a Not Available message.  When I updated to the server DNS name it started connecting.  I a guessing this is because its not running on my local machine

Looks like you have a typo, your working instance is on port 8080 not 8000.
Related to the notes:

Default login is created with arguments from https://github.com/karlomikus/bar-assistant/blob/master/app/Console/Commands/BarOpen.php#L30, the defaults are<EMAIL_ADDRESS>and password.
You must be able to visit your BA instance from your browser for salt-rim to work, so using localhost as a URL is depended on your setup

I'm successfully using traefik reverse proxy for my instances, so I can maybe help with some config options.

I did the docker-compose install listed here: https://github.com/bar-assistant/docker
After the install it asked me to register a user.  I setup my account and then promoted via the CLI to admin.  There were no other accounts on the server.  Is the docker image suppose to create an<EMAIL_ADDRESS>account by default as mine did not.
As for the reverse proxy issue are you saying that my browser needs to access the bar assistant server as well as the Salt-rim server directly?  Salt-rim listens on 8080 but bar-assistant listens on 8000 which is why I am confused why it wouldn't work through the proxy.  They way I have it configured is that my URL points to a Virtual IP which then points to the backend server [Salt-rim]  However Salt-rim shows an error message when I use the Proxied URL that the real server name isn't accessible.

vs when I go to real server with port 8080.

I think the easiest way is to setup reverse proxy for each service, and see if you can access it from your browser. Then you can setup .env variables accordingly.

See here....
https://github.com/karlomikus/bar-assistant/issues/59
If you want to Reverse Proxy in order to Expose SaltRim externally, Make sure you reverse proxy not only SaltRim but also Meilisearch and BarAssistant.

New docker improvements are now available as a release candidate.
I welcome you to try the new setup, you can find the guide here.
If you are still having problems please open a new issue.


Correction of condition to test presence of a device

as the command AT+DISI? is returning a string like this when a device is detected:
00000000:00000000000000000000000000000000:0000000000:CCXXXCD1A4C:-062
and nothing except OK+DISCE when no device are detected
I think the condition for incrementing devices_found should be == and not !=

maybe it is a particular return of my device, I tested with a beacon simulator and in this case it is returning
OK+DISC:4C000215:F6FB5591F41B4588B394D47D463EF713:00000000BF
which make the condition valid...
maybe the solution is to test against the before last part


"return this" from inherited method not working as expected

I'm writing classes where the methods return "this" to allow for method chaining.
When the method is inherited then "return this" doesn't seem to be working as expected:
class A {
  one() { return this; } // "this" should return the instance of "B" when inherited
}

class B extends A {
  two() {}
}

const b = new B();

b.one(); // ok
b.two(); // ok
b.one().two(); // Cannot call `b.one().two` because property `two` is missing in `A`

On flow/try:
https://flow.org/try/#0MYGwhgzhAECC0G8BQ1oHsB2BTAFASkWgCcsAXAVyI2lIAsBLCAbmgF9oB6D6AIjsZ7QItNORAATYmUrU6WaPQwRSYDMHloAZrwBCggO60s1RUaL1SWcUlZIkoSDB3QsAD0sZxMeMlSl9aPiItrb2mMrQAEbQALzQ2PrQOvhMdpEAdJi4eCxc6ADWSBn+gTmc3GiFGVn46SUp5dAAwqoYaKTQwGAgINAABtXYtSV9UVhd5BDyAA5EaNNYRKQAnv0jCjAAtowQigDmCtR9sH12QA
Any suggestions appreciated, thanks.

+1 this is really a false positive. The only workaround I know is the unfortunate use of // $FlowFixMe

Many thanks @aksuska, will use that for now. I'll leave this open since it appears to be genuine issue.

I don't know why the type isn't inferred correctly there, but explicitly annotating the return type to be "this" works without having to suppress type safety.
Fixed example.

That is working for me as well. @noppa do you happen to know how to alias "this"?

But this approach doesn't work for variable types
I get this is weird but I use polymorphic factory methods that may return the object called on (this) or another object of the same type.

@aksuska I don't quite follow, why do you need to alias it? I don't see it documented anywhere so I'm not sure, but it seems that the this type can only be used as the return type for a method.
Could you show an example where the type is difficult to declare correctly and that is a bit closer to your actual usecase?
When the factory is a static method of class A, this inside that static method will refer to the class that is used to invoke it, i.e. class A itself or some other class that extends it. If you want to return the class constructor itself, you could implement it like this:

class A {
  static factory(): Class<this> { return this; }
}
class B extends A {}

// Tests
const a: Class<A> = A.factory();
const b: Class<B> = B.factory();

flow.org/try.
Here, the return values are the classes itself, not instances of the classes, and type annotation Class<this> denotes that. However, if you are talking about a factory function in a more traditional sense and want to create instances from the class using a static method in the class, you would instead write something like

class A {
  static factory(): this { return new this(); }
}
class B extends A {}

// Tests
const a: A = A.factory();
const b: B = B.factory();

flow.org/try.

The use case for alias is that I prefer to centralize often-used type declarations that serve a specific purpose. This way if the purpose changes, I don't have to search/replace through all my source files to update it. I can simply make the single change and it is reflected across my entree project codebase.


Namespace should be consistent

Due to my neglection, the main package LLamaSharp uses the root namespace LLama but LLamaSharp.semantic-kernel and LLamaSharp.kernel-memory are using LLamaSharp.
We should take a good timepoint to refactor it to keep the namespace consistent, maybe in the next major release (1.0.0).

Which one should we change? Changing the main package to LLamaSharp is more consistent, but is the bigger impact change.

In my opinion we should use the LLama namespace everywhere. Though LLamaSharp is more suitable, it will impact too much.


Resin OS port to C.H.I.P.

Can one of the admins verify this patch?

Hello @hh . First of all sorry for this late review. We had many talkes internally about ubi support in resin given that many components in resin are based on labels. Even so, your solution with the labels created by a new rule looks fine. I will add some other comments to the other bits that I wanted to point out.

@hh pinging incase forgotten

@agherzan Sorry i have been caught with other work recently, i will try get on and respond to the current questions and if there is anything else can help with please reach out.

There also probably needs to be some logic added to the meta-chip Layer to support the 3 iterations of Nand flash for the C.H.I.P

Here are the links for the other requied Layers to support the C.H.I.P
Upstream poky way also missing the ability to do multipile ubifs Vols so ubi_multi_vol-chip.bbclass was added as a bb.class to expand support, i have created a PR to @agherzan meta-chip layer

@dlx I'm wondering why ubi_multi_vol-chip.bbclass was added. Is the multiubi IMAGE_FSTYPE from poky morty not good enough for the job?

@dlx Hey, would it be possible for you to update this PR to apply to the latest version of meta-resin? Unfortunately some parts of the code have changed and this PR can no longer be applied.

@michal-mazurek Here is an Updated PR to for the C.H.I.P to Support Resin v2.0.8

This PR was intended for CHIP support. In the meanwhile that is history so we can drop these PRs. Closing.


Arbitrum Sepolia wstETH and weETH

SIPs

SIP-388: Adding Support for EtherFi weETH to Arbitrum V3 LP https://sips.synthetix.io/sips/sip-388/
SIP-389: Adding Support for Yield Tokens from Aave and Lido to Arbitrum V3 LP https://sips.synthetix.io/sips/sip-389/
SCCP-338: Set Arbitrum Yield-Generating Asset LP & Issuance Variables https://sips.synthetix.io/sccp/sccp-338/
SCCP-345: Reconfigure Arbitrum Collateral Issuance Parameters https://sips.synthetix.io/sccp/sccp-345/

Extra

Renamed to lowercase (what is is possible without redeploys)
Simplify configs with var

ah there we go been ok just few seconds ago


reload vxlan module

once  vxlan port have been changed, force to reload vxlan module

We probably do not need this PR. Need to root cause the issue further on failing server where we saw this problem

retest

Build started sha1 is merged.

There is still more investigation going on system where we hit this issue.

@brianhu2006 what is update on investigation on only system we saw this issue?

@brianhu2006 please close this PR if is no longer applicable.

retest

retest

Closing old, unneeded PRs


Namespaces and modules

Namespaces are containers of variables. There are some predefined namespaces, and by importing modules additional namespaces may be introduced.
Modules are self-contained code units that facilitate code reusing. In particular, shell plugins are modules.
As of 74e3db42c15087faa47f077493fce7e1395706c9, nothing of the namespace or module system has been implemented. This issue only keeps track of the early designing phase. Once a prototypical implementation is pushed, this issue should be closed.

Predefined namespaces
The predefined namespaces are:

local, which contains all local variables
captured, which contains all non-local variables (captured by the closure). All non-locals, whichever level they are actually are, reside in this namespace. Empty for the root scope.
builtin, which contains all builtin variables. This namespace is read-only.
universal, which contains universal variables. This namespace is dynamic; its access cannot be checked statically.

Additional namespaces may be introduced by importing modules, the design of which is not yet done.
Qualification and scoping
Variable access may be namespace-qualified by prepending <namespace>:. For instance, $universal:foo refers to the variable foo in the universal namespace.
Unqualified names are looked up in the predefined namespaces, in the order they were listed. This consists the scoping rule of the language.
Internal resolution of command names
When a string is used as a command, it is first resolved internally by prepending fn- to the name part (= the part after the colon if any, or the whole string otherwise) and treating it as a variable name. For instance, command put is rewritten to $fn-put, while builtin:put gets written to $builtin:fn-put.
For completeness, external resolution is attempted when internal resolution fails, which looks up a binary with the name in $PATH.

Importing a module
Additional namespaces are created by importing an elvish source file, also known as a module in that case. This is done by creating a new Evaluator, evaluating the source file, and extract the local namespace of that evaluator into a new namespace.
The same module imported from different modules do not get created multiple times in the memory.
import
import takes an optional namespace name and the file name. If the namespace name is not given, it is inferred from the filename by taking the stem of the base name. For instance, the following two import call are equivalent:
import ./lorem.elv
import lorem ./lorem.elv

After the import call, the lorem namespace becomes available.
If the filename does not start with /, ./ or ../, it is looked for in ~/.elvish.

The local:, captured: and builtin: namespaces were implemented in d0740a760749195c432d48e33c122a080eb420c4.

env: was implemented in b10cf7ea1de0f6448ac20b3c91d856228bc3886c. The implementation of shared: is tracked in #15 and the namespace part is considered to have been completely implemented.

import conflicts with a command of ImageMagick, so we'd better avoid it. require comes to mind, but I don't like it.

use (inspired by Rust which may in turn be inspired by some other langauge) is a good choice.

The module search algorithm is not yet implemented and is tracked in #44.


Hotkey to show hotkey help

Several times in a long-running gow session, I've found myself forgetting all hotkeys except ^C - even forgetting which ones are available. It would be nice if there was a way to show the hotkey help directly in the session, without having to open a separate terminal for gow -h (or open a browser to the readme).
I figured it would make sense to wire e.g. ^H to that, and started reading code to prepare a PR, but looking at https://github.com/mitranim/gow/blob/e50a405cdbc4cf6b473b802311a2f2355259ccb8/gow_misc.go#L14-L29 I realized I don't know where to find out the "true" names or corresponding integer values for the hotkeys.
I think it'd be a pretty trivial change once that is figured out; basically, add a case here with a new helper method like this one that prints all of the hotkeys and what they do.

When reading the terminal in raw mode, we receive "control" inputs in two ways: via single-byte ASCII control codes, and via ANSI escape sequences. Currently, gow interprets only ASCII control codes, which is why internally it uses a single-byte buffer, for simplicity. For example, ctrl+r in many terminals sends 0x12 which gow interprets as "restart", while ↑ sends 0x1b 0x5b 0x41 (esc [ a). References: ASCII, ANSI escapes. I just checked by logging in gow, and in my terminal, ctrl+h sends 0x7f which is the ASCII delete character. This might vary by terminal. I'm using the MacOS built-in one. If this is consistent between various terminal apps, then there isn't much reason not ot add a special case. Feel free to make a PR. 🙂

Ah, nice! I'll see if I can get the same level of logging working to verify some other terminals (eg the vs code integrated one and Windows Terminal). Any hints on how you set this up are appreciated :)
Once I have that I'll probably put a PR together!

You can log the buffer in Stdio.Run, or the byte in Stdio.OnByte, then check the byte against ASCII. If the char is 0x1b, you're seeing the beginning of an ANSI escape sequence which is continued in subsequent bytes. Changing the buffer to []byte allows to read an entire escape sequence in raw mode, or an entire line in cooked mode. It's not currently implemented this way because gow doesn't need that, and I don't want to deal with the edge case of accidentally splitting an escape sequence or Unicode character across buffer boundaries.

For hacking on gow, I typically run gow -c -v install in one tab (and leave it like this), and manually restart gow in another tab while working on the code. Restore the normal global executable later. Technically you can also run gow under gow (to any depth), but the resulting behavior is hard to predict so you'd spend more time trying to understand what's happening than actually hacking.


Filter out some jobs based on branch name

It would be very nice to filter out some jobs, like the feature branchs. Maybe someone is only interested in the jobs in the develop branch or main. If all repositories have the same branch names (develop, main, issue/, feature/, etc...)

Hi @CarlosMorenoBlazquez, are you suggesting to have branch filter for all repositories (example ** develop** branch for each repository) or only for a specific repository?

Hi @sumanmaity1234, for all repositories, if we want to use this as status dashboard, I am only interested in the status of some branched, if a developer breaks the workflow in one of his features branch I do not care.

Hi @sumanmaity1234  I will try to answer.

So we wait, I think we dont need real time data here, it is more important to get the right data.
Ideally here I would like to show both, if that is a problem then I will only show passed if all passed. Otherwise you show failed and then try to fix it.

I hope it helps.

Hi @CarlosMorenoBlazquez, thanks for clarifying the doubts. There are couple of things are mind
This tool pulls realtime (almost) data and display the data to all team members. So even if some team member doesn't care about the status a specific workflow, other team members might be interest in them. If we do branch filtering (which needs to do in backend side) then all team members will not have the data. Which I think it's not correct.
If we need to fetch data for each branch for each workflows, then we'll reach Github API rate limit issue. Instead of this can we have workflow filtering itself (it can be done in frontend side)?

Closing this issue due to inactivity.


Consider updating Shapeless to milestone version

I'm getting notable improvement of compilation speed in latest milestone 2.4.0-M1, also they've fixed nasty duplication bug in RemoveAll.
@Odomontois WDYT, should we consider merging milestones, if they contain quality of life improvements and bugfixes?

@REDNBLACK is 2.4.0-M1 not backwards compatible? I mean would anything break if you force shapeless version to 2.4.0-M1 in your project (and use current typed-schema)? Currently we already have too many pain points and I this it's quite undesirable to introduce one more.

Odo has shown me in private conversation other possible compilation errors, closing this.


Transactions with 'db.useTransaction' when multiple (same) connections are around.

Hello.
I had a situation in which I had multiple Database s with the same connection parameters around. Rollback had no effect when I used the transaction scope as a method db.useTransaction { ... }, but succeeded whenever I used the function useTransaction, i.e. on the global instance.
I stepped through the code. rollback SQL is called reliably but in the case described above has no effect.
As soon as I reduced the multiple connections to one, both ways of employing the transaction scope worked.
Maybe having multiple same connections is against the concept? Then of course it can also be correct undefined behaviour.
Great work by the way!

How can I reproduce that? Can you show me your code?

I condensed it to this:
// inside DBUtils:
fun ktormConnect(config: JsonObject): Database {
    val host = config.getString("host")
    val port = config.getInteger("port")
    val db = config.getString("db")
    val u = config.getString("user")
    val p = config.getString("pass")
    val dbUrl = "jdbc:mysql://%s:%d/%s".format(host, port, db)
    val driver = "com.mysql.cj.jdbc.Driver"
    val dataBase = Database.connect(dbUrl, driver, u, p)
    return dataBase
}
...
// then:
val dbConfig = config.getJsonObject("db")
val db = DbUtils.ktormConnect(dbConfig)
val db2 = DbUtils.ktormConnect(dbConfig)    // this line makes the difference, if it's active rollback has no effect
...
// somewhere else I use a function copied from transaction tests:
fun testTransaction() {
    class DummyException : Exception()

    try {
        //useTransaction {
        //Database.global.useTransaction {
        db.useTransaction {
            PendingConfirmations.insert {
                it.token to "administration"
                it.type to 23
                it.email to "Hong Kong"
                it.time to TimeUtils.shared.now()
            }
            assert(PendingConfirmations.count() == 2)
            throw DummyException()
        }
    } catch (e: DummyException) {
        assert(PendingConfirmations.count() == 1)
    }
}

I'm still slow formating code here...

Thank you for your feedback. I reproduce this bug with the following code:
fun main() {
    val db = Database.connect("jdbc:mysql://<IP_ADDRESS>:3306/ktorm", driver = "com.mysql.jdbc.Driver", user = "root")
    val db2 = Database.connect("jdbc:mysql://<IP_ADDRESS>:3306/ktorm", driver = "com.mysql.jdbc.Driver", user = "root")

    class DummyException : Exception()

    try {
        db.useTransaction {
            Departments.insert {
                it.name to "test"
                it.location to "New York"
            }

            println(Departments.count())
            throw DummyException()
        }
    } catch (e: DummyException) {
        println(Departments.count())
    }
}

Related issues are: #47, #41, #27

This bug is caused by the design of Database.global, which seems to be a mistake now.
After we call connect function, Ktorm will save the latest created database instance to Database.global automatically, then obtain it when executing a SQL.
Departments.insert, Departments.count or any other functions always use the global instance Database.global to execute their generated SQL. That's why the transaction doesn't work here, we are opening an transaction with db, but executing our SQL commands with db2.
fun main() {
    val db = Database.connect("jdbc:mysql://<IP_ADDRESS>:3306/ktorm", driver = "com.mysql.jdbc.Driver", user = "root")
    val db2 = Database.connect("jdbc:mysql://<IP_ADDRESS>:3306/ktorm", driver = "com.mysql.jdbc.Driver", user = "root")

    class DummyException : Exception()

    try {
        db.useTransaction {                     // open transaction with db
            Departments.insert {                // insert a record with db2 (Database.global)
                it.name to "test"
                it.location to "New York"
            }

            println(Departments.count())        // query the record count with db2 (Database.global)
            throw DummyException()
        }
    } catch (e: DummyException) {
        println(Departments.count())            // query the record count with db2 (Database.global)
    }
}

I noticed the problem of Database.global months ago. I've been working on deprecating it for long and it's just finished now. I will release it as Ktorm version 2.7  after updating the documents.
There is a workaround before 2.7 released. db { } can change the value Database.global in the scope of the closure. You can use it temporally:
fun main() {
    val db = Database.connect("jdbc:mysql://<IP_ADDRESS>:3306/ktorm", driver = "com.mysql.jdbc.Driver", user = "root")
    val db2 = Database.connect("jdbc:mysql://<IP_ADDRESS>:3306/ktorm", driver = "com.mysql.jdbc.Driver", user = "root")

    class DummyException : Exception()

    db {                                        // Database.global will change to db in the scope of the closure
        try {
            db.useTransaction {                 // open transaction with db
                Departments.insert {            // insert a record with db2 (Database.global)
                    it.name to "test"
                    it.location to "New York"
                }

                println(Departments.count())    // query the record count with db2 (Database.global)
                throw DummyException()
            }
        } catch (e: DummyException) {
            println(Departments.count())        // query the record count with db2 (Database.global)
        }
    }
}

Thank you!
For now I changed my connection management, but I'm looking forward to the next release. Cheers!

This issue is fixed in Ktorm 2.7, see https://ktorm.liuwj.me/en/about-deprecating-database-global.html


Connection to Kodi with micro dropouts

When I start the adapter, a connection to Kodi is established, but according to the status symbol of the adapter it seems to be disconnected und reconnected repeatedly. According to the log this happens 2-3 times every second and spams the log with many Kodi connected messages.
I use MrMc on an Apple TV 4K with tvOS 14.4.8

Same Problem with Kodi 17.5 on Windows.
Kodi 18 works instantly, but i need v17 for MadVR

give me debug adapter log.

Here my debug Log
host.NUCiobroker	2021-02-22 00:18:30.807	info	instance system.adapter.kodi.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
kodi.0	2021-02-22 00:18:30.696	debug	(3493) Error GetChannels: PVR is not use?{"response":{"code":-32100,"message":"Failed to execute method."}}
kodi.0	2021-02-22 00:18:30.684	debug	(3493) GetVolume: {"muted":false,"volume":100}
kodi.0	2021-02-22 00:18:30.683	debug	(3493) GetNameVersion: {"System.Platform.ATV2":false,"System.Platform.Android":false,"System.Platform.Darwin":false,"System.Platform.IOS":false,"System.Platform.Linux":false,"System.Platform.Linux.Ra............
kodi.0	2021-02-22 00:18:30.631	debug	(3493) GetPortWebServer: {"value":8080}
kodi.0	2021-02-22 00:18:30.630	info	(3493) KODI connected
kodi.0	2021-02-22 00:18:30.584	debug	(3493) Error: SyntaxError: Failed to handle response: Unexpected token � in JSON at position 0
kodi.0	2021-02-22 00:18:30.565	debug	(3493) KODI connecting to: <IP_ADDRESS>:9090
kodi.0	2021-02-22 00:18:30.565	debug	(3493) TypeError: this.schema.schema.notifications[method] is not a function{GetVideoLibrary}

Update from github and check

Yes i tested version 2.0.7 now.
All works fine 👌


Add oauth and openid missing endpoints

Hi,
This PR add the following elements:

oauth endpoints based on this article and this article.
openid endpoints and meatdata files based on this article.

I was thinking to add a dedicated file but as the common.txt file already contains a bunch of metadata files, I have proposed to add the missing elements into it.
Feel free to reject the PR if you prefer that I create a dedicated dict file for oauth-openid elements.
Thanks in advance 😃

Thank you!

You are welcome 😃
It is always a pleasure to contrbute to this amazing project ❤


Missing arguments after import

Describe the bug
Hello!,
Working on https://github.com/GoogleCloudPlatform/terraformer/pull/939, I discovered that a number of resources have bugs after import.
Expected behavior
The provider should import all attributes, or at least the required attributes.
Current behavior
I encountered these bugs:

[ ] name attribute missing after import: panos_management_profile, panos_ike_crypto_profile, panos_ike_gateway, panos_ipsec_crypto_profile
[x] dynamic routes dist (ex: ospfv3_ext_dist) are set to 0 by default instead of the default value in panos_virtual_router
[ ] all Objects resources (common to the firewalls and Panorama) don’t have a vsys nor a device_group set
[ ] hip_profiles are not set in panos_security_rule_group
[ ] destination|source blocks are not set in the translated_packet in panos_nat_rule_group if the destination|source is not modified

Possible solution
Set these attributes on import.
Steps to reproduce
$ terraform import ... ...
$ terraform state show ...

Context
Development of the Terraformer provider for panos.
Dedicated commit to create workarounds for this issue: https://github.com/GoogleCloudPlatform/terraformer/pull/939/commits/4f5a6a8d9ff3d2ba0027dfa50c4f49d391f1c23b.

Any update on this?


[PR][CLOSED] Add common doxygen pdf path

 Issue by sewon-oh
Tuesday Jun 12, 2018 at 04:31 GMT
Originally opened as https://github.sec.samsung.net/STAR/TAOS-CI/pull/17

book-hard-copy-ci-generate.sh : edit ci_path
book-hard-copy-prj-generate.sh : edit src_path

Signed-off-by: Sewon Oh<EMAIL_ADDRESS>
sewon-oh included the following code: https://github.sec.samsung.net/STAR/TAOS-CI/pull/17/commits

:octocat: cibot: Thank you for posting issue #34. The person in charge will reply soon.


Type Definition file does not import

I want to use Aurelia Orm in a VS 2015 typescript project.
I have installed the library with JSPM.
I then import it:
import {EntityManager} from 'aurelia-orm';
I could not find a way to install with the "Typings" tool like the rest of the Aurelia libs.  So I dropped the .d.ts file into my project.
However, I get a compile time error: Cannot find module 'Aurelia-orm"
The code does in fact run ok, but I can't get rid of the compile errors.
I have looked at the d.ts and it appears different from the other Aurelia type definitions, but I have not been able to resolve so it works.
I have the same issue with aurelia-api

Ok, I should have read the installation docs where it says how to install with jspm.


Failed to activate the atom-ftp-editor package

[Enter steps to reproduce below:]

...
...

Atom Version: 1.0.5
System: Mac OS X 10.9.4
Thrown From: atom-ftp-editor package, v0.5.0
Stack Trace
Failed to activate the atom-ftp-editor package
At Cannot find module 'atom://config/.ftp-settings.json'

Error: Cannot find module 'atom://config/.ftp-settings.json'
  at Module._resolveFilename (module.js:328:15)
  at Function.Module._resolveFilename (/Applications/Atom.app/Contents/Resources/app.asar/src/module-cache.js:383:52)
  at Function.Module._load (module.js:270:25)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at Object.module.exports.AtomFtpEditor.__createFTP (/Users/rodrigo/.atom/packages/atom-ftp-editor/lib/main.js:103:32)
  at module.exports.AtomFtpEditor.__onopen (/Users/rodrigo/.atom/packages/atom-ftp-editor/lib/main.js:82:21)
  at PaneContainer.module.exports.PaneContainer.observePaneItems (/Applications/Atom.app/Contents/Resources/app.asar/src/pane-container.js:126:9)
  at Object.module.exports.AtomFtpEditor.activate (/Users/rodrigo/.atom/packages/atom-ftp-editor/lib/main.js:52:36)
  at Package.module.exports.Package.activateNow (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:243:19)
  at /Applications/Atom.app/Contents/Resources/app.asar/src/package.js:836:25
  at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:82:11)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:222:20)
  at CommandRegistry.handleCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:3:61)
  at CommandRegistry.module.exports.CommandRegistry.dispatch (/Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:156:19)
  at EventEmitter.<anonymous> (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:70:30)
  at emitOne (events.js:77:13)
  at EventEmitter.emit (events.js:166:7)

Commands
     -0:01.3.0 ftp-editor:create (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "themes": [
      "one-dark-ui",
      "one-light-syntax"
    ]
  }
}

Installed Packages
# User
atom-ftp-editor, v0.5.0
emmet, v2.3.12
less-autocompile, v1.0.0

# Dev
No dev packages

please provide steps to reproduce the error.

It just happened to me as well.  I'm on OSX.  Installed, then selected "Create and Initialize Settings".  Nothing seemed to have happened, so I tried it again.  Nothing.  So I restarted Atom, and selected "Create and Initialize Settings" again - thats when I receive the error message.
In case it might help, I had also installed the "Remote-FTP" package at the same time to compare with, but I have not set it up yet.
Thx.

I will release the next version in the next week so I hope that most of the issues will be solved by then.
the create and initialize settings create a setting file in your project folder the project file need to be edited with your ftp settings it's not that comfortable and I think that a lot of people don't understand the flow and that's what cause the issues ...

Happened to me as well.

Me too same error...

same error

Same for me. Just installed and this is what came up.

Same here I am on Windows...
I downloaded the package, and from the menu clicked Packages -> FTP Editor -> Create and Initialize settings ..
I tried restarting atom, no luck ..

Still happening on Windows at least. Tried to Create and Initialize and happened the very first time

Same problem : windows 7 pro. git installed then  Packages -> FTP Editor -> Create and Initialize settings ..

Hope you can fix it! package looked promising !
Best

Same problem : Arch Linux - (Antegros Linux).


Feature/connection manager

Hi this is the first version of the connection-manager i wrote for our project. I hope some of the code is usefull to integrate.

in some cases this does not work, i did find the problem yet


Allow daytona logs to read straight from the log file

Is your feature request related to a problem? Please describe.
If the daytona server is not running or crashes, the user can not get the logs to debug issues.
Describe the solution you'd like
daytona server logs should have an option to read logs straight from the log file and not go through the server.
I suggest daytona server logs --file but open to other options.
Additional context
Related to #755.

Instead of a separate --file flag, we can do a check if the current profile is "default" in which case we always go straight for the file
If there is no profile at all (daytona serve had failed for example) then we can also default straight to the file

/bounty $30

/attempt #772


Outdated TypeScript types

Hello 😃
Looks like it has been two years since the @types/react-medium-image-zoom package has been updated. Is it still compatible with the 4th version of the react-medium-image-zoom library?

I have no interaction with the @types project types, but this project should already be exporting its own TS types, so do you need that other one?

Closing unless I hear back otherwise


[Removal]: I have followed the requirements of the real deployment please remove from the Denylist

Hotspot Name
Massive Basil Crocodile
Hotspot b58 Address
11LDd2KuTMcWQ9TuhMfyHFji4xoXDdUWRmdXUUTbCaodgvztMPT
Discord Handle
No response
Hotspot Manufacturer
Bobcat
Removal Reason
Hello, I purchased 21 Sensecap miners from a secondhand seller thru Alibaba. it's a real deploy. Could you please remove it from denylist? Thank you in advance. Regards
Modifications
Yes
Extra forwarders
No
Extra antennas
No
Additional Information
I have already bought, and actual arrangement，But there's no way to complete the transfer

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


Add ElephantDex connector on Harmony

Add ElephantDex as a default connector on Harmony. Updated the Harmony default token list to latest valid tokens after bridge hack.
Change the default Harmony RPC to official harmony url, this allows users to make JSON requests for free with no limit.

hi @elephantproject please be informed that new connectors PR should be headed to the development branch
https://hummingbot.org/developers/contributions/
https://hummingbot.org/developers/contributions/#checklist

What type of request is this considered? A pull request, or new connector proposal?

What type of request is this considered? A pull request, or new connector proposal?

New Connector Proposal


RFC: Nested Cargo packages

Rendered
This is my first Rust RFC. The idea was previously discussed on IRLO (Private nested Cargo packages), and the feedback was generally positive except for confusion about exactly what was being changed, which I believe I have now precisely defined in this RFC draft.

Thanks @kpreid for taking the time to write this up!

Progress on the RFC has been stalled mainly because I have been pondering how to specify the behavior given the premise that inclusion should be based on the presence of dependencies, not just directory nesting (particularly to permit nested “utility” packages which, in the workspace they are developed, are not directory children of the published package, because they are shared between multiple published packages).
I'm currently thinking that:

Each dependencies entry must explicitly request nesting of the named package
If the nested package is within the parent's directory, keep it there. If not, put it in a designated location, perhaps ./.cargo-package/packages/ (the ./.cargo-package/ parent directory being reserved for future extensions in case something like this comes up again).
Sub-packages declaring package.publish = "nested" is still required, to prevent mistakes. But there might be e.g. a flag to cargo publish to override that requirement.
Sketch out some means by which "public binary packages" could be achieved, to make sure that we are not making it difficult to add later. Since such packages will often depend on the parent package, not vice versa, they will need explicit manifest information pointing at them, unlike the current version.

Perhaps something like package.include-packages = ["..."], and if you specify it then it has to be complete (i.e. it is an error if a dependency entry asks for nesting but include-packages does not mention that package.

I think that covers most of the necessary ground, but I still need to write the corresponding RFC text.

Huh, just found #2224.  @kpreid I'd recommend going through that old RFC discussion to see what is relevant or not.

This would dramatically improve the current state of publishing and managing proc macro crates, and just would be a huge QOL improvement for large-workspace projects, of which there are many.

Any idea how this feature would impact downstream consumers of Rust crates, like Linux distributions that build packages for them (i.e. Fedora Linux and Debian)?
For example, the fact that no crates published on crates.io can have any path type dependencies is currently a "hard assumption" in our tooling for building packages for crates in Fedora, and introducing them would very likely break our tools and processes in at least some "interesting" ways - like when doing dynamic dependency resolution for a package build, path-type dependencies are not supported at all for Rust crates, since they (currently) don't exist in crates published on crates.io. (Path-type dependencies are supported when building a cargo workspace, but those don't come from crates.io and are handled differently).

Any idea how this feature would impact downstream consumers of Rust crates, like Linux distributions that build packages for them (i.e. Fedora Linux and Debian)?

Without knowing the intricacies of downstream users, its hard to predict.
The one case that might be weird is if there are anti-vendoring rules.   One use case for nested packages is allowing one user-visible package to be made up of multiple compilation units, so you should consider the code as if it was under src/.  However, depending on how general we make this, it might allow some degree of vendoring of code from outside of the project.

For example, the fact that no crates published on crates.io can have any path type dependencies is currently a "hard assumption" in our tooling for building packages for crates in Fedora, and introducing them would very likely break our tools and processes in at least some "interesting" ways - like when doing dynamic dependency resolution for a package build, path-type dependencies are not supported at all for Rust crates, since they (currently) don't exist in crates published on crates.io. (Path-type dependencies are supported when building a cargo workspace, but those don't come from crates.io and are handled differently).

This sounds like its more of a "tools need updating when nightly implementation is available" rather than "this affects the design or feasibility".  Is that right?

Any idea how this feature would impact downstream consumers of Rust crates, like Linux distributions that build packages for them (i.e. Fedora Linux and Debian)?

Without knowing the intricacies of downstream users, its hard to predict.
The one case that might be weird is if there are anti-vendoring rules. One use case for nested packages is allowing one user-visible package to be made up of multiple compilation units, so you should consider the code as if it was under src/. However, depending on how general we make this, it might allow some degree of vendoring of code from outside of the project.

Yeah, that's one use case that we'd not want :) We have strong rules against vendoring sources, and if this "nested crates" approach is used to vendor other third-party crates (for no good reason, like them being an incompatible fork), that's something we'd want to avoid ...

For example, the fact that no crates published on crates.io can have any path type dependencies is currently a "hard assumption" in our tooling for building packages for crates in Fedora, and introducing them would very likely break our tools and processes in at least some "interesting" ways - like when doing dynamic dependency resolution for a package build, path-type dependencies are not supported at all for Rust crates, since they (currently) don't exist in crates published on crates.io. (Path-type dependencies are supported when building a cargo workspace, but those don't come from crates.io and are handled differently).

This sounds like its more of a "tools need updating when nightly implementation is available" rather than "this affects the design or feasibility". Is that right?

Yup - it would be great to have the tooling support in place when this feature hits the "stable" train. Otherwise any crates that start to use this feature would be impossible to update until the tooling support is in place (similar to what happened when the dep:foo and foo?/bar syntax in feature dependencies was introduced ...).

Yeah, that's one use case that we'd not want :) We have strong rules against vendoring sources, and if this "nested crates" approach is used to vendor other third-party crates (for no good reason, like them being an incompatible fork), that's something we'd want to avoid ...

I assume there isn't a reason we need to be taking on this distribution policy (this isn't a rule we've agreed to, we already support other forms of vendoring, and users can always copy/paste code) but that this is more of a note that you'll be needing to patch these packages?

Yup - it would be great to have the tooling support in place when this feature hits the "stable" train. Otherwise any crates that start to use this feature would be impossible to update until the tooling support is in place (similar to what happened when the dep:foo and foo?/bar syntax in feature dependencies was introduced ...).

If you watch the tracking issue, when created, and the stabilization FCP ends with a disposition to merge, that gives you 6-12 weeks warning before people will start using it widely.  Even then, people are unlikely to use it and release on Day 1.
Is that sufficient?

Yeah, that's one use case that we'd not want :) We have strong rules against vendoring sources, and if this "nested crates" approach is used to vendor other third-party crates (for no good reason, like them being an incompatible fork), that's something we'd want to avoid ...

I assume there isn't a reason we need to be taking on this distribution policy (this isn't a rule we've agreed to, we already support other forms of vendoring, and users can always copy/paste code) but that this is more of a note that you'll be needing to patch these packages?

I'll need to look into what the actual implementation looks like. If the "private" / "inner" / "nested" crates are just an implementation detail, and they are not exposed to other crates in any way, I don't think that would even count as them being vendored / bundled, since they are effectively "one project".

Yup - it would be great to have the tooling support in place when this feature hits the "stable" train. Otherwise any crates that start to use this feature would be impossible to update until the tooling support is in place (similar to what happened when the dep:foo and foo?/bar syntax in feature dependencies was introduced ...).

If you watch the tracking issue, when created, and the stabilization FCP ends with a disposition to merge, that gives you 6-12 weeks warning before people will start using it widely. Even then, people are unlikely to use it and release on Day 1.
Is that sufficient?

Yes. I've subscribed to all relevant tickets I could find, and that timeframe should give us enough time to make necessary tooling changes (if any).

I'll need to look into what the actual implementation looks like. If the "private" / "inner" / "nested" crates are just an implementation detail, and they are not exposed to other crates in any way

Yes, that's the idea. From the outside view of the package, this should be no different from the fact that a package may compile multiple crates within itself (build script, library dep of binary); it's just generally recursive instead of restricted to specific cases.
(P.S. In general: Sorry I haven't gotten around to updating the RFC for months. I got a little writer's-block on it because of the dismaying prospect of ripping out my "elegant" file-inclusion-based system in favor of something needing more configuration and implementation rules, but I do intend to do that.)

I have pushed major updates to the RFC text.

Nested packages (packages to be published in another package) are now allowed to not be sub-packages (packages which happen to be located inside another package directory). This solves some problems for workspace root packages and allows the possibility of nested packages being duplicated into more than one published package (making a Rust form of “header-only library”, in a sense).
Prior art has been added.
More drawbacks and considerations have been discussed.

I have not yet re-written the “Reference-level explanation” as requested.

I have now rewritten “Reference-level explanation” and reorganized the discussion of alternatives, which I believe completes what I can currently do in response to reviews given so far. Two unresolved review conversations currently exist:

Should nesting be called vendoring?
How much boilerplate are we avoiding?

food for thought: if every crate that has a proc-macro sub crate were to adopt this, that would be n * number of dependents less crates that would need to sit collectively in people's dependencies, which might actually be a non-zero percentage of all crates.io traffic

One drawback that I think would be good to include is the risk around having publicly exposed shared types be incompatible if a dependency is built multiple times.
For example: If I have three packages, "a", "b", and "shared". There is a dependency from a→shared and b→shared, and I publish a and b with shared being nested in both, and a and b expose types from shared, then they cannot be used together. That might not be evident even after publishing, since publishing won't validate that a and b work together. Also, the error message from rustc could be fairly difficult to understand.

We discussed this further in today's cargo team meeting.  The above comments opened represent some of the discussion.
Several areas of concern were focused on:
The original appeal of this solution is that is relatively trivial in thought as path dependencies exist.  The problem is when getting into the details, particularly dependency resolution / the Index.  On top of that, crates.io would likely want to duplicate the Index Summary generation from the .crate file because they want to work with one source of truth, rather than multiple (and its unclear if we can flatten in just Cargo.toml).
This also adds more design choices to the user, making it harder for them to navigate the choice of what tools to use which would include

workspaces
packages
build-targets / crates within a package
open namespaces
public / private packages
nested packages

While this helps to streamline people's workflows by reducing publishing overhead, there isn't any inherent blockers from people solving this today.  The closest is likely in communicating semver guarantees and there is interest in something like pub(namespace) as a way solving the problem.  For the friction in publishing these packages, we should likely work to improve that larger problem. In several workflows discussed, it seemed likely that a workspace would have more than one non-nested package, meaning workspace workflow improvements are still necessary.
All of that said, the unease wasn't enough to block this proposal at this stage but we would be open to this being explored further to see how much these concerns are addressed or validated when this is put into practice.
As for next steps, we didn't fully resolve that.  The RFC affects two teams with crates.io mostly being involved for the Index side of things and would generally be implemented after a go/no-go from the above exploration.  We didn't get to the point of discussing whether we'd want to push this RFC forward, experiment with it, and possibly reject it after approval if the concerns were shown to be blocking, or if we'd want to authorize an experiment to be done as part of the writing of this RFC, much like cargo-script.
The big risk would be to where you put your time as this would likely be a big experiment with enough uncertainty around it that the odds of it being stabilized are iffy.

FWIW, I currently believe it makes sense to wait for the accepted RFC 3243 packages as namespaces (tracking issue) to be implemented before pursuing this RFC any further; they cover some of the same ground (more coherent organization of a user-facing library broken up into many crates) and would likely have some interactions to address.


Custom multiple select field with REST API data overrides default multiple select field

Version information

Laravel: v5.7.*
Voyager: v1.1.12
PHP:  7.2.20
Database: 10.1.43-MariaDB

Description:
This will need some side info in order to explain my problem in detail, so please bare with me :)
I want to create a custom multiple select field with data coming from REST API. SO:
First: I created My REST API consumer and call it like this: RestAPIConsumer::getData()
This gives me a JSON array of data.
Second I want each of the rows from the JSON data to be an option in a multiple select field, so I create a "custom field" like this:
class SelectMultipeFromAPIRepository extends AbstractHandler
{
    protected $codename = "Select Multiple from API";

    public function createContent($row, $dataType, $dataTypeContent, $options)
    {
        $gamesSelectOptions = RestAPIConsumer::getData()

        return view("formfields.select_multiple_api", [
            "row" => $row,
            "options" => $gamesSelectOptions,
            "dataType" => $dataType,
            "dataTypeContent" => $dataTypeContent
        ]);
    }

}

So far all is good - I register it in the service provider like so:
    public function register() {
           Voyager::addFormField(SelectMultipeFromAPIRepository::class);
    }

And then I add the view:
@php
$dataTypeContent->{$row->field} = json_decode($dataTypeContent->{$row->field})
@endphp
<select class="form-control select2" name="{{ $row->field }}[]" multiple>
    @if(isset($options->options))
        @foreach($options->options as $key => $label)
                <?php $selected = ''; ?>
            @if(is_array($dataTypeContent->{$row->field}) && in_array($key, $dataTypeContent->{$row->field}))
                <?php $selected = 'selected="selected"'; ?>
            @elseif(!is_null(old($row->field)) && in_array($key, old($row->field)))
                <?php $selected = 'selected="selected"'; ?>
            @endif
            <option value="{{ $key }}" {!! $selected !!}>
                {{ $label }}
            </option>
        @endforeach
    @endif
</select>

I can see the view in the BREAD editor, but when I submit data for that model I get an SQL error for array to string conversion:

Illuminate \ Database \ QueryException
Array to string conversion (SQL: insert into buletines (title, status, type, certifications, change_notes, other, games, multigames, games_meta, multigames_meta, updated_at, created_at) values (, draft, online, , , , online, , , , 2019-11-27 07:18:46, 2019-11-27 07:18:46))

So I decided to debug the flow and saw that the default multiple selection field is handled in the voyager controller based on $codename like so:

 /********** SELECT MULTIPLE TYPE **********/
            case 'select_multiple':
                return (new SelectMultiple($request, $slug, $row, $options))->handle();

But My custom multiple selection field always enters the default:
          /********** ALL OTHER TEXT TYPE **********/
            default:
                return (new Text($request, $slug, $row, $options))->handle();

Then I checked the default handler for the default multiple select field and I saw that it has a $name property which of course was missing from the documentation, but I decided to add it to my custom field never the less, so I changed my field to:
class SelectMultipeFromAPIRepository extends AbstractHandler
{
    protected $codename = 'select_multiple';
    protected $name = 'Select Multiple from API';

Perfect - now my field is shown in the BREAD editor and IT IS WORKING!!!!!
But I can't see the default multiple select field any more, and I can't use it :(
So my issue is that the process for adding a custom multiple select field either doesn't handle this type of field properly in the switch - case handler, or it completely overrides the default multiple select field and makes it unusable.
Please advise how I can bypass this problem and have both normal - default select multiple field, and a custom REST API multiple select field.

When you create a custom formfiled you can have your custom template and manage data passed to it, unfortunately managing data sent was not included as functionality but is treated as text as you saw.
In your case you can cleanly override getContentBasedOnType to add your option and encode your data before is saved, something like:
public function getContentBasedOnType(Request $request, $slug, $row, $options = null)
{
    if (($row->type == 'your_custom_codename') {
        return (new YourCustomSelect($request, $slug, $row, $options))->handle();
    }

    return parent::getContentBasedOnType($request, $slug, $row, $options)
}

Personally I'm not liking where you put your API call, I would have probably used the normal select_multiple and inject the data in VoyagerBaseController edit and create methods.
Something like:
public function edit(Request $request, $id)
{
    $view = parent::edit($request, $id);

    $dataTypeContent = $view['dataTypeContent'];
    //Call API, put  your data in $dataTypeContent and put it back in $view

    return $view;
}

Maybe there are better ways, this is my two cents.

Also are you sure you need to call RestAPIConsumer::getData() everytime?
Consider saving it in db, you won't need a custom multiselect anymore and your data is cached for how long you choose.

When you create a custom formfiled you can have your custom template and manage data passed to it, unfortunately managing data sent was not included as functionality but is treated as text as you saw.
In your case you can cleanly override getContentBasedOnType to add your option and encode your data before is saved, something like:
public function getContentBasedOnType(Request $request, $slug, $row, $options = null)
{
    if (($row->type == 'your_custom_codename') {
        return (new YourCustomSelect($request, $slug, $row, $options))->handle();
    }

    return parent::getContentBasedOnType($request, $slug, $row, $options)
}

Personally I'm not liking where you put your API call, I would have probably used the normal select_multiple and inject the data in VoyagerBaseController edit and create methods.
Something like:
public function edit(Request $request, $id)
{
    $view = parent::edit($request, $id);

    $dataTypeContent = $view['dataTypeContent'];
    //Call API, put  your data in $dataTypeContent and put it back in $view

    return $view;
}

Maybe there are better ways, this is my two cents.

Initially this was my exact wish. I like the idea of overriding getContentBasedOnType but where and how. I don't want to put any custom code inside the tcg vendor folder. Maybe I didn't fully understand the concept behind this override and how to use it. Can you give me a bit more context to it.
As for the non cahe-able Rest API calls- that is a story for another day with a lot of back-ground. Just assume I have to consume an API every time and there is a very good chance, that the data could be different every time

The only way you should change vendor is using a fork, override controller as per documentation:
https://voyager-docs.devdojo.com/customization/overriding-files

Thanks for the Help!
I have overriden the getContentBasedOnType function in my Resource controller which extends the voyager base controller, and the rest is as per the documentation for the custom fields!.
We can close this


Add robot framework tests to actions

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@b3e884e). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 7ca05f5 differs from pull request most recent head da67019. Consider uploading reports for the commit da67019 to get more accurate results

@@           Coverage Diff           @@
##             main      #19   +/-   ##
=======================================
  Coverage        ?   67.88%
=======================================
  Files           ?       10
  Lines           ?      274
  Branches        ?       49
=======================================
  Hits            ?      186
  Misses          ?       84
  Partials        ?        4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b3e884e...da67019. Read the comment docs.


I41 bootstrap

Closes #41.
Using bootstrap 4 the app is now also mobile pleasant to use (except the temporary plotly figures are not yet super nice). I would suggest that we tackle that when we implement the dash apps properly.

@martinjrobins
Hi Martin everything seems to work when I check the app manually, however the test of the password reset workflow weirdly fails
Run python pkpdapp/manage.py test pkpdapp
Creating test database for alias 'default'...
......WARNING:django.request:Not Found: /pkpdapp-team/pkpdapp)
F..............
System check identified no issues (0 silenced).
======================================================================
FAIL: test_password_reset_workflow (pkpdapp.tests.test_views.TestRegistrationViews)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/pkpdapp/pkpdapp/pkpdapp/pkpdapp/tests/test_views.py", line 153, in test_password_reset_workflow
    self.assertEquals(response.status_code, 200)
AssertionError: 404 != 200

I don't think I've changed anything with the log in workflow and it seems to me that this should be independent of the html layout anyway. Would you know what is going wrong?

oh, and I fixed that bug as well with the test

Thank you so much for reviewing @martinjrobins !

yay, automatic deployment went off without a hitch :)


backport: fix: joining multiple dns server lists (#2506)

Reason for Change:

Backports #2506 to fix #2353 .
Issue Fixed:

Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] relevant PR labels added

Notes:

Waiting on manual testing to complete before merging

Waiting on manual testing to complete before merging

status?

Testing has been blocked for a number of reasons. @QxBytes is leading the effort.


Feat/devengage 1630 add cobrowse to webdeployment config

Since our project went live, there's a new option in the webdeployment config called cobrowse.
I added it so it can be created if needed - we'll use it in provisioning in our e2e tests.

@MateuszKikmunter
I created a branch on our main repo (also called feat/DEVENGAGE-1630-add-cobrowse-to-webdeployment-config) , could you please edit the PR to merge into this branch instead of main? This way we can run our pipeline tests against the changes before merging into main, just to be sure everything's good to go.
Thanks

Hey @charliecon , I made requested changed and swtiched base branch to feat/DEVENGAGE-1630-add-cobrowse-to-webdeployment-config, please take a look. :)


Accept Gift:Text change.

Top should be: Accept Gift Sats
Some space after “You have received a gift from…”
The instruction message should be (instead of “You can choose ….. till fees!)):
“Add the data to an account or keep them to send to someone else”

Top should be: Accept Gift Sats
First line “You have received bitcoin gift from…”
Some space after that
The instruction message should be (instead of “You can choose ….. till fees!)):
“Add bitcoin to an account or keep them to send to someone else”

The buttons should be Accept and Deny

Verified this issue on live app v2.0.65(393)


ad yellow bar appears for a split second then player controls (skip,fwd,settings,etc...) becomes unavailable

Script version
What version is the script on eg 2.9 , 3.1 ect
Describe the bug
A clear and concise description of what the bug is.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots or a video to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

they will show up again at the end of video, but cannot click anything else inside the player (other videos or the player controls)

Same issue randomly appears here. Nearly every second or third video. Navigating through video is only possible with left/right arrow keys and using space key to start/stop. Have to reload the video.

This was fixed in the latest version.


Upload file like text,doc,csv, images etc for each row

Hi ,
I want to option for file upload for each row.
For example I have tasks list row by row and what I want is that I want to add a doc file for the each task that will contain the instruction related to that task.
Please let me know the way how can I upload file in the Jexcel table cell.
Thanks

Can you send an email to<EMAIL_ADDRESS>Thanks.

I send the email please check
On Thu, Aug 8, 2019 at 7:52 PM Paul Hodel<EMAIL_ADDRESS>wrote:

Closed #526 https://github.com/paulhodel/jexcel/issues/526.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/paulhodel/jexcel/issues/526?email_source=notifications&email_token=AA5465ZR6VLXWPVA45U6ZALQDQTZLA5CNFSM4IKHF2KKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOS6NVNXI#event-2543539933,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA54657AKB4DCGKZZ4P5CM3QDQTZLANCNFSM4IKHF2KA
.

@paulhodel If you are not too bussy, maybe you can check  your email. I sent email to request this feature. Thanks

@Rajinderimpinge Excuse me, Could you got solution from this problem?


Changed url for Gradient Designer

I updated the Gradient Designer to version 2, which also has all the colors from Tailwind 2.
A minor change has been done to the name. I removed "Tailwind" but it's still a gradient generator for Tailwind.

Is there any difference between these two projects outside of name and url change? Is the old one focusing on Tailwind v1, and new one Tailwind v2?
If so maybe we should have them both in the list as v1 is still being used by many people. What are your thoughts @innocenzi?

Took a look, and it doesn't seem like there are changes between the two. I'd say we only keep the new version, unless I missed stuff that is Tailwind v1-specific in the first version, in which case I'd agree we should keep them both in the list for now.

@jenstornell can you clarify?

@innocenzi @joshmanders
Yes, you have a point. Tailwind 1 users may still like the old version of Gradient Designer better.
I've put it back now and it's available here:
https://gradient-designer.csspost.com/v1.0/

LGTM 👍


Add BloodHound.app v1.1

If there’s a checkbox you can’t complete for any reason, that's okay, just explain in detail why you weren’t able to do so.
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked that the cask was not already refused in closed issues.

Please fill the template.

You still need to fill the template.

Sorry I am not sure what you mean when you say fill the template?

Look at your first post.

I see now. Thanks


chore(deps): update to latest version of opentelemetry

Update to latest version of the opentelemetry crate.
This is going to fix https://github.com/kubewarden/policy-server/pull/465 and https://github.com/kubewarden/policy-server/pull/439

Moving to blocked. I looked into the upgrade and I discovered the current main branch of opentelemetry has already a different API.
I propose to look back into this issue as soon as the next version of the opentelemetry crates are released.
Apparently there's already an issue open about tagging a new releases that includes these changes

update the controller dependency: See https://github.com/kubewarden/kubewarden-controller/pull/458


ISPN-5213 ISPN-5131 Created CacheStoreFactory

Hey!
This is a preview of a first part of Deployable Cache Store implementation:

https://issues.jboss.org/browse/ISPN-5131
https://issues.jboss.org/browse/ISPN-5213

Highlights:

Refactoring in PersistenceManagerImpl - now it uses CacheStoreFactoryRegistry
CacheStoreFactoryRegistry added to DI
Logic of converting StoreConfiguration to an instance moved to LocalClassLoaderCacheStoreFactory

Full implementation is here: https://github.com/infinispan/infinispan/pull/3263


[WIP] Possible Capability addition to info message

A controller and/or controller UI might want to only attempt operations and features which are supported by EVE-OS.
As we add new fields/messages to the EdgeDevConfig we need a way for the
controller to know which additions the device is implementing. This adds
an explicit ApiCapability field to specify the most recent capability
the device implements in the EdgeDevConfig API.

Report the shutdown capability in the info message

When will EVE send this capability data (either feature wise or version indication) to controller? For ex: In the case of upgrade, will EVE wait till the upgrade process to succeed?

No it will send it as soon as it is running the new version. Should it fall back it will send based on the EVE release which is running then.
Basically this isn't trying to predict the future capabilities of what might be running but merely what new parts of the EdgeDevConfig EVE-OS will parse and handle.

Is this capability data sent periodically or will be a one time action after boot or upgrade?

Sent in every device info message.

Alternatively, can a monotonically incrementing index be embedded into EVE (incremented with every minor EVE release and sent as part of info/metrics) which can be used to lookup for a capability matrix in zedcloud (static capability table added for every minor release in zedcloud). This approach puts some additional load on the release process, but UI apart from enabling/disabling feature can also show the capability matrix of a given device. And EVE/zedcloud do not have to track the capability per feature, instead happens per release.

The problem with this is that it assumes a simple mapping between EVE version strings and EVE API versions, which begs the question whether we'd add the 0.0.0-* EVE version strings to that mapping; in fact we would have to in order to run regression tests on EVE PRs. That seems very painful.
But also, if down the road someone else (some hardware OEM, whoever) issues their own EVE-OS releases we would also have to teach the controller about the mapping from their EVE version strings to the API capabilities.
Doing this explicitly avoids all of those issues.

Yetus(buflint) suggest renaming of proto enum, probably it is reasonable.
Also I am not sure that we should add unsupported fields there (we can add them as comments now) because of no information about the order of their implementation/testing/done cycle. And we are not sure now that they will have order you defined. I think we should add fields to enum during implementation of capability (in the same PR) or a bit later (in release after testing). Probably it would be nice to define this statement somewhere in docs.

Addressed the comments from @giggsoff and @milan-zededa. Don't know about adding API_CAPABILITY_WWAN_GPS

@eriknordmark I think the unit test failure was recently fixed by @giggsoff , no?
commit dee0c391e23f40e08b7e7eacf2e532c03086c846 (HEAD -> master, origin/master, origin/HEAD)
Author: Petr Fedchenkov<EMAIL_ADDRESS>Date:   Mon Jun 6 13:06:42 2022 +0300

    WorkerPool races fixes

    "go test -race" indicates several potential races inside workerpool_test
    . Testing CI returns error as well "panic: close of closed channel" in
    Done function. Seems we should add locking around workers and make
    atomic numChan edits.

    Signed-off-by: Petr Fedchenkov<EMAIL_ADDRESS>

@eriknordmark I think the unit test failure was recently fixed by @giggsoff , no?
commit dee0c391e23f40e08b7e7eacf2e532c03086c846 (HEAD -> master, origin/master, origin/HEAD)
Author: Petr Fedchenkov<EMAIL_ADDRESS>Date:   Mon Jun 6 13:06:42 2022 +0300

    WorkerPool races fixes

    "go test -race" indicates several potential races inside workerpool_test
    . Testing CI returns error as well "panic: close of closed channel" in
    Done function. Seems we should add locking around workers and make
    atomic numChan edits.

    Signed-off-by: Petr Fedchenkov<EMAIL_ADDRESS>

Parent commit of current changes is https://github.com/eriknordmark/eve/commit/71a6ed0790a8f786859c76172bed521c774f57ec (you can see it here https://github.com/eriknordmark/eve/commit/ae9dc377b2d503bcd0f768a6b752e419eaefc8d8).


Add ability to run website source docs from local repository

@Pessimistress Done, is src-local/static ok?  Or basically any directory location that won't be part of the build.  I tried building, but it failed with some issue (seems related to the ocular changes and the babel plugin settings again)  I tried to fix it, but now it now longer works for me.
Can you work your magic.  The build pipeline for JS/webpack is a bit too magical for me right now.

Coverage increased (+9.0007%) to 39.181% when pulling c21f0f716aea033d865960e1ab250dfe06578303 on website-docs-local into 5d4f90e9ecd0ca3c744ea6edd23cb567903fd26b on master.


[wip] Support fst

As mentioned in #798

I just downloaded and ran
make clean build_dump.sc sim_dump.sc

and got thousands of these:
%Warning: previous dump at t=2040245000, requesting t=2040245000, dump call ignored
%Warning: previous dump at t=2040247500, requesting t=2040247500, dump call ignored
%Warning: previous dump at t=2040250000, requesting t=2040250000, dump call ignored
%Warning: previous dump at t=2040252500, requesting t=2040252500, dump call ignored
%Warning: previous dump at t=2040255000, requesting t=2040255000, dump call ignored

How do I turn on warnings?
But yes with the changes I can't open the dump.fst for hello_world anymore.
The dumps for aha_compress and towers on the other hand I am able to open.
Is there anything in hello_world that could interfere with dumping?

I didn’t do anything except checkout your branch and run that command, so not sure about the warnings.
No, hello world is like 20 lines of assembly — as simple as it gets

If the dump call in test_bp.cpp like you had before works, we can just do that. It's not worth digging too deep into this...

Oh yes sorry I didn't push the dependency update for basejump_stl. I'm not an expert on git submodules but I think I can't by design. Just use the fix_dpi_clock_gen branch for the basejump submodule.
That's why you are getting those warnings...
Now that being said the inability to open the dump.fst for hello_world is independent of that.

oh of course! FYI, you can update submodules. They are simply pointers to other git repo commit hashes (or branches). The process is:
cd ./external/basejump_stl
git checkout fix_dpi_clock_gen
cd ../../ # To black-parrot
git add external/basejump_stl
git commit -m "Bump basejump"

I see this behavior for hello world as well as other short programs rv64ui-p-add, for example. My guess is the flush is periodic and doesn't happen with short programs

I had a similar suspicion...
Just an observation: If I switch to vcd (with $dumpfile and $dumpvars) then I'm able to open the file without problems.
Maybe vcd is uncompressed so it's not as sensitive if the file get's closed to early or improperly.

Found a fix, can you try this and see if it works for you?
patch.txt

Just ran hello world and towers on it.
Unfortunately in both cases if you view the file in gtkwave it only contains the wires but not the signals. It's just a few kB after all...
Let's go with the option B for now and open a bug report for option A on verilator.

Ah I didn’t actually look at the signals haha. Sounds like a plan

Now all testbenches are updated. The default test for syn/me runs without errors and I can open the dump.fst files for it.
@dpetrisko Since the test_bp.sv top levels are now removed I also removed their references from the Makefile.vcs's. So please check if those work.

LGTM. Thanks, this solves a big problem we've had with using BP in classes!