[UI] rke.windows should be treated as the same as rke

The cluster provider function has been modified to differentiate between linux RKE1 vs windows RKE1 here, need to update the UI to treat RKE.Windows the same as rke

@westlywright Backend change is merged in 2.5-head and master.

@sowmyav27 mentioned that she is not seeing the change in master or 2.5. I add the awaiting backend tag again, can @sowmyav27 or @StrongMonkey remove the tag when the backend is fixed? Thanks

On 2.5-head - commit id: 395b4fe7

Windows cluster shows RKE1. And custom shows Custom as the provider.

Expected:

now that windows shows provider as rke.windows in View in API, it should still show the right provider - Custom on the UI.

rke.windows should show Windows as the provider

On 2.5-head - commit id: 3df817c5 and master-head - commit id: e4ce3766

Windows cluster, provider is shown as "Windows"

Custom cluster windows enabled - with just linux nodes, shows cluster type as "Custom"


Tiny flags appearing as empty squares

Hey, love the program but I am having a strange issue.
It will not display the tiny flag but the ascii one is displayed no issues. Example attached below.

�Thanks for the neat terminal candy!

Yea after making this issue I tried it on kitty and everything works perfectly with the same setup. Not quite sure where the dependency would lie since I use nerd font icons primarily.

What terminal do you use in the screenshot which shows squares?

Foot. I have recently made a full switch to kitty though, because despite how much I love foot, a lot of issues are shining through and I use my terminal for all that I can so I try to keep it looking nice. Foot for some reason struggles with image and video previews in ranger where kitty does not and I am working toward using 100% cli tools for day to day stuff so it makes a difference.

I see, it's a terminal specific issue then. Well, kitty is a great terminal emulator so it will serve you well.
Closing the issue.


Termdebug encoding - again

let the expression replacement actually work (there is a double \\  in there - removed before applying the previous replacements)
don't replace NULL values with NULLs as those either "cut" the string or are removed

Test case in GDB:
char buff[12] = {0};
memcpy(buff,"TST",3);
buff[5] = '"';
buff[7] = '\n';
// evaluate buff here

GDB shows: "TST\000\000\"\000\n\000\000\000", without those changes we had "TST\\000\\000\\"\\000\\n\\000\\000\\000", after applying the missing \\ conversion we had "TST\"\n" - with those changes :Evaluate shows the data correctly.
Beware:

I have no clue if vim operates on non-ascii, non-utf8 data - UTF16 and UTF32 with its included null bytes would be broken by the NullRepl stuff [if in question you may want to comment that out]
I was told that does a conversion on print if the data is actually defined as wide char, not sure if this is the case and/if Vim could do the same

Things I originally wanted to but did not get it working (maybe @lacygoill could kick in):

in s:HandleEvaluate(): use ->substitute syntax
move most of the decoding stuff out into a s:DecodeText(), so only the initial value (ending at first " / within value="") and the "special" handling (like \n) is in s:DecodeMessage() / s:HandleEvaluate()

in s:HandleEvaluate(): use ->substitute syntax

Does this work?
diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index 9707b25f9..d61194acd 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -1090,18 +1090,19 @@ let s:evalFromBalloonExpr = 0

 " Handle the result of data-evaluate-expression
 func s:HandleEvaluate(msg)
-  let value = substitute(a:msg, '.*value="\(.*\)"', '\1', '')
-  let value = substitute(value, '\\"', '"', 'g')
-  let value = substitute(value, '\\\\', '\\', 'g')
-  " multi-byte characters arrive in octal form, replace everthing but NULL values
-  let value = substitute(value, '\\000', s:NullRepl, 'g')
-  let value = substitute(value, '\\\o\o\o', {-> eval('"' .. submatch(0) .. '"')}, 'g')
-  " Note: GDB docs also mention hex encodings - the translations below work
-  "       but we keep them out for performance-reasons until we actually see
-  "       those in mi-returns
-  "let value = substitute(value, '\\0x00', s:NullRep, 'g')
-  "let value = substitute(value, '\\0x\(\x\x\)', {-> eval('"\x' .. submatch(1) .. '"')}, 'g')
-  let value = substitute(value, s:NullRepl, '\\000', 'g')
+  let value = a:msg
+    \->substitute('.*value="\(.*\)"', '\1', '')
+    \->substitute('\\"', '"', 'g')
+    \->substitute('\\\\', '\\', 'g')
+    "\ multi-byte characters arrive in octal form, replace everthing but NULL values
+    \->substitute('\\000', s:NullRepl, 'g')
+    \->substitute('\\\o\o\o', {-> eval('"' .. submatch(0) .. '"')}, 'g')
+    "\ Note: GDB docs also mention hex encodings - the translations below work
+    "\       but we keep them out for performance-reasons until we actually see
+    "\       those in mi-returns
+    "\ ->substitute('\\0x00', s:NullRep, 'g')
+    "\ ->substitute('\\0x\(\x\x\)', {-> eval('"\x' .. submatch(1) .. '"')}, 'g')
+    \->let value = substitute(value, s:NullRepl, '\\000', 'g')
   if s:evalFromBalloonExpr
     if s:evalFromBalloonExprResult == ''
       let s:evalFromBalloonExprResult = s:evalexpr . ': ' . value

*line-continuation-comment*

For the "\ comment leader syntax, see :help line-continuation-comment.

move most of the decoding stuff out into a s:DecodeText(), so only the initial value (ending at first " / within value="") and the "special" handling (like \n) is in s:DecodeMessage() / s:HandleEvaluate()

I'm really not familiar with the code.  Which lines exactly should be moved into a separate function?

Ah no, the previous patch was wrong at the end.  Here is a new try:
diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index 9707b25f9..b0ab2c483 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -1090,18 +1090,19 @@ let s:evalFromBalloonExpr = 0

 " Handle the result of data-evaluate-expression
 func s:HandleEvaluate(msg)
-  let value = substitute(a:msg, '.*value="\(.*\)"', '\1', '')
-  let value = substitute(value, '\\"', '"', 'g')
-  let value = substitute(value, '\\\\', '\\', 'g')
-  " multi-byte characters arrive in octal form, replace everthing but NULL values
-  let value = substitute(value, '\\000', s:NullRepl, 'g')
-  let value = substitute(value, '\\\o\o\o', {-> eval('"' .. submatch(0) .. '"')}, 'g')
-  " Note: GDB docs also mention hex encodings - the translations below work
-  "       but we keep them out for performance-reasons until we actually see
-  "       those in mi-returns
-  "let value = substitute(value, '\\0x00', s:NullRep, 'g')
-  "let value = substitute(value, '\\0x\(\x\x\)', {-> eval('"\x' .. submatch(1) .. '"')}, 'g')
-  let value = substitute(value, s:NullRepl, '\\000', 'g')
+  let value = a:msg
+    \->substitute('.*value="\(.*\)"', '\1', '')
+    \->substitute('\\"', '"', 'g')
+    \->substitute('\\\\', '\\', 'g')
+    "\ multi-byte characters arrive in octal form, replace everthing but NULL values
+    \->substitute('\\000', s:NullRepl, 'g')
+    \->substitute('\\\o\o\o', {-> eval('"' .. submatch(0) .. '"')}, 'g')
+    "\ Note: GDB docs also mention hex encodings - the translations below work
+    "\       but we keep them out for performance-reasons until we actually see
+    "\       those in mi-returns
+    "\ ->substitute('\\0x00', s:NullRep, 'g')
+    "\ ->substitute('\\0x\(\x\x\)', {-> eval('"\x' .. submatch(1) .. '"')}, 'g')
+    \->substitute(s:NullRepl, '\\000', 'g')
   if s:evalFromBalloonExpr
     if s:evalFromBalloonExprResult == ''
       let s:evalFromBalloonExprResult = s:evalexpr . ': ' . value

We can probably support 8-bit encodings, such as latin1.  But supporting UTF-16 or others with NUL bytes is going to be very tricky.  Perhaps we should not spend time on it and wait until someone actually needs it.
I assume most users will use utf-8 these days.

latin1 here :-)
Interestingly GDB has a charset translation (target charset + host charset) we might be able to use https://sourceware.org/gdb/onlinedocs/gdb/Character-Sets.html and according to some rant the host charset should be checked by Vim to know if/how translations are done.
For Vim's displays and assignments to be correct I guess the host charset should be set to UTF-8 and the target charset to the one that matches ... the target. We could tweak those settings, I'll likely check if/how those make a difference next weeks.
@brammool  If supporting NUL bytes is not important I guess you are likely to include this PR or a variant, don't you?

latin1 here :-)
Interestingly GDB has a charset translation (target charset + host charset) we might be able to use https://sourceware.org/gdb/onlinedocs/gdb/Character-Sets.html and according to some rant the host charset should be checked by Vim to know if/how translations are done.
For Vim's displays and assignments to be correct I guess the host charset should be set to UTF-8 and the target charset to the one that
matches ... the target. We could tweak those settings, I'll likely
check if/how those make a difference next weeks.

The host charset should match 'encoding'.  When it is any Unicode
encoding then utf-8 should be used, since that is what is used
internally also for ucs-16 and utf-16.

@brammool  If supporting NUL bytes is not important I guess you are
likely to include this PR or a variant, don't you?

Using the built in gdb support sounds better.
--
How To Keep A Healthy Level Of Insanity:
7. Finish all your sentences with "in accordance with the prophecy".
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool If supporting NUL bytes is not important I guess you are likely to include this PR or a variant, don't you?

Using the built in gdb support sounds better.

That may was misleading - without this patch the de-encoding on variables does not work at all and every de-encoding which includes NUL bytes is broken, too. Those are fixed by this patch and I'd say @lacygoill's 2nd patch makes the code cleaner, too.

OK, so we need both?
Please include the patch from @lacygoill and check that it works properly.

Checked the on-top patch from @lacygoill, works fine so is now included.
I suggest to pull that in, then inspect the rest.
Also checked the set host-charset UTF8 encoding - it seems to break our printing but I don't know why
Test:

GDB only:

set one byte of a C char[] to a hex-value of 8bit encoding (ISO-8859-15 in my case) - 0xFC
print it via GDB - out of termdebug - works fine and shows the 8it character, because host-charset = target-charset = auto  => derived from LANG -> ISO-88959-15

Termdebug:

do the same setting on the GDB console
do the print - displays garbage because the host and target charset options are still identical, but as noted in #9206 the buffer GDB works in seems to be UTF8 (I'd really like to adjust that...)
:Evaluate the char - the character is shown correctly, checked the mi buffer shows it is received as \374

Termdebug:

