pantilt_bot.launch.py error

Hallo,
i am starting to work with the code and wanted to launch the pantilt_bot using the cmd:
 ros2 launch pantilt_bot_description pantilt_bot.launch.py
sadly i am not getting any futhur as there still seams to be some errors:
 [ros2_control_node-1] [FATAL] [1636901750.857381442] [DynamixelHardware]: [TxRxResult] There is no status packet! [ros2_control_node-1] terminate called after throwing an instance of 'std::runtime_error' [ros2_control_node-1]   what():  Failed to configure 'pantilt_bot_ros2_control' [ERROR] [ros2_control_node-1]: process has died [pid 11068, exit code -6, cmd '/opt/ros/foxy/lib/controller_manager/ros2_control_node --ros-args --params-file /tmp/launch_params_3ksga6qn --params-file /home/ubuntu/foxy_test/install/pantilt_bot_description/share/pantilt_bot_description/controllers/controllers.yaml'].
thank you for the help

ok... i think if was a problem on my side, i needed to set the right baud rate for the motor this fixed the first error:
[ros2_control_node-1] [FATAL] [1636901750.857381442] [DynamixelHardware]: [TxRxResult] There is no status packet! [ros2_control_node-1] terminate called after throwing an instance of 'std::runtime_error'
the rest kist worked out of the box!
greate magic here... bravo nice code!


Logger timestamp support timezone setting

Currently, the timestamp of log output is in UTC format
2021-03-25T10:03:06.641Z [info]: 🚀 gateway ready at http://gw-org1:4001/graphql ([gw-org1] app.js)
It is nice to have a function to set the timestamp of log in specific region (Eg. Hong Kong)
2021-03-25T18:02:57+08:00 [info]: 🚀 admin service ready at http://localhost:15011/graphql (service-admin.js)
Example
https://medium.com/front-end-weekly/node-js-logs-in-local-timezone-on-morgan-and-winston-9e98b2b9ca45
Sample of modification in getLogger.ts
// using moment-timezone package
var moment = require('moment-timezone');

//...

// timezone setting
const appendTimestamp = format((info, opts) => {
  if (opts.tz) info.timestamp = moment().tz(opts.tz).format();
  return info;
});

//...

// set the timezone value when createLogger
    loggers[name] = createLogger({
      level,
      exitOnError: false,
      format: combine(label({ label: name }), appendTimestamp({ tz: 'Asia/Hong_Kong' }), logFormat),
      transports: transportArray,
    });

@rtang03 change is straight forward, does it require test case?

No test case is fine

TimeZone value will be

input with arg timezone when initiate getLogger or
setting environment variable TZ to override the default value or
default value is Asia/Hong_Kong when none of above is set


Remove 3d preview in web version

Due to this bug in web versions of Godot https://github.com/godotengine/godot/issues/56670
This causes the whole computer to lockup for 30 seconds while 3D shaders are compiled.
As a reference tool this is not so user friendly, I would suggest that the 3D version is only used for downloaded instances of the software.

Thank you for pointing this out!
I had not noticed this, but I was getting a long lockup when switching to 3d mode too.
I believe I can switch to gles2 without issue.
So I can do that for just the html5 export.
You can checkout https://jayaarrgh.itch.io/book-of-shaders-godot and let me know if its resolved for you.

Hi, thank you for the quick fix! Working now :)


Openssl v3.0.8 + wpa_supplicant2.10 can not connect 802.1x network

wpa_supplicant v2.10 with OpenSSL v3.0.8
Issue description:
I used supplicant2.10+openssl3.0.8 to test connecting to an 802.1x network, I got the following results:
PEAP+MSCHAPV2:Failed
PEAP+GTC:Passed
I want to use PEAP+MSCHAPV2 authentication with openssl3.0.8 for windows NPS servers where GTC is not supported (only MSCHAPV2 is supported by default).
I used supplicant2.10+openssl1.1.1t where it can connect to 802.1x using PEAP+MSCHAPV2
Steps to reproduce:
Connect to the 802.1x network and select the encryption mode PEAP + MSCHAPV2 with OpenSSL v3.0.8
Observed behavior:
connect timeout
Expected behavior:
connect ok
Log snippet:

16:57:53:437 wpa_supplicant: OpenSSL: RX ver=0x303 content_type=256 (TLS header info/)
16:57:53:445 wpa_supplicant: EAP-PEAP: received Phase 2: code=1 identifier=185 length=43
16:57:53:445 wpa_supplicant: EAP-PEAP: Phase 2 Request: type=26
16:57:53:456 wpa_supplicant: EAP-PEAP: Selected Phase 2 EAP vendor 0 method 26
16:57:53:470 wpa_supplicant: EAP-MSCHAPV2: RX identifier 185 mschapv2_id 185
16:57:53:471 wpa_supplicant: EAP-MSCHAPV2: Received challenge
16:57:53:481 wpa_supplicant: EAP-MSCHAPV2: Generating Challenge Response
16:57:53:481 wpa_supplicant: OpenSSL: EVP_DigestInit_ex failed: error:0308010C:digital envelope routines::unsupported

Log snippet using eapol_test utility to test 802.1x authentication provided in wpa_supplicant:

EAP-MSCHAPV2: Generating Challenge Response
Get randomness: len=16 entropy=0
random from os_get_random - hexdump(len=16): 77 b5 40 38 12 e0 da 75 3c 96 41 67 9a 40 6a f5
random_mix_pool - hexdump(len=20): 0d b9 b1 bf 70 7c bd fa 8b 8c 0a 46 d8 96 87 a4 8e 89 0d 7d
random from internal pool - hexdump(len=16): 52 c7 66 0a bf 85 ed d3 d8 c1 5b 8c 5d 36 f0 8e
mixed random - hexdump(len=16): 25 72 26 32 ad 65 37 a6 e4 57 1a eb c7 76 9a 7b
MSCHAPV2: Identity - hexdump_ascii(len=5):
61 64 6d 69 6e                                    admin
MSCHAPV2: Username - hexdump_ascii(len=5):
61 64 6d 69 6e                                    admin
MSCHAPV2: auth_challenge - hexdump(len=16): 3e 04 b8 c6 6b 23 3d 40 cb bf 55 7b e4 b2 85 d9
MSCHAPV2: peer_challenge - hexdump(len=16): 25 72 26 32 ad 65 37 a6 e4 57 1a eb c7 76 9a 7b
MSCHAPV2: username - hexdump_ascii(len=5):
61 64 6d 69 6e                                    admin
MSCHAPV2: password - hexdump_ascii(len=8):
70 61 73 73 77 6f 72 64                           password
OpenSSL: EVP_DigestInit_ex failed: error:0308010C:digital envelope routines::unsupported
EAP-MSCHAPV2: Failed to derive response
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL eapRespData=0
EAP: EAP entering state SEND_RESPONSE
EAP: No eapRespData available
EAP: EAP entering state IDLE
EAPOL test timed out
EAPOL: EAP key not available
EAPOL: EAP Session-Id not available
WPA: Clear old PMK and PTK
EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit
MPPE keys OK: 0  mismatch: 1
FAILURE

Further, when debugging it is found NULL value is returned in the following code snippet of crypto/evp/digest.c
In function evp_md_init_internal, EVP_MD_fetch returns a NULL value below which it is returned inside NULL check.
        /* The NULL digest is a special case */
        EVP_MD *provmd = EVP_MD_fetch(NULL,
                                      type->type != NID_undef ? OBJ_nid2sn(type->type)
                                                              : "NULL", "");

        if (provmd == NULL) {
            ERR_raise(ERR_LIB_EVP, EVP_R_INITIALIZATION_ERROR);
            return 0;
        }

Probably you need to load the legacy provider as the digest used for authorization is insecure and is absent in the default provider. See https://bugzilla.redhat.com/show_bug.cgi?id=2072070 for details


Type definitions for parameterized rules are inconsistent with behavior

Hi!
Thank you for maintaining this project! It is proving very useful for me.
If I define a parameterized rule like so:
Test{

AThen<B>
  = A B

A
  = "A"+

AX
  = AThen<"X">

}

The ActionDict type hints generated by ohm generateBundles --withTypes show AX as taking a single parameter (matches for "X"):
// ...
export interface TestActionDict<T> extends ActionDict<T> {
  AThen?: (this: NonterminalNode, arg0: NonterminalNode, arg1: Node) => T;
  A?: (this: NonterminalNode, arg0: IterationNode) => T;
  AX?: (this: NonterminalNode, arg0: NonterminalNode) => T;
}
// ...

But in practice, when the AX rule is triggered ohm will pass two parameters (matches for "A"+ and matches for "X").
Is this intended behavior? What I expected was what ohm is actually doing (actions for the AX rule should receive the matches for both "A"+ and "X").
Thanks!

