text:
fix #675 ECDSA verification fail when padding is added

The sign method may add 1 or 2 '\0' character padding to ensure the signature TLV is 72 bytes. But the verification function didn't strip the paddings before invoking crypto libraries. It causes failure when the signature is 70 or 71 bytes.

This will soon be a duplicate of a change I am about to push.

#680 should make this unnecessary.

#680 should make this unnecessary.

Nope. It is not the case. When you sign with option to add padding (for compatibility with previous MCUboot), the verify function will fail as it does now if there is padding.
So, I believe this patch is still necessary.

This should be eliminated by merging #680.

Nope. It is not the case. When you sign with option to add padding (for compatibility with previous MCUboot), the verify function will fail as it does now if there is padding.

Don't pass the option. We're trying to get rid of padding, not add more things to work around it being there. I'm not understanding how you could have both an old version of MCUboot and a new version of MCUboot which would have a workaround for this problem?

I'm not going to use this option or argument myself.
Whoever is using an earlier MCUBoot with padding, he/she shall have trouble verify their image on host due to the padding issue. This patch addresses that. He/she will be able to verify on the host machine with this patch.

@d3zd3z @pakls Did a bit of testing here and I can confirm it fixes the issue for versions <= 1.5.0; master does not need this fix anymore, but at the same this won't break master so I'd rather merge it. I am assuming there are no other side-effects, can you think of any @d3zd3z?

We wouldn't want to back port this to old versions of MCUboot. If this was really an issue for older versions of MCUboot, it would be better to backport the patch that removes the requirement for the padding.

I can think of two approaches, either imgtool supporting older versions, or not. In the later case, then we should probably release imgtool with this fix as 1.5.1 or 1.5.0.1, whatever semver dictates!

I don't see any benefit to merging this. This change would allow old versions of mcuboot to work with newer versions of imgtool (that didn't specify this option, the purpose of the option being to support older versions of mcuboot). It offers no benefit to the current version of mcuboot, so there is no reason to put it on master. It might fix an old version of mcuboot, if we were to release that, but why would we then not just apply the same fix that makes master work.
This change adds extra code, and complexity, and doesn't solve a problem in any branch that it would be applied to.
Am I misunderstanding something?

I guess if we wanted to bring something like this in, we should at least compute the length correctly (if the high bit is set, using multiple bytes), or at least detect and fail (an ECDSA signature shouldn't be that long).

Oh, let's just put this in. I now agree with Fabio that it at least shouldn't hurt anything.

authors: d3zd3z pakls utzig

repo: JuulLabs-OSS/mcuboot


text:
Jw

Christopher Columbus pease

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Postcard from Google Earth

#googleearth https://earth.app.goo.gl/?apn=com.google.earth&isi=293622097&ius=googleearth&link=https%3A%2F%2Fearth.google.com%2Fweb%2F%4033.60922908,-84.34857461,283.0551253a,857.03876242d,35y,11.55310988h,0t,0rSkip to content
Skip to table of contents
JW.ORG
Change site language
Log In (opens new window)
Search JW.ORG
SHOW MENU
Ho
10
Hosea10:1-15
Play
Current time 0:00
Loaded: 0%
Progress: 0%
Duration 0:00
Mute
10  “Israel is a degenerate* vine yielding its fruit.aThe more his fruit increases, the more he multiplies his altars;bThe better his land produces, the more splendid his sacred pillars.c 2  Their heart is hypocritical;*Now they will be found guilty.There is one who will break their altars and destroy their pillars. 3  Now they will say, ‘We have no king,d for we have not feared Jehovah.And what could a king do for us?’ 4  They speak empty words, make false oaths,e and make covenants;So the judgment that springs up is like poisonous weeds in the furrows of the field.f 5  The residents of Sa·marʹi·a will fear for the calf idol of Beth-aʹven.gIts people will mourn over it,As will its foreign-god priests who rejoiced over it and its glory,For it will go away from them into exile. 6  It will be brought to As·syrʹi·a as a gift to a great king.hEʹphra·im will be put to shame,And Israel will be ashamed because of the advice it followed.i 7  Sa·marʹi·a and her king will certainly be done away with,*jLike a snapped-off twig on the surface of waters. 8  The high places of Beth-aʹven,k

Skip to content
Skip to table of contents
JW.ORG
Change site language
Log In (opens new window)
Search JW.ORG
SHOW MENU
Ho
10
Hosea10:1-15
Play
Current time 0:00
Loaded: 0%
Progress: 0%
Duration 0:00
Mute
10  “Israel is a degenerate* vine yielding its fruit.aThe more his fruit increases, the more he multiplies his altars;bThe better his land produces, the more splendid his sacred pillars.c 2  Their heart is hypocritical;*Now they will be found guilty.There is one who will break their altars and destroy their pillars. 3  Now they will say, ‘We have no king,d for we have not feared Jehovah.And what could a king do for us?’ 4  They speak empty words, make false oaths,e and make covenants;So the judgment that springs up is like poisonous weeds in the furrows of the field.f 5  The residents of Sa·marʹi·a will fear for the calf idol of Beth-aʹven.gIts people will mourn over it,As will its foreign-god priests who rejoiced over it and its glory,For it will go away from them into exile. 6  It will be brought to As·syrʹi·a as a gift to a great king.hEʹphra·im will be put to shame,And Israel will be ashamed because of the advice it followed.i 7  Sa·marʹi·a and her king will certainly be done away with,*jLike a snapped-off twig on the surface of waters. 8  The high places of Beth-aʹven,k Christopher Columbus pease


text:
setup documentation outdated

Hello, the current documentation is not valid with this plugin.
Specifically, the setup markdown is outdated and has no examples of how to integrate with PermissionEvaluator. (Truthfully I expected this integration to be optional, as the permission plugin is not published and marked experimental)
There doesn't appear to be any documentation for the permission plugin itself either, so there's very little in the way of usable documentation for the announcements plugin at this time.
Please update the documentation with a working example. Thank you!

Done by #78 :)

authors: K-Phoen dmckernanacv

repo: K-Phoen/backstage-plugin-announcements

license: MIT


text:
Duplicate of #2

Duplicate of #2

No comments

repo: KAMLESHINGH/skills-connect-the-dots


text:
0731~0802 . 로그아웃상태 페이지 코드리뷰 결과

통과 UI

유정하- 멤버정보 수정- 로그아웃상태

유정하- 공지사항- 로그아웃 상태

유정하- 비밀번호 변경 - 로그인 상태

(유정하- 비밀번호 변경 -로그인 상태)나중에 수정사항
1) 비밀번호 type을 password로 하기.
1) 비밀번호 비어있는문자열은 일치하지 않게끔하기 (최소 다섯글자이상 입력하도록 한다)

나중에 최은강(@loveAlakazam )이 로그인상태의 틀을 올리면 그때 틀만 변경할 것.

김용연-회원가입- 로그아웃 상태

유정하 - 아이디 찾기- 로그아웃 상태

유정하 - 비밀번호 찾기- 로그아웃 상태

수정 필요 UI

정창섭- 팀페이지- 로그아웃 상태

수정사항

navigation 다시 변경해서 적용하기(navigtion 글씨가 너무 큼)

하민재 - 매치 게시판 - 로그아웃 상태

수정사항

표(테이블)과 버튼2개 부트스트랩 적용하기
버튼 배치 약간 왼쪽으로 이동할 필요있음 (margin이나 padding으로 조절)

김용연 - 로그인 - 로그아웃 상태

수정사항

navigation(default layout) 적용하기
로고(투명배경 png파일) 적용하기.
디자인 변경