do the same setting on the GDB console
go to the console and set host-charset UTF8
do the print - displays fine now
:Evaluate the char - the character is shown bad, checked the mi buffer shows it is received as \303\274

I was confused first but guess that some encoding option, defaulting to LANG in Vim needs to match that.

The changes from this PR are already in - so closing.
Open:

check evaluateExpression - it seems to be "safe", every non-ascii-character should be converted to GDB's octal (or hex) encoding
check charset conversions via GDB


[Feature Request] Cursor placement within doc comment created by triple-slash

Environment data
latest of everything
extension 1.23.9
Steps to reproduce
Enter triple slash before method to generate xml doc comment.
Expected  behavior
The cursor should be placed within the summary block
Actual behavior
The cursor should be placed after the entire comment
Example:
/// <summary>
/// *                                           <--- cursor should be placed here
/// </summary>
/// <param name="bar"></param>*                 <--- cursor is placed here
public void Foo(string bar) {

This is a known limitation. There's not much we can do about it unless vscode adds a new lsp api that supports this type of edit with position.

So this is different from the snippets stuff, which allows you to choose where to place the cursor?

So this is different from the snippets stuff, which allows you to choose where to place the cursor?

Correct. That's completion, where the user is presented with a list of things to insert. This is automatically inserted, which doesn't have an API for moving the cursor today. We're using on-type formatting to insert the text as a workaround.

Ok I understand now thanks. I suppose you can close this then if there's nothing you can do about it.


New Package

Hello Guys,
for now, this package will have new updates in:
https://pub.dev/packages/plugin_wifi_connect
me and "my team', are working together to continues this project, with permission of weplenish.
thank you and let's do it ;)

Thanks, I added a comment on the readme that this package is deprecated.


keep breadcrumbs as a part of the last input

The last input in Algernon is currently saved.
But when navigating with a right arrow key hit in a class and typing new words only this last input is kept. So when reopening Algernon ~this last input is displayed, but on top level and not in the correct navigation hierarchy~ Algernon jumps back to the first layer results, discarding the last hierarchical navigation.
Acceptance Criteria

[ ] When closing Algernon while in a layer > 1 and then reopening it, restore the last hierachical navigation
[ ] Also restore last query string in this layer
[ ] Make this behavior optional via an entry in the preferences

We concluded that we don't really like this exact behavior. I think that it would be annoying if you always had to leave previously entered dialogs :man_shrugging:
I could imagine that we remember the search string in the nested search box and maybe even where the keyboard focus in the result list was before exiting the launcher.


Add compiled BSD release builds

Right now there are releases available here at Github for Apple, Windows and Linux. Installing on FreeBSD myself with Cargo is working fine. Can you please add compiled releases that are executable on BSD distros like FreeBSD, too?

I tried to cross-compile for FreeBSD on github actions but got a link error.
I'm not sure if it is possible to build a FreeBSD binary on Github actions.

@Gamerboy59 Thank you for the information.
I tried freebsd-vm, and it works quite well. FreeBSD builds are now available!


ImmPtl nether portal does not trigger "Subspace Bubble" advancement?

Will be fixed in the next version (for MC 1.19.3)


404 Not Found

After upgrading from 1.4.3 to 1.4.3 , /swagger-ui.html returns 404 but swagger-doc works
I think https://github.com/Ysj291823/egg-swagger-doc/pull/21 is wrong

You can accept https://github.com/Ysj291823/egg-swagger-doc/pull/23 too

Also we have a warn

2018-11-24 10:36:20,791 WARN 2164 [http_server] A request GET /public/favicon-16x16.png timeout with client (::ffff:<IP_ADDRESS>:51616)

but /public/favicon-16x16.png works

each time I load /public/swagger-ui.html , I see warns
2018-11-24 10:35:48,525 WARN 2164 [http_server] A request `GET /public/favicon-16x16.png` timeout with client (::ffff:<IP_ADDRESS>:51609)
2018-11-24 10:36:20,791 WARN 2164 [http_server] A request `GET /public/favicon-16x16.png` timeout with client (::ffff:<IP_ADDRESS>:51616)
2018-11-24 10:37:50,356 WARN 2164 [http_server] A request `GET /public/swagger-ui.css` timeout with client (::ffff:<IP_ADDRESS>:51641)
2018-11-24 10:37:50,356 WARN 2164 [http_server] A request `GET /public/swagger-ui-bundle.js` timeout with client (::ffff:<IP_ADDRESS>:51642)
2018-11-24 10:37:50,917 WARN 2164 [http_server] A request `GET /swagger-doc` timeout with client (::ffff:<IP_ADDRESS>:51643)


NL: Map/ranking charts should show dates

example:

@beets @chejennifer

If you add '${date}' in the chart title, when the tile is rendered, that string will be replaced with the actual date of the data

Thanks @chejennifer. So what chart types specifically support it?  It seems ranking table might not?

Bar chart doesn't show too?

Any chart that shows a single obs should support it (looks like we left out
quite a few in implementation). Bounce the bug back to us and we can fill
it in.


Update README.md

Hey,
noticed a typo here and thought I'd fix it :) Nice package!
Kind regards,
g

Merged! Thank you :)


Build failure: python310Packages.debugpy

Steps To Reproduce
Steps to reproduce the behavior:

nix build github:nixos/nixpkgs/a2eca347ae1e542af3f818274c38305c1e00604c#python310Packages.debugpy