Please disregard. There was a non-obvious mismatch between my actual environment and this minimal example. Everything in ohm is working as expected. (Although I will note for future readers: AX will receive its own match as just one argument. To get the separate matches for A and X you need to look at arg0.children.
My apologies, and thanks again for maintaining the library!


Add upper bound rate limiter in guaranteed throughput sampler

Adaptive sampling is a feedback mechanism that we’ve built into Jaeger. It dynamically adjusts the sampling probability for every endpoint in the system such that every endpoint is sampled at a specific SPS (sampled per second).
However, due to inherent latencies in the feedback loop, the new probabilities are not calculated and propagated in real time. In the worst case, sampling probabilities can take up to 2 minutes to propagate to the corresponding client. This means that adaptive sampling cannot react to fluctuations in traffic.
Under certain conditions, the sampling probability might increase to 100% (imagine having a very low QPS operation). However, every now and then this operation is hit with a ton of traffic and all the requests are sampled before adaptive sampling can kick in and prevent the oversampling.
To prevent this, I'm adding an upper bound rate limiter such that clients don't oversample during traffic spikes.

Coverage increased (+0.1%) to 84.048% when pulling 4cdba2b64112ff871ac0698d1572179ce48e387e on add_short_circuiting into 9f62f47d5a24c80dc7839aefd3c2667756c16cd2 on master.

Coverage increased (+0.09%) to 84.037% when pulling c00f388fcabdb101925a63c210aa0dcdc1dba017 on add_short_circuiting into 9f62f47d5a24c80dc7839aefd3c2667756c16cd2 on master.

Coverage increased (+0.09%) to 84.026% when pulling ccaa1a156b3d60d920ffc4ea491d90ce9eb679df on add_short_circuiting into e56cc8236bd0a97ea71ddc12ff2150327d9290c8 on master.

Coverage decreased (-0.01%) to 83.929% when pulling f007dbb7aad4aaf63d65a5c7f90270dd47eceb21 on add_short_circuiting into 061e54e542167596b1b0ae680ed2fea83ab39189 on master.


GH-699 showing issue with batch listener, along with fix

This was merged in https://github.com/spring-projects/spring-kafka/commit/eee0b2fd32e5b77108444d5c6bc557ae567a126d

@zach-schoenberger Thanks for the contribution!
Merged as eee0b2fd32e5b77108444d5c6bc557ae567a126d cherry-picked to 2.1.x: 9d167b75e5b2814c459e85cd5185adceb7d15456


Create Dockerfile

Dockerfile e.g.?

Pull request closed 11:24-2021-05-27

Restore branch or reopen?


Count of Host with alerts and hosts without alert

I need to get the number of hosts with alerts and also need the number of host without alers. Please assist me on this.

It's not possible to get a number of hosts without alerts through the Zabbix datasource. You can use SQL data source and try to write an appropriate SQL query.


Implement contracts, transaction templates, and script templates as files

Describe the feature few words
Change the implementation of contracts, transaction templates, and script templates to be a file.
What will be the end result of this change?
The end result of this change will enable the front end and backend to treat all user code as a file rather than separate entities. This will likely simplify the backend code, and provide a cleaner API.
General file endpoints include:

Create new file (blank or from template)
Update file name
Delete file

Is there any previous work that needs to be completed before making this change?
This change requires the models and schema to be reworked first.
Which components will this change affect?
This change will effect the following components:

Contract model
Transaction template model
Script template model
GraphQL Schema

Other remarks
This change is a large refactor which will effect the underlaying functionality of all backend functions relating to executing contracts, scripts, and transactions on the blockchain.

Merged with https://github.com/onflow/flow-playground-api/issues/72


Django 1.9 support

Hi @AliLozano, thanks for the PR!
Can anyone explain why the Jinja2 imports are now wrapped in a try-catch block? Curious to know how/why that works.

Because Django 1.9 import all templatetags, and when Django tries import jinja, it fails.

Hi @AliLozano and thank you for the PR.
Have you seen #1816? @kaedroho added Django 1.9 to tox and fixed some texts.
I am inclined to mark this as duplicate of #1816, but will wait to see what the maintainers say.

Oh, I didn't see the other PR. Apologies, mark this as duplicated, The other PR has more reviews and changes, I think that it is more complete.

Hi @AliLozano - this is really useful, as it lets us compare different approaches, and catch fixes that the other PR might have missed.
I like the Extension = object trick, as it means we don't have to move the jinja2 modules outside of templatetags - @timheap @kaedroho, any downsides to this approach? (I guess it might result in misleading error messages if people enable Jinja2 but don't have the package installed - is that something people are likely to do?)

I actually prefer having them separate. There's convention to keep your jinja2 templates completely separate from your Django ones at the app level and I think it's neater to apply this to template tags as well. This also reduces the risk of obscure error messages when using Django 1.9/jinja2.
But perhaps we could use a similar trick to allow backwards compatibility for a couple of releases.

Well, if you  like the extension=object fix, instead object class, we can use a ExtensionNoJinja class with a especific error in init to warn the user when use the templatetag and forget install jinja.
Django Extensions uses conditionals: https://github.com/django-extensions/django-extensions/issues/705

The consensus seems to be for simply moving the jinja2 modules rather than tweaking the imports, so I'll close this in favour of #1816 now - but thanks for providing a second perspective!


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/63360

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/86658


Bump 7.7 to 7.7.1

DO NOT MERGE UNTIL PAST 7.7 RELEASE.
Bump 7.7 to 7.7.1

Thanks for catching those issues, @jbaiera!


Add additional viewers for PGI

Summary

Release Note

Documentation

cc @bobcallaway

the ci failure will be fixed in this pr https://github.com/sigstore/community/pull/380

@haydentherapper please rebase


leapjs does not work with Gemini

Hello friends, have been struggling with getting my Leap Motion working with the leapjs library (both in the browser and in node.js) with no luck. Downgraded to Orion 4.1.0 and everything's working splendid.
Any suggestions on what might need to be updated to get the javascript up to date with the WebSocket server in the latest tracking software?

Unfortunately the latest server does not support LeapJS; a separate application would need to be written to consume LeapC and act as the LeapJS server.
This is an example of a minimal C# layer that consumes the LeapJS schema as a client, so, assuming the server emits these same structures, it should be able to drive v6 LeapJS applications:
https://gist.github.com/jselstad/6c6cbbb558e0b1858baab185eb764960