[정규동- 마이페이지(일반회원) -내 기본정보- 로그인상태]
(https://github.com/KHAcademyProject2020/Semi-Project/blob/master/02_UI구현/trial/0802/정규동/마이페이지(일반회원)/GB_my_page.html)

수정사항

나중에 최은강(@loveAlakazam )이 로그인상태의 틀을 올리면 그때 틀만 변경할 것.
버튼그룹(내 기본정보/ 내 팀정보/ 매니저 정보/ 메세지) ui 수정(bootstrap적용하기)
"파일선택" 버튼 ui 수정할것 (bootstrap적용하기)
"내 기본정보" 는 색깔 다르게할 것 (색상:  #4ce3da 으로 선택표시할것.)

-정규동- 마이페이지(일반회원) - 내 팀정보 - 로그인상태

수정사항

나중에 최은강(@loveAlakazam )이 로그인 상태의 틀을 올리면 그때 틀만 변경할 것.
"내팀 정보"는 색깔 다르게함 (색상: #4ce3da 으로 선택 표시할 것.)

[8/3]
유정하(@JungHa-Yu ) : 비밀번호 변경 페이지 => 나중에 "로그인 후 레이아웃" 틀 적용
김용연(@kimyongyoen ) : 공지사항 등록페이지(오븐참고) / 로그인 화면 디자인 변경
정규동(@JungKyuDong ) & 정창섭(@werty12123 ) : 버튼그룹 code-pen에 있는 것 적용.
@Haminjae : 매칭사이트 - 매칭등록/ 매칭찾기(modal)적용


text:
请问安装依赖是报了shasum的错是什么原因

可能是vscode的问题 用webstorm  npm i 没有出现此问题

repo: KINGGUOKUN/SystemManagement


text:
🛑 Paardekooper Webshop is down

In e41db31, Paardekooper Webshop (https://www.paardekooper.nl) was down:

HTTP code: 500
Response time: 542 ms

Resolved: Paardekooper Webshop is back up in fb0426b.

repo: KPGhelpdesk/upptime


text:
I encountered a problem running under Windows , help me!

Launching lib\main.dart on Windows in debug mode...
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: ���setlocal [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: "D:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P cmake_install.cmake [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: :cmEnd [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% &
goto :cmDone [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: :cmErrorLevel [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: exit /b %1 [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: :cmDone [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5): error MSB3073: :VCEnd�����˳�������Ϊ 1�� [D:\flutter\audioplayer-main\build\windows\x64\INSTALL.vcxproj]
Building Windows application...                                    31.2s
Error: Build process failed.

if  i dont use metadata_god , it working.

我猜是dll的问题，虽然我还没用过这个插件，但是用过类似的，本质上rust桥的问题，首先你到对应的插件的目录的rust文件是否已经cargo build了？如果没有手动一下，其次在插件的windows目录下的CMakeLists.txt下把最后的set(metadata_god_bundled_libraries
"${LibRoot}/${FLUTTER_TARGET_PLATFORM}/metadata_god.dll"
PARENT_SCOPE
)修改一下路径改为绝对路径，{LibRoot}/${FLUTTER_TARGET_PLATFORM}改成刚才的哪个rust下的文件。
具体路径应该是C:/Users/你的用户名/AppData/Local/Pub/Cache/hosted/pub.dev/metadata_god.对应版本号/rust/target/debug/deps

或者还有一个办法，你把metadata_god.dll直接扔windows目录下好了，这样camkelists就不用修改了。这个windows目录是指你插件的目录不是你项目的目录别弄错了


text:
Create NetKAN for Strategia

New NetKAN for Strategia (released version to be created shortly, meanwhile everything in GitHub is a pre-release).

Looks fine to me. Merging with thanks!

source: gharchive/pull-request

authors: jrossignol politas

repo: KSP-CKAN/NetKAN


text:
Fix RSSExtrasolar installation and details

Found to be broken via Netkan status page. Quite a few changes to the organisation on this one. Enabled staging

Strange error Jenkins is giving, there. Testing locally without RSS dependency to avoid the huge installation overhead.

Looks good to me. Thanks, me from two weeks ago!


text:
Add RO/RP-1 express install netkans

Purpose
This adds "express install" packages (a main package and three choices for graphics level) to allow express installation of RO/RP-1/RSS/etc.
Motivations
RO/RP-1 users often ask for a simple gamedata zip, or "what mods should I install", or the like--to the point of asking which recommended or suggested mods to install, which graphics mods, etc.
Changes
This adds a single express install netkan that depends on the core mods for an RP-1 install, and then depends on an RSSGraphics package. That package is provided by three express packages, each reporting only as a detail level, which depend the various RSS-Textures packages, visual enhancements, and Canaveral terrain/pads necessary for a complete experience.
Metanetkans for easy reference:

https://raw.githubusercontent.com/KSP-RO/RP-1-ExpressInstall/main/RP-1-ExpressInstall.netkan
https://raw.githubusercontent.com/KSP-RO/RP-1-ExpressInstall-Graphics/main/RP-1-ExpressInstall-Graphics-High.netkan
https://raw.githubusercontent.com/KSP-RO/RP-1-ExpressInstall-Graphics/main/RP-1-ExpressInstall-Graphics-Medium.netkan
https://raw.githubusercontent.com/KSP-RO/RP-1-ExpressInstall-Graphics/main/RP-1-ExpressInstall-Graphics-Low.netkan

Issue ref: #8688
Once https://github.com/KSP-CKAN/CKAN/pull/3426 is merged, I will update the local netkans with comments on the graphics choice.

Side note: I just learned NetKAN's inflation error reports the line number and error for an internal JSON representation of the YAML spec. I was at first quite surprised to hear of an error on a line, and with a character, that my file did not include!

I believe this is now correct, though the checks are still failing--this seems to be because the CLI version of CKAN defaults to installing recommended mods, and the main netkan depends on both Ven's New Parts (which recs Ven's Stock Revamp) and on ReStock, and of course VSR and ReStock conflict.
Is there some way to get the checker to run without auto-installing recs?

Side note: I just learned NetKAN's inflation error reports the line number and error for an internal JSON representation of the YAML spec. I was at first quite surprised to hear of an error on a line, and with a character, that my file did not include!

Does it? I don't think that's the case.

I believe this is now correct, though the checks are still failing--this seems to be because the CLI version of CKAN defaults to installing recommended mods, and the main netkan depends on both Ven's New Parts (which recs Ven's Stock Revamp) and on ReStock, and of course VSR and ReStock conflict.
Is there some way to get the checker to run without auto-installing recs?

The checker is highlighting a real problem. These probably shouldn't recommend conflicting modules.

Oops, forgot these were metanetkans, I'll remove those depends, but can you add them to your repo?

We'll need to copy this metadata locally and try installing with GUI to make sure the desired work flow happens. The command line tools are already easier for the RP-0 identifier because they don't interactively prompt for recommends or suggests.

We'll need to copy this metadata locally and try installing with GUI to make sure the desired work flow happens. The command line tools are already easier for the RP-0 identifier because they don't interactively prompt for recommends or suggests.

What I'm trying in case anyone wants to replicate it:

Make a CKAN-meta-rp1express folder somewhere locally (doesn't matter where)
Create RP-1-ExpressInstall-v1.0.ckan, RSSGraphics-ExpressInstall-Low-v1.1.ckan, RSSGraphics-ExpressInstall-High-v1.1.ckan, and RSSGraphics-ExpressInstall-Medium-v1.1.ckan in that folder with their contents as reported by the validation script
Make an archive of that folder: tar czf rp1express.tar.gz CKAN-meta-rp1express
Add the archive as a CKAN repo: ckan repo add rp1express 'file:///full/path/to/rp1express.tar.gz'
Launch GUI, click Refresh to load the new repo, start testing

My compatible versions are 1.10–1.12. Initial change set:

Click Apply, one recommendation appears:

Click Continue, prompted to choose RSS textures, I'll install the 2K package:

Prompted to choose KSPBurst or KSPBurst Lite, I'll pick the non-lite one:

Prompted to choose RSS Graphics, I'll try High to see how it handles a mismatch with the textures:

Install fails:

So it doesn't look like the RSSGraphics-ExpressInstall relationships are working as intended. I was under the impression that that choice was supposed to be presented early and drive most of the rest of it. Probably need to reorder the depends list a bit.

You don't need to use any_of for MechJeb because the dev builds have "provides": "MechJeb2". A simple depends on MechJeb2 will prompt the user to choose if they have the dev repo configured. The any_of just makes the dev build show up twice:

So it doesn't look like the RSSGraphics-ExpressInstall relationships are working as intended. I was under the impression that that choice was supposed to be presented early and drive most of the rest of it. Probably need to reorder the depends list a bit.

Even reordered it prompts me for a RSSTextures resolution later on.  We might have to fix our RelationshipResolver behavior to recalculate it after TooManyModsProvides selections have been made.
Although thinking about it, doesn't it basically restart the installation from start after a selection has been made? So it should already include them for relationship resolution, no? :thinking:

Yeah, this is where it should skip that relationship:
https://github.com/KSP-CKAN/CKAN/blob/a8331592dda3bbfed3e42cdeb5e39f6858d23c5c/Core/Relationships/RelationshipResolver.cs#L381-L385
And this is where that call should already be checking provides:
https://github.com/KSP-CKAN/CKAN/blob/a8331592dda3bbfed3e42cdeb5e39f6858d23c5c/Core/Types/RelationshipDescriptor.cs#L113-L118
So... deeper investigation required.

I wonder if the ordering of the depends inside the low/med/high modules is affecting it. Depending on RSS before the textures might make it pull in RSSTextures before that texture dependency is applied:
      "depends": [
          {
              "name": "RealSolarSystem"
          },
          {
              "name": "RSSTextures4096"
          }
      ],

I believe this is now correct, though the checks are still failing--this seems to be because the CLI version of CKAN defaults to installing recommended mods, and the main netkan depends on both Ven's New Parts (which recs Ven's Stock Revamp) and on ReStock, and of course VSR and ReStock conflict.
Is there some way to get the checker to run without auto-installing recs?

The checker is highlighting a real problem. These probably shouldn't recommend (depend on? not sure yet) conflicting modules.

Perhaps the later bit (where you're attempting to install via GUI) supersedes this but, see here for RP-0's netkan. The issue arises because the express install netkan depends on Restock, but in RP-0.netkan Ven's is the first of the two any_of recs so it is preferentially installed as the CLI blasts through every single mod's recommendeds.

Ven's is the first of the two any_of recs so it is preferentially installed

I'm looking for code that could do this, and I'm not finding it. The resolution of the any_of rec should return both modules, which should then cause the user to be prompted to choose.

@HebaruSan ah then I misunderstood, so the issue is actually worse in CLI than I thought, i.e. it will turn "any_of" into "all_of"? :D

@HebaruSan ah then I misunderstood, so the issue is actually worse in CLI than I thought, i.e. it will turn "any_of" into "all_of"? :D

No, it should be prompting.

Oh, even prompting in CLI in the action? Yeah that does seem weird.
Well, I'm happysad I provided a great way to find client bugs, I guess? :\

( MM dependency added here https://github.com/KSP-RO/RSSGraphics-ExpressInstall/commit/3121b77bf870bc7ddade621d589f96827bae0e5e per note upthread.)

EDIT: Nope, fixing that (putting RSSTextures4096 first) still doesn't suppress the RSSTextures prompt.

I think we're getting tripped up by the relationship resolver working depth-first, essentially. After we pick RSSGraphics-Whatever out of the list, we restart the install with two modules in the change set, RP-1-ExpressInstall and RSSGraphics-Whatever, in that order. RSSGraphics-Whatever is able to satisfy relationships itself (this is why we don't immediately get prompted to make the same choice again), but its dependencies are not looked at yet; rather, the relationship resolver tries to satisfy all of RP-1-ExpressInstall's dependencies (and depends-of-depends) before it looks at any of RSSGraphics-Whatever's depends.
So the current RP-1-ExpressInstall module approach does not seem to be workable. Rather, it seems that the module the user chooses up front needs to have all the "deep depends" in it, so the new modules could be something like:

RP-1-ExpressInstall-Low
RP-1-ExpressInstall-Medium
RP-1-ExpressInstall-High

Each of those modules would have the depends that are currently in the RSSGraphics modules (with the detail-specific depends such as the 4K textures as early as possible in the list), and then the depends that are currently in RP-1-ExpressInstall, later in the list. That way it should be possible to pre-satisfy the RSSTextures and other dependencies early on.
Sorry for all the confusion, but this is getting really deep into the functionality of the relationship resolver, and we usually treat it as a black box not to be touched unless we're really sure what we're doing.

Alternately, if you really want to have a "main" module branching into "detail level" modules, the "main" module could depend only on those "detail level" modules and not on RP-0, RO, RSS, etc.

Ah, I see what you mean. And you answered the question I was in the middle of asking. It is definitely the case that I want a main module, because as I understand the spec, I need to include an installable with each package or it gets treated as a metapackage and (per an issue from lamont a few years back) conflicts won't work.
I'll make that change.

Also, that route is required as well to take advantage of https://github.com/KSP-CKAN/CKAN/pull/3426 - we need a main package to have a depends with a comment.

@HebaruSan this change is now done. 🤞

OK, I'm taking a look now and I restarted the validation script. We might still need to reorder some of the depends, but the overall structure is a better fit to how the relationship resolver works now.

Thanks! And thanks for taking the time to dig through this all (especially the deep rabbit holes of CKAN black magic :D )

Next test. Initial change set is a lot smaller, as expected:

Click Apply. One recommendation again:

Then the detail level prompt comes up:

I'll pick Low. Womp womp, the next prompt is the textures again:

Try putting the 4K/8K/whatever depends as early as possible in the list, before anything that could possibly depend on anything that depends on RSSTextures.

@HebaruSan  Done, and inflator restarted.

I need to take off for an event in a bit, but I'll be back in a few hours. The steps I listed above should still work if you're feeling adventurous.

@DasSkelett, if ckan_meta_tester published its repo tar.gz file as a downloadable artifact, that could make it a lot easier to do client testing like this.

Fixed! Thanks. :)
There's one remaining issue, which is related to KSPBurst. That's that instead of the usual setup, where both the full KSPBurst and the Lite KSPBurst provides something else, which other mods depend on, instead other mods depend directly on KSPBurst, and KSPBurst-Lite provides KSPBurst. I think that means there is no way to force install of the full KSPBust--I switched to depends-ing it directly but, of course, you still get a prompt because two packages provide it (one natively and one via provides).

(To be clear, I mean: I did the local testing. It was a pain to get working since I couldn't get CKAN to accept a file:// path from windows cmd, but using WSL Ubuntu I could get it to do so. I probably just wasn't formatting the string right somehow.)

Actually, given that all the depends got pushed down to the RSSGrarphics stuff, I need to rename all of them because they're not RSSGraphics anymore. Will require renaming the KSP-RO repo, redoing the release, there etc., then updating the PR.

This seems to be fine now (or at any rate is back to the single error on the CLI regarding the multiple recs colliding).

@HebaruSan is it safe to add choice_help_text now, or do I need to wait for the next release? I do not presume it to work until the next release, but if it's safe to add now I will do so now and not have to remember to do so later. :D

@HebaruSan is it safe to add choice_help_text now, or do I need to wait for the next release? I do not presume it to work until the next release, but if it's safe to add now I will do so now and not have to remember to do so later. :D

Yes and no; as @DasSkelett discovered in KSP-CKAN/CKAN#3426, the current client throws an exception if an any_of relationship has any additional properties, so it's not safe to use choice_help_text in an any_of relationship. But if you use it in a normal provides-based relationship, then the current client would safely ignore it. Please don't crash everybody's clients. :grimacing:

Awesome. Yeah, I plan to use it on the initial depends (in the main express-install) for selecting a graphics level, to explain how that works; and then for the KSPBurst depends that each of the sub-mods has (due to that dep being repeated across all 3 submods).
That said that can be done later, so from my perspective I think this is ready to go--the flow is fine from testing locally with a dev repo. Anything else you need from me on this?

I think this is ready to go--the flow is fine from testing locally with a dev repo. Anything else you need from me on this?

I'm planning to get #8704 working and then use it to test the GUI work flow myself again. I'll let you know if we find anything else you need to change.

I think this is ready to go--the flow is fine from testing locally with a dev repo. Anything else you need from me on this?

I'm planning to get #8704 working and then use it to test the GUI work flow myself again. I'll let you know if we find anything else you need to change.

Ok. Cheers!

OK, I tried a low-detail install first. Looks good, I didn't get prompted for anything unnecessary as far as I know. I'm going to try medium and high as well just in case since they're pretty independent now.

There's one remaining issue, which is related to KSPBurst. That's that instead of the usual setup, where both the full KSPBurst and the Lite KSPBurst provides something else, which other mods depend on, instead other mods depend directly on KSPBurst, and KSPBurst-Lite provides KSPBurst. I think that means there is no way to force install of the full KSPBust--I switched to depends-ing it directly but, of course, you still get a prompt because two packages provide it (one natively and one via provides).

We can do something about this (thanks to Scatterer-sunflare-default for reminding me). If KSPBurst provides KSPBurst-Full (or whatever name we choose), then you could depend on KSPBurst-Full to skip the prompt. I'll start a pull request to add that to KSPBurst.

OK, @NathanKell, it's looking pretty good now. I think these changes should eliminate the remaining unnecessary prompts:
Low: Depend on KSPBurst-Full
Med & High: Depend on KSPBurst-Full and Scatterer-sunflare-default

We can do something about this (thanks to Scatterer-sunflare-default for reminding me). If KSPBurst provides KSPBurst-Full (or whatever name we choose), then you could depend on KSPBurst-Full to skip the prompt. I'll start a pull request to add that to KSPBurst.

Oh! Yes, if we're willing to edit other netkans than that's a perfect solution! Sweet.
I made the changes to the remote netkans.

I ran another few tests, and it looks great in GUI now! :+1:
I'm going to dig a bit deeper into the errors that the CLI is spitting out in the validation scripts, since it would be helpful for future maintenance if these netkans could pass those tests. But I won't let that hold it up for too much longer, if it starts to look like no simple resolution is possible then I'll be OK with merging, since GUI users will have an easy time.

Ok! Happy to be a guinea pig. :D That'll give us time to update the wiki
And thanks for all the help as always!
Sent by my thumbs, slowly.
On Mon, Aug 9, 2021, 1:01 PM HebaruSan @.***> wrote:

I ran another few tests, and it looks great in GUI now! 👍
I'm going to dig a bit deeper into the errors that the CLI is spitting out
in the validation scripts, since it would be helpful for future maintenance
if these netkans could pass those tests. But I won't let that hold it up
for too much longer, if it starts to look like no simple resolution is
possible then I'll be OK with merging, since GUI users will have an easy
time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KSP-CKAN/NetKAN/pull/8701#issuecomment-895501315, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHH4IQREVP3XPCNNFZXAH3T4AXZDANCNFSM5BYE5IFA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

CLI findings (using the install-all-recs default behavior of ckan install RP-1-ExpressInstall since that's how most CLI users would probably use it):
$ ckan install RP-1-ExpressInstall
Module RP-1-ExpressInstall-Graphics is provided by more than one available module. Please choose one of the following:
1) RP-1-ExpressInstall-Graphics-High (RP-1 Graphics High Res Express Install)
2) RP-1-ExpressInstall-Graphics-Medium (RP-1 Graphics Medium Res Express Install)
3) RP-1-ExpressInstall-Graphics-Low (RP-1 Graphics Low Res Express Install)
Enter a number between 1 and 3 (To cancel press "c" or "n".):
1
Module MechJeb2 is provided by more than one available module. Please choose one of the following:
1) MechJeb2 (MechJeb 2)
2) MechJeb2-dev (MechJeb 2 - DEV RELEASE)
Enter a number between 1 and 2 (To cancel press "c" or "n".):
2
Module RSSVE-Textures is provided by more than one available module. Please choose one of the following:
1) RSSVE-HR (RSS Visual Enhancements - High Resolution)
2) RSSVE-LR (RSS Visual Enhancements - Low Resolution)
Enter a number between 1 and 2 (To cancel press "c" or "n".):
1
Module RemoteTech OR RealAntennas is provided by more than one available module. Please choose one of the following:
1) RemoteTech (RemoteTech)
2) RealAntennas (Real Antennas)
Enter a number between 1 and 2 (To cancel press "c" or "n".):
2
The following inconsistencies were found:
* VenStockRevamp v1.15.1 conflicts with ReStock 1.4.1
Install canceled. Your files have been returned to their initial state.