Build log
paste.sr.ht pastie (warning: veeery long)
Additional context
Seems caused by https://github.com/NixOS/nixpkgs/pull/250298?
Also previously reported (if I'm reading the many thousands of lines of output right) to be another instance of https://github.com/NixOS/nixpkgs/issues/230030.
Breaks: vscode-extensions.ms-python.python.
Notify maintainers
@kira-bruneau
Metadata
-> $ nix run nixpkgs#nix-info -- -m
 - system: `"x86_64-linux"`
 - host os: `Linux 6.4.8, NixOS, 23.11 (Tapir), 23.11.20230808.844ffa8`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.15.1`
 - channels(root): `"nixos"`
 - channels(x10an14): `""`
 - nixpkgs: `/nix/store/qx67jipw01zps1rqgmmpl7as1irff275-source`

This appears to have been fixed somewhere between cf2004afe4d4b95a295c63c911e949e40915eedb and a999c1cc0c9eb2095729d5aa03e0d8f7ed256780

I have no idea how you tested, but after a nix flake update (pulling master branch), I fail to build this same package.
Now with the newer hash: cddebdb60de376c1bdb7a4e6ee3d98355453fe56'
# Just in case you don't test the same way I report, here's a `nix build` that fails on this package...
nix build github:nixos/nixpkgs/cddebdb60de376c1bdb7a4e6ee3d98355453fe56#python310Packages.debugpy

I vote for this issue to be marked as "prematurely-closed", and thus re-opened.

debugpy was blocking my nixos rebuilds through cf2004afe4d4b95a295c63c911e949e40915eedb. Updating to a999c1cc0c9eb2095729d5aa03e0d8f7ed256780 resolved it for me.
That's about all the testing I did at the time, and figured it was good.

Looks like this is related to flaky process test timeouts (which are more likely to fail on less powerful devices). #252070 should fix this!

You can checkout https://nixpk.gs/pr-tracker.html?pr=252070 to see when the fix will be applied to the channel you're using.


Anything I can do to help?

Hi @nodeful !
First I just want to say thank you for creating this app. I use it every day and find it extremely useful.
I'm curious if there's anything I can do to help out with development. I'm a web developer not familiar with macOS programming, but I'm willing to learn.
(Feel free to close this issue, I just wanted to get a message to you somehow and didn't see an email address in your profile.)

Thanks for offering your help Eric!
Unfortunately this is not a project that could benefit a lot from the community in terms of development on the audio processing side. It's very niche technology that a lot of devs would find very frustrating to work with.
Also, I'm planning to make this project commercial at some point, and I don't want to ask people to help me for free just to get all the benefit afterwards.
I am planning to open source the UI side and the website eventually (both written in Angular, but might swap to React at some point) so that the community can make it better for everyone.
Thanks again.

Hey everyone 👋
I will be open sourcing the new version of eqMac, therefore, I am closing this issue and repository as I will be transfering nodeful/eqMac2 repo to bitgapp/eqMac
Please bear with me for the next couple of days as I setup that new repo. The eqMac2 code will be living in the old-eqMac2 branch if anyone is interested in referencing it for whatever reason.
Please try out the new version and report bugs to the new repo.
Thanks for using eqMac.


[#13247] Replace GlobalMarshaller with protobuf based marshaller

Closes #13247
For 16.0.0-SNAPSHOT. Depends upon https://github.com/infinispan/infinispan/pull/13259
Apologies in advance for the large diff :scream:
I suggest that we approach the review of this PR by getting SMEs to review commands/classes associated with their areas. However, before that I think it would be prudent if a couple of volunteers reviewed the changes to the GlobalMarshaller and Protostream constructs to ensure that we're happy with the approach before all uses are reviewed.
I'm creating a draft PR to begin until CI is green, or close to it. Once CI is in a good shape, the reviewing can start in earnest :slightly_smiling_face:
Docs will be handled in a separate PR.
Command IDs
I have left these in place as we currently use them in the code to check command identity. We can't use the ProtoStreamTypeIds here as the id needs to be a byte. It should be possible to replace the use of getId with instanceof, however this may have performance implications. As the diff is already huge, I think we should tackle this in a follow-up PR.
Marshallable* Wrappers
In the org.infinispan.marshall.protostream.impl package there are several different Marshallable* wrapper classes. It's necessary to use these so that we can delegate down to a user marshaller if one is configured. We can't just use a WrappedMessage as it's not aware of the user marshaller and so if a user configures jboss-marshalling or Java Serialization it has no way of marshalling the user classes. This is probably the trickiest part of this conversion.
In general I have tried to use WrappedMessage when polymorphism is required, but we know that a user provided value is never applicable. For all other use-cases I default to the Marshallable* wrappers. My branche(s) have been worked on over multiple years as this feature has come in and out of fashion, so it's possible that there are inconsistencies, please comment if you think you find one!
The MarshallableWrappers* work from a functional perspective, but I'm sure we can make them more efficient and potentially reduce the amount of wrapping required here. Any ideas here are greatly appreciated!
Performance
So far my efforts have been focused on functionality, not performance. The previous marshaller was very efficient in many ways, so we will have to evolve this solution to minimise the performance cost of the migration.
In order for the core tests to consistently pass on my local machine without an OOM i had to increase the default xmx to 1.5Gb.
ProtoStream TypeIds
I have applied a TypeId to nearly all messages that we will be sending over the wire to reduce the payload. For the TypeIds we have a very small range where this TypeId can be a single byte instead of two. I have not tried experimenting with applying the single byte id to more frequently used messages yet, this is a perf optimisation we can make as we go, probably in a follow up PR.
Caching Objects
The old GlobalMarshaller did many tricks to reuse objects. So far I have avoided this for simplicity, but we can/should look more into these aspects once we know what the performance cost is of the conversion in it's current form.

Do you plan to to open a smaller PR into the feature branch to remove the deprecated commands as
   @Deprecated(since = "15.1", forRemoval = true)
   default XSiteBringOnlineCommand buildXSiteBringOnlineCommand(String siteName) {
      return null;
   }

   @Deprecated(since = "15.1", forRemoval = true)
   default XSiteOfflineStatusCommand buildXSiteOfflineStatusCommand(String siteName)  {
      return null;
   }

   @Deprecated(since = "15.1", forRemoval = true)
   default XSiteStatusCommand buildXSiteStatusCommand() {
      return null;
   }

   @Deprecated(since = "15.1", forRemoval = true)
   default XSiteTakeOfflineCommand buildXSiteTakeOfflineCommand(String siteName) {
      return null;
   }

I've noticed some enum values being deprecated too.
Some commits in this PR may be in a separated PR to make this smaller and motivate us to review it :rofl:

Do you plan to to open a smaller PR into the feature branch to remove the deprecated commands as

That's a good idea! My focus has been on getting things functional, but I'm getting tired of debugging tests, so I'll do that now :slightly_smiling_face:


it will be wonderful if TreeView can contain icons

Describe the solution you'd like

: (      I want to delete the title change history!!!


InfiniteSampler: don't pass dataset to super class

Modulus Pull Request
Description
The data_source argument to torch.utils.data.Sampler does nothing, and now triggers a warning if it is not None.
UserWarning: `data_source` argument is not used and will be removed in 2.2.0.You may still have custom implementation that utilizes it.

This change avoid passing it to the super class __init__() function.
Fixes #526
Checklist

[x] I am familiar with the Contributing Guidelines.
[ ] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.
[ ] The CHANGELOG.md is up to date with these changes.
[X] An issue is linked to this pull request.

Dependencies

/blossom-ci

/blossom-ci

/blossom-ci

/blossom-ci

/blossom-ci


[bug] MD5/Hash check for existing files in save folder does not work

I was testing Grabber's detection of existing files and noticed that Grabber, at the present time, appears to only check the filename of files in the user specified save folder to detect if a file already exists and not the MD5/hash of the file.
Problem:
Grabber does not use hash checking like the options --> save menu says it does to detect existing files.
Grabber version: 4.6.0
Procedure to reproduce:

Find a file on a booru, download, and make a copy of it
Delete original file and rename the copy something different
Check hash value, should be the same
Attempt to download the file again from the booru using Grabber, it will download even though the copy has the same hash and should count as an existing file.

If you rename the copy to the same name as the original, Grabber correctly detects that it's a existing file.
OR

Find a file on a booru and download it, copy the filename and then delete it
copy a totally different file to the save directory
rename totally different file to the same as original
open up the image on the booru using Grabber's image viewer and notice that it changed to the totally different file's image rather than the correct one from the booru. Grabber also detects the wrong file as an existing copy of the correct one from the booru.

Implementing proper existing file hash checking would be a great feature to have :D

The fact is that Grabber has some kind of internal map of "filename to MD5". That's why as soon as you move a file, unless you re-run the "MD5 list fixer" tool (which checks all the images in your save folder, then try to get their MD5 either from their filename or using the algorithm, and update the list), it will "break". Each time an image is saved, it saves both its MD5 and location in that list.
The reason for this is that checking all the files in the save folder at every start and running the MD5 algorithm on them would be too intensive I believe, especially for people with millions of images in their collection. If the MD5 was always in the filename, it wouldn't be such a bad thing (as it wouldn't have to use the algorithm to get the hash), but for many people it isn't, or they just don't always use the same filename.
I didn't find a good solution to this problem myself. Except for parsing all the files in your save folder every time the program starts or the save directory changes (which could be resource intensive and slow depending on how many images you have).
Any suggestions?

Ahh, I see. So that's how Grabber's file checking works. That's a bit of an odd way to go about it (defaulting to using filename to MD5, instead of the actual hash first), but it does make sense from a speed perspective. Having Grabber use its own internal list would be the easiest / quickest way to do it.
Thanks for pointing out the MD5 list fixer tool, that's a good solution to the problem and what I'm looking for... except it doesn't appear to be working.
Problem:
MD5 list fixer does not appear to correctly either parse and/or add the MD5 of a file to Grabber's own internal list
Steps to reproduce:

download an image from a booru and place it in your Grabber save directory. Rename it something different.
Run the MD5 list fixer tool with 'force MD5 calculation' option on
Go to a booru and open up the same image in Grabber's viewer, Grabber won't recognize that you already have the file and give you the option to save it again.

Perhaps I'm going about it wrong? Here's the scenario I'm trying to accomplish: I've got some tags that I would like to grab all the images from a booru, but I've already downloaded some of the images and renamed them via other means.

Just a suggestion regarding the storing of MD5 hashes. Instead of storing the MD5 as the MD5 and the path of the saved image, would it be possible/better to store the MD5 and the image URL? This would prevent the image from being downloaded if it had already been. If this route is taken it might also be necessary to include a way to edit the stored MD5's in case an image is deleted however.


[HANDS-ON BUG] Unit8 Part1 (_Box2D)

Describe the bug
I was working on UNIT 8. PART 1 PROXIMAL POLICY OPTIMIZATION (PPO)  Hand on
when running the command:
!python ppo.py --env-id="LunarLander-v2" --repo-id="youraccount/ppo-LunarLander-v5" --total-timesteps=50000
I had the error message
_Box2D.RAND_LIMIT_swigconstant(_Box2D)
AttributeError: module '_Box2D' has no attribute 'RAND_LIMIT_swigconstant'
I replaced this code
!pip install gym==0.21
!pip install imageio-ffmpeg
!pip install huggingface_hub
!pip install box2d
by
!pip install gym==0.22
!pip install imageio-ffmpeg
!pip install huggingface_hub
!pip install gym[box2d]==0.22
and it was solved
Material
I was using Google Colab?
Screenshot

Also had this Issue, the fix also works with the previous version:
!pip install gym==0.21
!pip install gym[box2d]==0.21

We updated the Unit 8 with gym 0.22 I'm closing the issue :hugs:


[Event Request] Event signature change in Codeunit 12 "Gen. Jnl.-Post Line"

Please, consider changing the signature of OnBeforeCode event in Codeunit 12 "Gen. Jnl.-Post Line", from:
    [IntegrationEvent(true, false)]
    local procedure OnBeforeCode(var GenJnlLine: Record "Gen. Journal Line"; CheckLine: Boolean; var IsPosted: Boolean; var GLReg: Record "G/L Register")
    begin
    end;

to:
    [IntegrationEvent(true, false)]
    local procedure OnBeforeCode(var GenJnlLine: Record "Gen. Journal Line"; CheckLine: Boolean; var IsPosted: Boolean; var GLReg: Record "G/L Register"; var GLEntryNo: Integer)
    begin
    end;

and call it accordingly inside the "Code" procedure:
    local procedure "Code"(var GenJnlLine: Record "Gen. Journal Line"; CheckLine: Boolean)
    var
        Balancing: Boolean;
        IsTransactionConsistent: Boolean;
        IsPosted: Boolean;
        IsHandled: Boolean; //RNE-n
    begin
        IsPosted := false;

        **OnBeforeCode(GenJnlLine, CheckLine, IsPosted, GLReg, GLEntryNo);**

        if IsPosted then
            exit;

        GetGLSourceCode();
...
...

Thank you!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: .


react boolean attribute value

When using react component (stateless) without explicit boolean attribute value, gives error like
type P = {
  selected?: boolean,
}

function Box({ selected }: P) {
 //...
}

when uses like
<Box selected /> , it gives error
179:       return (<Box
                   ^ React element `Box`
 60:   selected?: boolean,
                  ^^^^^^^ boolean. This type is incompatible with
182:          selected
                ^^^^^^^^

explicit values works fine
<Box selected={true} />
flow version
Flow, a static type checker for JavaScript, version 0.26.0

Looks like a similar issue with string values
 95:     return (<Layout
                 ^ React element `Layout`
124:   layoutClass?: string,
                     ^^^^^^ undefined. This type is incompatible with
 97:       layoutClass="row" conf={conf}
                       ^^^^^ string

all these errors after updating to latest version which supports stateless function components.

dupe https://github.com/facebook/flow/issues/1878


Dedicated Server & Local Client Patching

Supports both client-side as well as dedicated server-side mod loading

Changed injection point to GameManager.OnEnable
Detects server/client install instance based on file structure and patches accordingly
Looks for default.ini for dedicated server mod install location
Disabled Workshop & UI loading status on server instance (workshop does not load on dedicated servers)
Addon loading and harmony patches tested to be working client-side and server-side
Added and cleaned up some debug information

Should be good to go now!

Looks good to me, thanks! Gotta merge this now.


fix issue 13975 - ICE: dmd crash if -gc and enum member is immutable int

add missing masking of Tty
https://issues.dlang.org/show_bug.cgi?id=13975

Looks good, but needs a test for the test suite.

Looks good here too.

Added test case from the bugzilla report.

Auto-merge toggled on


Delete ImageLoader::COUNT in favour of ImageLoader::SUPPORTED_FORMATS.len().

Objective

This is a followup to #15812.

Solution
I just deleted the COUNT const and replaced it. I didn't realize for loops are not const yet, so improving the other const variables is not obvious.
Note: slice::len has been const since Rust 1.39, so we're not relying on a brand new feature or anything.
Testing

It builds!

@bushrat011899 We could also replace COUNT_FILE_EXTENSIONS with Self::SUPPORTED_FORMATS.len() since today the formats map one-to-one with extensions, but this one feels a lot less bad to me. This just future proofs the code for a tiny cost, and it feels more "algorithm-y" so keeping it is more reliable.


WILDLFY  elastic-apm-agent ERROR Failed to start agent   URI is not hierarchical

WildFly Configuration ::  ver 21.0.2.FINAL
JAVA 1.8
if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
fi

export JAVA_OPTS="$JAVA_OPTS -Delastic.apm.log_level=DEBUG"
export JAVA_OPTS="$JAVA_OPTS -Delastic.apm.service_name=acme -Delastic.apm.server_url=https://localhost:1111/ -Delastic.apm.secret_token="
export JAVA_OPTS="$JAVA_OPTS -Delastic.apm.application_packages=org"

MODULE_OPTS="-javaagent:/apps/wildfly-kie-server/elastic-apm-agent-1.25.0.jar"
18:09:23,637 INFO  [org.jboss.modules] (main) JBoss Modules version 1.10.2.Final
[elastic-apm-agent] ERROR Failed to start agent
java.lang.IllegalArgumentException: URI is not hierarchical
	at java.io.File.<init>(File.java:420)
	at co.elastic.apm.agent.premain.AgentMain.getAgentJarFile(AgentMain.java:167)
	at co.elastic.apm.agent.premain.AgentMain.loadAndInitializeAgent(AgentMain.java:141)
	at co.elastic.apm.agent.premain.AgentMain.init(AgentMain.java:94)
	at co.elastic.apm.agent.premain.AgentMain.premain(AgentMain.java:50)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.jboss.modules.Main.main(Main.java:540)

Thanks for reporting this issue @kunalgithub !
I've managed to reproduce the stack trace that you observed when using MODULE_OPTS to set the agent.
The issue goes away when using directly the JAVA_OPTS instead, this is likely related to the security manager

Thus in your case simply replacing
MODULE_OPTS="-javaagent:/apps/wildfly-kie-server/elastic-apm-agent-1.25.0.jar"

With
JAVA_OPTS="$JAVA_OPTS -javaagent:/apps/wildfly-kie-server/elastic-apm-agent-1.25.0.jar"

Should solve the issue and the agent should start properly.

Here the Wildfly sample configuration is definitely misleading, for example in bin/standalone.conf:
# Uncomment to add a Java agent. If an agent is added to the module options, then jboss-modules.jar is added as an agent
# on the JVM. This allows things like the log manager or security manager to be configured before the agent is invoked.
# MODULE_OPTS="-javaagent:agent.jar"

Can you confirm that it solves your issue ? Thanks !

The underlying issue that triggers this stack trace is that the URL that is returned for the agent jar is jar:file://elastic-apm-agent-1.25.0.jar!/ when we expect file://elastic-apm-agent-1.25.0.jar, which seems an easy thing to fix, but...
When doing so everything else breaks, mostly because ServiceLoader does not seem to behave as expected, so we have further issues like not being able to properly load agent configuration. Since the workaround is quite straightforward and the error is easy to spot, we should try to improve this, at least for now.

@SylvainJuge  fixes the issue !
Thanks !!


cocomac: Watch hashshiny.io

cocomac requests the watch of the watch_keyword hashshiny\.io. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by cigien in Charcoal HQ


apple_dns: Add error code in the DNS resolution details on completion

Commit Message: Renames the resolution details from apple_dns_success to apple_dns_completed with error code since completed is more correct that success given that the callback will still be called when the error code is kDNSServiceErr_NoSuchRecord.
Additional Description: This behavior is also consistent with the implementations of other resolvers.

getaddrinfo
c-ares

Risk Level: low
Testing: unit tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: apple_dns

/assign @alyssawilk


Create e2e-main.yml

This Action solves [FEAT-CI] Add E2E test workflow that runs all the e2e tests available in the repo on the linux platform #316

The new version has been tested on my fork successfully: https://github.com/danivilla9/crc-extension/actions/runs/11233243342


WorkflowPackageManagerImpl requires that the user creating workflow package has read access to /var/workflow/packages

Required Information

[ ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.5.1
[ ] ACS AEM Commons Version: 4.2.0
[ ] Reproducible on Latest? yes

Expected Behavior
If user creating workflow package has read&write permissions for /var/workflow/packages/project1/tenant1/, it should be able to create packages there, even though it doesn't have any permissions for /var/workflow/packages
Actual Behavior
The user with permissions described above can not create packages for /var/workflow/packages/project1/tenant1/, unless it is granted read permissions for /var/workflow/packages/ - check here
Steps to Reproduce
Create user with permissions above and try to create a workflow package using WorkflowPackageManagerImpl#create(ResourceResolver , String, String, String...)
Links
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/workflow/impl/WorkflowPackageManagerImpl.java

Seems to be caused by https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/workflow/impl/WorkflowPackageManagerImpl.java#L265
The detection if the "new" or the "legacy" path is used could be done on startup of the service; of course then you need to restart the service/instance when you migrate the workflows. But if that happens on the startup, you could use a session with elevated privileges to detect that and then the user does not have to have read access to /var/workflow/packages anymore.

Would a

@gicig Can you review the bugfix I provided in #2077 and check if it is working for you?

Fixed via #2078

Sorry for not testing this earlier. Now that I did test it in my project I noticed something strange: acs-commons-workflowpackagemanager-service doesn't have read permissions on /var/workflow/packages. Please check https://drive.google.com/file/d/1q2y92bBgPzuGTZAjeYXPWIGVE6TsSkev/view?usp=sharing
Even though there is an allow permission under the respective rep:policy, useradmin doesn't show it does have read writes. Service resource resolver doesn't have those permissions either - getting resource from /var/workflow/package results in null.
However, when adding the permission through useradmin interface it can get that resource. Even though the rep:policy gets exact same allow permission: https://drive.google.com/open?id=16nJ6lCi7JPyH6hyivdsDLrSVlpWQfEEc

Strange. IIRC I heard that there were issues once when ACLs have been introduced with packages like this, that some internal cache got out of sync; adding a new (random) ACL fixed it.
Can you test if you can reproduce the issue you reported and if adding a random ACL helps?

For acs-commons-workflowpackagemanager-service I added through CRX:

jcr:read (there was a rep:policy with some ACEs) to one path under /content -> no change,
a new ACL (there was no rep:policy at the moment) with jcr:read to one path under /content -> no change,
a crx:replication to /var/workflow/package -> only new privilege in column Replicate is present in useradmin, no change in column Read

You tried my recommendation and added some random ACLs, but there was no effect and the required permissions /var/workflow/package were not there?
In that case it's not this Oak issue, and we have to investigate further.


Getting Uncaught GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: certificate has expired (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

Guzzle version(s) affected: 6.3
PHP version: 7.1.33
cURL version: 7.66.0
Description
When I tried to send a normal request, I am not getting any issue. But when I tried to send a file with form data, I am getting below issue

How to reproduce
Try to upload a file with form data

To possible problems here, but neither are IMHO related to Guzzle:

either the remote servers certificate is expired (can you open that host in the browser without getting a security warning?)
or (maybe) the local certificate chain is outdated.

Hi @mfn,
I don't get any security warning on the server where I post the request.
When I posted the normal form data, I am not getting any issue. But when I post data with files, I am getting this issue. I am looking for solutions... I will post it if I found any.

Maybe your code is using a different host for uploading bigger files? That's not uncommon, some platforms do that.

I am uploading small files. Script used to work for more than 3 months. It stopped suddenly since yesterday and return that error.

@rajkumargohan, do you use any Guzzle certificate-related options in your request? If no, then it's definitely not Guzzle related, and you should start with checking your certificate chain (as @mfn suggested).
I'm closing this one, because it doesn't look like a Guzzle bug. Please ask your question (better with more details) on StackOverflow please, it's a better place for general questions like this.
Closing this one for now. Feel free to reopen with more info (a reproducible example is appreciated, it's really hard to guess something without one).

It stopped suddenly since yesterday and return that error.

That's indicator that the certificate expired.


Add 2 more devices

Added 2 more devices. The strings were sniffed with burp from real devices.

Unfortunately, we need a good reason to update the list of devices. A lot of users use generateDevice with their username as seed. If we will change the list all this users may get problems with their account due to device change.
Thank you for your contribution!


proposal: Variables in Defers should probably have a warning if they overwrite something that the function Returns

Go Programming Experience
Intermediate
Other Languages Experience
Java, C, Python, Rust, C++
Related Idea

[ ] Has this idea, or one like it, been proposed before?
[ ] Does this affect error handling?
[ ] Is this about generics?
[X] Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?
Not as far as I'm aware
Does this affect error handling?
No, It's just a linter change
Is this about generics?
No
Proposal
I propose a small change to add a warning for when a defer overwrites the return of the surrounding function.
This is particularly a problem with errors, as sometimes you use a defer to close a resource, and closing it might have it's own error.
Suppose you had the following CODE

No warnings/errors will show up as the code is syntactically correct.
However, in the case where someOtherFunc() errors out, the returned err could still be nil as the defer overwrites it.
The solution is of course to change a single line in the defer from

to

To shadow the err value.
This mistake is trivial and easy to fix, so I think that this should be brought up to the user.
But as there may be valid cases for this, I think a simple warning is the best solution.
Language Spec Changes
A change in the linter and all related systems
Informal Change
When handling errors and resources in Golang, one should be wary of accidentally overwriting the returned err with an error in the resource handler. This is typically a problem one would encounter when making use of defers to close resources. If one forgets to shadow the err declaration inside their defer, they will unknowingly commit themselves to a hard to diagnose error, where the resource closure error value overwrites the function error.
Is this change backward compatible?
Yes, it's just a warning, no syntax or functionality is changed
Orthogonality: How does this change interact or overlap with existing features?
The goal is to make a minor edge-case slightly easier to find, it shouldn't affect existing features in any way
Would this change make Go easier or harder to learn, and why?
It would make Go easier to learn as it will help one spot a minor error that is otherwise quite diffcult to see.
Cost Description
I imagine that this would be have a minor cost, but I am unfamiliar with such changes
Changes to Go ToolChain
gopls I believe
Performance Costs
I imagine it would be none
Prototype
When an error value is referenced in a defer, a warning should appear if that value is from the scope of the wider function

the go toolchain doesn't do warnings.
proposals to cmd/vet should ideally come sufficient evidence to demonstrate that it is a common error that can be diagnosed with no false positives, perhaps demonstrated that it is popular as a third party linter first.

The ability for a deferred function to change a result variable is an essential feature.  We should not warn about it.  This specifically permits a deferred function to adjust the returned error.


function Phoenix.HTML.Tag.csrf_meta_tag/0 is undefined (module Phoenix.HTML.Tag is not available)

Describe the bug
#AshAdmin
When loading the url set up on the router, the error pop up
To Reproduce
Just followed the readme to implement it on my small project (2 API's)
defmodule MyApp.Accounts.User do
  use Ash.Resource,
    data_layer: AshPostgres.DataLayer,
    extensions: [AshAuthentication, AshAdmin.Resource],
    authorizers: [Ash.Policy.Authorizer]

  admin do
    actor?(true)
  end

And the second one
defmodule MyApp.Items.Item do
  use Ash.Resource,
    data_layer: AshPostgres.DataLayer,
    authorizers: [Ash.Policy.Authorizer],
    extensions: [AshAdmin.Resource]

Expected behavior
To open the admin
Runtime

Elixir version: Elixir 1.15.7 (compiled with Erlang/OTP 26)
Erlang version: 26.1.1
OS: macos-x64
Ash version 2.18
any related extension versions
{:ash, "~> 2.18"},
{:ash_admin, "~> 0.10"},
{:ash_authentication, "~> 3.12"},
{:ash_authentication_phoenix, "~> 1.9"},
{:ash_phoenix, "~> 1.3"},
{:ash_postgres, "~> 1.4"},

Additional context
New to Ash, so I guess im doing something wrong, sry
Router file
  use AshAuthentication.Phoenix.Router
  import AshAdmin.Router

  pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_live_flash
    plug :put_root_layout, {MyAppWeb.Layouts, :root}
    plug :protect_from_forgery
    # plug :put_secure_browser_headers
    plug :put_secure_browser_headers, %{
      "content-security-policy" => "default-src 'nonce-ash_admin-Ed55GFnX' 'self'"
    }

    # Ash AUTHENTICATION
    plug :load_from_session
  end

And the related route
  # ONLY for AshAdmin
  scope "/" do
    pipe_through :browser

    ash_admin("/admin")
  end

  scope "/", MyAppWeb do
    pipe_through :browser

Might be because AshAdmin depends on PhoenixHTML 3.2 and AshPhoenix on PhoenixHTML 4.0.
Im using override on the phoenix_html package to circumvent the dependency error, but this can be some side effect

Yeah, that was it reverting ashphoenix to the latest 1.2 worked. Below is the versions that im using for it to work
{:ash_admin, "~> 0.10"},
{:ash_phoenix, "~> 1.2"},
{:phoenix_html, "~> 3.2"},

Thank you for reporting the issue. Fixed in main, includes a hard requirement on phoenix_html 4.0

Thank you for fixing it so fast :)


obsolete meta-virtualization commit

Build Error
ERROR: mc:x86:lxc-4.0.1-r0 do_fetch: Fetcher failure for URL: 'http://linuxcontainers.org/downloads/lxc-4.0.1.tar.gz'. Unable to fetch URL from any source.

From "https://linuxcontainers.org/lxc/downloads/" the correct path is:
https://linuxcontainers.org/downloads/lxc/lxc-4.0.1.tar.gz

So this is meta-virtualization issue. This was fixed by commit 55b5e02d

So why do you use commit 61f1cd9c, it is obsolete.

5) This is good place for sarcasm: Did someone eve tried to build it? I see more errors, I am sure this fails.
Jan

This is a known issue, lxc downloads was moved soon after the latest release was made.

Hello, I do not want to mess your project issues... but...

This is a known issue, lxc downloads was moved soon after the latest
release was made.

Nice to know, do you have some list of know issues? ...because I can
not see it. There is really more issues in your project.
I just wonder how this happend?
I asked you colleagues for details @.*** It is sad,
no response... (yes I could be more patient but man, it is internet
age - 21 century).
Intel representatives and support are unclear about this yocto-iotg
project. I see effort to make it public but it is obviously heavily
untested.
We are looking forward for public EHL support and  yocto-iotg. Could
you please be so kind and provide us more details about this project,
timeline and what to expect.
I do no want to debug your whole project build... especially when it
is all known.
We would appreciate bit of cooperation. We are ready to test, spread
across our customers. I hope this could also help you in spirit of
opensource community.
Btw. I still can not build the yocto-iotg, no wonder... obsolete poky...
Problem here:
ERROR: ParseError at
/home/honza/yocto-iotg/build/../intel-embedded-system-enabling/meta-virtualization/recipes-extended/libvirt/libvirt-python.inc:1: Could not inherit file
classes/python3targetconfig.bbclass
ls ~/yocto-iotg/intel-embedded-system-enabling/meta/classes/python* -1
meta/classes/python3-dir.bbclass
meta/classes/python3native.bbclass
git log --oneline
b9296bdeaa (HEAD, m/master) wic: Add 512 Byte alignment to --offset
0ff2579712 wic: Fix error message when reporting invalid offset
62a7a10c31 wic: Fix --extra-space argument handling
897aaff896 wic: Add --offset argument for partitions
@.***:~/yocto-iotg/intel-embedded-system-enabling/meta$ git
checkout master
Previous HEAD position was b9296bdeaa wic: Add 512 Byte alignment
to --offset
Branch 'master' set up to track remote branch 'master' from 'origin'.
Switched to a new branch 'master'
@.**:~/yocto-iotg/intel-embedded-system-enabling/meta$ ls
classes/python -1
classes/python3-dir.bbclass
classes/python3native.bbclass
classes/python3targetconfig.bbclass
... also known right? I would really appreciate a) fix in current
project or b)publish know issues and solutions.
Thank you for understanding.
Best Regards,
Jan Janson
SW Engineer (yocto project)
congatec
Tel:
+420 371 121 281
Email:
@.***
Web:
www.congatec.com
congatec s.r.o. | Brojova 16 | 301 00 Plzen | Czech Republic

Auwiesenstraße 5
94469
Deggendorf
Deutschland

Management Board: Jason Carlson, G. Edi, J. Wenzl, T. Schultze
Place of Business: Deggendorf | HRB Deggendorf 5276

Hello, I do not want to mess your project issues... but...
This is a known issue, lxc downloads was moved soon after the latest release was made.
Nice to know, do you have some list of know issues? ...because I can not see it. There is really more issues in your project. I just wonder how this happend? I asked you colleagues for details @.*** It is sad, no response... (yes I could be more patient but man, it is internet age - 21 century). Intel representatives and support are unclear about this yocto-iotg project. I see effort to make it public but it is obviously heavily untested. We are looking forward for public EHL support and yocto-iotg. Could you please be so kind and provide us more details about this project, timeline and what to expect. I do no want to debug your whole project build... especially when it is all known. We would appreciate bit of cooperation. We are ready to test, spread across our customers. I hope this could also help you in spirit of opensource community. Btw. I still can not build the yocto-iotg, no wonder... obsolete poky... Problem here: ERROR: ParseError at /home/honza/yocto-iotg/build/../intel-embedded-system-enabling/meta-virtualization/recipes-extended/libvirt/libvirt-python.inc:1: Could not inherit file classes/python3targetconfig.bbclass ls ~/yocto-iotg/intel-embedded-system-enabling/meta/classes/python* -1 meta/classes/python3-dir.bbclass meta/classes/python3native.bbclass git log --oneline b9296bdeaa (HEAD, m/master) wic: Add 512 Byte alignment to --offset 0ff2579712 wic: Fix error message when reporting invalid offset 62a7a10c31 wic: Fix --extra-space argument handling 897aaff896 wic: Add --offset argument for partitions @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ git checkout master Previous HEAD position was b9296bdeaa wic: Add 512 Byte alignment to --offset Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ ls classes/python* -1 classes/python3-dir.bbclass classes/python3native.bbclass classes/python3targetconfig.bbclass ... also known right? I would really appreciate a) fix in current project or b)publish know issues and solutions. Thank you for understanding. Best Regards, Jan Janson SW Engineer (yocto project) congatec Tel: +420 371 121 281 Email: @.*** Web: www.congatec.com congatec s.r.o. | Brojova 16 | 301 00 Plzen | Czech Republic
…
_________________ Auwiesenstraße 5 94469 Deggendorf Deutschland
_________________ Management Board: Jason Carlson, G. Edi, J. Wenzl, T. Schultze Place of Business: Deggendorf | HRB Deggendorf 5276

Have you submitted your question via IPS?

Hello,
IPS? sure, Case 00597652 for example - where we ask mainline kernel
timeline. No response, just we do not know.
Now it gets worse when yocto iotg is not possible to build. Known
Issues could help.
Best Regards, Jan Janson
Quoting Mok Kim Hoe @.***>:

Hello, I do not want to mess your project issues... but...
This is a known issue, lxc downloads was moved soon after the
latest release was made.
Nice to know, do you have some list of know issues? ...because I
can not see it. There is really more issues in your project. I just
wonder how this happend? I asked you colleagues for details
@.*** It is sad, no response... (yes I could be more patient
but man, it is internet age - 21 century). Intel representatives
and support are unclear about this yocto-iotg project. I see effort
to make it public but it is obviously heavily untested. We are
looking forward for public EHL support and yocto-iotg. Could you
please be so kind and provide us more details about this project,
timeline and what to expect. I do no want to debug your whole
project build... especially when it is all known. We would
appreciate bit of cooperation. We are ready to test, spread across
our customers. I hope this could also help you in spirit of
opensource community. Btw. I still can not build the yocto-iotg, no
wonder... obsolete poky... Problem here: ERROR: ParseError at
/home/honza/yocto-iotg/build/../intel-embedded-system-enabling/meta-virtualization/recipes-extended/libvirt/libvirt-python.inc:1: Could not inherit file classes/python3targetconfig.bbclass ls ~/yocto-iotg/intel-embedded-system-enabling/meta/classes/python* -1 meta/classes/python3-dir.bbclass meta/classes/python3native.bbclass git log --oneline b9296bdeaa (HEAD, m/master) wic: Add 512 Byte alignment to --offset 0ff2579712 wic: Fix error message when reporting invalid offset 62a7a10c31 wic: Fix --extra-space argument handling 897aaff896 wic: Add --offset argument for partitions @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ git checkout master Previous HEAD position was b9296bdeaa wic: Add 512 Byte alignment to --offset Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ ls classes/python* -1 classes/python3-dir.bbclass classes/python3native.bbclass classe
s/python3targetconfig.bbclass ... also known right? I would really appreciate a) fix in current project or b)publish know issues and solutions. Thank you for understanding. Best Regards, Jan Janson SW Engineer (yocto project) congatec Tel: +420 371 121 281 Email: @.*** Web: www.congatec.com congatec s.r.o. | Brojova 16 | 301 00 Plzen | Czech
Republic
…
_________________ Auwiesenstraße 5 94469 Deggendorf Deutschland
_________________ Management Board: Jason Carlson, G. Edi, J.
Wenzl, T. Schultze Place of Business: Deggendorf | HRB Deggendorf
5276

Have you submitted your question via IPS?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/intel/iotg-yocto-ese-manifest/issues/5#issuecomment-820801781

Hello, IPS? sure, Case 00597652 for example - where we ask mainline kernel timeline. No response, just we do not know. Now it gets worse when yocto iotg is not possible to build. Known Issues could help. Best Regards, Jan Janson Quoting Mok Kim Hoe @.***>:

Hello, I do not want to mess your project issues... but... > This is a known issue, lxc downloads was moved soon after the > latest release was made. > Nice to know, do you have some list of know issues? ...because I > can not see it. There is really more issues in your project. I just > wonder how this happend? I asked you colleagues for details > @.*** It is sad, no response... (yes I could be more patient > but man, it is internet age - 21 century). Intel representatives > and support are unclear about this yocto-iotg project. I see effort > to make it public but it is obviously heavily untested. We are > looking forward for public EHL support and yocto-iotg. Could you > please be so kind and provide us more details about this project, > timeline and what to expect. I do no want to debug your whole > project build... especially when it is all known. We would > appreciate bit of cooperation. We are ready to test, spread across > our customers. I hope this could also help you in spirit of > opensource community. Btw. I still can not build the yocto-iotg, no > wonder... obsolete poky... Problem here: ERROR: ParseError at > /home/honza/yocto-iotg/build/../intel-embedded-system-enabling/meta-virtualization/recipes-extended/libvirt/libvirt-python.inc:1: Could not inherit file classes/python3targetconfig.bbclass ls ~/yocto-iotg/intel-embedded-system-enabling/meta/classes/python* -1 meta/classes/python3-dir.bbclass meta/classes/python3native.bbclass git log --oneline b9296bdeaa (HEAD, m/master) wic: Add 512 Byte alignment to --offset 0ff2579712 wic: Fix error message when reporting invalid offset 62a7a10c31 wic: Fix --extra-space argument handling 897aaff896 wic: Add --offset argument for partitions @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ git checkout master Previous HEAD position was b9296bdeaa wic: Add 512 Byte alignment to --offset Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ ls classes/python* -1 classes/python3-dir.bbclass classes/python3native.bbclass classe
s/python3targetconfig.bbclass ... also known right? I would really appreciate a) fix in current project or b)publish know issues and solutions. Thank you for understanding. Best Regards, Jan Janson SW Engineer (yocto project) congatec Tel: +420 371 121 281 Email: @.*** Web: [www.congatec.com](http://www.congatec.com%5D(http://www.congatec.com)) congatec s.r.o. | Brojova 16 | 301 00 Plzen | Czech
…
Republic > … > _________________ Auwiesenstraße 5 94469 Deggendorf Deutschland > _________________ Management Board: Jason Carlson, G. Edi, J. > Wenzl, T. Schultze Place of Business: Deggendorf | HRB Deggendorf > 5276 Have you submitted your question via IPS? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #5 (comment)

Hi, I have checked on the IPS ticket, it was closed. Our tech specialist has replied but I didn't see any comments from your team. We have release note and get started guide for specific platform to help user to build Yocto Project*-based image. If you have further questions regarding the build step from get started guide, please file a new IPS. Thanks

Hello Mr. Hoe,
first of all thank you for open communication, I understand this is
not what you usually do and it is very hard for us to reach right
people on your side.
Regarding timeline and support - I fully understand your position and
IPS approach. Sorry, but now we do support more you now than asking
for support. We debug your work.
There are bugs in the repository not mentioned in the guides or
release notes. You use opensource repository - github. On such
repository is communication about bugs and cooperation expected. I
filled two issues which shows (I can be wrong of course but I see no
other explanation) that you did not test it AND not published known
issues. This leads to reinventing a wheel on our side and debugging
your work. Usually this is OK on github but your approach is
authoritative which means all this work is odd.
Finally I found next (third issue) in your manifest (you are using
obsolete commit again) which prevents to build it. I expected this is
not mistake - especially when you say we know it "it is known issue".
So I expected communication could help.
For a community could be helpful to create other issues on github - by
me. But this shows your mistakes. I see no better way than this way.
Debug your work, fill issues and let others to see it and benefit from
solutions in the section...
This is really what you expect? I do not expect that.
It is about cooperation - I would expect your secret known issues as
temporary solution because IPS will not provide something like this
(or not soon).
Best Regards,
Jan Janson
Quoting Mok Kim Hoe @.***>:

Hello, IPS? sure, Case 00597652 for example - where we ask mainline
kernel timeline. No response, just we do not know. Now it gets
worse when yocto iotg is not possible to build. Known Issues could
help. Best Regards, Jan Janson Quoting Mok Kim Hoe @.***>:

Hello, I do not want to mess your project issues... but... > This
is a known issue, lxc downloads was moved soon after the > latest
release was made. > Nice to know, do you have some list of know
issues? ...because I > can not see it. There is really more issues
in your project. I just > wonder how this happend? I asked you
colleagues for details > @.*** It is sad, no response... (yes
I could be more patient > but man, it is internet age - 21
century). Intel representatives > and support are unclear about
this yocto-iotg project. I see effort > to make it public but it is
obviously heavily untested. We are > looking forward for public EHL
support and yocto-iotg. Could you > please be so kind and provide
us more details about this project, > timeline and what to expect.
I do no want to debug your whole > project build... especially when
it is all known. We would > appreciate bit of cooperation. We are
ready to test, spread across > our customers. I hope this could
also help you in spirit of > opensource community. Btw. I still can
not build the yocto-iotg, no > wonder... obsolete poky... Problem
here: ERROR: ParseError at >
/home/honza/yocto-iotg/build/../intel-embedded-system-enabling/meta-virtualization/recipes-extended/libvirt/libvirt-python.inc:1: Could not inherit file classes/python3targetconfig.bbclass ls ~/yocto-iotg/intel-embedded-system-enabling/meta/classes/python* -1 meta/classes/python3-dir.bbclass meta/classes/python3native.bbclass git log --oneline b9296bdeaa (HEAD, m/master) wic: Add 512 Byte alignment to --offset 0ff2579712 wic: Fix error message when reporting invalid offset 62a7a10c31 wic: Fix --extra-space argument handling 897aaff896 wic: Add --offset argument for partitions @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ git checkout master Previous HEAD position was b9296bdeaa wic: Add 512 Byte alignment to --offset Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' @.:~/yocto-iotg/intel-embedded-system-enabling/meta$ ls classes/python* -1 classes/python3-dir.bbclass classes/python3native.bbclass
classe
s/python3targetconfig.bbclass ... also known right? I would really
appreciate a) fix in current project or b)publish know issues and
solutions. Thank you for understanding. Best Regards, Jan Janson SW
Engineer (yocto project) congatec Tel: +420 371 121 281 Email:
@.*** Web:
[www.congatec.com](http://www.congatec.com%5D(http://www.congatec.com)) congatec s.r.o. | Brojova 16 | 301 00 Plzen |
Czech
…
Republic > … > _________________ Auwiesenstraße 5 94469
Deggendorf Deutschland > _________________ Management Board: Jason
Carlson, G. Edi, J. > Wenzl, T. Schultze Place of Business:
Deggendorf | HRB Deggendorf > 5276 Have you submitted your question
via IPS? -- You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub: #5
(comment)

Hi, I have checked on the IPS ticket, it was closed. Our tech
specialist has replied but I didn't see any comments from your team.
We have release note and get started guide for specific platform to
help user to build Yocto Project*-based image. If you have further
questions regarding the build step from get started guide, please
file a new IPS. Thanks
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/intel/iotg-yocto-ese-manifest/issues/5#issuecomment-820916281

Thank you.


[vcpkg] #11129: Add VCPKG_LINKER_FLAGS_.

Resolves issue #11129.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: psfrolov sign nowYou have signed the CLA already but the status is still pending?

Looks like the x64_uwp regressions are sourceforge servers being down

Looks like the SourceForge bits are fixed by https://github.com/microsoft/vcpkg/pull/13176

Thanks for your contribution!


Jenkins master on Windows?

I was trying the cookbook against a Windows Server which would run the Jenkins master server, and it fails ("Received unknown error code (2224)") when trying to create the new users.
I see in version 2.0.0 that the README.md file removed the lines, so I thought it might work with Windows Server as the master now:
Server (Master) Recipe
* Ubuntu
* RHEL/CentOS

The code looks pretty Linux specific now that I've looked into it.  Should those server requirements go back into the README.md or should it work for Windows?
The error is:
       Recipe: jenkins::_master_war
         * user[jenkins] action create
           - alter user jenkins

           ================================================================================
           Error executing action `create` on resource 'group[jenkins]'
           ================================================================================

           ArgumentError
           -------------
           Received unknown error code (2224)

           Resource Declaration:
           ---------------------
           # In C:\Users\vagrant\AppData\Local\Temp\kitchen\cookbooks\jenkins\recipes\_master_war.rb

            34: group node['jenkins']['master']['group'] do
            35:   members node['jenkins']['master']['user']
            36:   system node['jenkins']['master']['use_system_accounts'] # ~FC048
            37: end
            38:

           Compiled Resource:
           ------------------
           # Declared in C:\Users\vagrant\AppData\Local\Temp\kitchen\cookbooks\jenkins\recipes\_master_war.rb:34:in `from_file'

           group("jenkins") do
             action [:create]
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             group_name "jenkins"
             members ["jenkins"]
             declared_type :group
             cookbook_name :jenkins
             recipe_name "_master_war"
             system true
           end

       Running handlers:
       [2015-12-16T07:39:48-08:00] ERROR: Running exception handlers
       Running handlers complete
       [2015-12-16T07:39:48-08:00] ERROR: Exception handlers complete
       Chef Client failed. 1 resources updated in 10 seconds
       [2015-12-16T07:39:48-08:00] FATAL: Stacktrace dumped to C:/Users/vagrant/AppData/Local/Temp/kitchen/cache/chef-stacktrace.out
       [2015-12-16T07:39:48-08:00] FATAL: ArgumentError: group[jenkins] (jenkins::_master_war line 34) had an error: ArgumentError: Received unknown error code (2224)

Hey,
I get the same error when running this on Windows Server 2012 R2:
group[jenkins] (jenkins::_master_war line 34) had an error: ArgumentError: The account already exists.
Interestingly this is a fresh copy of Windows with nothing on it so shouldn't be any conflicts
I tried installing Java separately first but that didn't make a difference.
The recipe mentions windows
Cheers

Have you found any work around for this?
Even I am facing the same issue.

Hey,
I ended up doing the Jenkins install manually in the end and then using the cookbook for the rest of configuration (like creating users etc):
directory "C:\\Components" do
  action :create
  recursive true
end

remote_file "C:\\Components\\jenkins.zip" do
   source 'http://mirrors.jenkins-ci.org/windows/jenkins-1.658.zip'
end

seven_zip_archive 'seven_zip_source' do
  path      'C:\\Components\\jenkins'
  source    'C:\\Components\\jenkins.zip'
  overwrite true
end

windows_package 'Jenkins' do
  source 'C:\\Components\jenkins\jenkins.msi'
  installer_type :msi
end

However be a little careful as the cookbook doesn't work with Jenkins 2.0 yet
Cheers

Thanks @AdrianMW for the suggestion and sorry for the delayed response.

The existing cookbook can install plugins and create jobs on Windows after you install Jenkins manually.
Again only with Jenkins version 1.6xx at the moment

So I can use resource libraries of supermarket cookbook without any modification. I have used recipe installation, should I change any attribute files?

Closing this one as we only support jenkins slaves for Windows and the questions have been answered. If someone wanted to add testing and support for Windows in other capacities that would be great but it's not currently in the plans.


MOD doesn't work on some combinations of byte or word variables

XC-Basic v3.0.6 (May 25 2022)
dim dividend as word
dim divisor as word

dividend = 70
divisor = 6

print dividend mod divisor

This prints 0.
dim dividend as byte
dim divisor as word

This prints 0 as well.
dim dividend as word
dim divisor as byte

This correctly prints 4.
Other combinations including INT seem to work fine.

Looks like a bug in dividing WORD types, thanks for reporting.


Rewrite recheck package in TypeScript

Fix #145
Changes

Rewrite recheck package in TypeScript
Add node-typecheck job

Codecov Report

Merging #149 (f343f19) into main (31d2c3f) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #149   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           50        50
  Lines         2297      2297
  Branches       110       110
=========================================
  Hits          2297      2297

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 31d2c3f...f343f19. Read the comment docs.


Fixes off centered clear button

Fixes #3974.

@navedqb @martijnrusschen This is a bad solution to solving the clear button problem as it will cause the <input> element used by the datepicker to no longer span the full widget of its container.

@mellis481 I have the same problem when updating.

@martijnrusschen @mellis481 Maybe we can add this as a breaking style change in the release? https://github.com/Hacker0x01/react-datepicker/releases/tag/v4.14.0


[ROX-10236] Link deployments and namespace table

Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
~Evaluated and added CHANGELOG entry if required~
~Determined and documented upgrade steps~
~Documented user facing changes~

If any of these don't apply, please comment below.
Testing Performed

hmm, bad rebase I guess


fix(providers): added auto close for quotes and brackets for tss

Added auto closing for quotes and brackets in the tss file and modified the style auto complete to
behave the same for know tags

Good improvement! Any timeline on shipping this?

@hansemannn, it's pretty much good to go so I imagine we'll ship this mid-late next week


change Node $id type to mixed instead of int (minor)

Encountered this issue when using a string primary key (UUID):
exception: "TypeError"
file: "/var/www/html/vendor/laudis/neo4j-php-client/src/Types/Node.php"
line: 43
message: "Laudis\\Neo4j\\Types\\Node::__construct(): Argument #1 ($id) must be of type int, string given

Hello @Mulkave,
Thank you for your PR. This is a friendly reminder that the mixed keyword was only recently added in PHP 8, but the library also supports 7.4 so we can't use it yet (which is why the CI complains).
Also, the OGM is supposed to be a strict relationship with Neo4J objects, is there any example of non-int ids? In that case we can use mixed or string, otherwise I can take a look at NeoEloquent to get it to work with string IDs

I don't know PHP client details but Neo4j returns ID as integer.
https://neo4j.com/docs/cypher-manual/current/functions/scalar/#functions-id

Maybe one more link to see ID of Node is integer https://www.neo4j.com/docs/bolt/current/packstream/#structure-node

I'm going to close this issue due to inactivity. We will keep the ID as an integer as per documentation in pack stream.


Autotrain for text classification, non specified error

In my Autotrain space (built with Gradio), I've a message "Erreur" when I launch a text classification (e few seconds after the launch). No access to a log explaining the error. No matter if I change the processor, the model, etc. Or if I try with a smaller csv training file.
Any clue ?

please factory rebuild your space. you are using an older version.

Ah OK thanks, I try that.


[Wallet] Make the dismiss Gold Education button work

Description
The dismiss button for the CELO education notification was just logging the analytics event but not actually dismissing the notification.
Tested
On simulator
Related issues

Fixes #4397

Hi @jeanregisser i have verified task using Test flight build v1.1.0 (21)
Test scenarios:
Verify user is able to see the “Valora allows you to buy and sell CELO” in app notification
Verify "Learn More" & "Dismiss" buttons should show on "Valora allows you to buy and sell celo" notification
Verify notification should remove when user tap on Dismiss button
Fixed issues:
#4397
Note: we are blocked to perform this task on android because Not able to download Valora internal build
Please let me know if any thing else i need to verify for this task.
Thanks !


[Question] Application Map in Application Insights shows Question Marks when Using Azure Service Bus Topics

Application Map shows a question mark on the edge when Backend2 and Backend3 pull messages from two different subscriptions of Azure Service Bus Topics
Infrastructure
I have 3 .Net Core 3.1 back-ends: Backend1, Backend2, and Backend3. Backend1 sends messages through Azure Service Bus Topics. Backend2 and Backend3 receive messages from Subscription1 and Subscription2 respectively.
Question
When there is only Backend3 receiving messages, Application Map can form an edge between Backend1 and Backend3 with the correct number of calls.

When Backend2 and Backend3 receive messages, Application Map can form two edges between Backend1 and Backend2 and between Backend1 and Backend3. However, there is a question mark on the edge.

Here are my questions:

What does the question mark on the edge mean?
Why there is no edge between Backend1 and Service Bus?
Why there is a question mark? I have checked the Log Analytics on Application Insights, and the id, operation_Id, and operation_Parent_Id are logged correctly for request and dependencies objects. So, Application Map should display the number of calls on the edge. Is this a bug of Microsoft.Azure.ServiceBus 4.1.2 or Microsoft.ApplicationInsights 2.13.1?

Environment:

Name and version of the Library package used: Microsoft.Azure.ServiceBus 4.1.2 and Microsoft.ApplicationInsights 2.13.1
Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): Windows 10 .Net Core 3.1
IDE and version : Visual Studio 2019 Professional 16.5.2