There are POC builds of a compatible websocket available for Gemini (WIN/Linux/MacOS(Intel/M Chipset) on their discord server:
https://discord.gg/3VCndThqxS
Tested it successfully with leapjs on MacOS Ventura M2 chip, Ultraleap software 5.17.1 and the very first Leap Motion Controller hardware.


TagUI does not recognize variables when expecting for string - outdated syntax used

No matter the quoting I try TagUI just see variables like string literals instead of variables when it is expecting for a string parameter (shoud accept variables).
I'm trying to do this:
1-Running TagUI for a csv file this way from shell:
tagui my_autom.tag data/data_file.csv -h
2- here, the csv file content (header plus 3 lines of data):
projeto,bolsa,nome
proj1,voluntario,marcelo
proj2,caps,joao
proj3,fapeam,guilherme
3- So it runs the following code:
if bolsa equals to 'fapeam'
echo fapeam
else
echo nao fapeam
echo 'bolsa'
echo '+bolsa+'
4- the 3 outputs respectively I get for each iteration:
(Iteration 1):
nao fapeam
'bolsa'
'+bolsa+'
(Iteration 2):
nao fapeam
'bolsa'
'+bolsa+'
(Iteration 3):
fapeam
TagUI is not using the variable as a variable consistently, so.. I realy tryed to solve it but I'm stuck..
What could be?
I'm using a updated Ubuntu last LTE version.. everything installed following https://tagui.readthedocs.io steps.
Please help this newby..

Hi @malbicomp sorry for the trouble! The syntax for quoting variables is the backtick symbol ` for eg
a = 'abc'
echo `a`

So the syntax for your example would be -
if bolsa equals to 'fapeam'
	echo fapeam
else
	echo nao fapeam
	echo `bolsa`

Can you share more how you ended up trying out '++' or ''? All existing documentation has been updated over a year ago to use backticks for variables, including object repository and datatable. It might be some external tutorial or reference. For example, below echo step in documentation is using backtick.
https://tagui.readthedocs.io/en/latest/reference.html#echo

Hello again Mr. Soh (Mr. @kensoh). Sorry for my disappearance. My fault in answer so many days after.
I read your answer as soon as you reply. And... I remembered when, surrendered after hours trying to track some code files, looking for some clue about any kind of setup I could be missing in my environment.. well again.. :face_with_head_bandage:
I realized I was just confusing backticks (`variable`) with single quotes ( 'just literals' ) :facepalm:... I read the right reference too.. but.. with... tired eyes...
So, I apology to have '+blamed+' TagUI... :face_with_thermometer:  what if issue's title changes to 'tired eyes mistakes'(kidding) becouse.. TagUI `ROCKS!!!!` :v:
Everything runs fine right now... :+1: :+1: :+1:

Hi @malbicomp no probs at all, take your time! Great to hear your feedback that it runs ok now 😄
Hope you have fun using the tool, there is a recent release of MS Word plug-in v3 which can make it even easier to use - https://github.com/kelaberetiv/TagUI#do-rpa-with-microsoft-word
And if you are someone familiar with Python programming, you can check out the Python version of TagUI - https://github.com/tebelorg/RPA-Python


New Version Bug: Language button does nothing

Describe the bug
The language translation feature button does not do anything.
To Reproduce
Steps to reproduce the behavior:

Go to 'next.dogehouse.tv' and login.
Click on 'Your profile picture'
Click on language
Nothing happens

Expected behavior
I expected to see a popout with a language list similar to old design
Screenshots
If applicable, add screenshots to help explain your problem.
What device are you on?
Up to date Chrome for Windows 10
Additional context
Add any other context about the problem here.

can confirm, I can't change language as well, clicking on Language does nothing
Safari 14.0.3

I think the feature hasn't been added yet

Not a bug, this feature is pending to be added

Ok


Nested modals have flickering overlay

Version
vue-final-modal: 4.5.4
vue: 3.4.21
OS
Mac
Reproduction Link
https://stackblitz.com/edit/github-fwkzck
Steps to reproduce

Open base modal
Open nested modal
Toggle nested modal between open / closed, to see the flickering

What is Expected?
Either the nested modals shouldn't have their own overlay or a better transition between modal overlays needs to be supported. Basically we shouldn't see the overlay flicker due to the transitions between modals
What is actually happening?
As can be seen in the video, when the previous modal and nested modal swap, the overlays "jump" resulting in an annoying flicker. It's less noticeable with light overlay but is very obvious with dark overlay
https://github.com/vue-final/vue-final-modal/assets/4270980/8af8d688-f6cc-4e0c-acd5-e904491abaed

Any thoughts on this @hunterliu1003

For nested modals, when two modals are displayed simultaneously, the overlay layer of the lower modal is actually removed (the content layer of the lower modal is not removed). I don't know why this is handled this way; I prefer that the two modals are completely independent and do not affect each other. @hunterliu1003

As mentioned above, adding the overlay-behavior="persist" attribute can solve this problem, but the documentation does not specify this.

That fixed it, thanks @Alecyrus


Unify the guava version for kyuubi server and kyuubi beeline

Why are the changes needed?

Unify the guava version between kyuubi server and kyuubi beeline.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Make local testing.

open kyuubi connection
show tables
select from table

merged to master, thanks


Pathway issue

Hey, sorry for bothering you with more issues.
I have an error with the pathway analysis could you please help me.
I am running seaborn 0.11.2 on Python 3.10.11

Unfortunately KEGG is not available for mouse, only 'GOBP' and 'Reactome' works with mouse. 'KEGG' is available only for human at the moment.
We will eventually add KEGG for mouse.

Thank you, worked now.

Hi @SimonE1220,
Great to hear that it worked. Just in case you want to use other resources, you could check this vignette for resource orthology conversion: https://decoupler-py.readthedocs.io/en/latest/notebooks/translate.html

Thanks a lot for your response. I have one more question intepreting the results. For example i have condition A and B. And than i perform the progeny analsis, it shows that Nfkb activity is upregulated wheras Jak-Stat activity is reduced. How do I know if the activity is upregulated in condition A or B, so whats the reference ?
Thank you very much.

Hi @SimonE1220,
High interaction loadings (and hence pathway activities estimated on those) should be linearly associated with your sample/context loadings.
So, whichever A or B has high loadings in your factor of interest is also the condition where NFKB activity is up. The same goes for JAK-STAT - i.e. it's down in the samples with high loadings.
For the samples with low loadings, you can think of the pattern (i.e. signaling captured by Factor X) as not being strongly associated with those.
Hope this helps!

@dbdimitrov
Thanks a lot that realy helps me.


Please add a screen shot

I'd like to add this to awesome-zsh-plugins, but I prefer to add themes with screen shots so that users can see what they look like without having to install them.

I did it, but I really made this colorscheme for my personal use, so it can (and will probably) still change a bit before finding it's final form :)


cut in srfi 26

I've finished a version of cut in srfi-26 by define-macro with simple test cases. As I didn't find any chapter related, I write them in raw.
Could you please create some relevant chapter then I can move it in the ".tmu" file, and pr again.
@da-liii

Also, the test of srfi-26.scm hasn't been added to the list. The build error may occurs there.

I've finished a version of cut in srfi-26 by define-macro with simple test cases. As I didn't find any chapter related, I write them in raw.

需要新建一个章节，名为 (liii cut)

Could you please create some relevant chapter then I can move it in the ".tmu" file, and pr again.

我来创建吧

I've finished the cut with docs, but I don't know what happened to the "windowsbuild" as there are some errors. Please check it @da-liii thanks.

Here is the error:
tests/goldfish/srfi/srfi-26-test.scm => wrong-number-of-args

;wrong-number-of-args ("The number of args should be same with the holes.")
;    (when (not (= (length args) 0))...

I think I can't solve it right now, I will fix it later.


Buffer is not defined

Hi, I installed the library in a JS project and it works without problem, as soon as I imported the code I wrote in a project with React Typescript it doesn't work and gives me an error ```uncaught (in promise) ReferenceError: Buffer is not defined".
Snippet Code

Error screenshot

Import

Here you go, Webpack 5 issue, this fixed it for us and we were able to verify our Merkle tree on-chain in our smart contract 💪
https://stackoverflow.com/questions/68707553/uncaught-referenceerror-buffer-is-not-defined


Switch linting to stylelint

Hello from GOV.UK 👋 , as forewarned this is a draft PR to propose a change in linter from the abandoned sass-lint to stylelint. This also abstracts the existing linting rules from this repo into a new package, stylelint-config-gds, which is intended to provide a stylelint configuration that can be recommended to all GDS projects via the GDS way.
Motivation for GOV.UK to work on this
GOV.UK is currently trying to migrate away from the deprecated Ruby SASS and instead use Sassc in projects. One of the blockers we have is that the linter we use, scss-lint, introduces Ruby SASS into projects and makes it cumbersome to migrate to Sassc.
We therefore want to upgrade our linter. We don't think GOV.UK needs to go it's own route with a linter and prefer our SCSS to be consistent with the design system, thus ideally we'd like to adopt a similar configuration as the design system. However since sass-lint is now abandoned it doesn't make much sense to put work into applying that to ~40 applications. Thus we felt it'd be beneficial to try extract the design system linting rules into a configuration and then see if that could be adopted across GDS. Stylelint felt like the obvious choice given it's ubiquity in CSS/SCSS linting.
The alternative approach - should this GDS attempt prove too complex, divisive or time consuming - is to have a stylelint configuration that is just for the GOV.UK programme and then to consider merging things at a later date.
stylelint-config-gds
We've put together a repository, stylelint-config-gds, that provides SCSS or CSS rules that can be applied to projects. The basic goals of this project were:

Have as few rules as possible, instead leaning on community standards. In a similar vein to how standard JS resolves the need for lots of rule discussion
Be consistent with govuk-frontend styles to offer the least painful path for initial adoption forward
Can be applied to plain CSS as well as SCSS, since vanilla CSS has been regaining popularity for years
Be sufficiently agreeable that the frontend community of GDS can, or aspire to, adopt the rules

The approach taken involved building rules from stylelint-config-standard and then tweaking any rules where govuk-frontend's existing ruleset disagreed. These rules can be seen (and are annotated) in scss.js and css.js. One thing to note when reviewing these rules is that the stylelint project is renaming it's whitelist/blacklist rules in their next release to neutral terminology (I could understand this producing reservations in adopting this tool).
The project is named stylelint-config-gds to represent that this is intended for the GDS organisation. It may well be that we decide later we want to make this broader and then give it a different name. This seems like a future step unless anyone has clear ideas now.
Applying to govuk-frontend
The approach taken in this PR is to apply stylelint at the same time of scss-lint and then disable the occasional line/rule were there are minor disagreements between the linters. Although this is not a long term plan this did seem to offer a possible short term approach that two linters could run in parallel to aid adoption. I also broke down the applying of each rule to a single commit so that the effects of individual rules could be seen. It's likely easiest to review this PR commit by commit.
When establishing the rules for stylelint-config-gds it felt like the property ordering rule in govuk-frontend was somewhat more project specific than the other rules so I decided to employ that at a project level rather than in stylelint-config-gds. This was consistent to how GOV.UK adopted the scss-lint rules for one project but didn't use the property ordering rule. Do let me know if that raises eyebrows.
Anyway, here is a breakdown of rule differences from scss-lint:
bem-depth - there isn't an equivalent core stylelint, there is a potential plugin route but doesn't appear to be like-for-like. Could potentially also be achieved with specifying class name regex.
border-zero - An equivalent rule doesn't exists in stylelint-core as it's rather divisive topic. We could apply this by a plugin but I'm inclined to not have a rule for it given the divisive aspects.
class-name-format - there isn't the same BEM option available in stylelint core. Instead gone for a relatively loose regexp that's roughly similar.
no-color-literals - there isn't an equivalent rule in stylelint core that forces colors to always be hex. Could consider doing something with a regex if this is a concern.
no-important - rather than allowing important values I left stylelint to raise an error on an important. This feels like the sort of rule developers should have to disable themselves for a single declaration.
Next steps
The things we're looking for at this point are:

Feedback on the rules in stylelint-config-gds. Are we missing any rules? or are some of the rules wrong? Are there any govuk-frontend specific preferences that can be deleted to fallback to stylelint-config-standard?
Identify if there is a road to adoption. Is this approach welcome? are there blockers? do any things need to happen before this can be adopted?
Feedback on this specific PR. Are there are things that should be done differently to work towards adopting this?

Do feel free to raise issues on https://github.com/alphagov/stylelint-config-gds too for more in-depth conversations about aspects than can be covered in this PR.
Thanks for your time :-) I'll look into arrange a meeting so we can chat more.

@vanitabarrett @hannalaakso I've updated this now with the inclusion of the declaration-no-important rule

Thanks for the approval @vanitabarrett. I've now created the initial public release of stylelint-config-gds and rebased against this. Unfortunately I've learnt that there is a regression in the latest version of stylelint (which we depend on), which they're working on fixing quickly so I've rebased this with the failing branch. I'll ping you once this is sorted and this is ready to merge.
I also noticed that earlier on you were experimenting with seeing about keeping some rules (I recall disallowing hsl function) do you want to consider raising an issue on stylelint-config-gds about those things if they're still a concern?

Thanks for the update @kevindew 🙂 We're just digging into https://github.com/alphagov/govuk-frontend/pull/1875/commits/448f78eb4b5df22ea2674ffd3266f66a09d5b96e to make sure we're happy with the media features being dropped in that commit, but all good otherwise.
We decided against the other rules I was experimenting with (hsl and a stricter class regex for nesting), so nothing to raise against stylelint-config-gds there 👍

Thanks for the update @kevindew 🙂 We're just digging into 448f78e to make sure we're happy with the media features being dropped in that commit, but all good otherwise.
We decided against the other rules I was experimenting with (hsl and a stricter class regex for nesting), so nothing to raise against stylelint-config-gds there 👍

That's great @vanitabarrett - did you come to a decision on the commit (now ba6641d)?
I've updated to stylelint 13.7.1 so this is now a passing build.
Would it be helpful if I cherry picked https://github.com/alphagov/govuk-frontend/pull/1902 onto this so it is just a single PR that goes in and applies both?

Thanks @kevindew - all ok to leave https://github.com/alphagov/govuk-frontend/commit/ba6641d05db94a5812c55cea6449018ba81e4e02 as is 👍
I'll go ahead and merge this, and then the PR to remove sass-lint. Thank you for all your hard work getting this completed! 🎉 👏

Yay, thanks @vanitabarrett 👍


Implement after-watch hook

Used for stopping the $ tsc --watch process. This is needed in long living processes which may work with multiple projects.
Ping @rosen-vladimirov @sis0k0

@rosen-vladimirov you have a point - I've reverted the file name change


Feature/asio

This draft pull request includes the rebase of develop into the feature/asio branch and the solution to the hangs and aborts that were present in the branch in the integration-tests (see GEODE-8318).
All test cases are passing now, even the IPV6 one, without the need to configure IPv6 in the CMakeLists.txt file.
The code is ready for review.

This is failing one of our "acceptance" tests, SNITest.dropSNIProxy.  This is a negative test case, so I think it's expecting a Geode exception and now it's getting the following:
terminate called after throwing an instance of 'boost::wrapexcept<boost::system::system_error>'
  what():  remote_endpoint: Transport endpoint is not connected

Command line for CI running acceptance tests is the following:
cd /home/geode/build/cppcache/acceptance-test && ctest -C Debug --output-on-failure --output-log test.log --timeout 600

You can probably repro with just this:
cd /home/geode/build/cppcache/acceptance-test && ctest -C Debug -R SNITest.dropSNIProxy --timeout 600

Outstanding work, BTW!  As advertised, everything else appears to be passing.  This is a huge win, thanks so much!

This is failing one of our "acceptance" tests, SNITest.dropSNIProxy. This is a negative test case, so I think it's expecting a Geode exception and now it's getting the following:
terminate called after throwing an instance of 'boost::wrapexcept<boost::system::system_error>'
  what():  remote_endpoint: Transport endpoint is not connected

Command line for CI running acceptance tests is the following:
cd /home/geode/build/cppcache/acceptance-test && ctest -C Debug --output-on-failure --output-log test.log --timeout 600

You can probably repro with just this:
cd /home/geode/build/cppcache/acceptance-test && ctest -C Debug -R SNITest.dropSNIProxy --timeout 600

I forgot about the acceptance-tests :-).
I have fixed the issue in the new commit.

Down to one failed test on a couple of platforms now - so close!
testXmlCacheCreationWithPools

Is timing out on Windows and RHEL7.
FYI, I'm out this week for the US holiday, so will be of limited, if any, help.  @mmartell & @mreddington can follow up as needed, I'll ping them via DM.

