About the gdspy.Text() class

Dear developers of Gdspy,
I am a user of gdspy from the integrated photonics community. Gdspy has been a powerful and essential tool for me, but one issue has bothered us.
By default, the gdspy.Text() creates polygons with only horizontal or vertical edges, but some of the polygons share the same vertices, as shown below. We are told by some silicon photonics foundries that this violates their design rules.

Currently, this issue can be solved by first using gdspy.Label() and then converting the label into a PCell in Klayout (shown below), but it is not so convenient.

Could you consider providing additional font styles to address this issue?
Thank you very much!

hi @ru-tan ,
I also work in photonics and contribute to both gdspy and gdsfactory (which is built on top of gdspy). The gdsfactory text() function may be better suited for your needs. That said, I usually use custom fonts and realize it is not super straightforward to do so in either library. I created an issue in gdsfactory for this
@joamatab

Hello @ru-tan, font support is a very deep rabbit hole I wouldn't have time to work on.
That would require at least:

Support the most common formats
Support for system-specific font paths/loading libraries
Plus implementation “detail”: font metrics, kerning, ligatures, encoding, writing directions, etc.
The solution here is probably to depend on other libraries, but that increases the complexity of the build system in all platforms. I might be able to work on that in the future, but right now this is a very low priority.

Creating another “font” in the same way I did with the current one might solve the problem with a specific foundry, but there would always be processes with different design rules…
Meanwhile, you can try using an offset on your text to avoid those 4-way intersections or follow the example on how to use system fonts through matplotlib.

from my experience, it's smart to be dumb with fonts 😆
as you say, @heitzmann , it can be a never-ending rabbit hole. we should not try to implement every font you have in Microsoft Word, for example, or get too caught up in all the complexities of actual fonts in a word-processor. but we should have
A. A reasonable default font (or maybe a couple, as the definition of reasonable might vary!)
B. Capability to load a custom character set... which I would argue should be contrained to only have character geometries and fixed character widths and spacings. Going much further beyond this provides little value to polygon text.  Doesn't need to be fancy.
but anyways, then you start to get into a fairly opinionated design, which seems a better fit for gdsfactory to me than gdspy/gdstk (which sticks more to the essentials)
or as you say, a reasonable, simple alternative (if it works for you) is to simply add an offset to the existing characters in gdspy

hi @ru-tan , apparently this is already built into phidl, which is a library built on top of gdspy.
see: https://github.com/gdsfactory/gdsfactory/issues/259#issuecomment-1099768545
thanks to @joamatab and @spauka for sharing

Yes, in phidl the default font used is DEPLOF (originally made by David Elata at Technion to avoid issues like this, and also prevent any floating islands which causes issues when doing certain processes like MEMS). Thanks to @spauka, it also recently has full truetype (font support)[https://phidl.readthedocs.io/en/latest/geometry_reference.html#Text]
You're obviously welcome to use the phidl text function (which as mentioned is built on top of gdspy), but if you're looking for something a little more quick-and-dirty, I'd recommend just grabbing the individual character glyphs for the DEPLOF font here: https://github.com/amccaugh/phidl/blob/master/phidl/constants.py


Add lemmatised text from TEI markup to search

Add content from tei:w/@lemma and dereferenced tei:name/@nymRef to the Solr index and allow that to be searched over.

This seems like something that is potentially useful for any TEI text, not just Epidoc, and that the indexing process should always index a lemmatised form (which, in some cases, will be the same as the non-lemmatised form). This removes the need for any indexing configuration (at this stage).

What, if anything, do we wish to do with tei:w/@lemmaRef?

Re @lemmaRef: if present, treat it like @nymref — i.e. try to dereference it, and fetch the headword if found.
The difference being, as far as I can see, @nymRef points to the xml:id of a <nym> element whose headword can be find in /tei:form/tei:orth, whereas @lemmaRef is not (according to the TEI Guidelines) normally suggested to point to a tei:entry, but rather to "an online lexicon", whose format we can of course not second guess.
Short answer: in the short term, either do nothing, or test for whether both @lemmaRef and @nymRef point to a TEI file, and if not, ignore them. In the medium term we'll query the Markup list for more robust suggestions.

I think @lemmaRef is not implemented, and so should be ignored for now. Anything else outstanding on this ticket? If not, close it.

Non-local @nymRef values are not supported, but supporting that (and any other 'need the external content at the time of indexing' references) would require a change to the indexing process (to operate on an aggregation of the source document and every fetched document it references).
The references to authority lists, by the way, are fine, because we just store the reference, not the referenced content (which is pulled in during display).


No backgound color in light mode for fullscreen editor

Like the title says, there's no background colour set in the tiptap-content div for lightmode.
<div class="tiptap-content max-h-[40rem] h-auto overflow-scroll rounded-b-md dark:bg-gray-700" x-ref="element">
Needs a bg-white, or it the editor becomes transparent when going fullscreen ;)

I e got some other styling fixes to make. I’ll include this in those fixes. Thank you.

Thanks again @grahammtbr
This is fixed in the latest version: https://github.com/awcodes/filament-tiptap-editor/releases/tag/v0.2.10

:+1:


Comparing LibGit2Sharp blows with "Format of the executable (.exe) or library (.dll) is invalid."

To repro just execute
http://localhost:2321/compare/LibGit2Sharp/0.20.1...0.20.2
causes Mono.Cecil to blow with mentioned ex.

cc @SimonCropp @nulltoken

@andreasohlund :heart: for having taken a look at this.

causes Mono.Cecil to blow with mentioned ex.

Most certainly due to trying to load one of the native binaries as a managed one.
A try/catch (BadImageFormatException e) should work around this. FWIW, this is the way it's been solved by the scriptcs project

Unless someone beats me to it, I'll try to send a PR tomorrow. Cool with you?

That would be awesome. One way to integration test this would be to add a
similar test to
On Fri, Sep 4, 2015 at 8:45 PM, nulltoken<EMAIL_ADDRESS>wrote:

Unless someone beats me to it, I'll try to send a PR tomorrow. Cool with
you?
—
Reply to this email directly or view it on GitHub
https://github.com/ParticularLabs/APIComparer/issues/47#issuecomment-137818148
.

We have some code in NServiceBus to exclude non .net asm that could be used as inspiration :)
https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Hosting/Helpers/AssemblyScanner.cs#L171


HTMLElement.prototype.click detail property

Hey,
I'm not sure what any spec says about that, but from my limited testing of browsers, synthesized click events come with a detail property of 0, differentiating them from real clicks that have it at 1 or higher. The button and buttons property are 0, too, indicating the left mouse button.
JSDOM's HTMLElement.prototype.click implementation has detail and other properties as undefined.

Hmm. Because the default value for the dictionary is zero, it should be 0 in all click events created by default. Do you have a small 10-line test case showing that this is not the case in jsdom?

For some reason, the following throws for me on JSDOM v9.4.1 with Node v4.3.0:
var Jsdom = require("jsdom")
var assert = require("assert")

var reporter = Jsdom.createVirtualConsole()
reporter.on("jsdomError", function(err) { throw err })
var document = Jsdom.jsdom(undefined, {virtualConsole: reporter})
var window = document.defaultView

document.body.addEventListener("click", function(ev) {
  assert(ev.detail === 0)
})

document.body.click()

@Sebmaster, this is an interesting bug arising from the webidl2js bindings. As-is, the line
    const event = MouseEvent.createImpl(["click", { bubbles: true, cancelable: true }], {});

never triggers the actual generated MouseEvent constructor, and thus never gets all the dictionary defaulting goodness. Any ideas on the best fix? Maybe just call the real constructor, then use implForWrapper? Although even that is failing, hmm... I'll upload a PR.

Just to confirm liveliness, I believe v9.12 has not fixed this yet. My workaround since last year for those in need:
var HTMLElement = require("jsdom/lib/jsdom/living").HTMLElement
var MouseEvent = require("jsdom/lib/jsdom/living").MouseEvent

HTMLElement.prototype.click = function() {
  this.dispatchEvent(new MouseEvent("click", {
    button: 0, buttons: 1, bubbles: true, cancelable: true, detail: 0
  }))
}

Hit this problem, too. This break my test code with react-router-dom's Link, because it is using event.button===0 to trigger navigate.
See: https://github.com/ReactTraining/react-router/blob/master/packages/react-router-dom/modules/Link.js#L41


SeatAndEat : Correct grammatical errors throughout the website.

Description of what needs to be done
All grammatical and punctuation errors in the entire website need to be corrected.
Why does this need to be done?

This needs to be done to reduce the number of words on the page and provide a better user experience.
Pages with better language are usually ranked higher on the internet. (SEO)

This issue is against the norms of KSoC.

Okay. But it will make the website look much better. @Rupam-Matabber

We will let you know if we open this issue. But currently, it is against the guidelines of the KSoC.

@Rupam-Matabber Okay!


python311Packages.tilequant: refactor