Solved in https://github.com/microsoft/ApplicationInsights-dotnet/issues/1764


The db does not seem to be populated at launch

Here is my datasources.js:
{
  "db__old": {
    "name": "db",
    "connector": "memory"
  },
  "db": {
    "name"     : "storage",
    "connector": "sqlite",
    "debug"    : false,
    "file_name": "./test.sqlite3"
  }
}

When launching my loopback server, it does not seem like there is any migration happening. Here is the error I am getting:
{ [Error: SQLITE_ERROR: no such table: ACL] errno: 1, code: 'SQLITE_ERROR' }
Unhandled error for request POST /Members: Error: SQLITE_ERROR: no such table: ACL
    at Error (native)

Is there any steps to follow to get this working ?

@cadesalaberry Migration is not invoked automatically by Loopback. See https://loopback.io/doc/en/lb2/Creating-a-database-schema-from-models.html for background. You will need to decide when to trigger a migration.

Thanks,
I am using this connector to run my tests. My problem came from the fact that I was using postgres specific functions in my migration. It was crashing silently.


DataRaceSafety.md Para about ‘non-isolated’ could be clearer.

Hello.
In DataRaceSafety.md under the ‘non-isolated’ section there is a para which I believe is ambiguous and could be made clearer.
Currently it reads:

“Data isolation guarantees that non-isolated entities cannot access the mutable state from other domains. As a result of this, non-isolated functions and variables are always safe to access from any other domain.”

What is ‘the’ mutable state in this para? Does it refer to the mutable state of other domains? Or does it mean the mutable state in itself (the non-isolated domain) accessed from another domain?
If it’s the former (which the second sentence appears to support) then might I suggest that ‘from’ in the first sentence should be replaced with ‘of’. (Or perhaps 'in', or ‘belonging to’)
So the para would read as so:

“Data isolation guarantees that non-isolated entities cannot access the mutable state of other domains. As a result of this, non-isolated functions and variables are always safe to access from any other domain.”

Yeah, I completely agree.


Add RecordMX support in go-client

This will add the CreateMXRecord , GetMXRecord, GetMXRecordByRef and DeleteMXRecord operations to the infoblox-go-client, so that terraform can also support for the MXRecord.

replaced by https://github.com/infobloxopen/infoblox-go-client/pull/203


Plss, update

Not working in Blox Fruits :(

Its patched I think, It doesn't work for other games either

It's not fixed, just the lib site that has a problem.

It's not fixed, just the lib site that has a problem.

It's not fixed, just the lib site that has a problem.

When will it be fixed?

It's not fixed, just the lib site that has a problem.

When will it be fixed?

loadstring(game:HttpGet("https://raw.githubusercontent.com/Yuuki1y/BFaimbot/main/UniversalAim"))()

It's not fixed, just the lib site that has a problem.

When will it be fixed?

loadstring(game:HttpGet("https://raw.githubusercontent.com/Yuuki1y/BFaimbot/main/UniversalAim"))()())