Down to one failed test on a couple of platforms now - so close!
testXmlCacheCreationWithPools

Is timing out on Windows and RHEL7.
FYI, I'm out this week for the US holiday, so will be of limited, if any, help. @mmartell & @mreddington can follow up as needed, I'll ping them via DM.

I managed to fix the test on windows thanks to @gaussianrecurrence . I hope it is also fixed under RHEL7.

Down to one failed test on a couple of platforms now - so close!
testXmlCacheCreationWithPools

Is timing out on Windows and RHEL7.
FYI, I'm out this week for the US holiday, so will be of limited, if any, help. @mmartell & @mreddington can follow up as needed, I'll ping them via DM.

I managed to fix the test on windows thanks to @gaussianrecurrence . I hope it is also fixed under RHEL7.

Anyway, I have a question for @mreddington . The test case failed due to the addition of the following commit:
d2a307d80 cppcache/src/TcrEndpoint.cpp     (Matthew Reddington 2020-05-14 17:36:32 -0700 1181)   m_cacheImpl->doIfDestroyNotPending(&
{
What is the reason for this change? I have not seen it in the development branch so I wonder if it is really necessary.

This is passing on Windows now, and I have at least an example of it working on RHEL7 Release build.  Our Debug and Coverage builds of RHEL7 are now timing out on a test, though, which has been a problem in the past.  Here's the tail end of the output, which looks kind of strange to me.
[       OK ] PartitionRegionOpsTest.putPartitionedRegionWithRedundancyServerGoesDownSingleHop (60480 ms)
[----------] 1 test from PartitionRegionOpsTest (60480 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (60481 ms total)
[  PASSED  ] 1 test.
[debug 2020/11/25 21:03:47.396293 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] ThinClientPoolDM::destroy...
[debug 2020/11/25 21:03:47.396528 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] Internal fair queue size while closing is 0
[debug 2020/11/25 21:03:47.396541 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] ConnectionQueue::close( ): queue closed
[debug 2020/11/25 21:03:47.396559 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] recursive lock: CacheImpl::doIfDestroyNotPending

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 650.16 sec

The following tests FAILED:
	 27 - PartitionRegionOpsTest.putPartitionedRegionWithRedundancyServerGoesDownSingleHop (Timeout)
Errors while running CTest

This is passing on Windows now, and I have at least an example of it working on RHEL7 Release build. Our Debug and Coverage builds of RHEL7 appear to now be timing out on a test, though, which has been a problem in the past. Here's the tail end of the output, which looks kind of strange to me.
[       OK ] PartitionRegionOpsTest.putPartitionedRegionWithRedundancyServerGoesDownSingleHop (60480 ms)
[----------] 1 test from PartitionRegionOpsTest (60480 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (60481 ms total)
[  PASSED  ] 1 test.
[debug 2020/11/25 21:03:47.396293 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] ThinClientPoolDM::destroy...
[debug 2020/11/25 21:03:47.396528 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] Internal fair queue size while closing is 0
[debug 2020/11/25 21:03:47.396541 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] ConnectionQueue::close( ): queue closed
[debug 2020/11/25 21:03:47.396559 UTC heavy-lifter-80e74939-d075-5450-9833-2e242c016911:1522<PHONE_NUMBER>39104] recursive lock: CacheImpl::doIfDestroyNotPending

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 650.16 sec

The following tests FAILED:
	 27 - PartitionRegionOpsTest.putPartitionedRegionWithRedundancyServerGoesDownSingleHop (Timeout)
Errors while running CTest

Interesting... @gaussianrecurrence told me that he had seen a deadlock in the feature/asio branch once related to that mutex but had not been able to reproduce it again. We looked together at the code today and it appeared that a deadlock is possible after the change included by @mreddington about which I him asked above. We could try removing the call to CacheImpl::doIfDestroyNotPending in TcrEndpoint::closeConnections() to see if the timeout does not occur.

@albertogpz Despite it's terrible name, doIfDestroyNotPending ends a race condition where code tries to access the cache after it was destroyed. It's a shame we apparently need to set max connections which is only available from the distributed system when we close connections. This could cause a segfault during client shutdown.

@albertogpz Despite it's terrible name, doIfDestroyNotPending ends a race condition where code tries to access the cache after it was destroyed. It's a shame we apparently need to set max connections which is only available from the distributed system when we close connections. This could cause a segfault during client shutdown.

Thanks @mreddington .
@pdxcodemonkey , I have pushed a new commit to see if removing the need to use that method (and the use itself) in TcrEndpoint::closeConnections(), fixes the possible deadlock. I do not have a RHEL7 environment so I cannot verify if this change fixes anything. Could you please test it?

@albertogpz Despite it's terrible name, doIfDestroyNotPending ends a race condition where code tries to access the cache after it was destroyed. It's a shame we apparently need to set max connections which is only available from the distributed system when we close connections. This could cause a segfault during client shutdown.

Problem is that using doIfDestroyNotPending has undefined behaviour, as you are accessing the CacheImpl status equally. If it happens that the cache is removed and the mem page on which the cache was gets overwritten, doIfDestroyNotPending could try to execute the lambda.
The real issue here is that whenever ThinClientPoolDM::destroy is called, m_endpoints is not cleared
By the time ThinClientPoolDM::~ThinClientPoolDM is called, m_endpoints is to be destroyed, decrementing the reference counter to each of the container items.
If it happens that the container is holding an object which this was its latest reference, TcrEndpoint::TcrEndpoint will be called leading to undefined behaviour.
The real solution here is to make sure that before a pool destructor is called, all the references to the endpoints are cleared out.

Our CI didn't run builds after the last commit, because it has a clang-format issue:
@@ -140,7 +140,7 @@ class NamingContextImpl : virtual public NamingContext {
       LOGCOORDINATOR(func);
       LOGCOORDINATOR("Dump follows:");
       dump();
-      throw -1;
+      throw - 1;
     }
     return result;
   }

If you fix/push this, it should kick off a new set of builds.  Thanks!

Our CI didn't run builds after the last commit, because it has a clang-format issue:
@@ -140,7 +140,7 @@ class NamingContextImpl : virtual public NamingContext {
       LOGCOORDINATOR(func);
       LOGCOORDINATOR("Dump follows:");
       dump();
-      throw -1;
+      throw - 1;
     }
     return result;
   }

If you fix/push this, it should kick off a new set of builds. Thanks!

Done. Strangely, it was cmake the one who changed that line in the first place to throw -1.

This is green in CI now - can you please rebase the branch onto the latest develop?  We'll review it quickly and get it merged.

FWIW, a rebase is liable to be unpleasant, from what I saw when attempting it.  I saved off the contents of a merge commit into develop as a stash, applied it to a new branch, and came up with this:  https://github.com/apache/geode-native/compare/develop...pdxcodemonkey:feature/asio-latest.  Hope this helps.

Codecov Report

Merging #697 (fb064c6) into feature/asio (2c0a667) will increase coverage by 0.12%.
The diff coverage is 80.71%.

@@               Coverage Diff                @@
##           feature/asio     #697      +/-   ##
================================================
+ Coverage         73.84%   73.97%   +0.12%
================================================
  Files               644      642       -2
  Lines             51131    50810     -321
================================================
- Hits              37759    37588     -171
+ Misses            13372    13222     -150

Impacted Files
Coverage Δ

cppcache/include/geode/AuthInitialize.hpp
100.00% <ø> (ø)

cppcache/include/geode/Cache.hpp
100.00% <ø> (ø)

cppcache/include/geode/CacheFactory.hpp
100.00% <ø> (ø)

cppcache/include/geode/CacheableEnum.hpp
72.22% <ø> (ø)

cppcache/include/geode/DataInput.hpp
94.85% <ø> (ø)

cppcache/include/geode/DataOutput.hpp
94.44% <ø> (ø)

cppcache/include/geode/PdxInstance.hpp
100.00% <ø> (ø)

cppcache/include/geode/PdxInstanceFactory.hpp
100.00% <ø> (ø)

cppcache/include/geode/PdxReader.hpp
100.00% <ø> (ø)

cppcache/include/geode/PdxSerializable.hpp
100.00% <ø> (ø)

... and 124 more

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 2c0a667...fb064c6. Read the comment docs.

This is green in CI now - can you please rebase the branch onto the latest develop? We'll review it quickly and get it merged.

Done in the latest force push. Not sure why the checks are failing with merge conflicts. Everything looked correct in my local branch.

Your PR is still set up to merge from your fork into the apache feature/asio branch, rather than develop.  I think if you target develop the conflicts will be gone.

Your PR is still set up to merge from your fork into the apache feature/asio branch, rather than develop. I think if you target develop the conflicts will be gone.

You are right. I changed that and now I get errors in LGTM analysis but I do not understand why.

Your PR is still set up to merge from your fork into the apache feature/asio branch, rather than develop. I think if you target develop the conflicts will be gone.

You are right. I changed that and now I get errors in LGTM analysis but I do not understand why.

There was a merge commit from develop that I should not have added.
Now it is fixed and ready for review.

Well I guess we know why Connector needs to be APACHE_GEODE_EXPORT now:
c:\nativeclient\cppcache\src\TcpConn.hpp(33): error C2220: warning treated as error - no 'object' file generated (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
c:\nativeclient\cppcache\src\TcpConn.hpp(33): warning C4275: non dll-interface class 'apache::geode::client::Connector' used as base for dll-interface class 'apache::geode::client::TcpConn' (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
  c:\nativeclient\cppcache\src\Connector.hpp(40): note: see declaration of 'apache::geode::client::Connector' (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp)
  c:\nativeclient\cppcache\src\TcpConn.hpp(33): note: see declaration of 'apache::geode::client::TcpConn' (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp)
c:\nativeclient\cppcache\src\TcpConn.hpp(33): error C2220: warning treated as error - no 'object' file generated (compiling source file C:\nativeclient\cppcache\src\TcpSslConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
c:\nativeclient\cppcache\src\TcpConn.hpp(33): warning C4275: non dll-interface class 'apache::geode::client::Connector' used as base for dll-interface class 'apache::geode::client::TcpConn' (compiling source file C:\nativeclient\cppcache\src\TcpSslConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
  c:\nativeclient\cppcache\src\Connector.hpp(40): note: see declaration of 'apache::geode::client::Connector' (compiling source file C:\nativeclient\

It looks like TcpConn has also been exported and wasn't before.  Perhaps fixing that will take care of everything.

Well I guess we know why Connector needs to be APACHE_GEODE_EXPORT now:
c:\nativeclient\cppcache\src\TcpConn.hpp(33): error C2220: warning treated as error - no 'object' file generated (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
c:\nativeclient\cppcache\src\TcpConn.hpp(33): warning C4275: non dll-interface class 'apache::geode::client::Connector' used as base for dll-interface class 'apache::geode::client::TcpConn' (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
  c:\nativeclient\cppcache\src\Connector.hpp(40): note: see declaration of 'apache::geode::client::Connector' (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp)
  c:\nativeclient\cppcache\src\TcpConn.hpp(33): note: see declaration of 'apache::geode::client::TcpConn' (compiling source file C:\nativeclient\cppcache\src\TcpConn.cpp)
c:\nativeclient\cppcache\src\TcpConn.hpp(33): error C2220: warning treated as error - no 'object' file generated (compiling source file C:\nativeclient\cppcache\src\TcpSslConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
c:\nativeclient\cppcache\src\TcpConn.hpp(33): warning C4275: non dll-interface class 'apache::geode::client::Connector' used as base for dll-interface class 'apache::geode::client::TcpConn' (compiling source file C:\nativeclient\cppcache\src\TcpSslConn.cpp) [C:\build\cppcache\shared\apache-geode.vcxproj]
  c:\nativeclient\cppcache\src\Connector.hpp(40): note: see declaration of 'apache::geode::client::Connector' (compiling source file C:\nativeclient\

It looks like TcpConn has also been exported and wasn't before. Perhaps fixing that will take care of everything.

Let's see.

Confirmed - removing APACHE_GEODE_EXPORT from TcpConn fixes my Windows build.


(PUP-8974) Safely deserialize stringified array

The augeas provider used Kernel#eval to convert stringified arrays to Ruby arrays. For example, it extracted the array part of the "clause" below:
onlyif => 'values HostKey == ["/etc/ssh/ssh_host_rsa_key"]'

and called Kernel#eval with '["/etc/ssh/ssh_host_rsa_key"]'. Using eval is bad because it executes arbitrary code.
This commit changes the provider to convert the comma delimited string to a Ruby array. This mostly maintains the functionality of the original Kernel#eval (minus running arbitrary code) except for no longer handling the \M-x, \M-\C-x, \M-\cx, \c\M-x, \c?, and \C-? escape sequences in double-quoted strings, and \u{nnnn ...} is more lenient about whitespace.

jenkins please test this with 5.5.x

👍 I didn't find any issues.

My only question is whether it makes sense to move the parser to a util module to keep the provider class a little cleaner? Otherwise I'm :+1:

There are bits that could be reused, because of the nature of parser-combinators, but it feels a bit specialized for being util code. I’m not sure how often we’d need/want to be able to parse “mostly Ruby array syntax, but only supports string entries, and doesn’t support all of the escape sequences”. It does feel a little awkward having it directly in the provider, but it also feels more specific to augeas than general util code would be. Maybe an augeas util in the separated module when the change is ported to the puppetlabs-augeas_core repo?

Yeah, I'm fine leaving it as-is in 5.x and having a util file in the module :+1:

CLA signed by all contributors.

Copying in some comments from hipchat. It is possible to ask ruby to compile the string into a sequence of instructions, ensure the VM bytecodes are only ones that we expect, and if so, eval the sequence:
irb(main):036:0> expression = "[1, 2]"
=> "[1, 2]"
irb(main):037:0> iseq = RubyVM::InstructionSequence.compile(expression)
=> <RubyVM::InstructionSequence:<compiled>@<compiled>>
irb(main):038:0> iseq.to_a[13]
=> [1, [:trace, 1], [:duparray, [1, 2]], [:leave]]
irb(main):039:0> iseq.eval
=> [1, 2]

Note the :duparray bytecode. For comparison, an invalid expression generates:
irb(main):040:0> iseq = RubyVM::InstructionSequence.compile("puts 'hi'; [1, 2]")
=> <RubyVM::InstructionSequence:<compiled>@<compiled>>
irb(main):041:0> iseq.to_a[13]
=> [1, [:trace, 1], [:putself], [:putstring, "hi"], [:opt_send_without_block, {:mid=>:puts, :flag=>20, :orig_argc=>1}, false], [:pop], [:duparray, [1, 2]], [:leave]]

However, the InstructionSequence#to_a method is not really public API and can change across ruby versions. Given that fragility, better to implement the parsing ourselves. Adding a dependency on ruby parser is also possible, but seems overkill for just this one provider.

Should we create constants for the regexps so that we don't generate lots of local Regexp objects as we scan each character in the string, e.g. /'/. Otherwise 👍 from me.

I could see doing that. You thinking of having that for this PR, or for when things get moved around in the module repo?

Could you file a MODULES ticket for the extracted module and submit a PR there too?

Created MODULES-7443, and working on porting the patch (with util library, and constant regex cleanup) to the module repo.


GossipingPropertyFile snitch

Re-add property file snitch (code from my old "003-foo" branches)
Can be merged before PR #44 or #45 (or even after these)
The actual snitch can be configured with code provided by PR #44

#44 is merged, please rebase and add a config property so that a snitch can be provided at bootstrap time (this will allow us to set EC2 or GCE snitches).

Rebased

needs rebase after merging #45

Rebased


Add engine_params parameter to flask_sqlalchemy.SQLAlchemy constructor

One of the most discussed topic of issues is to add some additional parameters for passing to sqlalchemy.create_engine function (http://docs.sqlalchemy.org/en/latest/core/engines.html#sqlalchemy.create_engine). engine_params dictionary is passed 'as is' to sqlalchemy.create_engine, so now it allows to pass such parameters as isolation_level (#120 ), pool_pre_ping (#577 )  etc.
Example of usage:
from sqlalchemy.pool import StaticPool

db = SQLAlchemy(engine_params={'isolation_level': 'READ_UNCOMMITED', 'poolclass': StaticPool})

Duplicate of #487.


getting-paid.md has HTTP 404 Not Found link

"@mamiM did Japanese translations for @MetaMask after the issue was funded on Bounties Network." reference to https://beta.bounties.network/bounty/v1/134 which is missing.

gem "github-linguist", "~> 7.5.1"

Same issue..been working for almost a year no payments


Run test job on windows-latest

This adds running windows-latest to the set of OS's that we run E2E tests on. This ensures we have coverage for non-nix based operating systems.

LGTM


Using the Tagless Final Design Pattern Refactor the PowerPlant CRUD Controllers

Currently the CRUD methods in the PowerPlantController is a bit messy. There are a lot of nested pattern matching clauses and statements. This should be simplified. One way is to introduce a Service layer between the controller and the DBService where we could move all the nested checks into this. By having the tagless final, we can probably do flatmap like operations instead of the nexted case blocks.

Service layer introduced and the controllers and now using the service layer to talk to the database!


Compiling click.c warnings

Hello, so I tried compiling the click.c with the command supplied in the file :'gcc -Wall -pthread -o click click.c -lpigpio -lrt'.
The problem is I'm getting two error messages and I don't know anything about C, so I don't know how to fix them.
The errors are:
click.c:160:5: warning: first argument of 'main' should be 'int' [-Wmain]
int main(void *args){
^~~~
click.c:160:5: warning: 'main' takes only zero or two arguments [-Wmain]
Can somebody help me, Pigpio is installed and I'm guessing it has to do something with the main function, but I don't know how to fix this.

@Archipollo it is just a warning, look in the directory, you should find the compiled file nex to to the .c ;)

Ah yes I see, thank you!


investigate slow DTS build

do we need this in dev environments? or just before publishing packages?
why is it so slow and resource heavy? is it our complex, old config types?

currently store-sync is eating up ram and causing oom issues in some enviroments

cc @tash-2s in case you have some input/guidance

Some context: pnpm tsup in store-sync might fail on some machines.
To reproduce the error:
$ NODE_OPTIONS=--max-old-space-size=2048 pnpm tsup
CLI Building entry: src/index.ts, src/sqlite/index.ts, src/postgres/index.ts, src/postgres-decoded/index.t
s, src/recs/index.ts, src/trpc-indexer/index.ts, src/indexer-client/index.ts, src/zustand/index.ts
CLI Using tsconfig: tsconfig.json
CLI tsup v6.7.0
...
ESM ⚡ Build success in 25ms
DTS Build start
node:events:495
      throw er; // Unhandled 'error' event
      ^

Error [ERR_WORKER_OUT_OF_MEMORY]: Worker terminated due to reaching memory limit: JS heap out of memory
    at new NodeError (node:internal/errors:405:5)
    at [kOnExit] (node:internal/worker:301:26)
    at Worker.<computed>.onexit (node:internal/worker:222:20)
Emitted 'error' event on Worker instance at:
    at [kOnExit] (node:internal/worker:301:12)
    at Worker.<computed>.onexit (node:internal/worker:222:20) {
  code: 'ERR_WORKER_OUT_OF_MEMORY'
}

Node.js v18.19.0

do we need this in dev environments? or just before publishing packages?

We don't need .d.ts files locally with our current setup, so we can conditionally turn off the dts flag.
I believe most TypeScript packages should have .js and .d.ts, and then they can optionally add .ts and .d.ts.map for devex. (See also: https://github.com/latticexyz/mud/issues/2051)
So, here's a possible way to avoid the memory issue for now:

Run TSUP_ENV=development pnpm tsup for local environments.
In tsup.config.ts, turn off dts by checking process.env.TSUP_ENV.

why is it so slow and resource heavy?

I've also noticed that the tsup command is unusually slow in store-sync. It seems tsc currently fails in store-sync on the main branch intentionally because it's actively under development. Generating .d.ts files indeed adds some cost, but the current slowness might also relate to the failing types, but not sure now. I wouldn't be surprised if it can't build .d.ts files at all in that condition (failing tsc).

Regarding the NODE_OPTIONS option, if your machine has sufficient available memory, the default value should be 4096, in which case the process should complete successfully.
So, another potential workaround could be to use NODE_OPTIONS=--max-old-space-size=3072 pnpm tsup, but it may be painfully slow if it uses swap.

Also, another point about "slow DTS build" is that if the tsc runs slowly, the DTS build tends to be slow as well. For the JS build, we use esbuild internally, which just strips TS types, so it's fast.


How to make Visio?

I’ve cloned locally the repo. It runs against my resources. Is there a plug-in for Visio or do I need to have Visio installed locally?

Hi, you do need to have Visio installed. it uses the local APIs of visio


footer-updated

review #4

Hey @ramyashreeshetty, Kindly give some screenshots of the work you did on the footer🚀

@ramyashreeshetty, Will work on that image later, I can merge your PR right now but you have some conflicts, kindly check👀

Hey resolved it.

Merging @ramyashreeshetty 🚀
Do give a ⭐ to the repo if you learned something👀


Dependent classes should be part of the tree of classes that affect configuration generation

Right now, if a dependent resource class changes, the associated controller configuration is not regenerated even though it might need to.

This has been addressed.


Set didChangedWatchedFiles glob pattern to **/*.ext

**.ext will only look in the base folder.
@ahoppen

@swift-ci Please test

Thanks a lot for fixing this, Adam. I think the situation was even worse and **.ext didn’t even watch files in the base folder because apparently ** only matches path components but not file name components.


"other classes of bugs" than what?

Content Bug Report
Page(s) Affected
https://beta.rust-lang.org
What needs to be fixed?
I don't want to say that anything needs to be fixed, but the sentence—

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many other classes of bugs at compile-time.

—feels a bit awkward to me because I encounter "other classes of bugs" without any classes of bugs having been mentioned. It's quick for me to rescan the sentence in "quirks mode" and interpret it as "[...] many classes of bugs other than violations of memory-safety and thread-safety [...]", but I stumble on it slightly, and—
Suggested Improvement
—I don't see any semantic difference in, and wonder whether you would object to, changing it to—

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many classes of bugs at compile-time.

—(i.e., deleting "other").

Great catch! I think your suggestion is perfect -- care to open a PR?

@aturon: I've filed rust-lang/beta.rust-lang.org#504 as requested.


Ability to update default Felix and Typha Healthports where 9098, 9099 and Promentheus (9091) are already in use

Expected Behaviour
Ability to customise healthcheck ports and others (TCP 9091, 9098, 9099)
Current Behaviour
Cannot customise healthcheck ports using Operator.
Possible Solution
Expose port configuration for ports such as 9091, 9098 and 9099 where it is possible that other application on the host already use these ports.

Thank you for the issue. There is this issue projectcalico/calico#5697 that is covering Felix and Typha Healthports.
For prometheus we have a NodeMetricsPort and TyphaMetricsPort in the Installation Spec. Do those fit your needs for prometheus?

That issue should cover this ask - I am already in conversation with Manuel on that other Calico issue. But we do want to make sure that these are exposed in the Operator also and not just in Calico CRDs

But we do want to make sure that these are exposed in the Operator also and not just in Calico CRDs

We do not expose all configuration through the Operator CRDs, ideally we aren't duplicating Calico CRD configuration but I know we do duplicate some. I doubt we will be exposing the FelixHealthPort through the Operator.
It should be possible to install the CRDs (both operator and Calico) and pre-create a FelixConfiguration resource with the desired health port.

Will be available in the next release


Swagger codegen for websockets

Extend swagger-codegen to generate client and server code for websockets and push our changes upstream.

https://www.pivotaltracker.com/story/show/152471896


[BUG] pytorch is not included even though its used by example notebook

Describe the bug
When using the cusignal notebook from a docker container /rapids/notebooks/cusignal/E2E_Example.ipynb it tries to import torch which is not installed.
Steps/Code to reproduce bug

Run docker container rapidsai_cuda10.1-runtime-centos7 within Singularity.
Start Jupyter server with singularity run --nv rapidsai_cuda10.1-runtime-centos7.sif
Access Jupyter on localhost:8888
Try running the cusignal/E2E_Example.ipynb example.

Expected behavior
Notebook completes without failure.
Environment details (please complete the following information):

Environment location: Singularity on local HPC system
Method of cuDF install: Docker container

If method of install is [Docker], provide docker pull & docker run commands used
$ singularity pull docker://nvcr.io/nvidia/rapidsai/rapidsai:cuda10.1-runtime-centos7
$ singularity run --nv rapidsai/rapidsai_cuda10.1-runtime-centos7.sif

Please run and attach the output of the cudf/print_env.sh script to gather relevant environment details

rapids.log
Additional context
Using Singularity on HPC so could be issues with that.

@tomgreen66, thanks for bringing this to our attention and apologies for the late reply here. I'm told that we intentionally exclude PyTorch from our images due to its size. However, I just opened a PR to cusignal (https://github.com/rapidsai/cusignal/pull/242) to add both an explanation and a workaround for users who are running this Notebook in our containers.
closing this issue.


AFNetworking 2.5 Upgrade

Is it possible to use AFNetworking 2.5 ? I am using cocapods and have another library which is using 2.5 of AFNetworking but restkit is using 1.3
I can help with this if it's already planned.
Thanks

There are a bunch of issues open about this, which you should've found before opening this one, but the gist of things is that we want to nuke the AFN dependency entirely for 1.0.


Header should be semi-transparent and not expanding on scroll over

The header used to be semi-transparent and disappear on scroll up. Currently on scroll over menu items the bottom of the header also expands. Expected:

Make header semi-transparen as https://fossasia.org
Implement disappear on scroll up as on https://chat.susi.ai/overview
Avoid expansion of height on scroll over menu items

can i work on this @mariobehling ?

Avoid expansion of height on scroll over menu items

@mariobehling Can you provide a link to the page where this is happening?

@mariobehling Can I still work on this issue?

@mariobehling Can I still work on this issue?

Yes this issue is still open you can work on this

I would like to work on this issue @mariobehling


UnexpectedAdmissionError

Errors is as follows:
Events:
  Type     Reason                    Age               From           Message
  ----     ------                    ----              ----           -------
  Warning  FailedScheduling          73s               4pd-scheduler  AssumePod failed: pod c4c9c2a8-83d3-4e9b-b6fa-ed47719d3d19 is in the cache, so can't be assumed
  Warning  FailedScheduling          73s               4pd-scheduler  AssumePod failed: pod c4c9c2a8-83d3-4e9b-b6fa-ed47719d3d19 is in the cache, so can't be assumed
  Normal   Scheduled                 73s               4pd-scheduler  Successfully assigned default/gpu-pod to pkm-05
  Warning  FailedScheduling          73s               4pd-scheduler  AssumePod failed: pod c4c9c2a8-83d3-4e9b-b6fa-ed47719d3d19 is in the cache, so can't be assumed
  Warning  UnexpectedAdmissionError  73s               kubelet        Allocate failed due to rpc error: code = Unavailable desc = transport is closing, which is unexpected
  Warning  FailedMount               9s (x8 over 73s)  kubelet        MountVolume.SetUp failed for volume "kube-api-access-8hcmj" : object "default"/"kube-root-ca.crt" not registered

Example file as follows:
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
    - name: ubuntu-container
      image: ubuntu:18.04
      command: ["bash", "-c", "sleep 86400"]
      resources:
        limits:
          nvidia.com/gpu: 2 # requesting 2 vGPUs
          nvidia.com/gpumem-percentage: 50 # Each vGPU contains 50% device memory of that GPU （Optional,Integer）
          nvidia.com/gpucores: 30 # Each vGPU uses 30% of the entire GPU （Optional,Integer)

may I see the output of "kubectl version"?


Return of the self.file_ptr hack.

Makes filer's File object not choke on cascade deletes of
objects referencing them.

This obviously doesn't work, so back to the drawing board.


kubed helm chart - generated resources

https://github.com/appscode/kubed/blob/master/chart/kubed/templates/apiregistration.yaml#L1-L5
{{- $ca := genCA "ca" 3650 }}
{{- $cn := include "kubed.fullname" . -}}
{{- $altName1 := printf "%s.%s" $cn .Release.Namespace }}
{{- $altName2 := printf "%s.%s.svc" $cn .Release.Namespace }}
{{- $cert := genSignedCert $cn nil (list $altName1 $altName2) 3650 $ca }}

Generated resources like the above are problematic when using tools like helmfile because on every application new certificates are generated and a release created with helm. This makes it slow and gives the user a false sense of a tool that is updated a lot for no reason.
While this is a great feature, I am not suggesting removing it but can a manual override be added so an administrator can statically set it and not have it generate all the time. Also If the apiserver is disabled is this certificate still required?

Recently added a way to pass certificates from outside in one of our charts. https://github.com/kubevault/installer/commit/57d4945ff81a773ecd9775dd03b4605fc6bfe5cc#diff-31a50bdfee9401ac802054fe55e6602c
Does something like that solve your use-case?

Also If the apiserver is disabled is this certificate still required?

This has been changed in https://github.com/appscode/kubed/releases/tag/v0.12.0-rc.0 release.


[as2_behaviors_motion] Not able to deal with low latency frames

ROS2 Version
humble
Version
main
What happened?
When dealing with low latency frames that are not earth, behaviors reject their execution due to lack of ability for extrapolation into the future.
Relevant log output
No response

@javilinos Has this issue been resolved already?

Solved.


Fixes #154. ninja is now automatically called if bf was called without args

Coverage decreased (-0.8%) to 75.765% when pulling 80398ab7dac4c3dcb9de9738fe01068e8faf7ec7 on auto_execute_ninja into 65ca0f888287fc2d414dfc25130ff736f59ff90d on master.

I'll investigate and fix it :)

Coverage decreased (-0.6%) to 76.033% when pulling 32cbecb883b331d050e09ad1b92d8ca694bfa597 on auto_execute_ninja into 65ca0f888287fc2d414dfc25130ff736f59ff90d on master.


Unable to get an updae from the "stable" chart repo.

Summary
Installing JenkinsX using jx boot and unable to fetch the velero chart repo.
Steps to reproduce the behavior
Fetch the velero chart repo. durig JenkinsX install.
Install JenkinsX on top of an on-prem remote Kubernetes cluster using the jx boot command from a local MAC OS machine.
Expected behavior
Successful install of JenkinsX using jx boot command.
Actual behavior
Installation fails with the below error msg.
`
STEP: install-velero command: /bin/sh -c jx step helm apply --boot --remote --no-vault --name velero in dir: /Users/myid/Documents/jx/jenkins-x-boot-config/systems/velero
error: failed to build the dependencies of chart '/var/folders/4g/prh490450fv3hf_zjt31dzjrjyv20j/T/jx-helm-apply-071077216/velero': failed to run 'helm dependency build' command in directory '/var/folders/4g/prh490450fv3hf_zjt31dzjrjyv20j/T/jx-helm-apply-071077216/velero', output: 'Hang tight while we grab the latest from your chart repositories...
...Unable to get an update from the "local" chart repository (http://<IP_ADDRESS>:portno/charts):
Get http://<IP_ADDRESS>:portno/charts/index.yaml: dial tcp <IP_ADDRESS>:portno: connect: connection refused
...Successfully got an update from the "jenkins-x" chart repository
...Unable to get an update from the "stable" chart repository (https://kubernetes-charts.storage.googleapis.com):
open /Users/myid/.helm/repository/cache/~/.helm/repository/cache/stable-index.yaml: no such file or directory
Update Complete. ⎈Happy Helming!⎈
Error: velero chart not found in repo https://kubernetes-charts.storage.googleapis.com'
error: failed to interpret pipeline file jenkins-x.yml: failed to run '/bin/sh -c jx step helm apply --boot --remote --no-vault --name velero' command in directory 'systems/velero', output: ''
`
Versions
The components versions are
NAME               VERSION
helm - 2.1.x
Kubernetes cluster v1.16.8 (on-prem remote cluster)
kubectl            v1.16.6-beta.0
git                2.20.1 (Apple Git-117)
Running jxboot from local MAC machine.
Thanks!

/Users/myid/.helm/repository/cache/~/.helm/repository/cache/stable-index.yaml: no such file or directory

I’d check your local environment to see why an absolute and a relative path are used in the same file path. That seems like a good first step to determine a root cause here.

@bacongobbler - Thanks! Could you please let me know in which file the helm related settings are set? I can go and remove them. I uninstalled and reinstalled helm and no luck.
Thanks in advance!

Use helm env.

Hi, @2020testuser - hopefully the helm env suggestion enabled you to solve this issue. We'll resolve it at this time, due to inactivity.


install issue on linux mint

i have ran all install steps and troubleshoot for the dependancies but still get this issue
user@stewiemo ~/Dragonfire $ dragonfire
Traceback (most recent call last):
File "/usr/share/python/dragonfire/bin/dragonfire", line 6, in
from pkg_resources import load_entry_point
File "/usr/share/python/dragonfire/local/lib/python2.7/site-packages/pkg_resources/init.py", line 3142, in
@_call_aside
File "/usr/share/python/dragonfire/local/lib/python2.7/site-packages/pkg_resources/init.py", line 3126, in _call_aside
f(*args, **kwargs)
File "/usr/share/python/dragonfire/local/lib/python2.7/site-packages/pkg_resources/init.py", line 3155, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/share/python/dragonfire/local/lib/python2.7/site-packages/pkg_resources/init.py", line 664, in _build_master
ws.require(requires)
File "/usr/share/python/dragonfire/local/lib/python2.7/site-packages/pkg_resources/init.py", line 981, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/share/python/dragonfire/local/lib/python2.7/site-packages/pkg_resources/init.py", line 867, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyowm' distribution was not found and is required by dragonfire
user@stewiemo ~/Dragonfire $
any fix?

I am getting the same issue with Kubuntu 17.10, I also have re installed, and tried apt installing the dependencies.

@stewiemo and @wrapperband you can install pyowm manually with pip install pyowm
For more information about PyOWM


Problem with starting mp4 player

What is your Scenario?
I would like to run a player on the site that downloads mp4
What is the Current behavior?
Mp 4 downloads, but it takes a long time, much more than without testCafe.
This has resulted in the fact that it cannot be tested.
Normally the request requires ~100ms.

With testcafe it takes ~25s.

What is the Expected behavior?
Downloading mp4 through the player takes a normal amount of time
What is the public URL of the test page? (attach your complete example)
https://www.livereacting.com/tools/mp4-player
What is your TestCafe test code?
import { RequestLogger, Selector, t } from "testcafe";

const loggerMp4 = RequestLogger({ url: 'https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_30MB.mp4', method: 'get' }, {
    logResponseHeaders: true,
    logResponseBody: true,
    logRequestHeaders: true,
    logRequestBody: true,
});

fixture`test player mp4`
    .page('https://www.livereacting.com/tools/mp4-player');

test('load player', async () => {
    await t.addRequestHooks(loggerMp4);
    await t.click(Selector('#play-button'));
    await t.expect(loggerMp4.contains(record => record.response.statusCode === 200)).ok({ timeout: 10_000 });
});

TestCafe version
3.7.0
Command-line arguments
testcafe chrome tests/test.js --disable-native-automation
Platform(s) and version(s)
chrome, edge

Hello @JakubMaz,
I couldn't reproduce the issue based on the scenario you described. The video takes slightly longer to load compared to running without TestCafe, but it's not as delayed as you mentioned.
Without Testcafe:

Testcafe Native Automation mode:

Testcafe Proxy mode:

Could you please clarify if you have tried running it in Native Automation mode? Additionally, could you share your operating system and Node.js version?

@PavelMor25 I'm runing testcafe with flag --disable-native-automation. On Native Automation mode it works.
My system: Windows 11 Pro 22H2.
My node: 20.18.0

Hello,
Could you please clarify if there is a reason you do not use TestCafe with Native Automation enabled?
Also, we have tried running your example with Native Automation disabled yet we still got expected results.
Could the issue be related to your environment?
Please try running your example on a different machine and share your results with us.

Hey, I checked it on different machines and I still have a longer time when the player is run by testcafe (I created a new repository where testcafe is only one dependency).
Chrome + Win 10

Chrome + macOS 14.5

(I'm not using native automtion because I have to prepared my tests for it. For exaple I have to update my loggers because I manually decompress data with the zlib.brotliDecompressSync method. I have a task to change it but it's waiting in backlog)

Hello @JakubMaz ,
After we conducted a partial investigation, we couldn't reproduce the results you reported. Since the observed difference in loading time is not critical and this issue is not widely reported among users, we cannot prioritize it at this time. Additionally, you can use the native automation mode to resolve this issue.
Therefore, we will close this issue. We appreciate your understanding.


Magic Apiary Texture Rework + Fix Research

Retextures Apiary GUI to the same style as Forestry's Bee Houses with enhanced clarity for icons:
Increased Production:

Decreased Lifespan:

Increased Mutation:

Also fixed Research langs not correctly localized.

The Magic Bees Apiary is a unique bit of thaumcraft, do not sully it by unifying textures when it is already so unique.
This PR as a whole is a reflection of someone who doesn't understand the vibrant uniqueness that each thaum addon brings to the table that is design.

I agree with alastor, there's no reason to change the icons. Maybe the background, but I don't really think that needs changing either. If the author wanted it to use 'Forestry's Bee House icons' (which I don't recall ever seeing BTW) they would have used them.

I'd like to bring to focus one final thing as well, base forestry doesn't have icons, so these icons are entirely unique to the Magic Apiary

While you're at it, I'll pop in since the repo doesn't have any issues to actually start a discussion in and Alastor already did the same change between Gregapi and gregtech in https://github.com/GTNewHorizons/ThaumicHorizons/tree/gt6-gix, as mentioned in https://github.com/GTNewHorizons/ThaumicHorizons/issues/46, a specific commit in magic bees, specifically https://github.com/GTNewHorizons/MagicBees/commit/d9ef30fe32a71eb91bde9542c8fa52c4d2aa7ef1 crashes the modpack and using any version of magic bees alongside any version of gregtech outside of 5U causes a crash.
At least in the case of thaumic horizons it was just a matter of enabling an external config which is disabled by default, in this case the mod just crashes with no option to do anything about it. and as it is, is impossible to play any version of magic bees past that commit.
Oh also the new icons are cool and I personally thing as an external observer that they should be changed :+1:

These review are charming if not for their touch of creative flair.
MysteriousAges would appreciate a cleanup of Magic Bees' most cryptic aspect, especially after over a decade from its inception.
As a talented programmer artist yourself I get the apprehension, but when it comes to user interfaces, the ultimate aim should be making them feel cohesive and user-friendly which the original could use some improvement.
Anyways, you've asked for a comparison so here are the gifs (compression may slightly alter the colors).
Old:

New:

Things have been slightly tweaked in my latest iteration which is not included here but is available on request.

MysteriousAges would appreciate a cleanup of Magic Bees' most cryptic aspect, especially after over a decade from its inception.
Who is MysteriousAges?

As a talented programmer artist yourself I get the apprehension, but when it comes to user interfaces, the ultimate aim should be making them feel cohesive and user-friendly which the original could use some improvement.
Ehhhhhhhhhh, not so much with Thaumcraft, the majority of Thaumcraft consistently and intentionally keeps the UI user-unfriendly and enigmatic for various reasons, and it's important to stay consistent with that design goal, though this system is one of the less enigmatic given that the Thaumonomicon directly lists out what each of them mean. Though I hardly believe a full rework of the GUI itself is tantamount to making it any more "user friendly" you could make the argument for the icons sure, but personally, I don't think there is enough value here to justify the utter destruction of the original GUI in totality.

MysteriousAges would appreciate a cleanup of Magic Bees' most cryptic aspect, especially after over a decade from its inception.

~Who is MysteriousAges?~ NVM you mean one of the devs, I fully invite him to come here and say the same then, though I would still disagree with that opinion personally. Of course that considered, he could just re-release the mod himself, given he still has ownership.

As a talented programmer artist yourself I get the apprehension, but when it comes to user interfaces, the ultimate aim should be making them feel cohesive and user-friendly which the original could use some improvement.

Ehhhhhhhhhh, not so much with Thaumcraft, the majority of Thaumcraft consistently and intentionally keeps the UI user-unfriendly and enigmatic for various reasons, and it's important to stay consistent with that design goal, though this system is one of the less enigmatic given that the Thaumonomicon directly lists out what each of them mean. Though I hardly believe a full rework of the GUI itself is tantamount to making it any more "user friendly" you could make the argument for the icons sure, but personally, I don't think there is enough value here to justify the utter destruction of the original GUI in totality.

MysteriousAges would appreciate a cleanup of Magic Bees' most cryptic aspect, especially after over a decade from its inception.

Given there's been no update to Magic Bees in over 3 years though, I hardly believe you speak for MysteriousAges.

Thanks for the rework, this second iteration looks much better imo.

I like the second iteration of the GUI.
The icons seem slightly out of place for magic (at least the DNA one)

i like to see it with bees ingame.
Sure, I can do that:

ok thanks for showing. I think the hexagons need to be more visible and also the slots.

The icons seem slightly out of place for magic (at least the DNA one)
I reluctantly agree with the sentiment.
That DNA is definitely the weaker element of this design.

It is can be difficult to translate science elements such as genetic mutation into a magic theme.
I originally aimed to infuse a touch of alchemy, inspired by Fullmetal Alchemist/The Witcher 3 but I soon realized that this was quite a tough task, not just in the design-wise with a limited 10-pixel width canvas, but also in making sure it's easy to understand and use for everyone.
What you see is what I have settled on for lack of a better solution.

After hours of stringent and fervent debate, we have now updated our dev Code of Conduct, and thusly, I push forth that this PR breaks GTNH CoC 7-1 given how this proposal would shift the identity significantly too far away from the unique feel intended by magic within the pack, likewise, the alternative modification proposed in #meta-dev can be handled by GTNH CoC 7-4

Regarding textures within GTNH

Regarding magic textures: within the vision of the modpack, magic is meant to feel, look, and be different than GregTech, any form of GUI update for the sake of (or that would inadvertently bring) consistency with GT GUIs should be rejected.
n/a
n/a
Regarding inventory changing: GUIs that shift the colour of the player's internal inventory are allowed as long as its usage is consistent. Examples being: GT's Steam Machines, Magic Bee's Magic Apiary, Railcraft's Coke Oven, etc.

ok thanks for showing. I think the hexagons need to be more visible and also the slots.

I covered your valid concern.
There were also a couple of other issues fixed with it:

Moved "Inventory"  label a tad bit to the left.
The GUI was getting cut at the bottom by 2 pixel (also affects the original)

This can be tested from here:
https://github.com/DrParadox7/MagicBees/releases/tag/2.7.1-LE

@Alastors If you've already altered the rules to predetermine the outcome of this PR, there's no need for further opinions.
Enforcing your authority to conclude this discussion should be just as easy.

Kinda defeats the whole point of having a discussion if ya can simply edit the rules to what can be done and can't be done mid-discussion, doesn't it? But then again I'm just here to point the issue with magic bees crashing with gt6 anyway :^)

@DrParadox7 What about recolor/tint light grey part of UI to make it more unique? (with color of Greatwood/Arcane stone/Thaumium)

This still looks like a GT machine to me - not really what I'd want, but I've not done bees or magic this far.

Kinda defeats the whole point of having a discussion if ya can simply edit the rules to what can be done and can't be done mid-discussion, doesn't it? But then again I'm just here to point the issue with magic bees crashing with gt6 anyway :^)

The new ruling came after tireless debate for 2 days straight, that's literally the point of having rules, make rules when new issues come up.

This still looks like a GT machine to me - not really what I'd want, but I've not done bees or magic this far.

This is the entire issue, it defaces Magic's identity for no real reason

@DrParadox7 New UI looks nice. But what about to recolor/tint light grey part of new UI to make it more unique? (with color of Greatwood/Arcane stone/Thaumium)

There was also concern in those debates (not even mostly by me) that the icons look too "techy" compared to what the original looked like

what do we do with this PR?

what do we do with this PR?

It was rejected, and the CoC was changed to reflect it

We discuss it after stable

https://github.com/GTNewHorizons/GTNH-Dev-Doc/blob/master/developer's code of conduct.md
Dream, respectfully we wasted 2 months on and off discussing this exact topic, please do not waste developer time further on such tripe like this. However, I will remind you of our policies regarding this topic now:
Code of Conduct
Subsection 3: Content Creation

Regarding textures within GTNH
7-1. Regarding magic textures: within the vision of the modpack, magic is meant to feel, look, and be different than GregTech, any form of GUI update for the sake of (or that would inadvertently bring) consistency with GT GUIs should be rejected.
7-2. Regarding new textures: try to keep textures consistent with the mod/mod group they're being added to.
7-3. Regarding tooltips: reduction is fine when needed, but if there is a specific consistency, try to stay within that.
7-4. Regarding inventory changing: GUIs that shift the colour of the player's internal inventory are allowed as long as its usage is consistent. Examples being: GT's Steam Machines, Magic Bee's Magic Apiary, Railcraft's Coke Oven, etc.

I cannot stress this further, please do not waste any more of our time on meaningless debate on aesthetic taste, it gets incredibly argumentative, chaotic, downright rude, and quite frankly it's bad for developer moral on the pack. This has already been settled, we need to leave it in the past where it belongs.
Besides, even out of all the debate, no one actually cared for this specific UI, the most anyone actually cared about were the Icons or the rare desire to split the original UI instead.

Stating this as a violation of the CoC makes no sense, the mod contains 3 GUIs, 2 of which are vanilla esque, see https://github.com/GTNewHorizons/MagicBees/blob/master/src/main/resources/assets/magicbees/textures/gui/jarScreen.png and https://github.com/GTNewHorizons/MagicBees/blob/master/src/main/resources/assets/magicbees/textures/gui/ringScreen.png and the third is this strange shaded variant.
So arguably this PR actually brings it fully in line with the CoC by giving the same shading to all GUIs?

The color of the new GUI definitely feels too much like a GT/Vanilla one. I say we keep the old color of the gui, but apply that to all of Magic Bee's guis

Stating this as a violation of the CoC makes no sense, the mod contains 3 GUIs, 2 of which are vanilla esque, see https://github.com/GTNewHorizons/MagicBees/blob/master/src/main/resources/assets/magicbees/textures/gui/jarScreen.png and https://github.com/GTNewHorizons/MagicBees/blob/master/src/main/resources/assets/magicbees/textures/gui/ringScreen.png and the third is this strange shaded variant.
So arguably this PR actually brings it fully in line with the CoC by giving the same shading to all GUIs?

The bee ring and jar one are intentionally clones of each other, also the bee ring is not exactly in optimal shape, frankly I'm not sure if it actually has a recipe but using them as an example of two separate GUIs is very deceptive

The only problem I see here is that a DNA icon doesn't really fit magic content. Other than that, I look at the screenshots and what I think is Forestry bees with a touch of flair and a starry background that makes me think of Astral Sorcery, which is a magic mod. It overall looks fine to me, and I didn't really see it as a GT GUI the moment I looked at it.

The only problem I see here is that a DNA icon doesn't really fit magic content. Other than that, I look at the screenshots and what I think is Forestry bees with a touch of flair and a starry background that makes me think of Astral Sorcery, which is a magic mod. It overall looks fine to me, and I didn't really see it as a GT GUI the moment I looked at it.

I agree.
This was the original concept for the DNA symbol but I had given up on it as it proved to be too difficult conceptualize it into pixel art (too tiny canvas size and awkward angles):

Feel free to have a go at it

Made alterations to look less DNA-y and more runic (based on the Inguz rune shown above).
It should be satisfactory enough without compromising clarity.

tbh, i like the three new texture, how about just keep everything else, only update the 3 pics. i like the brown background and purple linings.


Maintaining state history?

Is it possible to maintain the state history as a user navigates between states using a single page apps own nav buttons?  Or is there a recommended way to handle this?
In my single page app, I need to keep a state history to make it easier to navigate back and forth between states. I have my own forward and back buttons that I'm using on my pages and not going through the browser's buttons.
This is the following code I have which uses the service I've created to store the states in an array.
$rootScope.$on('$stateChangeStart', function (event, toState, toParams) {
    StateMgmtService.add(toState, toParams);
});

In the service, I have something to the effect of the following:
var history = [];

    return {
        previous: function () {
            if (history && history.length > 0) {
                return history[history.length - 1];
            }
        },
        add: function (state, params) {
            var historyItem = {
                state: state,
                parameters: params
            };

            history.push(historyItem);
        }
    };

The problem is that any time I go back to a prior state, the stateChangeStart is fired which basically pollutes my history. Consider the following example:

starting from state a to b - b gets added to the history
b to c - c gets added
c back to b - b gets added again

This results in an endless looping of going from b to c to b to c... So I basically need to not allow prior items to be added to the history or to somehow know that it's going back in the history, but stateChangeStart doesn't allow any differentiation as such.  And unfortunately just comparing state isn't possible since they can be on the same state but with different parameters.
Help!

Why can't you use the browsers forward/back/history management?

Happens to mee to.
If b has params, it looses them when going back from c and also - c disappears from the history.
From the beginning the history looks lake this when I'm going from state to state:
a-b (with params)-c
When going back (using browser buttons) the history appears like this:
a-b (with params)-b (withour params)


reconnecting rpc provider

@chevdor
something that has pluggability per method (such as piecing in intermediate missed blocks)

This will be greatly simplified by rune

what is rune ?

We'll tackle this as part of our Smoldot rework #1109


GPU Load/Temperature Sensor identifies as UserNotificationState Sensors

Seems to have started happening with the newest update. Appears to be just a visual thing for existing sensors, but new sensors become notification sensors instead of GPU Load/Temperature sensors.

Hi! Is this still happening? I think it may have something to do with using a newer version of the UI to configure an older version of the service. This can happen right after updating.

I'll close this. If you're still having this problem, please let me know!

I'm having the same problem


[BEAM-13276] bump jackson-core to 2.13.0 for .test-infra

bump jackson-core to 2.13.0 for .test-infra

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @pabloem


check-inputs entry point checks all yaml in directory regardless of existence of passed settings file

I ran armi check-inputs on the most recent FFTF model terrapower/fftf-isothermal-model@793fd8ec1a494b0254bdac61f9b145837c6b41ca with terrapower/armi@47d3cc77b3f24540fcf6ae56be6c0e34b397604e
and got the following output
% armi check-input FFTF.yaml
Failed to import psutil; MemoryProfiler will not provide meaningful data.

                              ---------------------------------------------------
                             |             _      ____     __  __    ___         |
                             |            / \    |  _ \   |  \/  |  |_ _|        |
                             |           / _ \   | |_) |  | |\/| |   | |         |
                             |          / ___ \  |  _ <   | |  | |   | |         |
                             |         /_/   \_\ |_| \_\  |_|  |_|  |___|        |
                             |         Advanced  Reactor  Modeling Interface     |
                              ---------------------------------------------------
                                                   Version 0.1.7
Finding potential settings files matching ['*.yaml'].
Checking for valid settings files.
skipping FFTF-blueprints.yaml
           Attempted to load an invalid settings file from: FFTF-blueprints.yaml. Attempted to load an invalid settings file from: FFTF-blueprints.yaml. Missing the `settings:` header required in YAML settings
skipping FFTF-coremap.yaml
           Attempted to load an invalid settings file from: FFTF-coremap.yaml. Attempted to load an invalid settings file from: FFTF-coremap.yaml. Missing the `settings:` header required in YAML settings
-----------------------------------------------------  ------  -----------  --------------------------
                                                              case    can start    input is self consistent
       -----------------------------------------------------  ------  -----------  --------------------------
       /<path data>/FFTF.yaml                                 FFTF    UNKNOWN      PASSED
       -----------------------------------------------------  ------  -----------  --------------------------

Even though I passed a settings file, ARMI still tried to check all *.yaml files. If I passed FFTF.yaml FFTF.yaml as the settings and patterns arguments, then only the FFTF.yaml file was processed
Originally posted by @drewj-usnctech in https://github.com/terrapower/armi/discussions/508

The reason this is happening is because the suite.discover method is being called regardless of what input is being provided. This should be changed to accept specific settings file paths OR a pattern to discover - see: https://github.com/terrapower/armi/blob/04526a658dcf59ba1e29c4613374fe23624d33f2/armi/cli/checkInputs.py#L126