ReStock should be before RP-0 to fix the problem with the install failing. The VenStockRevamp recommendation is silently suppressible as long as ReStock is queued up to be installed before that relationship is processed.
High & Medium: The RSSVE depends should be before RealSolarSystem, since the latter recommends RSSVE-Textures and causes a prompt to choose between RSSVE-HR and RSSVE-LR.
(For Low, the user will be prompted to choose to resolve that recommendation, but that can't be helped. I've made a note that the CLI user should be able to cancel out of resolving a recommendation without aborting the whole install, seems like that should be a valid choice for recommendations, so hopefully that will get added at some point.)
RealAntennas should be before RealismOverhaul (and probably whatever is pulling in Kerbalism) so CLI doesn't prompt the user to choose between that and RemoteTech.

Changes made. Thanks!

Well that's exciting!
  Error: 383414 [1] ERROR CKAN.CmdLine.ConsoleUser (null) - Oh no! We tried to overwrite a file owned by another mod!
  Please try a `ckan update` and try again.

  If this problem re-occurs, then it maybe a packaging bug.
  Please report it at:

  https://github.com/KSP-CKAN/NetKAN/issues/new

  Please including the following information in your report:

  File           : GameData/FMRS/FMRS_MM.cfg
  Installing Mod : FMRS v1.1.0.1
  Owning Mod     : FMRSContinued
  CKAN Version   : v1.30.5

I'll take a look at those mods, this may be something we can resolve without changing anything on the RP-1 side. Guessing they should at least conflict with one another...

What the heck is pulling in FMRS? That must be deep in the recs of some rec'd mod. Gonna trawl the action log.
They certainly should conflict, though, yes.

Also probably need to make  KSC Extended incompatible with RSS, I saw that in the install list too. I'll handle that on the RSS side I guess.

Oh, found the issue. Canaveral Pads pulls in Tundra Space Center which recs Tundra Exploration which pulls in Kerbal Reusability Expansion and FMRS.
Well, this makes super clear that our install guide needs to point out that if you run CKAN from the command line, it needs to not pull in the recs of all mods down the chain. There's a ton of not-compatible-with-RP-1 stuff in there.

That does highlight something you may want to change, though. The original FMRS is only compatible from KSP 0.25 to 1.1.99, so we probably don't want to see it here; and it's only being pulled into the installation because the low/med/high modules have no game version compatibility set, whereas the main module has 1.10.0–1.10.1. Could they all share the same $vref?

Oh, yes, they certainly could. I'll make that change.
That's unrelated to the deeper problem, however, which is somewhat particular to RO/RP-1 (as we were discussing on the issue thread), namely that for most Kerbal contexts, mods are compatible unless indicated otherwise, but for RSS/RO/RP-1, for most mods, mods are in compatible unless indicated otherwise. I.e. it makes perfect sense for KK to rec Tundra Space Center, which recs Tundra Exploration, which recs FMRS and a bunch of other things, and it makes perfect sense for KK to rec a bunch of other mods that assume your home planet is Kerbin, and it makes total sense for e.g. Near Future Solar to recommend the rest of Nert's Near Future mods, and so forth--but none of that makes sense in the context of RSS/RO/RP-1.

Could they all share the same $vref?
Uh, maybe I'm misunderstanding the syntax, but how would I go about specifying that? The existing ksp-avc $vref relies on a version supplied in the archive, is there a way to specify a remote version file in the schema? I can find the CKAN schema but I couldn't find a netkan schema doc.

Could they all share the same $vref?

Uh, maybe I'm misunderstanding the syntax, but how would I go about specifying that? The existing ksp-avc $vref relies on a version supplied in the archive, is there a way to specify a remote version file in the schema? I can find the CKAN schema but I couldn't find a netkan schema doc.

You'd have to put the version file in the archive, yes.

Done.

@NathanKell, please don't put RP/RO/RSS-specific stuff on the CKAN user guide. It's fine to clarify how functionality works, but it's not supposed to be a reference for your project.

@HebaruSan  Oh holy crap I didn't realize I was editing it. :( :( Thought I was still on our wiki.
Gonna revert all that.

Yup it looks like it's linking within our wiki because it's in our CKAN101's table of contents, but sure enough it's on yours. Fixing.

There, force-pushed away all my crap. Again, super sorry about that! Thank you for the quick poke!

No worries, thanks for cleaning that up. If you do find things on the CKAN user guide that could be clearer, please do feel free to make edits as long as they are generally applicable to all CKAN users.
I think the validation script has stalled out. I'm going to cancel it and start it again in a little while. Fingers crossed that it should succeed soon!

The script just stopped at exactly the same line of installing Low as last time:
  26.3 MiB/sec - downloading - 724.2 MiB left - 42%

That makes me think we're hitting a resource limit of the workflow containers that we can't bypass. I believe it is actually working based on local testing, which means it's time to merge!

WOOHOO! (although sad robot noises at the beleaguered actionrunner :D )

Per my mistaken PR, in trying the express installer out I still got the prompt to choose KSPBurst version. This is despite KSPBurst-Full being the second line of the depends, here: https://github.com/KSP-RO/RP-1-ExpressInstall-Graphics/blob/main/RP-1-ExpressInstall-Graphics-High.netkan#L15

I think that means you've got some older versions of the metadata active, from before the depends was updated to -Full. Make sure to remove any testing repos and click Refresh to get the latest official metadata.