Thank you so much!

It's not fixed, just the lib site that has a problem.

I fixed it

loadstring(game:HttpGet('https://pastebin.com/raw/R0aN6JF7'))()
I also removed watermark

Thank you guys. you are the best <3


fix: modify cluster detail with controlPlaneHealth

Signed-off-by: liuying<EMAIL_ADDRESS>
What type of PR is this?
/kind bug

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

Codecov Report

Merging #228 (814fc15) into master (e9ff4cb) will not change coverage.
The diff coverage is n/a.


EN TN fixes for Issue #166

What does this PR do ?
Fixes the issue where the sentence-final period in sentences ending with domain is incorrectly normalized as part of the domain. The PR also adds a handful of relevant tests and expands on the top-level domain mappings.
To note: A handful of Sparrowhawk tests failed for the current implementation of EN TN.  This fix does not address those failures.
 Use git commit -s to sign.
[ ] Do all unittests finish successfully before sending PR?

pytest or (if your machine does not have GPU) pytest --cpu from the root folder (given you marked your test cases accordingly @pytest.mark.run_only_on('CPU')).
Sparrowhawk tests bash tools/text_processing_deployment/export_grammars.sh --MODE=test ...

[x] If you are adding a new feature: Have you added test cases for both pytest and Sparrowhawk here.
[x] Have you added __init__.py for every folder and subfolder, including data folder which has .TSV files?
[x] Have you followed codeQL results and removed unused variables and imports (report is at the bottom of the PR in github review box) ?
[x] Have you added the correct license header Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. to all newly added Python files?
[x] If you copied nemo_text_processing/text_normalization/en/graph_utils.py your header's second line should be Copyright 2015 and onwards Google, Inc.. See an example here.
[x] Remove import guards (try import: ... except: ...) if not already done.
[x] If you added a new language or a new feature please update the NeMo documentation (lives in different repo).
[x] Have you added your language support to tools/text_processing_deployment/pynini_export.py.