Description of changes
Fix build (https://hydra.nixos.org/build/254312798)

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 299742 run on x86_64-linux 1

18 packages built:

python311Packages.skytemple-dtef
python311Packages.skytemple-dtef.dist
python311Packages.skytemple-files
python311Packages.skytemple-files.dist
python311Packages.skytemple-ssb-debugger
python311Packages.skytemple-ssb-debugger.dist
python311Packages.tilequant
python311Packages.tilequant.dist
python312Packages.skytemple-dtef
python312Packages.skytemple-dtef.dist
python312Packages.skytemple-files
python312Packages.skytemple-files.dist
python312Packages.skytemple-ssb-debugger
python312Packages.skytemple-ssb-debugger.dist
python312Packages.tilequant
python312Packages.tilequant.dist
skytemple
skytemple.dist


Contribute to OpenJFX

Greetings,
Would you be willing to contribute javafxsvg to openjdk.java.net/projects/openjfx ?
If so, and if there is anything I can do to help, please let me know.
Best regards,
Henri

Hi Henri,
in general: yes of course. I guess this would however not include the SVG support itself as this would require apache tiki as a dependency. What could be done is probably creating some "official" interface to plug-in SVG support, but i'm not sure whether something like this is desired for openjfx.
So i guess we'd first need to start a new discussion regarding this interface on the openjfx mailing list.
BR
Jan

Hi Jan,
Apache tiki?  Apache Batik, perhaps?  I've managed to run the javafxsvg test on the eclipse IDE.  It comes with Batik.
I'll post here when I manage to create a JDK enhancement bug or a mailing list topic. It could be a few days.
Cheers,
Henri

🤦♂ I tried to write tika which was auto corrected tiki, but what I meant was batik of course 😉


Cache compression - cross OS support

Problems
There have been multiple reported issues related to compression of caches. The issue we are looking to solve:

Cross-OS compatibility: Currently on windows cache uses a different compression algorithm (gzip) as compared to on linux | mac (zstd). This leads to different versions for caches created on different platforms. Therefore caches created on windows might not be recoverable on linux | mac. For more details on cache version see this.

Proposal
We are looking to solve both the problems as follows::

Change the default tar used on windows runners to GNUtar. This is already suggested as a workaround for people in these problems. Same tooling will ensure that cache can be reused across all three OSes.
Fallback to BSDtar with zstd on windows. BSDtar is already present on Windows runners by default but it does not use zstd due to the issue of compression hanging with large caches. In our testing, we found that performing archiving and compression as separate processes (instead of calling tar --use-compress-program) does not have the hang problem for caches of size up to 2GB.

Reasoning to choose GNUtar over BSDtar as default
BSDtar has some implementation problems. That’s the reason it stopped being used in MacOS for our action. For more details see https://github.com/actions/toolkit/issues/552.
Related issues which should get fixed with this proposal
We have consolidated issues related to the above problems here. Feel free to provide feedback regarding these in this issue itself.

https://github.com/actions/cache/issues/330
https://github.com/actions/toolkit/issues/543
https://github.com/actions/cache/issues/301
https://github.com/actions/cache/issues/1010
https://github.com/actions/cache/issues/198 (Should be fixed with use of GNUtar)
https://github.com/actions/cache/issues/125 (Won’t fix)
https://github.com/actions/cache/issues/389 (Not fixing as of today)

I'm glad this is being addressed, but I'm not sure the stated proposal is the right path forward.  Or rather, it may be not the right path for all users.
I don't believe that cross-OS compatibility of single cache archive should be the primary driver, as it's quite common to put the runner.os in the cache key, as seen in the basic example in the docs.   In my case, we need a different set of packages cached and restored for each OS, so we wouldn't use one common cache anyway.
Also, it sounds as if the only plan for speeding things up on Windows is to switch to GNU tar.  As I stated previously, and reported by others here and here - this has not resolved the problem.  Cache restore is still very slow, even with GNU tar.
I think the part that is missing from the proposal is that I believe there should be an option to choose the archive format, and that should be exposed all the way up to the cache action.  Personally, I would like to use .7z as the format on Windows.  Or perhaps just .zip, but still using 7-Zip to do the work because it's much faster than anything that ships with Windows itself, and it's already pre-installed on the GitHub Actions runner images.

BTW - 7-Zip does support tar and tar.gz formats.  And like I said, it's pre-installed on both windows-2019 and windows-2022 runner images.  I'm not certain if it would be faster than BSD or GNU tar or not.  Perhaps you could experiment and see?

@mattjohnsonpint appreciate your feedback and suggestions on this. The stated proposal mainly addresses customer pain points surrounding reducing build time by leveraging cache across their runners. This proposal should also provide some performance improvements for windows as now the compression algo in use will be zstd instead gzip. We are also exploring other solutions for windows runner performance including 7-zip to provide better performance on windows when cross-os caching is not a concern.

New beta release
We have released a beta version of cache under<EMAIL_ADDRESS>for users to test for functionality. This should cache using GNU tar with zstd as compression and has BSD tar with zstd as fallback on windows. Functionality on linux | mac should remain same.
Expected behaviour
All the mentioned issues in above description should be resolved and not happening with this release. Performance might vary for different files on windows. No changes should happen to mac | linux cache performance
Call outs

Old caches on windows wouldn't be recovered as different compression algorithm is used in beta.
Don't expect any or major performance improvement

👋🏼  Created a discussion for any feedback: https://github.com/actions/cache/discussions/1019

You closed all the performance related issues and linked them to this, however, you say the patch will not resolve performance problems..
So either fix the performance as well, or have a seperate tracker for the performance problems.
Personally I've seen much more complaints about performance than requests for cross os caches.... So just like @mattjohnsonpint I am surprised about the priorities here.

@Safihre that's correct. We started by thinking to tackle both cross-os and performance problems together but realized that performance needs a more in-depth and targeted approach and needs more time. That's why we will first ship out the cross-os support. We have a separate internal tracker for performance problem. Will create a public tracker as well once we more details to share.

Update
Tag v3.1.0-beta has been updated to account for old caches saved by gzip compression on windows and fallback to gzip while recovering and decompressing. So old caches should be recoverable and new caches would be compressed using zstd.
Call out

While BSD and GNU tars are most compatible there might be some onetime corruption as old caches were saved using BSD tar and recovered using GNU tar.

Update
Have released all the changes to v3. Now cache would be able to work cross os. Go ahead to release notes for details on what new is added: https://github.com/actions/cache/blob/main/RELEASES.md#321
Keeping this issue open for sometime for feedback

Update
We have reverted the changes due to multiple complains regarding symlinks not working. If a cache containing symlink is saved on linux|mac and restored on windows then GNU tar not able to recover those symlinks. We are actively working to resolve this issue, till then have reverted the changes.
Related issue: https://github.com/actions/cache/issues/1043

Update
Currently we are fixing a problem related to symlinks creation on windows during a tarball extraction which was created on linux|mac. Common example is caching a node_modules folder. Original issue which was reported and lead to reverting original changes.
Solution:
We found that symlink creation is handled differently for different platforms and filesystems. We encountered two solutions to handle this:

Use --dereference with tar on creation to remove any symlinks present while creation:

Pros: Removed symlinks entirely while creation so no problem while handling
Cons: Size of tar would increase as this would create copies of same file.

Add environment variable MSYS=winsymlinks:nativestrict to handle symlinks as per windows symlink: Blog. This works for any tar based on msys2 platform, which is our current tar from git-for-windows.

Pros: Creates a symlink for any unix based symlink so should work as usual.
Cons: Might break if symlink created is still not handled by code. So user should still understand that symlinks on cross os caches might break.

We have chosen to go with 2nd solution and would love hear feedback from community.

I believe that MSYS=winsymlinks:nativestrict is a great way to go, assuming using git-bash of course. Older windows systems also have to have the "Developer mode" set for this to work, I'm not sure whether that is still a problem.

Hosted runners do run with administrative privileges so this should be fine

Update
We have released new changes with symlink issue fixed and allowing to use cross-os cache as an opt-in feature by adding enableCrossOsArchive input as true to cache action.
Note: All previous workflows should work as usual with cache miss for first time on windows due version changes done. This was done to keep previous workflows on windows cache separate as compared to cross-os cache.

I encountered a problem when restoring a cache saved by windows-latest with a self-hosted runner in Windows Server 2016.
After some research I found here and was able to solve the problem by installing GNU tar and zstd on the runner.
It would be helpful if it be documented that these installations are required (or recommended?) when using cache actions in a self-hosted runner.

Hi @mkht, thank you for this feedback. We had these documented previously in the workarounds section, we'll have these added to Pre-requisites moving forward for better visibility.

@mkht I think GNU tar already comes with Git installation: https://github.com/actions/cache/issues/576#issuecomment-830796954
At least for my workflows this works fine: https://github.com/devonfw-actions/java-maven-setup/blob/main/action.yml#L53

Hi @maybeec , thanks for the advice.
As odd as it may seem, Git is not installed on my self-hosted runner.
To keep the maintenance of the runner easily, I only install the minimum number of applications that are necessary.
As far as I know, there is no mention of Git being required for the self-hosted runner to work. The lack of Git has not caused any fatal problems in the past.
https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#requirements-for-self-hosted-runner-machines

Hi @mkht, so we have added gnutar and zstd as pre-requisites to the README. Closing this issue. Thank you everyone for the feedback and suggestions.


button group accessibility - Ensures every form element has a label

https://v4-alpha.getbootstrap.com/components/button-group/#button-toolbar
Ensures every form element has a label, the two sample for mail adress doesn't have a valid label (aria-described is not enough). I suggest to add an aria-label, which will reuse the palceholder content
e.g:
@
<input type="text" class="form-control" placeholder="Input group example" aria-describedby="btnGroupAddon" aria-label="Input group example">

Maybe need also an update for all form elements also on input-group page. And need to update the accessibility best practice : aria-describedby and placeholder are NOT a valid technique to provide a label input information
http://v4-alpha.getbootstrap.com/components/input-group/#accessibility

on the last point about aria-describedby and placeholder: while not ideal, it is my understanding that on inputs at least the latter DOES act as a "last resort" way of providing a label via the accessibility API if none of the better ways are present (see http://rawgit.com/w3c/html-api-map/master/index.html#accessible-name-and-description-calculation). so based on that, the current example code is not exactly elegant, but "valid" (/cc @stevefaulkner)
having said that, adding an explicit aria-label seems the cleaner option for those inputs. and removing aria-describedby (as it's clearly wrong) and placeholder (as it's contentious) from the advice section makes sense.

xref https://github.com/w3c/html-aam/issues/84 which resulted in related bugs being filed against iOS/VoiceOver and Android/Chrome/Talkback


Metric chart style updates

Fixes width of ICU tooltip
Drops marginLeft to allow chart to take up maximum space on mobile
Drops chart line stroke-width to 2px on mobile (vs. 4px on desktop)
Drops chart height to 280px on mobile (vs. 400 px on desktop)

 Make charts more legible on mobile (try making them shorter, t-hold labels on the left)


Support char, signed char, unsigned char types

These should be implemented in terms of:

char = https://doc.rust-lang.org/std/os/raw/type.c_char.html
signed char = https://doc.rust-lang.org/std/os/raw/type.c_schar.html
unsigned char = https://doc.rust-lang.org/std/os/raw/type.c_uchar.html

Useful for passing &[char] --> rust::Slice<char> --> const char*.

Maybe only char is needed? I guess signed char and unsigned char will always be the same as i8 and u8 on platforms that Rust supports.


chore(deps): update tubenhirn/semantic-release-gitlab docker tag to v4.0.3

This PR contains the following updates:

Package
Update
Change

tubenhirn/semantic-release-gitlab
patch
v4.0.2 -> v4.0.3

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 4.4.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Ipfs deprecate

This adds a deprecation to the IPFS API configuration option, so that we can remove this feature in the next major.

Hi, what is the reason for deprecating the ipfs api? I've never used it but have wondered about it

IPFS themselves deprecated the APIs and there isn't currently an effort to upgrade to their new suite of tools. There are also reliability and privacy concerns with using it in production.


Export your Dataverse data to Azure Data Lake Gen2 is not in preview

The text "We're now previewing a similar capability to export your Dataverse data to Azure Data Lake Gen2. " should be updated, as this is now GA

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3d51ad6f-b7a7-7abd-f1d1-1d7963dd3d49
Version Independent ID: 4612ff88-8457-2f49-8222-4fd110fd72f6
Content: Replicate data to Azure SQL Database using Data Export Service - Power Platform
Content Source: power-platform/admin/replicate-data-microsoft-azure-sql-database.md
Service: power-platform
GitHub Login: @jimholtz
Microsoft Alias: jimholtz

@algattik
Thanks for bringing this to our attention. This will be updated today.

@algattik
Thanks for bringing this to our attention. This will be updated today.


Add import gzip support

when ctr import a image file ,  it can be gzip ~and bzip2~ format file.

What version are you testing and how did you create the tar.gz file?
I have tested the main version and containerd is able to successfully import the tar.gz image.

save tar.gz

[root@dockervm ~]# docker save busybox:latest | gzip > busybox.tar.gz
[root@dockervm ~]# file busybox.tar.gz
busybox.tar.gz: gzip compressed data, last modified: Fri May 24 09:39:14 2024, from Unix, original size 4505600

import tar.gz

[root@devnode1 containerd]# ctr version
Client:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  Go version: go1.22.3

Server:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  UUID: 79343445-f320-4901-b203-5c2a2bb87144
[root@devnode1 containerd]# ctr image import busybox.tar.gz
docker.io/library/busybox:latest                saved
application/vnd.oci.image.manifest.v1+json sha256:1d8ee6ccd551c9d8dfa55730cba130e76f5a69ec8dbebe17fb5e1c309077dfb5
Importing       elapsed: 0.4 s  total:   0.0 B  (0.0 B/s)

What version are you testing and how did you create the tar.gz file? I have tested the main version and containerd is able to successfully import the tar.gz image.

save tar.gz

[root@dockervm ~]# docker save busybox:latest | gzip > busybox.tar.gz
[root@dockervm ~]# file busybox.tar.gz
busybox.tar.gz: gzip compressed data, last modified: Fri May 24 09:39:14 2024, from Unix, original size 4505600

import tar.gz

[root@devnode1 containerd]# ctr version
Client:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  Go version: go1.22.3

Server:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  UUID: 79343445-f320-4901-b203-5c2a2bb87144
[root@devnode1 containerd]# ctr image import busybox.tar.gz
docker.io/library/busybox:latest                saved
application/vnd.oci.image.manifest.v1+json sha256:1d8ee6ccd551c9d8dfa55730cba130e76f5a69ec8dbebe17fb5e1c309077dfb5
Importing       elapsed: 0.4 s  total:   0.0 B  (0.0 B/s)

I compile containerd from  main branch , make sure you have gzip file , could you check the 3 bytes front of the file is ’1f 8b 08  ‘？ hexdump -C busybox.tar.gz |head   I trace the code in import ,but there is no decomporess , If your code is from main branch now?

What version are you testing and how did you create the tar.gz file? I have tested the main version and containerd is able to successfully import the tar.gz image.

save tar.gz

[root@dockervm ~]# docker save busybox:latest | gzip > busybox.tar.gz
[root@dockervm ~]# file busybox.tar.gz
busybox.tar.gz: gzip compressed data, last modified: Fri May 24 09:39:14 2024, from Unix, original size 4505600

import tar.gz

[root@devnode1 containerd]# ctr version
Client:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  Go version: go1.22.3

Server:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  UUID: 79343445-f320-4901-b203-5c2a2bb87144
[root@devnode1 containerd]# ctr image import busybox.tar.gz
docker.io/library/busybox:latest                saved
application/vnd.oci.image.manifest.v1+json sha256:1d8ee6ccd551c9d8dfa55730cba130e76f5a69ec8dbebe17fb5e1c309077dfb5
Importing       elapsed: 0.4 s  total:   0.0 B  (0.0 B/s)

I compile containerd from main branch , make sure you have gzip file , could you check the 3 bytes front of the file is ’1f 8b 08 ‘？ hexdump -C busybox.tar.gz |head .. I trace the code in import ,but there is no decomporess , If your code is from main branch now?

[root@devnode1 containerd]# git pull origin main
From https://github.com/containerd/containerd
 * branch                main       -> FETCH_HEAD
Already up to date.
[root@devnode1 containerd]# git log -n 1
commit 45e30913bc75c43148e00aade10891e5a4a6eba5 (HEAD -> main, origin/main, origin/HEAD)
Merge: ccc41e670 65024e6fd
Author: Derek McGowan<EMAIL_ADDRESS>Date:   Thu May 23 21:23:18 2024 +0000

    Merge pull request #10257 from akhilerm/fix-unknown-platform

    core/image: fix usage of "unknown" platform
[root@devnode1 containerd]# ctr version
Client:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  Go version: go1.22.3

Server:
  Version:  v2.0.0-rc.2-6-g45e30913b
  Revision: 45e30913bc75c43148e00aade10891e5a4a6eba5
  UUID: 79343445-f320-4901-b203-5c2a2bb87144
[root@devnode1 containerd]# hexdump -C busybox.tar.gz |head -n 2
00000000  1f 8b 08 00 42 60 50 66  00 03 ec 5c 0b b4 15 d5  |....B`Pf...\....|
00000010  79 de 17 91 f7 45 44 69  7c 20 39 b9 71 2d 31 c2  |y....EDi| 9.q-1.|
[root@devnode1 containerd]# ctr image import busybox.tar.gz
docker.io/library/busybox:latest                saved
application/vnd.oci.image.manifest.v1+json sha256:1d8ee6ccd551c9d8dfa55730cba130e76f5a69ec8dbebe17fb5e1c309077dfb5
Importing       elapsed: 0.4 s  total:   0.0 B  (0.0 B/s)

main branch, revision 45e30913bc75c43148e00aade10891e5a4a6eba5
first 3 bytes 1f 8b 08

docker save busybox:latest

sorry I find my mistake , my ctr use  1.7.2 version . That's such a huge mistake .  When I debug , I use the latest containerd but ctr is 1.7.2 . I will change this pr , if xz and bandzip2 is need 。 thanks for u.This is a big black dragon

#10260 I have take a new pr


test add batch size in long time case

Proposed changes
For even PRs, the batch size is set to 50, and this case runs for 50 minutes.

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Stronghold placement

The Placement of the stronghold is totally off. Pieces arent connected.

I can confirm this, but I don't think it's an issue with the stronghold itself. All pieces are fine when edited, and when the stronghold structure is manually placed with /iris jigsaw place stronghold, the pieces are connected perfectly. I believe it's got something to do with connections during world generation

This is a plugin issue, not an overworld issue ;)


Add myself to loops in progress

Add myself to open loops in progress

Did you change your mind?  Or can I go ahead and merge this?

Go ahead and merge it. I was looking for ways to make it harder, lol
Terri - Sent from my iPhone

On Jul 17, 2016, at 12:50 PM, Scott Leibrand<EMAIL_ADDRESS>wrote:
Did you change your mind? Or can I go ahead and merge this?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

LOL, found one! ;-)


Ruotong's Final Project

Nice work!  Thanks for a great semester.  More feedback to follow via email.


Some blue and white vertical lines appear in the canvas.

Some blue and white vertical lines appear in the canvas. Did you have ever meet this problem,and can you get me some ideas.

@brion

I've not encountered this exact problem, no... but try tweaking this bit of WebGLFrameSink.js:
js 	WebGLFrameSink.stripe = (function() { 		if (navigator.userAgent.indexOf('Windows') !== -1) { 			return true; 		} 		return false; 	})();
to return false on Windows as well. This will use a simpler code path but might be slightly slower.

@brion
thank you.I tried the method you said and the problem was solved.
But what is the real cause? Is the difference between GL and D3API supported by the graphics card cause this different phenomenon on defferent devices?


twister: Fix suite-name-check bypass on flash error

Fix suite-name-check bypassed at DeviceHandler on flash errors.
If the flash timeout is smaller than needed, but test images are actually flashed successfully and appropriate tests executed, then results from the previous test case were taken because the flash error status makes the suite-name-check bypassed.
Don't override a test case name check failed result by the following RunID check failed result to report clearly about test case mismatch situation as well as more specifically when the same test case appears with unexpected RunID.
Log expected and detected test case names for the test suite name check debug.

Run twister with -- level smoke, with a smaller flash timeout than needed on that platform - 3 false positives.
INFO    - 2308 test scenarios (2102 test instances) selected, 2097 configurations skipped (2093 by static filter, 4 at runtime).
INFO    - 3 of 2102 test configurations passed (60.00%), 0 failed, 2 errored, 2097 skipped with 0 warnings in 211.85 seconds
INFO    - In total 12 test cases were executed, 8342 skipped on 1 out of total 564 platforms (0.18%)
INFO    - 5 test configurations executed on platforms, 0 test configurations were only built.
INFO    - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INFO    - The following issues were found (showing the top 10 items):
INFO    - 1) tests/kernel/threads/tls/kernel.threads.tls on intel_ish_5_4_1 error (Device issue (Timeout))
INFO    - 2) tests/kernel/interrupt/arch.interrupt on intel_ish_5_4_1 error (Device issue (Timeout))

same run with the fix:
INFO    - 2308 test scenarios (2102 test instances) selected, 2097 configurations skipped (2093 by static filter, 4 at runtime).
INFO    - 0 of 2102 test configurations passed (0.00%), 2 failed, 3 errored, 2097 skipped with 0 warnings in 377.20 seconds
INFO    - In total 13 test cases were executed, 8341 skipped on 1 out of total 564 platforms (0.18%)
INFO    - 5 test configurations executed on platforms, 0 test configurations were only built.
INFO    - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INFO    - The following issues were found (showing the top 10 items):
INFO    - 1) tests/kernel/threads/thread_apis/kernel.threads.apis on intel_ish_5_4_1 failed (Testsuite mismatch)
INFO    - 2) tests/kernel/threads/thread_init/kernel.threads.init on intel_ish_5_4_1 failed (Testsuite mismatch)
INFO    - 3) tests/kernel/threads/thread_stack/kernel.threads.thread_stack on intel_ish_5_4_1 error (Device issue (Timeout))
INFO    - 4) tests/kernel/threads/tls/kernel.threads.tls on intel_ish_5_4_1 error (Device issue (Timeout))
INFO    - 5) tests/kernel/interrupt/arch.interrupt on intel_ish_5_4_1 error (Device issue (Timeout))

without the fix (--level smoke), small flash timeout, 3 false positives
INFO    - 2308 test scenarios (2102 test instances) selected, 2097 configurations skipped (2093 by static filter, 4 at runtime).
INFO    - 3 of 2102 test configurations passed (60.00%), 0 failed, 2 errored, 2097 skipped with 0 warnings in 212.13 seconds
INFO    - In total 12 test cases were executed, 8342 skipped on 1 out of total 564 platforms (0.18%)
INFO    - 5 test configurations executed on platforms, 0 test configurations were only built.
INFO    - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INFO    - The following issues were found (showing the top 10 items):
INFO    - 1) tests/kernel/threads/tls/kernel.threads.tls on foo_bar error (Device issue (Timeout))
INFO    - 2) tests/kernel/interrupt/arch.interrupt on foo_bar error (Device issue (Timeout))

with the fix
INFO    - 2308 test scenarios (2102 test instances) selected, 2097 configurations skipped (2093 by static filter, 4 at runtime).
INFO    - 0 of 2102 test configurations passed (0.00%), 2 failed, 3 errored, 2097 skipped with 0 warnings in 377.20 seconds
INFO    - In total 13 test cases were executed, 8341 skipped on 1 out of total 564 platforms (0.18%)
INFO    - 5 test configurations executed on platforms, 0 test configurations were only built.
INFO    - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INFO    - The following issues were found (showing the top 10 items):
INFO    - 1) tests/kernel/threads/thread_apis/kernel.threads.apis on foo_bar failed (Testsuite mismatch)
INFO    - 2) tests/kernel/threads/thread_init/kernel.threads.init on foo_bar failed (Testsuite mismatch)
INFO    - 3) tests/kernel/threads/thread_stack/kernel.threads.thread_stack on foo_bar error (Device issue (Timeout))
INFO    - 4) tests/kernel/threads/tls/kernel.threads.tls on foo_bar error (Device issue (Timeout))
INFO    - 5) tests/kernel/interrupt/arch.interrupt on foo_bar error (Device issue (Timeout))

@nashif @PerMac @hakehuang please take a look


put quiet mode on when debugging otherwise debugging output gets clob…

…bered

Looks good! May be good to add some helpful debugging back in too, especially around connectivity.


Allow to scroll with mouse outside of the central column

I think it would be nice to allow users to scroll without having the mouse pointer in the way of the central feed column, but also in the gray area in the background.

Please update the application to the latest. It has been fixed :)


mllama3.2-V-11b support text-only mode?

Can mllama3.2-V-11b support text only mode?
transformers code like this: https://github.com/huggingface/transformers/blob/655bec2da7120a8681acc2ce951f8d58c6f0e6ef/src/transformers/models/mllama/modeling_mllama.py#L1645

Yes, text only is supported.

Yes, text only is supported.

@AllentDan cool !
how to use the text only infer on pipeline? set the image = None?
from lmdeploy import pipeline
from lmdeploy.vl import load_image

pipe = pipeline('meta-llama/Llama-3.2-11B-Vision-Instruct')

#image = load_image('https://raw.githubusercontent.com/open-mmlab/mmdeploy/main/tests/data/tiger.jpeg')
image=None
response = pipe(('who won the world cup in 2006?', image))
print(response)

No, just like normal LLM inference. response = pipe('who won the world cup in 2006?')

No, just like normal LLM inference. response = pipe('who won the world cup in 2006?')

@AllentDan  found log  lmdeploy - WARNING - archs.py:53 - Fallback to pytorch engine because /models/Llama3.2-11B-Vision-Instruct/ not supported by turbomind engine.
How long  can turbomind engine support ?

There is no such a plan in the short future.

There is no such a plan in the short future.

@AllentDan  Got it, another question , Dose lmdeploy serve api_server   support mllama3.2 _V ?
lmdeploy serve api_server mllama3.2 _V

and how can I use the restful api to request text-only and image-text ?
Thanks!

May refer to https://lmdeploy.readthedocs.io/en/latest/multi_modal/mllama.html. As for text only, just follow llm api_serving. https://lmdeploy.readthedocs.io/en/latest/llm/api_server.html

May refer to https://lmdeploy.readthedocs.io/en/latest/multi_modal/mllama.html. As for text only, just follow llm api_serving. https://lmdeploy.readthedocs.io/en/latest/llm/api_server.html

@AllentDan works will ! last question, How can I add backend_config in api_server cli?
lmdeploy serve api_server mllama3.2 _V   --backend_config ??

Please use -h command to find what arguments you can use.
PyTorch engine arguments:
  --adapters [ADAPTERS ...]
                        Used to set path(s) of lora adapter(s). One can input key-value pairs in xxx=yyy format for multiple lora adapters. If only have one adapter, one can only input the path of the adapter.. Default:
                        None. Type: str
  --device {cuda,ascend,maca}
                        The device type of running. Default: cuda. Type: str
  --eager-mode          Whether to enable eager mode. If True, cuda graph would be disabled. Default: False
  --dtype {auto,float16,bfloat16}
                        data type for model weights and activations. The "auto" option will use FP16 precision for FP32 and FP16 models, and BF16 precision for BF16 models. This option will be ignored if the model is a
                        quantized model. Default: auto. Type: str
  --tp TP               GPU number used in tensor parallelism. Should be 2^n. Default: 1. Type: int
  --session-len SESSION_LEN
                        The max session length of a sequence. Default: None. Type: int
  --max-batch-size MAX_BATCH_SIZE
                        Maximum batch size. If not specified, the engine will automatically set it according to the device. Default: None. Type: int
  --cache-max-entry-count CACHE_MAX_ENTRY_COUNT
                        The percentage of free gpu memory occupied by the k/v cache, excluding weights . Default: 0.8. Type: float
  --cache-block-seq-len CACHE_BLOCK_SEQ_LEN
                        The length of the token sequence in a k/v block. For Turbomind Engine, if the GPU compute capability is >= 8.0, it should be a multiple of 32, otherwise it should be a multiple of 64. For Pytorch
                        Engine, if Lora Adapter is specified, this parameter will be ignored. Default: 64. Type: int
  --enable-prefix-caching
                        Enable cache and match prefix. Default: False
  --max-prefill-token-num MAX_PREFILL_TOKEN_NUM
                        the max number of tokens per iteration during prefill. Default: 8192. Type: int
  --quant-policy {0,4,8}
                        Quantize kv or not. 0: no quant; 4: 4bit kv; 8: 8bit kv. Default: 0. Type: int


do we need tornado?

https://github.com/pywren/pywren-ibm-cloud/blob/master/pywren_ibm_cloud/libs/ibm_iam/iam_connector.py
@JosepSampe can you please tell me if we need tornado? if yes, should we add it to dependencies? if not, do you have suggestions for alternatives? thanks

@gilv We have 2 options: Use tornado and add it to dependencies, or move to another library like requests or httl.client as in cf_connector.py.
The question is: Did you use tornado for some reason?

@JosepSampe actually there is no reason for tornado... seems  landed in the code without me noticing it. So i guess you suggest then to remove this package...right?

@gilv Yep, I will change it to requests or http.client

@gilv Fixed in #140


Projection alias

Summary
Adds aliases to Projections, in the same way we have for Event Handlers. They default to the name of the read model class, and can be overridden with a decorator option or a builder method.
Added

An optional alias property on the @projection decorator options.
A .withAlias method on the Projection builder API.

TODO:

[ ] Upgrade contracts to released version

Just update the contracts and it's good to go :)


info is empty and aad is the group context

The info and aad parameters were swapped (spec for reference).
Thanks for Théophile for finding this.

I'm confused. As I read the spec, it should be first info, then aad. But then your changes move the group_context to the aad field?

Order doesn't matter, it's different everywhere. The spec defines SetupBaseS(node_public_key, "") for SetupBaseS(pkR, info) and Seal(group_context, path_secret) for ContextS.Seal(aad, pt). So the info is empty and the group_context is the aad. This is currently the other/wrong way.


Created release notes for 2.10 release

Description
Created release notes for 2.10 release
Issues Resolved
#443
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@navneet1v Could you help add https://github.com/opensearch-project/dashboards-maps/pull/462 to the release notes? Thanks

@navneet1v Could you help add #462 to the release notes? Thanks

sure

@junqiu-lei please review it one more time.


Endpoint: /key/{name}/{profiles} returns same key

Hi!
"/key/{name}/{profiles}" endpoint is meant to do what?
I've created a keystore and added 2 keys, but the endpoint always the same key (the default one) no matters what parameter i provide.

How have you configured the keys?
@dsyer might be able to explain it.

Hi!
I've created a keystore
keytool -genkeypair -alias cbr-setup -keyalg RSA -dname "CN=setup.abc.com.br" -keypass XXXXX -keystore cbr-setup.jks -storepass XXXXX
added another key to it
keytool -genkeypair -alias scc -keyalg RSA -dname "CN=scc.abc.com.br" -keypass XXXXXX -keystore cbr-setup.jks -storepass XXXXXX
application.yml:
encrypt:
keyStore:
location: classpath:/cbr-setup.jks
password: XXXXX
alias: cbr-setup
secret: XXXXX
trying to obtain both keys with:
http://server/key/cbr-setup/default
http://server/key/scc/default
but the endpoint always return the default one (cbr-setup)

I see, the name parameter is not the name of the key, but the name of the application.

Hi, thanks for the feedback!
Sorry, but i dont got it.
For the record, i already made my own EncryptionController with a mapping to get the key based on the parameters, my doubt is if this endpoint was meant to do that.
If it is a bug, we can fix it, if is a feature i whant to understand how it works

I don't think so, but I'm not real familiar with this code.


(GH-144) Add templates for issues and pull requests

Description

This pull requests adds a couple of missing issue templates, a pull request template, a link to the Gitter channel on the issue list and disables creation of blank issues.
Related Issue

fixes #144
Motivation and Context

To have a common template that can be used when creating issues/pull requests.
How Has This Been Tested?

They haven't, but are similar to my own templates used in my projects.
Screenshots (if appropriate):
Checklist:

[ ] My code follows the code style of this project. (No code)
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes. (No code, so no tests added)
[x] All new and existing tests passed. (They should, no code changes have been implemented)

On a related note, additionally a SECURITY.md file could also be added.
However, I am not familiar with the security policy of GitTools, as such I did not add one here.

@AdmiringWorm thank you very much for doing this!

@AdmiringWorm said...
On a related note, additionally a SECURITY.md file could also be added.
However, I am not familiar with the security policy of GitTools, as such I did not add one here.

I think getting this added would be a good idea.  I don't think that GitTools Organisation has a standard for this, so perhaps we should discuss in Slack, and come up with something and then get it added.


SocketIO deployment enters crashloopbackoff when using external redis deployment

Description of the issue
Helm chart socketio deployment crashes when trying to use an existing redis deployment
Context information (for bug reports)
Steps to reproduce the issue

Install MariaDB and Redis externally from erpnext
Install ERPnext using the helm chart and the following values for Redis:

redisQueueHost: "redis-master.default.svc.cluster.local"
redisCacheHost: "redis-master.default.svc.cluster.local"
redisSocketIOHost: "redis-master.default.svc.cluster.local"

Observed result
SocketIO deployment enters crash loop backoff because it still expects the following host: erpnext-redis-socketio not the one specified in the helm chart. This is also the case if the chart is named anything other than "erpnext".
Expected result
Chart deploys successfully
Stacktrace / full error message if available
listening on *: 9000
node:events:356
      throw er; // Unhandled 'error' event
      ^

Error: getaddrinfo ENOTFOUND erpnext-redis-socketio
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:69:26)
Emitted 'error' event on RedisClient instance at:
    at RedisClient.on_error (/home/frappe/frappe-bench/apps/frappe/node_modules/redis/index.js:406:14)
    at Socket.<anonymous> (/home/frappe/frappe-bench/apps/frappe/node_modules/redis/index.js:279:14)
    at Socket.emit (node:events:379:20)
    at emitErrorNT (node:internal/streams/destroy:188:8)
    at emitErrorCloseNT (node:internal/streams/destroy:153:3)
    at processTicksAndRejections (node:internal/process/task_queues:81:21) {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'erpnext-redis-socketio'
}

I am able to use separate Elasticache in one of the clusters.
On another cluster I've setup separate redis server manually and I can access it by private ip.
Check networking of the external helm chart, does it need extra config to make it available for access?

I am able to use separate Elasticache in one of the clusters.
On another cluster I've setup separate redis server manually and I can access it by private ip.
Check networking of the external helm chart, does it need extra config to make it available for access?

I believe I have solved it. I did not realize that the env variables are saved on the first deployment and not used afterward (documented in the docker images). This would be helpful to document in this repo. I was using an AWS EFS storageclass (to achieve ReadWriteMany on sites_dir) that persisted after a helm uninstall. Originally I installed the helm chart as default (with the redis deployments) and only afterward switched to an external Redis deployment.

I believe I have solved it. I did not realize that the env variables are saved on the first deployment and not used afterward (documented in the docker images). This would be helpful to document in this repo. I was using an AWS EFS storageclass (to achieve ReadWriteMany on sites_dir) that persisted after a helm uninstall. Originally I installed the helm chart as default (with the redis deployments) and only afterward switched to an external Redis deployment.


Server Error. certificate has expired

error appears when running npm run serve-h

solution is at: https://stackoverflow.com/questions/59621948/firebase-tools-error-certificate-has-expired
cause: outdated firebase cli tool
solution: running npm i -g firebase-tools@latest


Typos in tests, rendering them ineffective

The following tests compare values against themselves instead of the expected values:
/src/github.com/soundcloud/visor/runner_test.go:53:5: identical expressions on the left and right side of the '!=' operator
/src/github.com/soundcloud/visor/runner_test.go:56:5: identical expressions on the left and right side of the '!=' operator
/src/github.com/soundcloud/visor/runner_test.go:170:6: identical expressions on the left and right side of the '==' operator

Thank you for the report. Visor is legacy and I do not recommend using it. We've run into many problems with its implementation and have many lessons learned about some of the design decisions. A few things are mentioned in my talk at KubeCon last year: http://www.slideshare.net/dagrobie/moving-to-kubernetes-tales-from-soundcloud
I recommend looking into modern container management software built upon docker or rkt. At SoundCloud we transitioned to Kubernetes.


Beta 2.29 alpha version and known issues tracking

Installation instructions:

Download ToolboxBeta.zip
Extract the ToolboxBeta.zip archive
Open your GWToolbox settings folder. You can find it at C:\User\<user>\AppData\Local\GWToolboxpp. You can also find it by typing %LOCALAPPDATA%\GWToolboxpp in your start menu or explorer path
Backup your toolbox settings! Copy and paste the following files somewhere else: GWToolbox.ini, builds.ini, herobuilds.ini, AgentColors.ini, interface.ini, Markers.ini, Theme.ini
Replace the GWToolbox.dll with the one you downloaded above
Launch GWToolbox.exe as usual. It will only work if you have only one GW client running. It may ask to update. Hit "Skip for now". You will want to accept the update once the message shows a new version.
Report bugs and feedback! Known issues will be listed below.

Known bugs:

[X] Price check in Material window crash Guild Wars.
[x] Opening Xunlai from Info window crash Guild Wars.
[x] Opening a template link will crash Guild Wars.
[ ] Tick-is-toggle is disabled.
[x] "Maintain fov" try to maintain the fov, but patch was removed from GWCA.
[x] Active pcons are not loaded from settings on restart anymore.

Launcher bugs:

[x] Can't read character names, so launcher won't work with multiple GW copies open.

Hello, I am not sure what is described by

Opening a template link will crash Guild Wars. (hint: disable that in settings)

If I try to open "Template code" from the game interface Guild Wars crash. I disabled from the toolbox settings:

Game Settings --> Open web links from templates
Game Settings --> Automatically change urls into build templates

But it still crashes. Is my bug a new one or the same described? If it's the same, am I disabling the correct settings?

Hello, I am not sure what is described by

Opening a template link will crash Guild Wars. (hint: disable that in settings)

If I try to open "Template code" from the game interface Guild Wars crash. I disabled from the toolbox settings:

Game Settings --> Open web links from templates
Game Settings --> Automatically change urls into build templates

But it still crashes. Is my bug a new one or the same described? If it's the same, am I disabling the correct settings?

Sorry, you're right, it will crash regardless. I didn't actually test that one.

whenever inside the game while running around anywhere or not moving ur character model or the screen itself tends to shake a little bit, however, I do not know if that is with Toolbox or not because without TB Open the character model doesn't tend to shake around

@3vcloud and I sorted the fov one

Before this beta version, the toolbox was memorizing the last pcons used between reload.
For example, if I had golden eggs active and relaunch the toolbox the golden eggs were still active.
With the beta version after a relaunch it disabled all the pcons.

https://github.com/HasKha/GWToolboxpp/commit/b86606d5b89a6363828356f3af7aa4bc98e4df9c ("Fix bug with loading active pcons")
just compiled it, it still does not activate the pcons set in the ini file (still all pcons are disabled).

Did you try to set some, close toolbox and restart it? Because, the previous version probably disable everything in GWToolbox.ini.

yes, that's what i did. i also checked my GWToolbox.ini for the values in [pcons] and it seems

values get ignored at start of TB
pcons changes are not saved to ini (when i close TB or when i press "save now" in settings), the ini file stamp is modified though
other changes i do seem to work as intended (still changed after TB restart)

tyvm

sry, my bad. i used the old dll for testing and did not notice. everything works as intended now, as far as i can see.
tyvm

Release was made and made a new issue for tick is toggle which can be found at #391.

I'm trying to launch the 2.29 version, but it gives the following error:

GWToolbox++ - Clientside Error Dete...
Please restart guild wars and try again.

@kazerniel u didnt put GWToolbox.dll in ur Toolbox directory folder
instructions are here that I typed up: Toolboxpp/releases/tag/2.29_Release - use new GWTB_Launcher and set GWToolbox.dll in %localappdata%/GWToolboxpp (installation folder) for dll (type %localappdata% in start menu and look for GWToolboxpp folder and put dll in GWToolboxpp folder)

instructions are here that I typed up: Toolboxpp/releases/tag/2.29_Release - use new GWTB_Launcher and set GWToolbox.dll in %localappdata%/GWToolboxpp (installation folder) for dll (type %localappdata% in start menu and look for GWToolboxpp folder and put dll in GWToolboxpp folder)

Thanks, I thought I did those steps, but apparently not. Which exe should I set to launch with GW1 after the patching?

@kazerniel set GWTB_Launcher.exe to set after patching


feat(esm): move to ESM

Current dependencies on/for this PR:

main

PR #78   👈

This comment was auto-generated by Graphite.


In collect to vector, drop any partial result on unwinding

When collecting into a vector, track initialized values for correct drop on unwind
The collect folder produces a CollectResult<'c, T>,
This is a "proxy owner" of the slice of elements that the folder has
written to, and if unwinding happens under way, the elements will
be dropped.
Rewrite the Collect methods so that it is used like this:
Collect::new(&mut vector, len).with_consumer(|consumer| ... );

Where the closure must run the collect consumer and return a
CollectResult of the promised length, to prove that the whole vector
has been written to.
The Collect can assert that the final CollectResult is covering the
target slice. The CollectResult borrows from the target slice, and the
lifetime parameter ensures that the collect caller can't subsitute or
fake the collect result.
The previous atomic used for counting writes is now removed, since
we trust the collected result instead. The producers under way
could misbehave, but in that case the CollectResult will not
end up correct.
Motivation
Even though it is accepted that drops may not run in corner cases, it should
not be routine that we leak on unwind. A robust system should be recoverable
to the best of its ability. The consumer result model maps well to tracking
initialized parts of the target, so the complexity cost is rather low for this change.
Not addressed in this PR
Current best practices for uninitialized values want us to use raw pointers,
raw slices or MaybeUninit<T>; existing parts of the code have not been
updated for this; MaybeUninit (Rust 1.36) can't be used at this point
and raw slices can't be created directly from raw pointers (not in any stable
Rust version).

Second draft posted. With more lifetime parameters so that the borrowing is correct. After working with the tests, I think the types guide usage of the collect consumer well, and it's impossible to fool it into creating a non-empty Vec without the whole area having been written to.
There are some inelegant parts, around the verify* function.

(Sorry for the noise). Third draft posted. Using a scoping function on struct Collect solves the previously not so pretty ends. Now, filling up the collect consumer and checking the result are integrated steps, so that it's much easier to use the API correctly.

I feel like if I just sit back, you're going to converge on an ideal implementation all by yourself!

I want to stop and not make further changes (unless we decide something in review). Remake of the uninit memory handling would be interesting, but we can do the best job if we have access to MaybeUninit, I think.

Interesting -- I was worried what the more-involved folding would do to performance, but at least on my Ryzen 3800X, it's faster! I guess removing that shared atomic helps, but I'm surprised it's so much.
$ cargo benchcmp bench.master bench.pr759
 name                                              bench.master ns/iter  bench.pr759 ns/iter  diff ns/iter  diff %  speedup
 vec_collect::vec_i::with_collect                  771,504               726,315                   -45,189  -5.86%   x 1.06
 vec_collect::vec_i::with_collect_into_vec         780,705               720,810                   -59,895  -7.67%   x 1.08
 vec_collect::vec_i::with_collect_into_vec_reused  448,375               407,077                   -41,298  -9.21%   x 1.10

This PR was my training grounds for doing the same for ndarray.
The n-dim case is pretty similar, because we arrange for the output array to be split only in such a way that each chunk is contiguous like a slice.
Instead of matching producer to consumer, both the input arrays and the output is handled in the producer.
We make an internal parallel iterator that produces the split parts as the iterator item. That means we can use standard rayon .reduce() to do the equivalent job of the collect reducer here, to combine the partial results. But it doesn't have the rigorous lifetime parameter use as this PR has.
The code is WIP and a current link is: https://github.com/rust-ndarray/ndarray/blob/24f0b20c11f36e7e56a51399e73c77d879710107/src/parallel/impl_par_methods.rs#L85-L130

Both the atomic and the folds would have a larger impact in the scenarios when we have a lot of rayon threads, and split the work much more than needed. Maybe the impact is much less noticeable with less threads?

(In my tests I was surprised to find that a > million element array was partly split down into single element parts; those weren't the most important chunks being processed, but still.)

Yeah, the adaptive splitting can get really aggressive in the tail end of computation. I usually suggest folks just add with_min_len, but maybe we should figure out an automatic limit, because this often surprises people.

I've moved the test. I'm unsure of the benefit from NonNull in this case, is it wanted for code "style" reasons?

@cuviper Oh on adaptive splitting, I have only been surprised, not have it bother me in performance yet (but it could be a reason we have to prefer a lower thread count for rayon, actually). with_min_len does not apply to ndarray's unordered producers, unfortunately. (For some producers, it makes sense to configure them in terms of maximal number of splits instead.)

I'm unsure of the benefit from NonNull in this case, is it wanted for code "style" reasons?

I like the self-documentation, and the chance for niche layout, but off-hand I don't know where it would matter in this case. Not a big deal.
Looks good, thanks!
bors r+


Don't joinFavorite

There's no need to call joinFavorite - if connman has a favorite network, it will already have joined at boot (unless it is badly configured). Previous networks will now be joined as per the connectionFile.
This should optimize start up time a bit.
This will also fix #10 in the meantime, while Doodle3D/connman-simplified#18 is merged and published.

LGTM


[WIP] Detach diff algorithm from main module [Re-created]

TODO

[x] Determine module name. => Differentiator

[x] Determine functions each module.

[x] Fix Tests.

[x] Remove WIP commits when merge into master.

[x] Tidy up Directories

[ ] Fix podspec

[x] Update RxDataSources.podspec
[x] Add Differentiator.podspec
[ ] pod trunk push Differentiator.podspec ( @kzaher please push )

[x] Bump up version 2.0.0 (Because, this PR has big changes)

[x] Fix scripts/common.sh

[ ] Update CHANGELOG.md

[ ] Update README.md

[ ] Test carhtage build --no-skip-current

[ ] Test pod lib lint

[x] Fix Travis

Breaking changes

Add Differentiator Module
DifferentiatorError -> Diff.Error
Remove Example by CocoaPods
Remove Differentiator-Test, Using Test
Remove xcworkspace, Pods/

#149
Memo

Old #153

@kzaher
Why did you add RxSwift as git-submodule? (in master-branch)
Vendoring also can by Carthage.
Therefore, Scripts will be getting simpler.

Hi @muukii ,
I think we would like to support CocoaPods, Carthage and git submodules everywhere. SPM is nice to have but I think it still doesn't work for iOS development.
If somebody just wants to hit run in Xcode and check how something works we can just pull RxSwift using submodules and run it. It takes 4 lines of code do do that.
Otherwise somebody maybe doesn't use Cocoapods or Carthage and we'll probably have issues raised that somebody can't run the project, or we won't have issues raised and people will just close it and assume it doesn't work.
We want to have as few assumptions as possible for somebody to be able to successfully run the project once he clones it and once somebody has Xcode, he will have git.


linux go1.12.2 tensorflow 2.3.1 installation error

I am facing this issue with TensorFlow 2.3.1 installation in golang go1.12.2 in ubuntu 20.04 with go mod.
Error:
go: downloading google.golang.org/protobuf v1.23.0
go: extracting google.golang.org/protobuf v1.23.0
go build github.com/tensorflow/tensorflow/tensorflow/go/core/protobuf/for_core_protos_go_proto: no Go files in

Full error:
$ go get github.com/tensorflow/tensorflow/tensorflow/go

go: finding github.com/tensorflow/tensorflow/tensorflow/go latest
go: finding github.com/tensorflow/tensorflow/tensorflow latest
go: finding github.com/tensorflow/tensorflow v2.3.1+incompatible
go: downloading github.com/tensorflow/tensorflow v2.3.1+incompatible
go: extracting github.com/tensorflow/tensorflow v2.3.1+incompatible
go: finding github.com/tensorflow/tensorflow/tensorflow/go/core/protobuf/for_core_protos_go_proto latest
go: finding github.com/tensorflow/tensorflow/tensorflow/go/core/protobuf latest
go: finding github.com/tensorflow/tensorflow/tensorflow/go/core latest
go: finding github.com/golang/protobuf/proto latest
go: finding github.com/golang/protobuf v1.4.3
go: downloading github.com/golang/protobuf v1.4.3
go: extracting github.com/golang/protobuf v1.4.3
go: finding github.com/google/go-cmp v0.4.0
go: finding google.golang.org/protobuf v1.23.0
go: finding github.com/golang/protobuf v1.4.0
go: finding golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543
go: finding google.golang.org/protobuf v1.21.0
go: finding github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0
go: finding google.golang.org/protobuf v1.20.1-0.20200309200217-e05f789c0967
go: finding github.com/golang/protobuf v1.4.0-rc.2
go: finding google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60
go: finding github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208
go: finding google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64
go: finding github.com/google/go-cmp v0.3.1
go: finding github.com/golang/protobuf v1.4.0-rc.1
go: finding google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd
go: finding github.com/google/go-cmp v0.3.0
go: downloading google.golang.org/protobuf v1.23.0
go: extracting google.golang.org/protobuf v1.23.0
go build github.com/tensorflow/tensorflow/tensorflow/go/core/protobuf/for_core_protos_go_proto: no Go files in

@sayan1999
Please refer to this resolved issue with same error: # 39744 and let us know.
[similar issues link, #36495 #39307]

This is absolutely right.
Just one question before I close the issue.
My tensorflow c  has version 2.3.1
But the go library wrapper is of version v1.15.0
Why isn't that being an issue??

@sayan1999
Sorry for the delayed response, Could you please create a new issue for the information requested as i did look it up in this link and dint find anything.


Images are not resolved when installed on a subfolder

SS 3.x. SS4 might be OK assuming we're using the module manifest loader to resolve file paths.

Install a project in a subfolder
Go to login
See introduction MFA screen has broken images

It's resolving to the root domain, not the project root.

My BASE_URL constant value is ss37/

This setup is how I work from home, I'm 95% sure there's no issue in SS4 :)


Add a package.json

Package dependencies have changed (express has split its modules into separate packages, etc.), proper way to handle this is with a package.json file that allows npm to do its job -- managing packages.

Closed in #2 by @jcarapia (Thanks!)


Geo support

What are your thoughts about supporting geo features?  For starters, it could be just geopoints with Wikibase-compatible distance and bounding box searches, but eventually it could also store boxes and possibly even arbitrary polygons.  I suspect this would require geometry object values to be stored in a separate index (not sure how Wikibase implements it), or at least to have some geo-specific index.  See also spatial index explanation for PostGIS.
(P.S. awesome project, really! Thank you!!! :) )

It would be amazing! It's not high on my personal priority list because I do not have a use case for it myself at the moment but if someone is willing to contribute it, I would be very please to review and merge the code.

@Tpt thanks, I just began working with rust, might take me a bit of time become rust prolific))
My use case is to replace blazegraph in sophox service. You can see example queries at sophox.org. I think it's a perfect testing place, it has relatively low usage and low stability expectations

@nyurik Amazing! I am not sure Oxigraph is ready for Sophox scale for now (I am huge fan of it, thank you!). I am currently working on a v0.3 version that improves a lot of stuff and adds a fast bulk loader. So, if you start to deep dive, the in-development v0.3 branch is quite different from the current main branch.

Thanks! I'm a bit surprised you do development in a versioned branch - usually most projects have main branch as the most unstable and up to date, but sure :) Bulk loader is obviously critical - blazegraph has a system for zipped ttl file processing that works fairly well, but makes my code a bit more complicated - when processing initial data I need to generate one format, whereas for updates I must use SPARQL insert queries. Not a biggie, not sure its possible to combine the two.
Why do you say Oxigraph wouldn't scale?  What kind of issues do you forsee?

Bulk loader is obviously critical - blazegraph has a system for zipped ttl file processing that works fairly well, but makes my code a bit more complicated - when processing initial data I need to generate one format, whereas for updates I must use SPARQL insert queries. Not a biggie, not sure its possible to combine the two.

Doing bulk loading when no one is reading the database is much easier: the system does not have to take care of being always consistent while loading that data. It's why there is a huge incentive of providing a separated "bulk loader".

Why do you say Oxigraph wouldn't scale? What kind of issues do you foresee?

Sorry, I was saying that v0.2 is not scaling well at the moment, not that Oxigraph won't scale in the future.
There are two challenges with the v0.2 version:

Loading is slow: a recent Wikidata dump will take a few days to load. The bulk loader aims to fix that.
There is no real query optimizer and some dumb evaluation operator implementations: some queries that should be fast and are quite fast in Blazegraph are very slow. For the dumb operators, they are fixed in the v0.3 branch. For query optimization it's a huge work I leave the follow up versions (0.4...).
To summarize, the v0.1 and v0.2 version were about making Oxigraph work, v0.3 and later versions are about making Oxigraph fast.

Sounds great, thanks!  Two days to ingest might be okayish, but query performance is kinda important :)  I wonder if LLVM can be used somehow to optimize the query (I'm not sure if #31 LLVM mention is relevant).  Regardless, I'm OK running the bleeding edge dev version (that's why i was mentioning main branch as the root) -- this way i can simply do an update&rebuild right on the prod server - worst case -- i will have to rebuild.
One other related question -- Blazegraph allows code extensions to optimize certain URI storage, e.g. the wd: is stored with a well known numbered prefix + the Q number, not as a long string. Does oxigraph support that?

Thank you!

I wonder if LLVM can be used somehow to optimize the query (I'm not sure if #31 LLVM mention is relevant).

Yes, people sometime compile CPU-heavy query parts to make them faster. PostgreSQL and Spark SQL are using it for example. But it is likly to not bring much improvements for SPARQL queries that are more I/O heavy.

Regardless, I'm OK running the bleeding edge dev version (that's why i was mentioning main branch as the root).

Yes, it's a great idea! But don't use more "current hacking" branch like the v0.3 branch, I do not care much about providing automated migration between individual commits in these branches.

One other related question -- Blazegraph allows code extensions to optimize certain URI storage, e.g. the wd: is stored with a well known numbered prefix + the Q number, not as a long string. Does oxigraph support that?

Not yet but it's very easy to support. I'm going to add this soon.

Not yet but it's very easy to support. I'm going to add this soon.
Thanks, I think this is probably the biggest ask -- with Sophox, I have tons of nodes, ways, and relations, each being essentially a u64, so storing them as full strings might be mega-wasteful.

Hi @Tpt , I noticed that recently a SPARQL engine newcomer - https://github.com/ad-freiburg/qlever - has been gaining a lot of attention because it hosted an example with all OpenStreetMap data (including geometries) as part of its index. I think OSM and similar projects may be a great way to popularize oxigraph index, and gain momentum.  P.S. do you know if qlever (C++) is slower/faster than oxigraph on similar tasks?
Looking forward to oneday migrate my Sophox project to Oxigraph :)

There is now spargeo that implements a small part of the GeoSPARQL standard (the geof:sf* functions)


Explain Application Administrator role

Can you explain why users assigned to this Application Administrator role are not added as owners when creating new application registrations or enterprise applications?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0767aac4-fcd9-eaac-2c30-8f17d8eadd92
Version Independent ID: a380a828-03f9-e037-3a62-e4165fda7cb6
Content: Azure AD role descriptions and permissions - Azure Active Directory
Content Source: articles/active-directory/roles/permissions-reference.md
Service: active-directory
Sub-service: roles
GitHub Login: @curtand
Microsoft Alias: curtand

@pirateutopia
Thanks for your feedback! We will investigate and update as appropriate.

@pirateutopia
Thanks for your feedback! We will investigate and update as appropriate.

I think it's a good point to add this to the documentation and I reached out to someone from my team for a more detailed explanation.
CC @curtand

I think it's a good point to add this to the documentation and I reached out to someone from my team for a more detailed explanation.
CC @curtand

Hi @pirateutopia, one main difference is in managing the application proxy settings. The Application Administrator role grants the ability to manage Application Proxy Settings, whereas the Application owner role doesn't grant the same.
Also, Owners can add credentials to an application and use those credentials to impersonate the application’s identity. The application may have more permissions than the owner, and thus would be an elevation of privilege over what the owner has access to as a user or service principal. An application owner could potentially create or update users or other objects while impersonating the application, depending on the application's permissions.
https://docs.microsoft.com/en-us/azure/active-directory/roles/concept-delegation
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/hallelujah-azure-ad-delegated-application-management-roles-are/ba-p/245420
Hope this helps!

Hi @pirateutopia, one main difference is in managing the application proxy settings. The Application Administrator role grants the ability to manage Application Proxy Settings, whereas the Application owner role doesn't grant the same.
Also, Owners can add credentials to an application and use those credentials to impersonate the application’s identity. The application may have more permissions than the owner, and thus would be an elevation of privilege over what the owner has access to as a user or service principal. An application owner could potentially create or update users or other objects while impersonating the application, depending on the application's permissions.
https://docs.microsoft.com/en-us/azure/active-directory/roles/concept-delegation
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/hallelujah-azure-ad-delegated-application-management-roles-are/ba-p/245420
Hope this helps!


[Forwardport v2.6.3-patch2] Bump rke for fix where addon jobs are stuck in removing

Forwardport of https://github.com/rancher/rancher/pull/36076/commits
https://github.com/rancher/rancher/issues/36642

@kinarashah , would it make sense to bump to the released RKE1 version? Or do we bump to released RKE1 as part of release checklist for Rancher release. Besides updating KDM data, referencing released 1.3.5 vs. the specific commit would bring in this change (https://github.com/rancher/rke/pull/2803), not sure if it's safe to do so. We want to minimize the amount of changes we get into the patch.
Let us know your thoughts on this.

We should be ok bumping RKE to v1.3.7, the change around hostnames is to fix an issue for clusters with AWS cloud provider - it needs rke-tools:v0.1.79 but is a no-op without rke-tools. I've let @sowmyav27 know this is an extra thing we should validate with this patch release.

@jakefhyde , given the comment above from @kinarashah let's bump RKE to 1.3.7. Thank you.


Improve missing dependency at specific version error

Currently Nickel returns the same error if a dependency is not present at all, or present but at an older than required version - these should be two separate messages.

Done in upcoming Nickel 1.0.0.


fix(remasc): add tex rendering through katex

What

Enable the tex rendering in the REMASC page

Why

The page is missing key information to understand how it works
The tex rendering was disabled

⚠ IMPORTANT

there was no way to test the output build locally, at least it wasn't described in the readme

Additional notes

render_features: "equations" isn't required, same as for the other features, but I haven't removed it yet

Refs
Below just one example of the page sections that aren't currently rendering as expected
Before

After

@antomor Thank you for submitting these changes.
Could point out the other features that are not required? Also, what's the way to test the build output? If there's any reference to this, I can add it to the docs.
Thanks.


round decimals to 2 places

When printing the turtle position in the REPL, we get full precision of the floating point.  We only need 2 decimal places at most.

Hey, is this referring to the output you get after each movement command? Or is there some other print command I'm missing? I'd like to take this on.

@galbacarys This probably refers to the string representation of the turtle. After each movement command the Turtle record is returned, thus printed in the REPL. There are some functions that determine the format of this string

Yes, @jeisses is right.  Keep in mind that there's a difference between println/print (printing meant for humans to read)  and prn/pr (printing in such a way that the REPL's reader can read them).  The REPL uses prn to print return vals.
A custom prn has already been implemented / extended for Turtle values for CLJ and for CLJS.  So for the purposes here, we just need to work within the pr-str-turtle fn to customize how the values for :x, :y, and :angle get turned into a string.  The math libs in Java vs. JS are probably different, so we'll need reader conditionals.
On second thought, I think just one digit after the decimal point is enough.


Spark lineage: Delete Task changed name/URN and appeared in lineage, didn't appear in spark platform UI

See slack thread here:
https://datahubspace.slack.com/archives/CUMUWQU66/p1672494615000419
found out that I should have used Spark shell instead of Spark%20shell, which I copied from the UI link.
More importantly, the deletion for Spark lineage only works with the hard way, not the soft way. This should be an issue. (edited)
white_check_mark
eyes
thanks_bear
Also, the deleted task changed its name to the urn and still appeared on the lineage (píc 1), although it wasn't seen in the Spark platform UI. So this is another bug.
image.png

I'm reopening the issue since the feature is important.


Large swathes of code are not compatible with Python 3

https://pythonclock.org/

Awesome! Thanks!

I feel like the Python 3 notes were added to #46 in error, those are in that ticket and this [google doc](https://docs.google.com/document/d/1kfhpqUKN3zAToC2_gdYMaZ0QYu641VjziycnfpVf5i8/edit# not ) forgotten, just misplaced.

TODO:

[ ] Code marked # TODO PY3.

Filter: https://github.com/exponential-decay/demystify/issues?q=is%3Aopen+is%3Aissue+label%3Apython-3

There is a Python 3 release here: https://github.com/exponential-decay/demystify/releases/tag/v1.0.0
And a discussion about next steps here, with Packaging likely to be the next most important thing, with sqliteid to be packaged first: https://github.com/exponential-decay/demystify/discussions/68
@joshuatj if you happen to have time to give the new version a whirl, it'd be a great help if you managed to turn up any issues. Anyone else following along is welcome to give it a whirl too.
Closing this issue now, ceremoniously. If there are issues with the new release, separate new issues would most helpful.


IBM.com style model research part 1

Notes
In order to support our adopters and help them make the best decisions re: style models for ibm.com, we need to identify and communicate design research best practices.
Problem
When designers are tasked with designing ibm.com experiences, they don't always know where to start. Design research can provide insights and best practices for designers to follow and apply to their work. IBM has robust user research tools but less design (visual, UX, interaction) guidelines.
Tasks

Map out design research flow/steps
Identify existing tools and resources that designers can use to get started
Propose new methods or tools that we need to provide
Consider how this fits into style model, library, system etc.

Things to consider:

What kind of sprint epics/stories can we create around research
What does the framework look like
How can our DDS designers research and feed into adopters

Created this Mural to map out ideas and steps.

Closing this issue. Will open a new one to track the continuation of this work.


Can this run in a container? Getting error

I'm trying to run this action in a container like below:
name: Deploy PR previews

on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
      - closed

concurrency: preview-${{ github.ref }}

jobs:
  deploy-preview:
    runs-on: [ self-hosted ]
    container: artifactory.mycompany.com/swr-docker-release/build-image/base:stable
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 14.17.0

      - name: Yarn install
        uses: borales/actions-yarn@v4
        with:
          cmd: install
          dir: ./app

      - name: Build production bundle
        uses: borales/actions-yarn@v4
        with:
          cmd: build
          dir: ./app

      - name: Deploy preview
        uses: rossjrw/pr-preview-action@v1
        with:
          source-dir: ./app/dist/

Note that this uses the container option with an artifactory URI to grab the image.
The following error is encountered:
Run /home/myuser/runners/01/_work/_actions/rossjrw/pr-preview-action/v1/lib/find-current-git-tag.sh -p $actionrepo -f $actionref
  /home/myuser/runners/01/_work/_actions/rossjrw/pr-preview-action/v1/lib/find-current-git-tag.sh -p $actionrepo -f $actionref
  shell: bash --noprofile --norc -e -o pipefail {0}
  env:
    action: auto
    targetdir: pr-preview/pr-232
    pr: 232
    pagesurl: swr.github.io/sre-portal
    emptydir: /tmp/tmp.GEsaOyeWhF
    datetime: 2023-04-26 05:10 UTC
    actionref: v1
    actionrepo: rossjrw/pr-preview-action
    deployrepo: swr/sre-portal
    token: ***
/__w/_temp/0dec96f1-b2e1-4f04-a548-60ec5383fe95.sh: line 1: /home/myuser/runners/01/_work/_actions/rossjrw/pr-preview-action/v1/lib/find-current-git-tag.sh: No such file or directory

Looks like this is caused by https://github.com/actions/runner/issues/716

This works great. Thanks for the fix!
I have other questions but I'll open another issue for that.

Excellent, thank you
Please feel free to!

Thanks @predominant. Noting that this is now released as of  v1.4.1, so you can switch back to rossjrw/pr-preview-action@v1 and get the fix.


The result of Centerpoint training on KITTI.

Hi,
I am now trying to study how to training Centerpoint on KITTI. My setting is training on the original KITTI dataset of 20 epoches.  Did you get similar results?
And what does the "Cyclist<EMAIL_ADDRESS>0.25, 0.25" mean? Could we modify the setting? Or this setting is fixed because we use the KITTI dataset?

Thanks in advance!

sounds reasonable. Some other people also tried this code and he got the following result with 80 epochs.
bbox AP:95.4993, 89.6682, 88.9629
bev  AP:89.8679, 87.6789, 85.9437
3d   AP:88.2657, 78.2677, 76.8833
aos  AP:95.46, 89.56, 88.80
Car<EMAIL_ADDRESS>0.70, 0.70:
bbox AP:97.6554, 94.1077, 91.6578
bev  AP:94.0013, 88.4244, 87.5006
3d   AP:90.4481, 81.1609, 76.7102
aos  AP:97.62, 93.97, 91.47
Car<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:95.4993, 89.6682, 88.9629
bev  AP:95.5043, 89.8126, 89.2684
3d   AP:95.4466, 89.7798, 89.1959
aos  AP:95.46, 89.56, 88.80
Car<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:97.6554, 94.1077, 91.6578
bev  AP:97.7235, 94.6102, 94.0849
3d   AP:97.5920, 94.5400, 93.8753
aos  AP:97.62, 93.97, 91.47
Pedestrian<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:72.7394, 69.3657, 66.4774
bev  AP:57.3676, 54.3496, 51.8871
3d   AP:52.3187, 50.2359, 45.8078
aos  AP:71.13, 67.24, 64.13
Pedestrian<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:72.9846, 70.1345, 66.9384
bev  AP:57.4010, 55.0816, 51.4492
3d   AP:52.3284, 49.7867, 45.8620
aos  AP:71.35, 67.77, 64.27
Pedestrian<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:72.7394, 69.3657, 66.4774
bev  AP:76.5806, 75.6884, 72.9038
3d   AP:76.5774, 75.4502, 72.5838
aos  AP:71.13, 67.24, 64.13
Pedestrian<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:72.9846, 70.1345, 66.9384
bev  AP:78.2667, 77.0423, 73.7477
3d   AP:78.2629, 76.7177, 73.4710
aos  AP:71.35, 67.77, 64.27
Cyclist<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:86.0278, 76.6100, 73.2047
bev  AP:78.2635, 66.3874, 62.1329
3d   AP:75.6480, 63.4762, 58.7180
aos  AP:85.89, 75.86, 72.50
Cyclist<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:91.0578, 77.7942, 74.1132
bev  AP:82.0086, 66.1239, 62.3801
3d   AP:77.1098, 62.2293, 58.4965
aos  AP:90.90, 76.93, 73.31
Cyclist<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:86.0278, 76.6100, 73.2047
bev  AP:82.8018, 71.4711, 68.1855
3d   AP:82.8018, 71.4711, 68.1855
aos  AP:85.89, 75.86, 72.50
Cyclist<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:91.0578, 77.7942, 74.1132
bev  AP:87.1466, 72.2116, 68.6427
3d   AP:87.1466, 72.2116, 68.6427
aos  AP:90.90, 76.93, 73.31

And what does the "Cyclist<EMAIL_ADDRESS>0.25, 0.25" mean? Could we modify the setting? Or this setting is fixed because we use the KITTI dataset?

I guess it means using iou threshold 0.5 / 0.25 /0.25 for easy /moderate / hard split evaluation. The evaluation code is taken from openpcdet (which is taken from second), please check the code here https://github.com/tianweiy/CenterPoint-KITTI/tree/main/pcdet/datasets/kitti/kitti_object_eval_python for modification

OK. Thank you very much!

Hi,
I am now trying to study how to training Centerpoint on KITTI. My setting is training on the original KITTI dataset of 20 epoches.  Did you get similar results?
And what does the "Cyclist<EMAIL_ADDRESS>0.25, 0.25" mean? Could we modify the setting? Or this setting is fixed because we use the KITTI dataset?

Thanks in advance!

Hi, yaxi. There is a tricky problem when I run the CenterPoint-KITTI code as follows:

I never modify any functions or implementations in this project, but the bug still exists. Did you have encountered it when you ran the code, or how to solve this problem in your view?
Any instructions would be appreciated!

The error seems to be related to something about CUDA. I haven't met the error before. But I think maybe you can try to check if your CUDA successfully runs now?

The error seems to be related to something about CUDA. I haven't met the error before. But I think maybe you can try to check if your CUDA successfully runs now?
Thanks for quick reply. You know, this project is based on OpenPCDet, and I have tried to run PV-RCNN model using config file 'pvrcnn.yaml' and corresponding modules. The CUDA usage is normal and training results are OK. The most difference between CenterPoint_rcnn and PVRCNN model is the choice of 'DenseHead', the former uses 'CenterHead', and the latter is 'AnchorHeadSingle'.
Maybe the definition of variances or tensors in 'centerpoint_head_single.py' file is abnormal, but I have not find the error localization yet. Anyway, thanks for your help.

The error seems to be related to something about CUDA. I haven't met the error before. But I think maybe you can try to check if your CUDA successfully runs now?

Thanks for quick reply. You know, this project is based on OpenPCDet, and I have tried to run PV-RCNN model using config file 'pvrcnn.yaml' and corresponding modules. The CUDA usage is normal and training results are OK. The most difference between CenterPoint_rcnn and PVRCNN model is the choice of 'DenseHead', the former uses 'CenterHead', and the latter is 'AnchorHeadSingle'.
Maybe the definition of variances or tensors in 'centerpoint_head_single.py' file is abnormal, but I have not find the error localization yet. Anyway, thanks for your help.

Hi，tianwei， Thanks for your great work.  I have trainied on the original KITTI dataset of 80 epoches. And what I got is as follows:
2021-12-07 13:10:28,513   INFO  *************** Performance of EPOCH 80 *****************
2021-12-07 13:10:28,514   INFO  Generate label finished(sec_per_example: 0.0208 second).
2021-12-07 13:10:28,515   INFO  recall_roi_0.3: 0.970305
2021-12-07 13:10:28,515   INFO  recall_rcnn_0.3: 0.970647
2021-12-07 13:10:28,516   INFO  recall_roi_0.5: 0.929803
2021-12-07 13:10:28,516   INFO  recall_rcnn_0.5: 0.934922
2021-12-07 13:10:28,517   INFO  recall_roi_0.7: 0.706809
2021-12-07 13:10:28,517   INFO  recall_rcnn_0.7: 0.746630
2021-12-07 13:10:28,520   INFO  Average predicted number of objects(3769 samples): 10.731
2021-12-07 13:11:01,067   INFO  Car<EMAIL_ADDRESS>0.70, 0.70:
bbox AP:95.2857, 89.6313, 89.2404
bev  AP:90.3275, 88.2867, 87.7532
3d   AP:89.4909, 83.2637, 78.8692
aos  AP:95.25, 89.55, 89.07
Car<EMAIL_ADDRESS>0.70, 0.70:
bbox AP:98.0934, 94.4439, 93.9938
bev  AP:94.3235, 90.8604, 88.6803
3d   AP:92.0645, 84.4424, 82.4541
aos  AP:98.07, 94.32, 93.77
Car<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:95.2857, 89.6313, 89.2404
bev  AP:95.2959, 94.0862, 89.2930
3d   AP:95.2515, 89.6288, 89.2513
aos  AP:95.25, 89.55, 89.07
Car<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:98.0934, 94.4439, 93.9938
bev  AP:98.0890, 96.2918, 94.3611
3d   AP:98.0683, 94.5043, 94.2440
aos  AP:98.07, 94.32, 93.77
Pedestrian<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:73.6650, 69.5978, 65.6966
bev  AP:66.1943, 60.8831, 55.6450
3d   AP:64.8805, 58.6524, 53.9130
aos  AP:69.63, 64.79, 60.77
Pedestrian<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:74.9979, 70.0114, 65.9919
bev  AP:67.5638, 60.6372, 55.9727
3d   AP:65.4102, 58.2713, 53.4406
aos  AP:70.58, 64.82, 60.53
Pedestrian<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:73.6650, 69.5978, 65.6966
bev  AP:78.0926, 74.4098, 71.2914
3d   AP:78.0364, 74.1602, 71.0305
aos  AP:69.63, 64.79, 60.77
Pedestrian<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:74.9979, 70.0114, 65.9919
bev  AP:80.1906, 75.3926, 71.5281
3d   AP:80.1303, 75.1233, 71.3368
aos  AP:70.58, 64.82, 60.53
Cyclist<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:93.7740, 78.5067, 76.7421
bev  AP:92.0618, 75.4258, 71.7374
3d   AP:87.3487, 72.9806, 68.8436
aos  AP:93.62, 78.09, 76.27
Cyclist<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:96.1210, 80.9916, 77.9249
bev  AP:94.3779, 76.2991, 72.6507
3d   AP:91.3215, 72.8844, 69.2675
aos  AP:95.97, 80.52, 77.39
Cyclist<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:93.7740, 78.5067, 76.7421
bev  AP:92.4993, 78.2184, 73.8739
3d   AP:92.4993, 78.2184, 73.8739
aos  AP:93.62, 78.09, 76.27
Cyclist<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:96.1210, 80.9916, 77.9249
bev  AP:95.0883, 79.1689, 75.9057
3d   AP:95.0883, 79.1689, 75.9057
aos  AP:95.97, 80.52, 77.39
I am not sure this is the correct result or not. Should I compare it with the result you released? Or is it compared with which baseline?
I am looking forward to your reply!
Thanks!

Hi，tianwei， Thanks for your great work. I have trainied on the original KITTI dataset of 80 epoches. And what I got is as follows:
2021-12-05 00:41:48,050   INFO  *************** Performance of EPOCH 76 *****************
INFO:pcdet.utils.common_utils:*************** Performance of EPOCH 76 *****************
2021-12-05 00:41:48,050   INFO  Generate label finished(sec_per_example: 0.0134 second).
INFO:pcdet.utils.common_utils:Generate label finished(sec_per_example: 0.0134 second).
2021-12-05 00:41:48,051   INFO  recall_roi_0.3: 0.957791
INFO:pcdet.utils.common_utils:recall_roi_0.3: 0.957791
2021-12-05 00:41:48,051   INFO  recall_rcnn_0.3: 0.958814
INFO:pcdet.utils.common_utils:recall_rcnn_0.3: 0.958814
2021-12-05 00:41:48,052   INFO  recall_roi_0.5: 0.910461
INFO:pcdet.utils.common_utils:recall_roi_0.5: 0.910461
2021-12-05 00:41:48,052   INFO  recall_rcnn_0.5: 0.917743
INFO:pcdet.utils.common_utils:recall_rcnn_0.5: 0.917743
2021-12-05 00:41:48,053   INFO  recall_roi_0.7: 0.659025
INFO:pcdet.utils.common_utils:recall_roi_0.7: 0.659025
2021-12-05 00:41:48,053   INFO  recall_rcnn_0.7: 0.728881
INFO:pcdet.utils.common_utils:recall_rcnn_0.7: 0.728881
2021-12-05 00:41:48,056   INFO  Average predicted number of objects(3769 samples): 11.529
INFO:pcdet.utils.common_utils:Average predicted number of objects(3769 samples): 11.529
2021-12-05 00:42:12,082   INFO  Car<EMAIL_ADDRESS>0.70, 0.70:
bbox AP:96.5962, 88.8321, 88.6788
bev  AP:89.1489, 86.6326, 86.1827
3d   AP:86.9565, 77.0815, 76.8418
aos  AP:96.55, 88.71, 88.46
Car<EMAIL_ADDRESS>0.70, 0.70:
bbox AP:98.2095, 93.5939, 91.5310
bev  AP:94.0437, 87.4882, 87.4322
3d   AP:89.5494, 80.1600, 78.4115
aos  AP:98.17, 93.44, 91.27
Car<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:96.5962, 88.8321, 88.6788
bev  AP:96.6649, 93.6752, 88.7519
3d   AP:96.5549, 88.8252, 88.6973
aos  AP:96.55, 88.71, 88.46
Car<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:98.2095, 93.5939, 91.5310
bev  AP:98.2117, 95.6037, 93.7540
3d   AP:98.1664, 93.6909, 93.5949
aos  AP:98.17, 93.44, 91.27
Pedestrian<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:67.8469, 64.0615, 61.9882
bev  AP:63.6253, 56.8471, 53.4049
3d   AP:60.2016, 53.3828, 49.2598
aos  AP:65.38, 61.01, 58.23
Pedestrian<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:69.1837, 64.2857, 61.7152
bev  AP:63.6414, 56.6040, 52.1890
3d   AP:59.6199, 52.2266, 48.1070
aos  AP:66.34, 60.77, 57.53
Pedestrian<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:67.8469, 64.0615, 61.9882
bev  AP:76.9900, 73.4777, 70.8975
3d   AP:76.9558, 73.3793, 70.7273
aos  AP:65.38, 61.01, 58.23
Pedestrian<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:69.1837, 64.2857, 61.7152
bev  AP:79.1741, 74.8277, 71.6753
3d   AP:79.1308, 74.7097, 71.5131
aos  AP:66.34, 60.77, 57.53
Cyclist<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:89.5139, 76.4873, 73.5068
bev  AP:86.2640, 70.3807, 66.1857
3d   AP:86.0349, 69.6714, 65.4482
aos  AP:89.43, 75.98, 73.05
Cyclist<EMAIL_ADDRESS>0.50, 0.50:
bbox AP:94.4208, 76.8401, 73.8751
bev  AP:88.6273, 71.7297, 67.4997
3d   AP:88.9594, 69.7150, 65.4788
aos  AP:94.30, 76.37, 73.37
Cyclist<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:89.5139, 76.4873, 73.5068
bev  AP:88.6250, 74.1480, 70.6165
3d   AP:88.6250, 74.1480, 70.6165
aos  AP:89.43, 75.98, 73.05
Cyclist<EMAIL_ADDRESS>0.25, 0.25:
bbox AP:94.4208, 76.8401, 73.8751
bev  AP:93.2914, 74.1941, 71.1469
3d   AP:93.2914, 74.1941, 71.1469
aos  AP:94.30, 76.37, 73.37
I am not sure this is the correct result or not. Should I compare it with the result you released? Or is it compared with which baseline?
I am looking forward to your reply!
Thanks!

your results look reasonable. My results (a few months ago) are similar to https://github.com/tianweiy/CenterPoint-KITTI/issues/9#issuecomment-874426375 Yours seem a little lower for car but much higher for ped / cyclist. I guess they are within reasonable variance.

@StiphyJay
Hi, im also training centerpoint on kitti detection dataset. I have tried several different model config defined in tools/cfgs/kitti_models. My best result was generated by centerpoint_rcnn.yaml. But this result is still much lower than yours.
I want to know about your train configurations, for example, the batch_size, the total epoch, and the yaml file used on training.
Thanks!