Nope, that was the first thing I did on launching CKAN. :(

(To double check I closed CKAN, started it again, and refreshed again, same flow.)

Check your repositories.

Only one listed, default, pointing to the official archive.

OK fine, but it still isn't possible to pull in KSPBurst-Lite by depending on KSPBurst-Full. Some other weird thing is happening that you're not hinting at. Is anyone else able to reproduce this?

It is not possible to pull it in from depending on KSPBurst-Full, but RealAntennas depends on just KSPBurst, and we depend on RealAntennas. Which I think would make it the same sort of issue as the RSS-Textures thing?
I asked on the RO discord for anyone available to try installing in a blank KSP 1.10 install, hope I'm just cursed. :D

Ugh, and same with the sunflare. Yep, looks to be exactly the same dependency-resolving issue as before with RSS-Textures, and ordering in the netkan has no effect.

It is not possible to pull it in from depending on KSPBurst-Full, but RealAntennas depends on just KSPBurst, and we depend on RealAntennas. Which I think would make it the same sort of issue as the RSS-Textures thing?

If that was the case, it would happen when I try it.

I have no explanation for why I am enountering that and you are not, unless I somehow have cached metadata that removing the repo it is from did not fix. Gonna clear my CKAN cache.

You really were trying all of this in parallel while we were looking at it, though? At which point did this prompt re-appear for you?

Ah, I think we had a miscommunication then maybe? I had the prompt for KSPBurst, you suggest depending on KSPBurst-Full and moving it above. I did so and you responded that it fixed the GUI here ( https://github.com/KSP-CKAN/NetKAN/pull/8701#issuecomment-895501315 ) , so I did not do a local retest at that point. Once it was merged down and in the main CKAN repo I tested now and got the prompts.

Ok, this just got weirder. DRVeyl reports:
"I was presented with EER and one other as recommended mods... then the textures [which we all expect]... then the TF configs.  Then it started." With this image:

Yeah, that one I saw. I assumed you changed something after my last test.

I do not get that prompt.
Wait, what KSP version were you testing against, and what compat versions? I bet that's it. I am on 1.10 with no compat versions; DRVeyl is on 1.10 but with 1.8 and 1.9 checked.

Yup, TestFlight got moved around in the High metanetkan:

Ugh, that would do it. Thought I discarded that. :(

I do not get that prompt.

That's even more evidence that you're not testing with the current metadata. Maybe try a completely fresh game install?

Will do.

Ok, a completely fresh install and linking that to CKAN fixed the issue, so now I'm only seeing evidence of my other stupidity 😂 (the TestFlight thing) rather than that weird situation with busted metadata. I fixed the local netkans so that should go away as well.

Circling back to say--it's working! Thank you again, from all of us--besides being I think a very positive option for our users, it'll make supporting them way easier on us. CHeers!

That's awesome and great to hear! :tada:
Where are you expecting to see the bulk of your support feeback? The KSP-RO Discord maybe? I can stop by to observe now and then to see how it's going rather than making you serve as a go-between for everything.

Yeah, on the RO discord and sometimes on reddit. The forums are pretty quiet these days. But the issues are often less specific questions from installation (though as I've mentioned we do get the "which of these recommended mods should I really install" :D ), and more we find out a good few messages in that it's actually a broken install in one way or another, not a bug in (whatever submod).
And that's super kind of you! You should know that (AFAIK) next to none of the support load is actually from how to use CKAN--your docs, and our CKAN-101, seems to work pretty well, the only issue there has been walking people through adding the MJ-dev repo (which is why I've been poking at sarbs and lamont to merge dev to release, which they did so yay!). Well, that and the "ok but what should I really pick", so having a one-stop "just click this one thing" answer will be super awesome.

I always forget KSP-CKAN/CKAN#2682 when repository shenanigans happen. :roll_eyes:
I think your CKAN client thought your metadata was up to date, because the Etag was the same as the last time you updated, and so it didn't actually do a refresh. Meanwhile you had removed a testing repo but its metadata was still in your registry, and would remain until the master repo's Etag changed. We don't have a good workaround for this currently; I sometimes edit my <KSP>/CKAN/registry.json file and delete the last_server_etag property to force a refresh.

AHA! Yes that makes perfect sense. I'll keep that in mind in future, it perfectly explains what was going on. The fresh install (or nuking the local CKAN folder, which presumably would have fixed it too but I wasn't taking chances, fresh install it was!) sorts that out by dint of utterly annihilating the json rather than tweaking it. :]

authors: DasSkelett HebaruSan NathanKell


text:
how to get items name

i have got item id  '167481de-4732-b44a-06ad-938625015abe' ,so how can i get this item name?

sorry, it's not a bug,please remove bug label

how did you get that item id? that is difficult to find.

there is my code
import { AuthClient } from '@valapi/auth'
import { Client as WebClient } from '@valapi/web-client'

import { Region } from '@valapi/lib'

const config = {
  region: Region.Default.Asia_Pacific,
  throwOnError: true,
}

const authClient = new AuthClient(config)

const login = async () => {
  await authClient.login('xxx', 'xxx')
}

const main = async () => {
  await login()
  const subject = authClient.getSubject()
  const json = authClient.toJSON()
  const webClient = new WebClient(config)
  webClient.fromJSON(json)
  const data = await webClient.Store.getStorefront(subject)

  console.log(data.data.SkinsPanelLayout.SingleItemOffers[0])
}

main()

here you are, try it first maybe it doesn't work.
const getOffers = await WebClient.Store.getOffers();

async function getOffersOf(ItemsId: string) {
    let Store_Display_Name = "";
    let Store_Display_Icon = "";
    const GetWeaponSkinLevel = await ValorantApiCom.Weapons.getSkinLevels();
    if (!GetWeaponSkinLevel.isRequestError && GetWeaponSkinLevel.data.data) {
        for (const _SkinLevel of GetWeaponSkinLevel.data.data) {
            if (_SkinLevel.uuid === ItemsId) {
                Store_Display_Name = _SkinLevel.displayName;
                Store_Display_Icon = _SkinLevel.displayIcon;

                break;
            }
        }
    }

    return {
        Name: Store_Display_Name,
        Icon: Store_Display_Icon
    };
}

const AllOffers = (await WebClient.Store.getStorefront("subject")).data.SkinsPanelLayout.SingleItemOffers;

for (const ofItemID in AllOffers) {
    const ItemID = AllOffers[ofItemID];
    const _Offer = await getOffersOf(ItemID);
}

here you are, try it first maybe it doesn't work.
const getOffers = await WebClient.Store.getOffers();

async function getOffersOf(ItemsId: string) {
    let Store_Display_Name = "";
    let Store_Display_Icon = "";
    const GetWeaponSkinLevel = await ValorantApiCom.Weapons.getSkinLevels();
    for (const _SkinLevel of GetWeaponSkinLevel.data.data) {
            if (_SkinLevel.uuid === ItemsId) {
                Store_Display_Name = _SkinLevel.displayName;
                Store_Display_Icon = _SkinLevel.displayIcon;

                break;
            }
        }

    return {
        Name: Store_Display_Name,
        Icon: Store_Display_Icon
    };
}

const AllOffers = (await WebClient.Store.getStorefront("subject")).data.SkinsPanelLayout.SingleItemOffers;

for (const ofItemID in AllOffers) {
    const ItemID = AllOffers[ofItemID];
    const _Offer = await getOffersOf(ItemID);
}

it's not work, this request  https://pd.ap.a.pvp.net/store/v2/storefront/subject  400 status

maybe it need auth?

yeah

there is my code now
import { AuthClient } from '@valapi/auth'
import { Client as WebClient } from '@valapi/web-client'
import { Client as ValorantApi } from '@valapi/valorant-api.com'

import { Region } from '@valapi/lib'

const config = {
  region: Region.Default.Asia_Pacific,
  throwOnError: true,
}

const authClient = new AuthClient(config)

const login = async () => {
  await authClient.login('xxx', 'xxx')
}

const main = async () => {
  await login()
  const subject = authClient.getSubject()
  const json = authClient.toJSON()
  const webClient = new WebClient(config)
  const ApiClient = new ValorantApi({
    language: 'zh-CN',
  })
  webClient.fromJSON(json)
  // ApiClient.fromJSON(json)
  const data = await webClient.Store.getStorefront(subject)

  const getOffers = await webClient.Store.getOffers()

  async function getOffersOf(ItemsId: string) {
    let Store_Display_Name = ''
    let Store_Display_Icon = ''
    const GetWeaponSkinLevel = await ApiClient.Weapons.getSkinLevels()
    for (const _SkinLevel of GetWeaponSkinLevel.data.data!) {
      if (_SkinLevel.uuid === ItemsId) {
        Store_Display_Name = _SkinLevel.displayName as string
        Store_Display_Icon = _SkinLevel.displayIcon

        break
      }
    }

    return {
      Name: Store_Display_Name,
      Icon: Store_Display_Icon,
    }
  }

  const AllOffers = (await webClient.Store.getStorefront('subject')).data.SkinsPanelLayout
    .SingleItemOffers

  for (const ofItemID in AllOffers) {
    const ItemID = AllOffers[ofItemID]
    const _Offer = await getOffersOf(ItemID)
    console.log(_Offer)
  }
}

main()

yes like that

@KTNG-3 like this? but it still not working now

@KTNG-3 like this? but it still not working now

import { AuthClient } from "@valapi/auth";
import { Client as WebClient } from "@valapi/web-client";
import { Client as ValorantApi } from "@valapi/valorant-api.com";

import { Region } from "@valapi/lib";

const config = {
    region: Region.Default.Asia_Pacific,
    throwOnError: true
};

const authClient = new AuthClient(config);

const login = async () => {
    await authClient.login("Username", "Password");
};

const main = async () => {
    await login();
    const subject = authClient.getSubject();
    const webClient = WebClient.fromJSON(authClient.toJSON());
    const ApiClient = new ValorantApi({
        language: "zh-CN"
    });

    const data = await webClient.Store.getStorefront(subject);

    // const getOffers = await webClient.Store.getOffers();

    async function getOffersOf(ItemsId: string) {
        let Store_Display_Name = "";
        let Store_Display_Icon = "";
        const GetWeaponSkinLevel = await ApiClient.Weapons.getSkinLevels();
        if (GetWeaponSkinLevel.data.data) {
            for (const _SkinLevel of GetWeaponSkinLevel.data.data) {
                if (_SkinLevel.uuid === ItemsId) {
                    Store_Display_Name = _SkinLevel.displayName as string;
                    Store_Display_Icon = _SkinLevel.displayIcon;

                    break;
                }
            }
        }

        return {
            Name: Store_Display_Name,
            Icon: Store_Display_Icon
        };
    }

    const AllOffers = data.data.SkinsPanelLayout
        .SingleItemOffers;

    for (const ofItemID in AllOffers) {
        const ItemID = AllOffers[ofItemID];
        const _Offer = await getOffersOf(ItemID);

        console.log(_Offer);
    }
};

main();

is it work?

The code works fine, but the information is not the same as my store information

hmm, its seem a problem

I can't tell whether I got the wrong id or the id is wrongly mapped to the displayname

there is my log
89b68205-4fe5-2434-a731-e5a734bd4a7a Undercity Bulldog
5f059d7e-413c-445c-e36f-9a9791fba5b0 Origin Crescent Blade
33d3c906-4305-19cf-8770-1eb5207482cc Rush Judge
1b94d997-4db6-014f-4cb8-c1b4df7d7ebc Smite Judge

so you need "displayname" in your language
or
the item is wrong

it is ok now


text:
ci: add installation of DNN Python Modules

Sorry for breaking the ci with my previous pr #78, this PR fixes it by installing the torch modules before running the tests!

Hallo! I didn't notice early but were these taken out of the requirements.txt only because it takes too much space?

Yes! Our github actions were failing because the runners ran out of memory. Taking the unnecessary dnn-requirements out of the container reduces the container size from 12GB to 3GB

authors: jorendumoulin rgantonio


text:
Generation of redundant bold glyphs?

During clean-up of font generation scripts, it was discovered that extra glyphs like \cdots and \longleftarrow for Main-Bold font were generated.
However, it seems that it's not used in the KaTeX, nor is it possible to access them.
Is it used anywhere? Or, will it be used in the future?
https://github.com/KaTeX/katex-fonts/blob/2b91a1cdd1c9f64c1333470d69dcb5362a215197/src/fonts/OTF/TeX/makeFF#L1899-L2169
CC @kevinbarabash @edemaine

They ought to be possible to access via \boldsymbol
\begin{align*}
\cdots\boldsymbol\cdots
\end{align*}

renders on quicklatex as:

So I think we should keep them, and add access to them.  (Their definition looks like a poor man's bold, though.  Are there really no symbols for them in AMS fonts or something?)

@edemaine I thought it should be in Main-BoldItalic, but now I see symbols are in Main.

authors: edemaine ylemkimon

repo: KaTeX/katex-fonts


text:
Reason for downsampling

Hi Kai, I hope you're doing well -- this is JJ! Congratulations on this great work!
I have a question regarding some parts of the code.
https://github.com/Kai-46/ARF-svox2/blob/22baf6e000e519b21ca26308f8ead1f4d2675cf5/opt/opt_style.py#L618
In this line, I see that you are downsampling the rendered image to half to compute the losses.
But you could instead render an image with a lower resolution, which would be much more memory efficient.
Is there a reason for doing this downsampling? Did you want to do anti-aliasing, perhaps?
Thanks in advance!

Hmm, the downsampling step might be a bit ad-hoc there. If I remembered it correctly, I added the statement there mainly because when I was using the colorful triangle style, I'd like the triangles to be bigger in the stylized 3D appearance. In other words, the relative resolution between the content image and style image fed into the VGG feature extractor for calculating the NNFM loss can affect the style pattern size in the stylized appearance.

Got it -- thank you for the answer!


text:
Issues when downloading the pre-trained checkpoints

Hi,
Thanks for the great work!
For the pre-trained checkpoints here, is it possible to also share them on other platforms such as Google Drive or One Drive for easier access? The Baidu Cloud downloads its own app instead of the actual pre-trained models. Much appreciated!

I would also welcome this if it's possible to host the checkpoints in another location.

Hi, please can you share your pre-trained models on a different location? Thank you for the response.

Hi, please can you share your pre-trained models in a different location? Thank you for the response,I also want this file.

I managed to download the pre-trained models from the author's link and have put them on Google Drive here. Hope this helps whoever finds it difficult to download from Baidu Cloud.


text:
Remove forecast offset, show current reviews in chart

KaniWani
This PR makes 2 changes:

Remove a "bug" in the displayed time of pending reviews (currently, any review with review date at hour H is displayed at hour H+1), shifting all review times to be listed at the start of their hour
Populates the current hour with the user's currrently available reviews

e.g. if it's currently 15:20 and the user has 5 reviews, the "3pm" column will be displayed in the chart with 5 reviews

Issue Ticket
Before opening a pull request, please ensure:

[x] You have followed our contributing guidelines
[x] double-check your branch is based on dev and targets dev
[ ] Pull request has tests (we are going for 100% coverage!)
[x] Code is well-commented, linted and follows project conventions
[x] Documentation is updated (if necessary)
[x] Internal code generators and templates are updated (if necessary)
[x] Description explains the issue/use-case resolved and auto-closes related issues

IMPORTANT: By submitting a patch, you agree to allow the project
owners to license your work under the terms of the MIT License.

Looks good to me 👍

Thanks for this! :tada:

authors: DJTB Travis-Taylor tadgh

repo: Kaniwani/kw-frontend


text:
🛑 IServ (for comparison) is down

In 9c7adbe, IServ (for comparison) ($SECRET_SITE2) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IServ (for comparison) is back up in be9cffc.

repo: KaratekHD/status


text:
Test cases for string range constraints

Add unit tests for the string validation type's minimumValue, maximumValue, minimumValueExclusive and maximumValueExclusive constraints.

Addressed by #236

authors: OldSneerJaw dkichler

repo: Kashoo/synctos

license: mit

license_source: bigquery


text:
Deprecate "%b" or "%O" in access logger

implementation for "%O" is wrong. output_size was never designed to use as response size.
@asvetlov @kxepal

I will change "%O" to use same value as "%b", but we need to decide what to do with it in general

I'm fine with either decision here since I didn't get the idea of these magic tokens at all (:

repo: KeepSafe/aiohttp


text:
Async iterator never returns close message

As you can see here the last message never gets returned because the exception is raised before it has a chance. As a result a developer can't respond to the close message, perhaps cleaning up something or closing another connection.

Try
async for msg in ws:
    processs_msg(msg)
process_closing()

authors: asvetlov mattupstate


text:
Demon Lord support

This pull request to add support to shadow of the demon lord system.

Will be added to next update/patch.

Request your discord tag if you have one

Updated in new version


text:
Define best practices, how to distribute the components

Motivation
Currently, there is no easy way, how to distribute the component as a nuget package.
Because as a part of the DLL is also the site cs files, that should not be there.
Proposed solution
Use the project profile condition to include just the files, that are required to be in the component package.

This issue relates to a solution that has been completely redesigned.
At the moment there is no issue with including unwanted C# files into the component library because the component files are kept separately from the sandbox sample site

repo: Kentico/ems-mvc-component-starter


text:
固定表头两行，表头的border会消失

固定表头两行，表头的border会消失，是transform影响的？

有没有实例代码看下

no reply

authors: KenyeeC deliawen

repo: KenyeeC/eleFixed


text:
Import lombscargle from astropy.stats will be deprecated.

Currently receiving the following warning when using lightkurve.periodogram:

WARNING: AstropyDeprecationWarning: Importing LombScargle from astropy.stats has been deprecated and will no longer be supported in future.
Please import this class from the astropy.timeseries module instead [astropy.stats.lombscargle]

We should probably fix this before it happens :)

Thank you for reporting this @ojhall94!!  I think the best backward-compatible solution involves something like this:
try:
    from astropy.timeseries import LombScargle
except ImportError:
    from astropy.stats import LombScargle

I opened #536 to implement this fix!

I'm closing this issue because I merged #536, however please do re-open if the deprecation warning appears again when using the latest master branch!

repo: KeplerGO/lightkurve


text:
Make the $decalsize from VMTs available to the importer.

Dear Fluffles,
please make the $decalsize from VMTs available to the importer.
Thank you in advance,
your friends from Chisel.

This could be improved by allowing the VMT parser to cache all the tags of each VMT and allow a search function such as VMTParser.TryGetValue(string key, out Type value), which would allow any tag to be searched instead of one specific one.


text:
Embedding changes

Rebasing went belly up, so I just branched off the fmt branch.

This was way easier to review :) My only concern is about the overall added complexity. I'm curious if there would be a way to abstract the individual components of neovide to fit your purposes without making any of the individual components more complex.
One way we could do that would be to abstract the renderer, editor, and bridge components and then have your system implement the windowing logic yourself. Your app would be somewhat more complicated, but it would effectively be pumping the other components itself instead of forcing Neovide's window wrapper into a form that works for it.
I'm not suuuper against adding these changes, just trying to be intentional about where the burden of complexity lies. Any thoughts?

I'll check to see if the send pattern works. For now, I think I'll branch off master and checkout the changes for the bridge. That sound good?

Sounds great to me! Let me know if theres anything I can do to help!

Closing this since it's stale and changes should be made more granular

repo: Kethku/neovide


text:
Add a wiki: Dying Light

Link to origin wiki: https://dyinglight.fandom.com/wiki/Dying_Light_Wiki
Link to destination (independent) wiki: https://dyinglight.wiki.gg/wiki/Dying_Light_Wiki

Thanks for the submission! Added in v3.5.0, now available on both Chrome and Firefox.

authors: Arbiterz KevinPayravi

repo: KevinPayravi/indie-wiki-buddy


text:
MSL: RWBuffer is translated into a texture2d and buffer of atomic_int even though SPIRV-Cross can tell the original type

We're using DXC to turn the following  HLSL:
RWBuffer<uint> g_DispatchIndirectBuffer : register( u0 );

[numthreads(1, 1, 1)]
void CSMain()
{
    uint prevGroupCnt;
    InterlockedAdd(g_DispatchIndirectBuffer[0], 4, prevGroupCnt);
}

Into the following SPIR-V
; SPIR-V
; Version: 1.0
; Generator: Google spiregg; 0
; Bound: 15
; Schema: 0
               OpCapability Shader
               OpCapability SampledBuffer
               OpCapability ImageBuffer
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %CSMain "CSMain"
               OpExecutionMode %CSMain LocalSize 1 1 1
               OpSource HLSL 630
               OpName %type_buffer_image "type.buffer.image"
               OpName %g_DispatchIndirectBuffer "g_DispatchIndirectBuffer"
               OpName %CSMain "CSMain"
               OpDecorate %g_DispatchIndirectBuffer DescriptorSet 0
               OpDecorate %g_DispatchIndirectBuffer Binding 0
       %uint = OpTypeInt 32 0
     %uint_0 = OpConstant %uint 0
     %uint_4 = OpConstant %uint 4
%type_buffer_image = OpTypeImage %uint Buffer 2 0 0 2 R32ui
%_ptr_UniformConstant_type_buffer_image = OpTypePointer UniformConstant %type_buffer_image
       %void = OpTypeVoid
          %9 = OpTypeFunction %void
%_ptr_Image_uint = OpTypePointer Image %uint
     %uint_1 = OpConstant %uint 1
%g_DispatchIndirectBuffer = OpVariable %_ptr_UniformConstant_type_buffer_image UniformConstant
     %CSMain = OpFunction %void None %9
         %12 = OpLabel
         %13 = OpImageTexelPointer %_ptr_Image_uint %g_DispatchIndirectBuffer %uint_0 %uint_0
         %14 = OpAtomicIAdd %uint %13 %uint_1 %uint_0 %uint_4
               OpReturn
               OpFunctionEnd

and then we use SPIRV-Cross to generate MSL:
#pragma clang diagnostic ignored "-Wunused-variable"

#include <metal_stdlib>
#include <simd/simd.h>
#include <metal_atomic>

using namespace metal;

kernel void CSMain(texture2d<uint> g_DispatchIndirectBuffer [[texture(0)]], device atomic_uint* g_DispatchIndirectBuffer_atomic [[buffer(0)]])
{
    uint _14 = atomic_fetch_add_explicit((device atomic_uint*)&g_DispatchIndirectBuffer_atomic[0u], 4u, memory_order_relaxed);
}

However, it creates a redundant texture2d and also changes the name of the buffer resource by appending _atomic at the end. Both of these could be avoided by doing something similar as done for RWStructuredBuffer, which would produce a regular MSL buffer of uint (not atomic_int) and would only cast to atomic where necessary (seen here). If I use SPIRV-Cross to generate HLSL instead of MSL it will produce the RWBuffer as in the original source:
RWBuffer<uint> g_DispatchIndirectBuffer : register(u0, space0);

void comp_main()
{
    uint _14;
    InterlockedAdd(g_DispatchIndirectBuffer[0u], 4u, _14);
}

[numthreads(1, 1, 1)]
void main()
{
    comp_main();
}

so it seems to have enough context to know that the texture won't be needed. This issue does not seem to be specific to DXC as I get the same output with glslang as seen here. Also to the point about context - using SPIRV-Cross reflection on the compiled MSL reports this resource as a SPVC_RESOURCE_TYPE_STORAGE_IMAGE and a dimensionality of buffer
spvc_type imageType = spvc_compiler_get_type_handle(spvCompiler, textureResource.base_type_id);
bool isBuffer = textureDimensionality == SpvDimBuffer;  //This is true for RWBuffers and not for RWTextures

The issue seems vaguely related to https://github.com/KhronosGroup/SPIRV-Cross/issues/950.
However I don't agree with the recommendation that instead of a RWBuffer we should use a RWStructuredBuffer or RWByteAddressBuffer since they produce the desired MSL buffer. This is not an option for us at Unity as our users can write their own shaders and thus the issue can't be fixed at the HLSL level.

This is a typed buffer, and not a raw buffer. MSL does not support typed buffers, and thus is emulated as a texture2D. In SPIR-V a typed buffer is expressed an image with buffer dimension, so this is all expected.
There is an option which enables native texture buffer support (minspec is Metal 2.1): https://github.com/KhronosGroup/SPIRV-Cross/blob/master/spirv_msl.hpp#L311
However, even with that, MSL does not support atomics on typed buffers/images, and thus we get the weirdness you see here. Another contributor added the atomic side buffer as a workaround for this problem.
I'm not sure what I can do, MSL is making it needlessly difficult to implement this as you'd expect.

Ok, I see another avenue here. The OpTypeImage format is declared as R32UI by DXC, that helps a lot. That might be enough to make this work. However, this can only possibly work for texel buffers, not RWTexture, just in case you were expecting that to work as well.

Actually, that won't work either ... Texture buffers in MSL are declared with [[texture()]] and not [[buffer()]]. We'd be silently rewriting the binding type, which breaks API side.

Here's an equivalent:
#version 450
layout(local_size_x = 1) in;

layout(set = 0, binding = 0, r32ui) uniform uimageBuffer uImg;

void main()
{
	imageAtomicAdd(uImg, 1, 2u);
}

With --msl-native-texture-buffer I get:
#pragma clang diagnostic ignored "-Wunused-variable"

#include <metal_stdlib>
#include <simd/simd.h>
#include <metal_atomic>

using namespace metal;

constant uint3 gl_WorkGroupSize [[maybe_unused]] = uint3(1u);

kernel void main0(texture_buffer<uint> uImg [[texture(0)]] /* :( */, device atomic_uint* uImg_atomic [[buffer(0)]])
{
    uint _17 = atomic_fetch_add_explicit((device atomic_uint*)&uImg_atomic[1], 2u, memory_order_relaxed);
}

From my perspective it's not clear why use a texture resource to emulate the buffer in the first place (and this might be lack of experience with Metal on my part), is it just that it's simpler to translate the SPIR-V that way? For more context, a snippet like this, which uses both atomic and regular writes:
RWBuffer<uint> g_DispatchIndirectBuffer : register( u0 );

#pragma never_use_dxc

[numthreads(1, 1, 1)]
void CSMain()
{
    uint prevGroupCnt;
    InterlockedAdd(g_DispatchIndirectBuffer[0], 4, prevGroupCnt);
    g_DispatchIndirectBuffer[5] += 6;
}

When passed through our existing MSL backend (which does HLSL -> [FXC]-> DXBC -> [HLSLcc] -> MSL, so there's no SPIR-V in the middle) produces the following MSL:
generates this MSL:
#include <metal_stdlib>
#include <metal_texture>
using namespace metal;

#if !(__HAVE_FMA__)
#define fma(a,b,c) ((a) * (b) + (c))
#endif

kernel void computeMain(
    device uint *g_DispatchIndirectBuffer [[ buffer(0) ]])
{
    int u_xlati0;
    atomic_fetch_add_explicit(reinterpret_cast<device atomic_uint *>(&g_DispatchIndirectBuffer[0x0]), 0x4u, memory_order::memory_order_relaxed);
    u_xlati0 = int(g_DispatchIndirectBuffer[(0x5)]);
    u_xlati0 = u_xlati0 + 0x6;
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    return;
}

And I'm not clear why couldn't SPIRV-Cross produce the same/similar (at least in the fact that is would use [[buffer ()]] and not [[texture()]]), given that it can tell that the resource was originally a buffer. We'd highly prefer if we didn't have to change our resource types depending on what compiler backend we're using as shaders from both might need be used together.

Because again, it's a typed buffer. That means that pixel conversion is applied to the buffer's contents on every load and store. In Vulkan, you would create a VkBufferView and bind it to a descriptor of type STORAGE_TEXEL_BUFFER. In MoltenVK, this is implemented by creating an MTLTexture on the buffer and passing that to the shader; that's why we need a texture2d or texture_buffer parameter here.

Either HLSLCC or FXC must be applying some very special workaround here, because that MSL code rewrites the fact that the buffer is typed, and I don't see how that would work in a more interesting case. I'm open to adding support for a similar workaround in SPIRV-Cross, but it would have to be opt-in. E.g. something like, typed buffer with R32UI/I format declared will be treated as a plain buffer, but that's a very narrow workaround and not a general purpose solution.

I'm open to adding support for a similar workaround in SPIRV-Cross, but it would have to be opt-in. E.g. something like, typed buffer with R32UI/I format declared will be treated as a plain buffer

Opt-in flag to get that behavior would work just fine for our (Unity) use case.

I'm open to adding support for a similar workaround in SPIRV-Cross, but it would have to be opt-in.

As @aras-p said, having an opt-in would be great for us.

E.g. something like, typed buffer with R32UI/I format declared will be treated as a plain buffer, but that's a very narrow workaround and not a general purpose solution.

You might have already had this in mind, but to be explicit about it - we would need regular Buffer<> types to produce [[buffer()]] bindings as well (not just RWBuffer<> types)

All Buffer<> types? How would that work? Now I'm very confused.
E.g. for a Buffer<float4> type, you could bind almost any pixel format for it in the API, and get implicit format conversion through the descriptor when you load a value. There is no way we can work around that with a plain buffer. Note that we won't know the underlying format in SPIRV-Cross, Buffer<> is a texel buffer.
This workaround can only work iff:

For RWBuffer, shader seems to declare R32UI/R32I types in the SPIR-V. The SPIR-V you posted does this.
The type system could rewrite that type to be a buffer, but it can only meaningfully work for that particular type.

There is also the question of alignment. Texel buffers can support very tight alignment, but buffer objects often don't. Does Metal guarantee support for 4-byte aligned buffer descriptors?

I think all of this is actually for a fairly narrow case of: original HLSL source has a Buffer or RWBuffer declaration of int or uint type, and only ever does reads/writes into it (maybe even "all of the reads/writes are atomic" even).
Yes that's a very "unorthodox" use case, and arguably the original HLSL source should be rewritten to use structured buffer or byte address buffer. But as it is right now, whoever wrote original HLSL ("anyone can write it!" is an issue we have at Unity :)), would be "oh this works everywhere, except on Metal, Metal must be broken!". Or even more likely, not even test on Metal, only to find out their end users or someone entirely else find that it's broken on Metal.
Yes that's a very "non generic" use case, and would be kind of a gross hack. But a flag to SPIRV-Cross that would essentially allow saying "if you find buffer or rwbuffer with 4-byte integer type that only ever does atomic operations on it, please output that as a buffer and not a texture" would probably cover this specific case.

Buffer<> cannot use atomics, it's a read-only type. It should translate perfectly to a texture_buffer. We won't know the underlying format, so I cannot support that anyways. Even if HLSL declares it as Buffer all sampling still happens on float4 types. It will just pick the x component for convenience.
RWBuffer<> with explicitly declared R32UI/R32I types in the SPIR-V is narrow enough that it can be done. However, I assume you do some funky detection logic in engine side to see "This is a typed UAV with R32UI type, let's make this a plain buffer instead of a typed buffer".

However, I assume you do some funky detection logic in engine side to see "This is a typed UAV with R32UI type, let's make this a plain buffer instead of a typed buffer".

Not exactly, our current backend has the limitation that it tries to produce output from DXBC which essentially has very little type information when compared to SPIR-V from what I've seen. This results in minimal type information being left in the output MSL, the buffer is assumed to be packed in memory as it would be in DirectX and casts are performed on every access

There is no way we can work around that with a plain buffer, what kind of code do you emit in hlslcc for that case?

So for a Buffer<float4> from source like this:
Buffer<float4> roBuffer : register( t0 );
RWBuffer<uint> g_DispatchIndirectBuffer : register( u0 );

[numthreads(1, 1, 1)]
void CSMain()
{
    uint prevGroupCnt;
    InterlockedAdd(g_DispatchIndirectBuffer[0], uint(roBuffer[1].y), prevGroupCnt);
    g_DispatchIndirectBuffer[5] += 6;
}

it would still generate a buffer of uint and output the following:
#include <metal_stdlib>
#include <metal_texture>
using namespace metal;

#if !(__HAVE_FMA__)
#define fma(a,b,c) ((a) * (b) + (c))
#endif

kernel void computeMain(
    const device uint *roBuffer [[ buffer(1) ]],
    device uint *g_DispatchIndirectBuffer [[ buffer(0) ]])
{
    float u_xlat0;
    int u_xlati0;
    uint u_xlatu0;
    u_xlat0 = as_type<float>(roBuffer[(0x1)]);
    u_xlatu0 = uint(u_xlat0);
    atomic_fetch_add_explicit(reinterpret_cast<device atomic_uint *>(&g_DispatchIndirectBuffer[0x0]), u_xlatu0, memory_order::memory_order_relaxed);
    u_xlati0 = int(g_DispatchIndirectBuffer[(0x5)]);
    u_xlati0 = u_xlati0 + 0x6;
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    g_DispatchIndirectBuffer[(0x5)] = uint(u_xlati0);
    return;
}

So that code translates roBuffer[1].y to as_type<float>(roBuffer[(0x1)]). How can that be correct? It does not take into account texel strides either, I'm somewhat puzzled by this.

Yes, I just noticed that myself, so as @aras-p  said we're most likely only meaningfully using Buffer in our code and Buffer seems like an untested case, just tried non zero offset with a Buffer and it's correct

So in that case, a workaround would look something like:

Any Buffer<> / UNIFORM_TEXEL_BUFFER or RWBuffer<> / STORAGE_TEXEL_BUFFER, no matter what is treated as being a scalar 32-bit value. Client side guarantees that the only texel formats will only be 32-bit scalar.
Any access to such a resource goes through a plain buffer pointer.
Certain features like GetResourceDimensions() will be unavailable (it's just a pointer).
Robustness is out the window (no resource size information, again, it's just a pointer).

It is still unclear to me why you would need to emit pointer types for Buffer though. There are several mechanisms you could use in Metal to implement this "correctly". The only real problem case I can see where this workaround would have made sense is RWBuffer with atomics, since Metal has no reasonable way to express this without ugly hackery.

Yeah that sounds like it would work for our case.
But all the discussion above has good points, our own particular (very occasional) usage of Buffer<uint> / RWBuffer<uint> in HLSL code is very much "unusual" and I'm actually surprised that we even use it in that way. Apparently someone did, and it has happened to (by accident) work with the previous compiler toolchain, but now with a "more proper" DXC + SPIRV-Cross one it has uncovered that our usage was kinda wrong. Maybe not worth doing this workaround, and instead we'll try to fix all the offending HLSL source code instead.

That would be much appreciated. Working around this in SPIRV-Cross is a last resort and I really don't want to do it, especially if it starts to affect all typed buffers like this. A SPIR-V -> SPIR-V transformation is more appropriate if possible, but the best fix is to fix the invalid shader code of course.

authors: Dredhog HansKristian-Work aras-p cdavis5e

repo: KhronosGroup/SPIRV-Cross


text:
GN: Fix build for debuginfo codegen.

Fixes #4535
@alan-baker PTAL
@jonahryandavis FYI

@alan-baker can we merge this in to unblock the roll into ANGLE/Chrome?

repo: KhronosGroup/SPIRV-Tools


text:
CPack usage

How do you think about to reuse the software "CPack"?

I'm not aware that anyone currently needs or intends to distribute binary-only releases of CTS. In fact, the official conformance procedure requires building from source.

authors: elfring phaulos

repo: KhronosGroup/Vulkan-CTS


text:
Added projects from issues, 2021-05-27

Fixes https://github.com/KhronosGroup/glTF-Project-Explorer/issues/99 : "New Project: Poimandres Market"
Fixes https://github.com/KhronosGroup/glTF-Project-Explorer/issues/100 : "New Project: Nomad Sculpt"
Fixes https://github.com/KhronosGroup/glTF-Project-Explorer/issues/101 : "New Project: 3D Comic toolkit for Blender"
Fixes https://github.com/KhronosGroup/glTF-Project-Explorer/issues/102 : "New Project: ReadyPlayerMe"
Fixes https://github.com/KhronosGroup/glTF-Project-Explorer/issues/103 : "New Project: V-Ray glTF viewer"

🙏 🙏 🙏

authors: javagl pjcozzi

repo: KhronosGroup/glTF-Project-Explorer


text:
docker pull not working

The first docker command is not working, this command used: docker pull kiirocoin/kiirocoind
Using default tag: latest
Error response from daemon: pull access denied for kiirocoin/kiirocoind, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Can this be fixed?

hello
sorry my friend we didnt pull image yet, will be done soon
can you use normal installation?

Will do the normal installation thanks

authors: Kiirocoin niels-sys

repo: Kiirocoin/kiiro


text:
Restore custom cover

The blog admin can use a custom cover (the image uploaded by the user in the blog admin area).

Awesome!
Check this. Can you adapt it for use the Admin background but apply the linear gradient filter?

I changed only the background-image (not the background)... So it should not change others already defined css styles... but I'm not familiar wit sass, or css filters..  you should check it...

The problem is that you use sass colors variables inside the linear gradient filter... while my code simply replaces your backgroud image with the one coming from the ghost admin area.. It think it is better to use the custom image without any other css filter... This fits exactly my needs for my blog..

I was working on this yesterday and and nothing has changed. background URL is in the ghost template and colors variables is in sass. The solution to combine both values is too complex, doing black magic with javascript.
Change your background from assets/img/cover.jpg. I know that is a little creepy solution, but is the most easy and clear solution.

repo: Kikobeats/uno-zen


text:
Moving carrier battle group

Today the carrier battle group (carrier + lha + destroiers and cruisers) is static. Is it possible to make then navigate forward? This would add a lot of realism to naval ops.

Moving carrier is planned in the future.

authors: felipejacobucci rhyver

repo: Kilcekru/dcc


text:
Erro no Windows 11 ou outra coisa...

Me ajuda ai pf

obs: ja reinstalei o canvas e o npm nada funcionou

#215

repo: KillovSky/iris


text:
Scripts on Mac

Make sure we've got two working scripts for Mac users (both Docker Toolbox setups and Docker for Mac setups). With Docker for Mac, this probably involves creating an alias for the loopback adapter because of limitations that currently exist in Docker for Mac.

@jeffreyscarpenter @SonicDMG You guys have already kinda tested out the Mac scripts now that you have KillrVideo running on your machines. One thing I'm kinda worried about is that the IP address that create-environment.sh uses to create the loopback adapter is hardcoded. See here:
https://github.com/KillrVideo/killrvideo-docker-common/blob/master/create-environment.sh#L17
I'm afraid is someone already is using that IP (maybe it's pointing at another NIC on their machine, for example) then we might get weird behavior or traffic being sent to the wrong place. I wonder if there is a way to make it more resilient and have it pick an local IP that definitely isn't being used?

Hrmmm...its been a while since I even looked at that.  interestingly as you
point that out I do remember having some weirdness on my end with loopback
when I was originally setting things up, however, just too far away for me
to remember.  I hear you though, sounds like something we need to improve.
Jeff, you have any issues on your end?
On Wed, Apr 19, 2017 at 6:46 PM, Luke Tillman notifications@github.com
wrote:

@jeffreyscarpenter https://github.com/jeffreyscarpenter @SonicDMG
https://github.com/SonicDMG You guys have already kinda tested out the
Mac scripts now that you have KillrVideo running on your machines. One
thing I'm kinda worried about is that the IP address that
create-environment.sh uses to create the loopback adapter is hardcoded.
See here:
https://github.com/KillrVideo/killrvideo-docker-common/blob/
master/create-environment.sh#L17
I'm afraid is someone already is using that IP (maybe it's pointing at
another NIC on their machine, for example) then we might get weird behavior
or traffic being sent to the wrong place. I wonder if there is a way to
make it more resilient and have it pick an local IP that definitely isn't
being used?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KillrVideo/killrvideo-docker-common/issues/1#issuecomment-295478556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWQ8HRxRQdHNfJwW5fUnPz-sns2f_uA4ks5rxo67gaJpZM4J6s_3
.

I brought it up because Joe Chu was giving the Node.js version a shot yesterday and he was seeing some weird behavior. It turned out that he was still trying to use Docker Toolbox instead of Docker for Mac. Which, as a side note, I'm not sure if we need to support but the current script for Mac doesn't. See:
https://github.com/KillrVideo/killrvideo-docker-common/blob/master/get-environment.sh#L9

Haven't they pretty much done away with the toolbox on Mac now?  Maybe we
should point folks away from using it at all.
On Thu, Apr 20, 2017 at 9:54 AM, Luke Tillman notifications@github.com
wrote:

I brought it up because Joe Chu was giving the Node.js version a shot
yesterday and he was seeing some weird behavior. It turned out that he was
still trying to use Docker Toolbox instead of Docker for Mac. Which, as a
side note, I'm not sure if we need to support but the current script for
Mac doesn't. See:
https://github.com/KillrVideo/killrvideo-docker-common/blob/
master/get-environment.sh#L9
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KillrVideo/killrvideo-docker-common/issues/1#issuecomment-295746307,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWQ8Hcfxc8C5i64bxBwEqu4VEe-tKbK5ks5rx2OIgaJpZM4J6s_3
.

For Mac, I'm not sure TBH. The reason I included it on Windows is because Docker for Windows only works on Windows 10 Professional editions (Docker for Windows uses Hyper-V which is not included on "Home" versions of Windows 10 or older versions of Windows like 8). I'm not sure if there is a similar situation for Macs where a bunch of users might be on a version of the OS that isn't able to run Docker for Mac.
Regardless of Toolbox support though, I do think the hardcoded IP is definitely a "brittle" part of the experience that could cause some headaches down the road.

authors: LukeTillman SonicDMG

repo: KillrVideo/killrvideo-docker-common


text:
New function: TCP connection monitoring

Describe the solution you'd like
Monitor whether the TCP connection is successful.
Monitor the cause of TCP connection failure.
Monitoring TCP connection time.
Describe alternatives you've considered
I will provide two kinds of events at the bottom:
First, TCP_ Connect. The occurrence of this event indicates that a TCP connection has occurred. It can be used together with syscall-connect to determine the starting point of analysis. At the same time, the event will also give some reasons for the failure of the company
Second, TCP_ finish_ Connect. This event only appears when the connection is successfully established. You can judge whether the connection is successful or not through this event
Additional context
If anyone is interested, you can supplement the code in the collector and grafana-dashboard

This is to solve a scene in the capsule

I tried to code for it. I found that it is impossible to judge whether the connection is successful only from the client, because the client defines that it can send data by completing the second handshake. The connection success can be judged only from the server, but the connection time cannot be calculated. Therefore, the feasibility of this function is in question

If the ACK transmission of the third handshake fails, resulting in the server's delay in receiving the ACK, the resource will be released. At this time, the client thinks that it has been connected, it will send data to the server. Because the server does not receive the third handshake, it will respond to the client with RST packet.

repo: Kindling-project/kindling


text:
🛑 FSDH INT is down

In 7af9ff2, FSDH INT (https://fsdh-portal-app-int.azurewebsites.net/register) was down:

HTTP code: 503
Response time: 22683 ms

Resolved: FSDH INT is back up in c644821 after 59 minutes.

repo: KingBain/proto-datahub-uptime


text:
Generate the main.py script

Description
Once #3 and #4 are complete, these should be added to main.py script, which will be used to run the pipeline and output results in a csv file
We can groom this more once we're happy with the previous issues
Acceptance criteria
The recommender runs from a main.py script rather than the notebook

Thank you, this is now fixed by PR 6

authors: Kinjuriu theycallmejeano


text:
[Project Item] -

Title Updated

[X] I have updated the title by replacing the '<title>' section.

Description
asdf
Acceptance Criteria
This issue is finished when:

[ ] Code documentation added
[ ] Unit tests added
[ ] All unit tests pass

ToDo Items

[ ] Draft pull request created and linked to this issue
[ ] Priority label added to issue (prio-low, prio-medium, or prio-high)
[ ] Issue linked to the proper project
[ ] Issue linked to proper milestone
[ ] Unit tests have been written and/or adjusted for code additions or changes
[ ] All unit tests pass

Issue Dependencies
No response

This was for testing purposes

repo: KinsonDigital/Velaptor


text:
🚧Create issues for refactoring unit test assertions

Complete The Item Below

[X] I have updated the title without removing the 🚧 emoji.

Description
Create a thorough and detailed issue for refactoring all of the unit test assertions to use the FluentAssertions library.
This will greatly cleanup the unit testing side of things.   First figure out how many files need to be converted and create the required number of issues that will equally divide up the work to eventually get all of the unit tests converted.  For example, if there was 100 files, you could divide the work up by having each issue convert 5 files at a time which would end up being a total number issues of 20 issues.
Each issue will be a https://github.com/KinsonDigital/Velaptor/labels/tech debt issue with low priority and each the issues will be brought into each release until all of the work is complete.
Acceptance Criteria

[ ] All issues created

ToDo Items

[X] Change type labels added to this issue.  Refer to the Change Type Labels section below.
[X] Priority label added to this issue.  Refer to the Priority Type Labels section below.
[X] Issue linked to the correct project (if required).
[X] Issue linked to the correct milestone (if required).

Issue Dependencies
No response
Related Work
No response
Additional Information:
Change Type Labels

Change Type
Label

Bug Fixes
https://github.com/KinsonDigital/Velaptor/labels/🐛bug

Breaking Changes
https://github.com/KinsonDigital/Velaptor/labels/🧨breaking changes

New Feature
https://github.com/KinsonDigital/Velaptor/labels/✨new feature

Workflow Changes
https://github.com/KinsonDigital/Velaptor/labels/workflow

Code Doc Changes
https://github.com/KinsonDigital/Velaptor/labels/📑documentation%2Fcode

Product Doc Changes
https://github.com/KinsonDigital/Velaptor/labels/📝documentation%2Fproduct

Priority Type Labels

Priority Type
Label

Low Priority
https://github.com/KinsonDigital/Velaptor/labels/low priority

Medium Priority
https://github.com/KinsonDigital/Velaptor/labels/medium priority

High Priority
https://github.com/KinsonDigital/Velaptor/labels/high priority

Code of Conduct

[X] I agree to follow this project's Code of Conduct.

⚠NOTE⚠
NO PULL REQUEST REQUIRED

@CalvinWilkinson  Can I work on this or do you have to come up with the test assertions first?

authors: CalvinWilkinson kselena


text:
Fixed Reloading

Hey @KiranPolaki I encountered an issue. Whenever we press "again" the answer was same every time. I've fixed it and now it's working fine. Kindly review changes and merge this PR.

What do u mean by same! elaborate.

What do u mean by same! elaborate.

The answer that is SecreteNumber was being the same whenever "again" was pressed. I fixed it by enabling it to reload once it's pressed.

What do u mean by same! elaborate.

You can check it. First time you have to guess the number but the subsequent times it was the answer is the same number. To avoid it I just added an eventListener and it is working fine

Yes i see now!

authors: KiranPolaki NikhilKalloli

repo: KiranPolaki/GuessTheNumber


text:
Feature/delete conformation

Adds an AlertDialog before actual deletion of exercise(s)
Minimal change to both remove_button instances
Added .vscode to .gitignore because half of my IDE turned bright red

Hey @VitoMinheere,
Thanks for contributing,
It looks like you have a different format setting.
Would you mind sharing it so we can update the editorconfig and have a consistent codebase style.

Though, the formatting will be overridden by the standard flutter formatting

authors: KiritchoukC VitoMinheere


text:
Reading Less than SOCKET_MINIMUM_READ_BUFFER_SIZE?

Is that possible for me to either change SOCKET_MINIMUM_READ_BUFFER_SIZE or read less than SOCKET_MINIMUM_READ_BUFFER_SIZE?
If I allocate only 4 bytes of Data and read from it, what happens if you read more than 4 bytes?

In case someone has the same question.
let buf = 256
var p = UnsafeMutablePointer<CChar>.allocate(capacity: buf)
try socket.read(into: p, bufSize: buf, truncate:true)
let data = Data(bytes: p, count: buf)
p.deallocate()

repo: Kitura/BlueSocket


text:
大佬好，我想请问2.0.2.5版本的GTNH可以使用哪个版本的汉化包替代汉化呢？还是2.0.2.5版本没有也不能使用替代汉化包呢？

如题，谢谢大佬！

这我就不太清楚了。。。2.5已经是几年前的事了，我接手就是4.9版本


text:
AutocompleteReference Component

A component managing a reference list with an autocomplete. It takes in its props the name of the list, the property name of the key and the property name of the label
import React, { PropTypes } from 'react';
import { AutocompleteSelect } from 'focus-components/components/input';

import referenceMixin from 'focus-components/common/form/mixin/reference-behaviour';
import storeMixin from 'focus-components/common/mixin/store-behaviour';

const displayName = 'AutocompleteReference';

const propTypes = {
    referenceName: PropTypes.string.isRequired,
    keyName: PropTypes.string,
    labelName: PropTypes.string
}

const defaultProps = {
    keyName: 'key',
    labelName: 'libelleLong'
}

const AutocompleteReference = React.createClass({

    displayName: displayName,
    mixins: [referenceMixin, storeMixin],

    querySearcher(query) {
        const normalizedQuery = query.toLocaleUpperCase();

        //We use this normalizedList in order not to capitalize the list for every query
        if (!this.normalizedList && this.state.reference[this.props.referenceName]) {
            this.normalizedList = this.state.reference[this.props.referenceName].map(x => { const toReturn = x; toReturn[this.props.labelName] = x[this.props.labelName].toLocaleUpperCase(); return toReturn });
        }

        const data = (this.normalizedList && this.normalizedList.filter(x => x[this.props.labelName].indexOf(normalizedQuery) === 0)) || [];
        const totalCount = data && data.length;
        return Promise.resolve({ data, totalCount })
    },

    keyResolver(key) {
        const data = (this.state.reference[this.props.referenceName] || []).filter(x => x[this.props.keyName] === key)[0];
        return Promise.resolve((data || {})[this.props.labelName]|| key)
    },

    getValue() {
        return this.refs.input.getValue();
    },
    _validate() {
        return this.refs.input._validate();
    },
    render() {
        return (
            <AutocompleteSelect
                ref='input'
                {...this.props}
                value={this.state.reference[this.props.referenceName] && this.state.reference[this.props.referenceName].length > 0 ? this.props.value : ''}
                querySearcher={this.querySearcher}
                keyResolver={this.keyResolver}
                keyName={this.props.keyName}
                labelName={this.props.labelName}
            />
        )
    }

})

const AutocompleteReferenceWithProps = React.createClass({

    displayName: 'AutocompleteReferenceWrapped',
    propTypes: propTypes,

    getDefaultProps() {
        return defaultProps;
    },

    render() {
        return <AutocompleteReference {...this.props} referenceNames={[this.props.referenceName]} />;
    }
});

export default AutocompleteReferenceWithProps;

Delivered in 2.2.0

authors: Ghodot Hartorn

repo: KleeGroup/focus-components


text:
fix: add missing typings

Hello 🙌
I was using this package and found there are no types. dist/core.d.ts was not emit while tsc. This PR fixes missing types by set declaration: true in tsconfig.json.
{
  "name": "browser-thermal-printer",
  "version": "0.0.1",
  "description": "Print on Epson and Star thermal printers in a browser",
  "main": "dist/core.js",
  "types": "dist/core.d.ts",
  // ...

Before:

After:

Thank you 🍻


text:
[dashboard] Fix sortability for KlimaData Retirement Trends tables

Describe the bug
In the old carbon dashboard, tables were typically sortable by all fields. However the tables on the new Klima Data TypeScript frontend, at least in the retirement trends section, are only sortable by some fields. They should be sortable by all fields for which sorting is practical (for instance free text fields don't need to be sortable).
To Reproduce
Steps to reproduce the behavior:

Go to https://data.klimadao.finance/retirement-trends?tab=byChain
Notice limited sorting options on tables

Expected behavior
Tables should be sortable by all reasonable fields
Screenshots

@sprrwhwk would be good to get a quick assessment of this first, let us know how challenging it is to fix or if this is going to unfold in a larger refactoring (api queries etc...)

Hi @0xAurelius, I am very intrigued by this. I have sort options for all columns on my browser.

What is your OS/Browser/version?

Hi @0xAurelius, I am very intrigued by this. I have sort options for all columns on my browser.
What is your OS/Browser/version?

I have the same problem with hidden controls on firefox. The SVGs seem to be hidden for some reason.

authors: 0xAurelius Atmosfearful biwano wowselim

repo: KlimaDAO/klimadao


text:
⚠ OpenAI API has degraded performance

In 5998196, OpenAI API ($OPENAI_URL) experienced degraded performance:

HTTP code: 200
Response time: 8010 ms

Resolved: OpenAI API performance has improved in 4710e15 after 4 minutes.

repo: KlutzyBubbles/alchemy-unbound-status


text:
AsyncFragmentOperation interface for asynchronous actions

Is your feature request related to a problem? Please describe.
Library actions that are asynchronous:

HttpAction
InMemoryCacheAction
CircuitBreakerAction
contain some boilerplate that can be encapsulated in a single interface.

Also, consistent error handling could be enforced - now these things may occur:

handler gets called by a future that succeeds
handler gets called by a future that fails
handler never gets called as future never resolves
handler never gets called as action throws an exception
handler gets called with AsyncResult that is not resolved at the time of reading value (see Vert.x bug)

Describe the solution you'd like
Create AsyncFragmentOperation interface
package io.knotx.fragments.api;

import io.vertx.core.AsyncResult;
import io.vertx.core.Future;
import io.vertx.core.Handler;

public interface AsyncFragmentOperation extends FragmentOperation {

  @Override
  default void apply(FragmentContext fragmentContext, Handler<AsyncResult<FragmentResult>> resultHandler) {
    tryApply(fragmentContext).onComplete(resultHandler);
  }

  default Future<FragmentResult> tryApply(FragmentContext fragmentContext) {
    try {
      Future<FragmentResult> result = apply(fragmentContext);
      if (result != null) {
        return result;
      } else {
        return Future.failedFuture(
            new IllegalStateException("Action " + this.getClass().getName()
                                          + " returned null Future. Created failed Future to pass information to handler.")
        );
      }
    } catch (Throwable t) {
      return Future.failedFuture(t);
    }
  }

  Future<FragmentResult> apply(FragmentContext fragmentContext);

}

With the following semantics:

Handler is always called (unless underlying action halts)
If action successfully returns a non-null Future<FragmentResult>, then handler is called with it
If action returns null or throws an exception, handler is called with Future.failedFuture(reason).

Unfortunatelly, failed future in this case encapsulates all three cases (failure within action, null result and exception thrown from action). However, each time we're dealing with an exception so I believe this is not an issue and can simplify error handling in the whole knotx-fragments repository.
Describe alternatives you've considered
N/A
Additional context
Relates to #184

Fixed.

authors: marcinus tomaszmichalak

repo: Knotx/knotx-fragments


text:
Update atleast 5 landmarks for every city present in cities.json

There should be atleast 5 landmarks for a specified city.

Hi @thenishantsapkota
Do you mean, as a part of the PR we must ensure that the json object at https://github.com/Know-Nepal/borderlines/blob/main/data/borderlines.json contains at least 5 landmarks for each of the already added cities?

Yes that's exactly my intention, atleast there must be 5 landmarks per city @dyaramatreya

Assigned it to you @dyaramatreya!

@thenishantsapkota Linked the PR #17 . Please review and approve the PR. Thanks

authors: dyaramatreya thenishantsapkota

repo: Know-Nepal/borderlines