PR Type:

[ ] New Feature
[x] Bugfix
[ ] Documentation
[x] Test

If you haven't finished some of the above items you can still open "Draft" PR.

Jenkins fails bc Sparrowhawk fails on EN to begin with. This was the case before the current fix was implemented.


Celotool command to create flattened artifacts and deploy them to blockscout

also see #1186

closed in favor of #1186


Extrude artifact filtering code from windows installer

The snap package needs to trim down the opam root as well.
The filtering code is a bit tied to nsh files, some refactoring may be needed in order to reuse it.
Something like for f in $files; do cp $f $SNAP_PART_INSTALL/; done is sufficient, but today $files is "implicit" in the .nsh files which are almost lists of files but not entirely

@gares : I must admit I don't understand the description of this issue. Do you plan to do this? Is it easy? Can you point me to the code?

The code for windows selects files from an opam switch to be copied in the installer.
The code for snap removes files which are not needed in order to run coq from the opam switch.
The list of files to keep/remove is the same, and is computed correctly only on windows (the snap script does not even try).

I completely reworked the snap file selection - it is now a positive filtering based of opam show --list-files and identical with MacOS and Windows.


Add support for href and target to IconButton

Button components in material ui will render as a tags when href is supplied. IconButton passes any extra props it receives that could be applied to Button down , so IconButton can accept href and target attributes to create links around the Icons. This PR just adds support for those props.

I will not add these to the generator, as they're not documented in Mui.
I have a helper function for this purpose to use buttons as a link if I have to.
Maybe it helps you solve your specific problem.
let generatePropSpreadCallback = (el: string, addProps: Js.t({..})) =>
  `Callback(
    props =>
      ReactDOMRe.createDOMElementVariadic(
        el,
        ~props=
          Js.Obj.(assign(assign(Js.Obj.empty(), props->Obj.magic), addProps))
          ->Obj.magic,
        [||],
      ),
  );
let generateRouterCallback = to_ =>
  generatePropSpreadCallback(
    "a",
    {
      "href": to_,
      "onClick": event => {
        event->ReactEvent.Mouse.preventDefault;
        ReasonReactRouter.push(to_);
      },
    },
  );


refactoring, type hints, bugfixes

Changes including:

refactoring of code
updates to docstrings
type hints and file py.typed
bugfixes

Thanks for handling the comments and finding several more small items to fix. While reviewing this, I was reminded that we need to increase test coverage. I will begin to write more tests after the next release.
I am going to make a release of polytope; then, the CI builds of tulip should be passing again.


Buttons on the “How it works” screens do not have a role of button [Android]

The “Previous”, “Next“, and “Close” buttons found at the bottom of the “How it works” screens do not convey a role of button. For example, the “Next” button is simply announced as “Next” by TalkBack.

We suspect the close ("X") functionality in the top-left of the screen on the "How it works" screens, is a graphical "X" button, lacking an accessible role or label, which results in TalkBack not conveying any information when it receives focus (nothing is announced).

Remediation Guidance:
We recommend using the Button element for all elements that perform discrete functions, like "Previous", "Next" and "Close".
<Button
   accessibilityLabel="Previous."
   accessibilityRole="button"
/>

Severity: High

@jonnyjames This has now been addressed

I can confirm this issue is fixed. Closing this issue.


pip3 install failing on installing numpy on Santoku distro

I'm trying to install this on my Santoku distro (based off Ubuntu)
It fails when it gets to running setup.py for a dependent package "numpy'
this is preventing PIP from installing the stringsifter package.
$ pip3 install numpy
Downloading/unpacking numpy
Downloading numpy-1.17.2.zip (6.5MB): 6.5MB downloaded
Running setup.py (path:/tmp/pip_build_santoku-bcheeves/numpy/setup.py) egg_info for package numpy
Traceback (most recent call last):
File "", line 17, in
File "/tmp/pip_build_santoku-bcheeves/numpy/setup.py", line 31, in
raise RuntimeError("Python version >= 3.5 required.")
RuntimeError: Python version >= 3.5 required.
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "", line 17, in
File "/tmp/pip_build_santoku-bcheeves/numpy/setup.py", line 31, in
raise RuntimeError("Python version >= 3.5 required.")

RuntimeError: Python version >= 3.5 required.

Cleaning up...
Command python setup.py egg_info failed with error code 1 in /tmp/pip_build_santoku-bcheeves/numpy
Storing debug log for failure in /home/santoku-bcheeves/.pip/pip.log
I plan to lookup who supports numpy and contact them as well. Cause I have python 3.7 installed and the error clearly states that python version >= 3.5 is required :)

some info on my setup:
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.6 LTS"

$ uname -a
Linux santoku-bcheeves-vm 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -l | grep numpy
$

$ dpkg -l | grep python3
ii  libpython3-dev:amd64                    3.4.0-0ubuntu2                                       amd64        header files and a static library for Python (default)
ii  libpython3-stdlib:amd64                 3.4.0-0ubuntu2                                       amd64        interactive high-level object-oriented language (default python3 version)
ii  libpython3.4:amd64                      3.4.3-1ubuntu1~14.04.7                               amd64        Shared Python runtime library (version 3.4)
ii  libpython3.4-dev:amd64                  3.4.3-1ubuntu1~14.04.7                               amd64        Header files and a static library for Python (v3.4)
ii  libpython3.4-minimal:amd64              3.4.3-1ubuntu1~14.04.7                               amd64        Minimal subset of the Python language (version 3.4)
ii  libpython3.4-stdlib:amd64               3.4.3-1ubuntu1~14.04.7                               amd64        Interactive high-level object-oriented language (standard library, version 3.4)
ii  python3                                 3.4.0-0ubuntu2                                       amd64        interactive high-level object-oriented language (default python3 version)
ii  python3-apport                          2.14.1-0ubuntu3.29                                   all          Python 3 library for Apport crash report handling
ii  python3-apt                             <IP_ADDRESS>ubuntu3                                       amd64        Python 3 interface to libapt-pkg
ii  python3-aptdaemon                       1.1.1-1ubuntu5.2                                     all          Python 3 module for the server and client of aptdaemon
ii  python3-aptdaemon.gtk3widgets           1.1.1-1ubuntu5.2                                     all          Python 3 GTK+ 3 widgets to run an aptdaemon client
ii  python3-cairo                           1.10.0+dfsg-3ubuntu2                                 amd64        Python 3 bindings for the Cairo vector graphics library
ii  python3-chardet                         2.2.1-2~ubuntu1                                      all          universal character encoding detector for Python3
ii  python3-colorama                        0.2.5-0.1ubuntu2                                     all          Cross-platform colored terminal text in Python - Python 3.x
ii  python3-commandnotfound                 0.3ubuntu12                                          all          Python 3 bindings for command-not-found.
ii  python3-dbus                            1.2.0-2build2                                        amd64        simple interprocess messaging system (Python 3 interface)
ii  python3-debian                          0.1.21+nmu2ubuntu2                                   all          Python 3 modules to work with Debian-related data formats
ii  python3-defer                           1.0.6-2build1                                        all          Small framework for asynchronous programming (Python 3)
ii  python3-dev                             3.4.0-0ubuntu2                                       amd64        header files and a static library for Python (default)
ii  python3-distlib                         0.1.8-1ubuntu1                                       all          low-level components of python distutils2/packaging
ii  python3-distupgrade                     1:0.220.11                                           all          manage release upgrades
ii  python3-gdbm:amd64                      3.4.3-1~14.04.2                                      amd64        GNU dbm database support for Python 3.x
ii  python3-gi                              3.12.0-1ubuntu1                                      amd64        Python 3 bindings for gobject-introspection libraries
ii  python3-gi-cairo                        3.12.0-1ubuntu1                                      amd64        Python 3 Cairo bindings for the GObject library
ii  python3-html5lib                        0.999-3~ubuntu1                                      all          HTML parser/tokenizer based on the WHATWG HTML5 specification (Python 3)
ii  python3-icu                             1.5-2ubuntu4                                         amd64        Python 3 extension wrapping the ICU C++ API
ii  python3-minimal                         3.4.0-0ubuntu2                                       amd64        minimal subset of the Python language (default python3 version)
ii  python3-packagekit                      0.8.12-1ubuntu5                                      all          PackageKit backend Python bindings
ii  python3-pam                             0.4.2-13.1ubuntu3                                    amd64        Python interface to the PAM library
ii  python3-pip                             1.5.4-1ubuntu4                                       all          alternative Python package installer - Python 3 version of the package
ii  python3-pkg-resources                   3.3-1ubuntu2                                         all          Package Discovery and Resource Access using pkg_resources
ii  python3-problem-report                  2.14.1-0ubuntu3.29                                   all          Python 3 library to handle problem reports
ii  python3-pycurl                          7.19.3-0ubuntu3                                      amd64        Python 3 bindings to libcurl
ii  python3-requests                        2.2.1-1ubuntu0.4                                     all          elegant and simple HTTP library for Python3, built for human beings
ii  python3-setuptools                      3.3-1ubuntu2                                         all          Python3 Distutils Enhancements
ii  python3-six                             1.5.2-1ubuntu1.1                                     all          Python 2 and 3 compatibility library (Python 3 interface)
ii  python3-software-properties             <IP_ADDRESS>                                            all          manage the repositories that you install software from
ii  python3-update-manager                  1:0.196.25                                           all          python 3.x module for update-manager
ii  python3-urllib3                         1.7.1-1ubuntu4.1                                     all          HTTP library with thread-safe connection pooling for Python3
ii  python3-wheel                           0.24.0-1~ubuntu1.1                                   all          built-package format for Python
ii  python3-xkit                            0.5.0ubuntu2                                         all          library for the manipulation of xorg.conf files (Python 3)
ii  python3.4                               3.4.3-1ubuntu1~14.04.7                               amd64        Interactive high-level object-oriented language (version 3.4)
ii  python3.4-dev                           3.4.3-1ubuntu1~14.04.7                               amd64        Header files and a static library for Python (v3.4)
ii  python3.4-minimal                       3.4.3-1ubuntu1~14.04.7                               amd64        Minimal subset of the Python language (version 3.4)

oops, my bad. that is my other box that has Python 3.7.  I can see from the output here that Python 3.4 is installed.