feat(contributors): add Twitter & Mastodon icons

The Notion table contains Twitter as well but it hasn't been integrated on the page where contributors as displayed.
Solving this issue involves working in Contributors folder:

Finding a Twitter SVG logo in light and dark theme
Expected behavior is the same as for GitHub, LinkedIn etc

Could you try to add Mastodon as well, while you're at it? :pray:

Any update on this, @SohamRatnaparkhi?

Hey @uniqueg
Sorry for holding on this issue so late. I am currently busy in a different venture so I wasn't able to get back to this. I am okay if some else takes up this issue.

Okay, sure - no worries :) Thanks a lot!

@uniqueg please assign this issue to me

Thanks a lot, @valens200 :pray:

The Notion table contains Twitter as well but it hasn't been integrated on the page where contributors as displayed. Solving this issue involves working in Contributors folder:

Finding a Twitter SVG logo in light and dark theme
Expected behavior is the same as for GitHub, LinkedIn etc

Hi, can you please provide more info on this issue?

Twitter and Mastodon profiles are available as full URLs (e.g., https://twitter.com/someuser or https://some.instance/@someuser) from the Notion table under Twitter and Mastodon, just like they are for Linkedin, Orcid, Scholar, Researchgate etc.
Do you need any other info?
I think @git-anurag-hub can tell you where to best find icons/logos. When dealing with these, note that you may need two versions to handle light and dark mode. But again, you can see how this is done for the other social media icons.

@uniqueg  the problem is not where to find those icons, but I can't even see the page where they are needed.

This PR implemented the other social media links: https://github.com/elixir-cloud-aai/landing-page/pull/14

thank you @uniqueg I have fixed the issue


fix(firebase): logout when user session ends

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


Got all nan after training 3 epoches

I trained a [context2vec].(https://github.com/orenmel/context2vec/blob/master/context2vec/train/train_context2vec.py)
I printed the context_v in explore_context2vec.py, and got all nan.
When using tensorflow, I can fix this by adding a small number to the loss function.
cross_entropy = self.target * tf.log(self.prediction+1e-10)
How to do this in chainer?

context2vec uses chainer's built-in negative sampling cost function (not cross_entropy) and this function should be stable. nan values could be related to the configuration of the optimizer, though. I think you should consider configuring the Adam optimizer with a slower learning rate or trying a different optimizer (e.g. SGD).

What is your final loss?

The loss function is chainer.links.NegativeSampling (a popular word2vec loss function). You can look at the code to see exactly how I use it.

Yes, I read the source code. And the learning rate needs to be setted using this:
def lr(self):
        fix1 = 1. - self.beta1 ** self.t
        fix2 = 1. - self.beta2 ** self.t
        return self.alpha * math.sqrt(fix2) / fix1

I added some information to the training data of ukwac. For the first epoch the accuracy is 71.6%, for the second it comes to 70.6% on SE3. To compare with your model, I didn't use other optimizer and parameters.
Will it help if set a drop ratio? My accum_loss/word is about 0.5 now. What is yours?
Thank you very much.

I experimented a little with dropout early on and didn't see it helping much on the dev set so I didn't use it, but I didn't explore this option thoroughly. In your case, where performance seems to decrease with epochs, it does seem to make sense to try dropout.
If you're first trying to reproduce my results the first thing is to make sure that your setting is identical. Please double check that you followed the ukwac preprocessing described in the paper (lowercasing, all words with frequency less than 100 converted to UNK, etc.). Also, would be good if you could share with me the exact command line that you're using to train your model, so I could double check that you're using the same arguments as I did.
PS I already finished my phd and don't currently have a setup for running context2vec, so I can't tell you my accum_loss/word.

Thank you for your kindness.
I used this to train.
 python context2vec//train/train_context2vec.py -i CORPUS_FILE.DIR  -w  WORD_EMBEDDINGS -m MODEL  -c lstm --deep yes -t 100 --dropout 0.0 -u 300 -e 10 -p 0.75 -b 800 -g 0
And I add the pos tag to each word like 'apple_nn' to train the model. But the accuracy is a bit lower than yours.
I changed the learning rate from 0.001 to 0.0005. It is strange . Do you have any advice for me?

I used -b 1000, but that shouldn't make a difference. I also used max-sent-len=64 when running corpus_by_sent_length.py. Of all that, the addition of the pos tag seems to be the one factor that could be significant. I recommend that you try without it.

Hello! We are also having this problem (training on gigaword with ≈100k vocab size); we're going to try switching from Adam to SGD for the optimizer, but can you think of any other reason for the numerical instability?

Looking at the code, it looks like the loss NegativeSampling loss function is returning NaN when asked for its data on line 138 of train_context2vec.py, which sounds to me like either gradient vanishing or exploding. But I'm a bit surprised to see it happen this way- seems like it should have taken a little longer to blow up (or vanish), and also would've resulted in some more dramatic fluctuations in the output numbers before hitting NaN.
Training happily continues for a few more days afterwards, but the resulting vectors are (unsurprisingly) full of NaNs. It happens at different points in the training (i.e., not always after the same number of words) so it doesn't seem to be caused by a malformed chunk of input, or anything like that, at least not as far as we can tell.

@stevenbedrick I decreased the learning rate and got a better result. When you got nan the model is very likely to overfit. So you can stop for you have got a really small number that can't be recognised. Hope my experience helps.

Yes. I'd suggest you try decreasing the learning rate. That can be done both for Adam and SGD.


Unable to use a custom module: RCTLog is not a registered callable module

Description
I'm trying to develop a react-native application.
My application will use a custom-module which, in turn, will call a Swift library.
My issue is that whatever I do I always get Invariant violation errors.
This time, the error I have is: Module RCTLog is not a registered callable module.
React Native version:
System:
OS: macOS 10.15.4
CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Memory: 27.83 MB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 12.11.1 - ~/.nvm/versions/node/v12.11.1/bin/node
Yarn: 1.22.4 - /usr/local/bin/yarn
npm: 6.14.4 - ~/.nvm/versions/node/v12.11.1/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 13.4, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
IDEs:
Android Studio: 3.6 AI-192.7<IP_ADDRESS>08749
Xcode: 11.4.1/11E503a - /usr/bin/xcodebuild
npmPackages:
react: 16.11.0 => 16.11.0
react-native: 0.61.5 => 0.61.5
npmGlobalPackages:
create-react-native-module: 0.18.0
react-native-cli: 2.0.1
react-native-create-library: 3.1.2
react-native-rename: 2.4.1
Steps To Reproduce

git clone https://github.com/ziccardi/RNUnifiedPush.git  - The custom module I'm developing
git clone https://github.com/ziccardi/RNIssue.git - The example project to replicate the issue
cd RNUnifiedPush && yarn install && cd ..
cd RNIssue && yarn install && react-native link && cd ios && pod install && cd .. && react-native run-ios

Expected Results
I'd expect the application to work
Snack, code example, screenshot, or link to a repository:
Already provided in Step to reproduce:

git clone https://github.com/ziccardi/RNUnifiedPush.git  - The custom module I'm developing
git clone https://github.com/ziccardi/RNIssue.git - The example project to replicate the issue
cd RNUnifiedPush && yarn install && cd ..
cd RNIssue && yarn install && react-native link && cd ios && pod install && cd .. && react-native run-ios

Do you have any idea? Am I doing something wrong?

Same for me when I try to follow React Native Modules iOS docs.
https://reactnative.dev/docs/native-modules-ios

We've not been able to have a react-native app working with a swift module, so, in the end, we regrettably rewrote the Swift library using Objective-C.
That way it worked.

Experiencing the same issue

Spent all day yesterday befuddled by this error. I was able to get rid of it by creating a new React Native app in a fresh directory using init --version 0.61.5. I manually reinstalled all of my JS dependencies, did a fresh pod install, and copied over my src files. Somehow it all works?

I'm also encountering this issue within my monorepo.
I imported a component from a separate package in the repo, and this component worked fine with Views/Text/Etc., but when I use react-native's StyleSheet.create within that package, I encountered this same error on both Android and iOS. I couldn't trace the issue back any further than that, but it's stopped me dead in my tracks. I will be watching this issue closely! 🙂

@BillGeoghegan I didn't investigate into this issue anymore because we switched to a plain Objective-C implementation of our module, however, if it can be of any help, if in my example you delete the RNIssue/node_modules/RNUnifiedPush/node_modules folder and re-run the command at point 5:
rm -rf RNIssue/node_modules/RNUnifiedPush/node_modules
cd RNIssue && yarn install && react-native link && cd ios && pod install && cd .. && react-native run-ios

it works.


MVVM Base Classes

Is there a reason the three MVVM base classes (BindableBase, ViewModelBase, and DelegateCommand) are in the projects rather than in the template library?  It would make more sense to me if they were part of the base library, which could be maintained independently of the actual projects using them.

The original intent was to have Template10 be somewhat MVVM framework agnostic... I hear what you are saying and we'll discuss - I'm not sure there is a "correct" approach to take though :)

This is still in a little bit of transition. I would like your feedback on this, too. We moved them into the library, but in all reality, what we want to do is move them back into Minimal and implement them with MVVM Light instead of our own implementation.
The reason is, developers who want to use Caliburn or any other library could then just swap the reference to Cliburn and swap the implementation of those classes to Caliburn, too. Repeat that for MVVM Cross or any other MVVM framework. The migration from one framework to another would be super-simple.
There's no real value in us writing our own micro MVVM framework, no matter how easy it is to do it. At least that is what we are thinking at this moment. I would like your thoughts, for sure.

I agree with you, Jerry.
It makes sense to not provide another MVVM implementation but to use an existing one like MVVM Light that can be eventually replaced.

I agree with using an existing MVVM implementation. I am confused however in how I would use this template if I downloaded this repo.
Would I just copy the minimal project into my own solution and modify it as necessary? How would I then swap out to use MVVMLight?
Is there any like 10 line "how to use this" readme or something?

 Once we get this up and going, we’ll write the documents. Could use some help authoring if you are willing. As for your first question, an existing solution would not download the repo at all, they would add Template10Library from NuGet (which is not there yet so don’t look today). The only manual implementation would be to update their app.xaml.cs base class to Bootstrapper.

Well, it turns out that the custom controls included in the Library simply require a basic set of MVVM implementations. Specifically, the DelegateCommand. This is a class common to most MVVM libraries. I thought I could solve this problem by making the library implementations [internal] and therefore requiring the external implementation by the consuming projects. I have not gotten that to work yet.

I think we have a good plan. Gonna close this discussion.


Developer document

In CONTRIBUTING.md we have:

Read the install guide for build and deploy instructions

It is impossible to build and deploy based on this page. I think now that we have a working test environment we can document how to use it.

Play with the project, submit bugs, submit patches!

It is impossible to play with the project when you cannot install it, but even if you could install it, we need instructions how to run common flows, maybe in the form of example scripts creating applications protected by ramen and using ramen to relocate or failover.

Make sure all tests pass, and add any new tests as appropriate.

Current info is not very useful, we need to point to relevant e2e tests showing the main flows, and instruction how to run the tests and how to add new tests.

I think we need a dedicated document for developers, that can be used by a new contributor to build, deploy, run existing system tests, and play with the system. Something like minikube start.

We have been lax in documentation and also have that as one of the items to complete before the first release of any sort. If you are starting any documentation, let us please look at a broader TOC initially and then start on individual documents.


EBUS or EMS?

Hello!
I have old Junkers atmospheric boiler (ZWC28-1MF2K) and stumbled in docs about using E/BUS devices (thermostats etc.), so the question is:
Does EMS is the same as EBUS older Junkers (Bosch) used?
Also I have started upgrade my heating system (step by step), and have 2 MM100 controllers (for floor/radiators heating accordingly) that are 100% EMS devices, was thinking about creating virtual thermostats from sensors I have in my house -- is it possible?

The EMS bus is something else.
If you know a bit of programming and can take the time to reverse engineer the MM100 than maybe yes.
But I guess the MM100 are also EMS slave devices so you still need an EMS master in the circuit, which would be the boiler.


Fix nightly spr & core perf test

Description

1. Why the change?
This submission install pydantic for spr & core perf test to fix nightly perf test failure:
https://github.com/intel-analytics/ipex-llm/actions/runs/9700292272/job/26771341907
https://github.com/intel-analytics/ipex-llm/actions/runs/9700292272/job/26771342167

It seems that import error of pydantic exists when install [all] option, maybe we also need to fix here or add pydantic in setup.py.

I don't think pydantic is a required option for cpu, as it is required for pp serving. We may update here :)


when I set aug = 'identity' or aug is None, the validation results using your model is exeactly the same

when I set aug = 'identity' or aug is None, the validation results using your model is exeactly the same. is the augmentation not work rightly?

The augmentation only affects the training phase. We're not doing augmentation in validation.

But I indeed found that the below code is still running in validate phase, and I did not find any code distincting training and validating phase.
"control_fields = transform.sample_power(
-0.4, 0.4, 3, tf.stack([bs, 5, 5, 5, 3])) * (np.array(imgs) // 4)
augFlow = transform.free_form_fields(imgs, control_fields)"

Yes, it's expected to run once when building TF graph, but the actual operation is conditioning on the training mode (see framework.py, line 57 and 67).

o, I see. Thank you very much for your help!


fix: format IP address with {:i}

{:ipv4} has been replaced with {:i} in aya-rs/aya#599.
This is causing the following compile error.
error: could not parse the format string: unknown display hint: "ipv4"
  --> src/main.rs:68:9
   |
68 |         "SRC IP: {:ipv4}, SRC PORT: {}", source_addr, source_port
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The build failure with "kprobetcp" example is due to the presence of Cargo.lock. This Cargo.lock refers to the old main branch.
I think this file should be removed from the repository, can I remove it?

I think this is being worked on in https://github.com/aya-rs/book/pull/118. Apologies this didn't get a review in a timely manner.


Adding warning on Windows 10 or 2016

Added warning about the requirement to have Windows 10pro or Windows 2016 to the Windows Containers lab

LGTM


About cpu ressources

Hello,
When I do some tests with kcptun on LAN network ( 100Mbit/s) , ~ 500 Kcp clients to one server,
cpu metric for kcp server is less < 10%
The same test with Wan network , kcp server is ~ 90% of cpu  ,
is there an explanation ? resend ? error ?
Regards,
Nicolas P.

try increase -interval to see if it lowers CPU consumption.
if it does,  the cause is latency.

and also,  try smaller window size,  like 64 or 128

I do not see any -interval option in client nor server ? what is about ?

hidden parameter,   -mode manual
https://github.com/xtaci/kcptun/issues/137


Add styles for all dropdown menu options

This removes the hyperlinks in dropdown menu options and keep the style of all the dropdown menus the same with the navbar dropdown menu.
We have another dropdown menu with such hyperlinks for Get Citation on item landing page. This pull request also fixes that one.

Tested on dev4 looks OK
https://dev4-web-c1.frdr.ca/repo/dataset/feae7103-4a11-4341-a933-4b78a9fefff0


Rlock not able to handle 200 concurrent requests

Hi,
I was trying to use distributed lock to do some operations and here I am facing an issue - it wasn't able to handle more than 200 concurrent requests
I am using redis as single server instance for this testing and here is my code
try {
RLock lock = redisTemplate.getLock("lock");
boolean lockStatus = lock.tryLock(10000L, 200L,TimeUnit.MILLISECONDS);
log.info("lock status" + String.valueOf(lockStatus));
// do some operations - this operation doesn't take more than 100 ms and so the same can be simulated with sleep
Thread.sleep(100)
if(lock.isHeldByCurrentThread()){
lock.unlock();
}
}catch (Exception e) {
log.error("Exception Occured " + e);
}
Please advise on what to look for to handle higher concurrency and handle the required requests per second. Our target was to handle around 1k concurrent requests

performance depends on factors like: network, CPU resources of both application and Redis


Camera calibration compenents

WIP of update to camera calibration to use Components and Tools

@kosack
The latest version contains two new temporary files:
calib.camera.factory_proposal.py - A proposal for a base factory object that would be exist in core.factory.py
calib.camera.new_tool_proposal.py - A proposal for replacing Tool, with a version that handles factories that are specified.
Full explanations can be found in the docstring.
I have included the example examples/calibration_tool.py to demonstrate how they work.
This is just my suggestion for how factory classes should be handled, and has functionality that I would hope exists in the final factory class implementation...
(like only parsing the traitlets for the class obtained via the factory, not any of the traitlets that belong to sibling classes - I believe this is important so the user isn't confused why some arguments seems to have no effect due to them being intended for a different class that could be the result of the factory given a different discriminator.)
I understand you might have a different approach for factory classes in mind...

This commit contains a new factory proposal. Compared to my last factory proposal, this does not change anything about how Tools operate. However it does require that all the traits that exist in the different possible products from the factory, must also exist in the factory class. The factory class will copy the correct traits to the product class when the product is created from the factory.
Once again, I have included the example examples/calibration_tool.py to demonstrate how this proposal works.

This PR requires #273 to be merged before merging.


Modification to support MongoDB 3.6+

I modified this file to support MongoDB 3.6 as the result is now a cursor, the array changed

Closing due to inactivity, free free to create new PR or provide an update here.


revert golang-http and keep golang-middleware

Description
Keeping golang-http same as @LucasRoesler 's suggestion and reverting workspaces but keeping workspaces for golang-middlewares
How Has This Been Tested?

 git clone https://github.com/LucasRoesler/golang-http-template-examples
 cd golang-http-template-examples
 rm go.work
 faas-cli template pull https://github.com/MrWormHole/golang-http-template
 faas-cli build

How are existing users impacted? What migration steps/scripts do we need?
examples no longer download dependencies from the internet after go mod vendor :+1:
also added build base due to CGO_ENABLED=1 causing build failure
https://pkgs.alpinelinux.org/package/v3.3/main/x86/build-base
if this PR is accepted, it closes #74 @LucasRoesler @alexellis
Checklist:
I have:

[X] updated the documentation and/or roadmap (if required)
[X] read the CONTRIBUTION guide
[X] signed-off my commits with git commit -s
[ ] added unit tests

can be closed, no longer required, golang-http will be using the interface for the golang-HTTP template. build-base is no longer required due to https://docs.openfaas.com/cli/build/#10-apply-build-options


Add task "Q" does not work (was issue 266, but that one is closed)

The Q key does not add a task. I added log output in the comments of issue 266.

Copy that. Latest firefox on windows.

Is this still occurring?  I don't have the issue with firefox on linux.  It'd be very surprising to me if linux vs windows mattered here.

Yes, this is still occuring.
Other extensions work fine, I use lastpass, diigo, deepl translator, clip to onenote, application launcher for drive (google) and some others.
Chrome version is:
Chrome is up-to-date
Versie 122.0.6261.112 (Officiële build) (64-bits)

Maybe @holstuwe can provide more information? It would also be interesting to know if this happens to all windows users.
I use todoist on my private laptop (W11) and my virtual work PC (W10), problem occurs on both.

@EelkoL  @mgsloan Can no longer confirm this behaviour. Firefox on Windows 11 (123.0.1 (64-Bit)), Extension version 195. "q" is adding tasks without any problem. Other shortcuts like "j", "k"... are working fine as well.

@EelkoL Ahh, I have a theory.  I noticed that your logs have (anoniem) and so you are probably using Todoist with Dutch locale.  Unfortunately the fix for #266 was to match the button based on the text.  Todoist used to have fairly semantic names for buttons to use, but increasingly only has obfuscated class names:

So, unfortunately the solution is to switch to the english locale or make a modified version that knows about the dutch localization https://github.com/mgsloan/todoist-shortcuts?tab=readme-ov-file#how-to-customize-keyboard-shortcuts .  In the meantime I'd also be happy to just throw in the translated versions of some of these for different languages.

You are right that I use the Dutch locale. However, I tested changing that, changed the Windows language, region but also the system locale  and the Q button still does nothing. I tried also the Chrome plugin 'Locale Switchter', but nothing. Moved Dutch down in chrome://settings/languages but again, no result.
Then I tried the local copy of the todoist-shortcuts plugin, but I don't know what I should change, maybe the quickAdd function?

Does the button in Todoist visually use Dutch?  I'd only expect the locale change to work if the button also visually changes to "Add task"
Yes it'd be in quickAdd, something like (button) => button.innerText.includes('Voeg taak toe')

Your Dutch is not bad at all. The button actually says 'Taak toevoegen'.
Your comment made me try something simple: Change the language in the Todoist settings (in General). That does the trick!
My windows is still Dutch, the locale is set to The Netherlands, only Todoist is now in English. And the Q-key works again.
Thanks a lot!


Optionally highlight range between start date and end date even though end date is set

The DateRangePicker won't highlight the range between start and end date if the latter is already selected and the end date DRP is opened again. Would it be possible and are you guys willing to include an option to alyways highlight the range between start and hovered end date (and vice-versa).

In the image only the range between the selected start and end date are highlighted, not the hovered day.
It would also suffice, if the DRP would just add CSS classes to the days in the range.
Alternatively do you know of a workaround to achieve this behaviour? Maybe temporarely unsetting the end date on mouseenter somehow. But then you would have to remember that date and re-set in on mouseleave, and only if no new end date was selected.
Thanks for any help!
Carsten

Hey, just checking, if you are willing to merge this feature if I were to implement it by myself?


SWS fails to start on Raspberry Pi 5 with the message "Unsupported system page size"

Search for duplicate issues

[X] I already searched, and this issue is not a duplicate.

Issue scope
Docker / Kubernetes
Describe the bug
Hi,
When I try to deploy SWS on a K3S kubernetes server running on a Raspberry Pi 5, the containers fail to start with the following error message:
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed

Kubernetes information on the container (information anonymized with XXX):
kubectl describe pod sws-deployment-66f5b8b9b8-z9vj8
Name:             sws-deployment-66f5b8b9b8-z9vj8
Namespace:        XXXXX
Priority:         0
Service Account:  default
Node:             XXXXX/192.168.XXX.XXX
Start Time:       Sat, 11 May 2024 22:08:49 +0200
Labels:           app=sws
                  pod-template-hash=66f5b8b9b8
Annotations:      <none>
Status:           Running
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/sws-deployment-66f5b8b9b8
Containers:
  sws:
    Container ID:   containerd://3f227308244481d87f40679cf9c1722654a27ba61e4a65ef90065e3ef1975e6f
    Image:          joseluisq/static-web-server:2.30.0-debian
    Image ID:       docker.io/joseluisq/static-web-server@sha256:c88844fd56f7462c2e0818d49df4dfd3e0ebdb12139e81d72c186df56c97d6a7
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    139
      Started:      Sat, 11 May 2024 22:25:03 +0200
      Finished:     Sat, 11 May 2024 22:25:03 +0200
    Ready:          False
    Restart Count:  8
    Environment:
      FAKE_DISABLE_JEMALLOC:  true
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-tmbls (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       False
  ContainersReady             False
  PodScheduled                True
Volumes:
  kube-api-access-tmbls:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  17m                   default-scheduler  Successfully assigned XXXXX/sws-deployment-66f5b8b9b8-z9vj8 to XXXX
  Normal   Pulling    17m                   kubelet            Pulling image "joseluisq/static-web-server:2.30.0-debian"
  Normal   Pulled     17m                   kubelet            Successfully pulled image "joseluisq/static-web-server:2.30.0-debian" in 6.258s (6.258s including waiting)
  Normal   Pulled     15m (x4 over 17m)     kubelet            Container image "joseluisq/static-web-server:2.30.0-debian" already present on machine
  Normal   Created    15m (x5 over 17m)     kubelet            Created container sws
  Normal   Started    15m (x5 over 17m)     kubelet            Started container sws
  Warning  BackOff    2m34s (x69 over 17m)  kubelet            Back-off restarting failed container sws in pod sws-deployment-66f5b8b9b8-z9vj8_XXXXX(d6040825-8420-4f32-9fc2-52389ab1c7db)

The same error is present with the scratch version or the docker image.
I found a bug that has been fixed and could be related to the same root cause on another software: https://github.com/qdrant/qdrant/issues/2474 or another related PR and also https://github.com/typesense/typesense/issues/1351 . I tried to add the DISABLE_JEMALLOC environment variable but it did not fix the issue (Note: then I renamed it to avoid potential conflicts).
For information, the page size seems to be configured to 16K on the system (total of 8Gi of RAM installed).
getconf PAGE_SIZE
16384

Have a nice day.
How to reproduce it

Install a k3s server on a Rasberry Pi 5B with 8G of RAM.

Deploy SWS using the following deployment file name sws.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sws-deployment
  labels:
    app: sws
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sws
  template:
    metadata:
      labels:
        app: sws
    spec:
      containers:
      - name: sws
        image: joseluisq/static-web-server:2.30.0-debian
        ports:
        - containerPort: 80

Command: kubectl apply -f sws.yaml

Check the pods status with kubectl get pods

NAME                              READY   STATUS             RESTARTS         AGE
sws-deployment-66f5b8b9b8-z9vj8   0/1     CrashLoopBackOff   10 (3m41s ago)   30m
sws-deployment-66f5b8b9b8-644jw   0/1     CrashLoopBackOff   10 (3m34s ago)   30m

The pods should be in the Running state but are in the CrashLoopBackOff after a few minutes.
The logs are indicating an issue with jemalloc : kubectl logs sws-deployment-66f5b8b9b8-z9vj8
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed

Expected behavior
The pods should be in the Running state after the deployment and not error should be logged.
Complementary information
The image deployed seem to be the correct one as the SHA matches the k3s description above: https://hub.docker.com/layers/joseluisq/static-web-server/2.30.0-debian/images/sha256-b7dce340af9f5d282de917dd9ae27306e0620f54377da4b0ce51cf32f1538329?context=explore
The issue seems to be documented on the Raspberry Pi issue tracker: https://github.com/raspberrypi/bookworm-feedback/issues/107
Build target
Docker ~linux/amd64~ linux/arm64
Environment and specs

[X] static-web-server: 2.30.0-debian
[x] OS: Linux XXXXX 6.6.28+rpt-rpi-2712 # 1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux
[x] Arch: ARM64 (64-bit) on Rasberry Pi 5B
[x] Docker: k3s kubernetes version v1.29.4+k3s1
[x] Client: Not applicable
[ ] Specify others

Additional context
No response

Workaround
After some web search, i found a workaround that could confirm the issue with the page 16K page size ( https://github.com/raspberrypi/bookworm-feedback/issues/107 ). I added the kernel=kernel8.img line after the [all] section in /boot/firmware/config.txt file and rebooted the Raspberry Pi 5.
[all]

kernel=kernel8.img

Now uname -a show that the kernel type/version changed from 2712 to 8 :
Linux ultra-trails.local.galette.net 6.6.28+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64

The pods are in the Running state:
NAME                              READY   STATUS    RESTARTS        AGE
sws-deployment-66f5b8b9b8-z9vj8   1/1     Running   111 (16m ago)   9h
sws-deployment-66f5b8b9b8-644jw   1/1     Running   111 (15m ago)   9h

And the logs show a successful start of SWS:
2024-05-12T05:10:05.220487Z  INFO static_web_server::info: static-web-server 2.30.0
2024-05-12T05:10:05.220524Z  INFO static_web_server::info: log level: error
2024-05-12T05:10:05.220596Z  INFO static_web_server::info: server bound to tcp socket [::]:80
2024-05-12T05:10:05.220600Z  INFO static_web_server::info: runtime worker threads: 4
2024-05-12T05:10:05.220603Z  INFO static_web_server::info: runtime max blocking threads: 512
2024-05-12T05:10:05.228592Z  INFO static_web_server::info: log remote address: enabled=false
2024-05-12T05:10:05.228606Z  INFO static_web_server::info: redirect trailing slash: enabled=true
2024-05-12T05:10:05.228611Z  INFO static_web_server::info: ignore hidden files: enabled=false
2024-05-12T05:10:05.228614Z  INFO static_web_server::info: grace period before graceful shutdown: 0s
2024-05-12T05:10:05.228619Z  INFO static_web_server::info: index files: index.html
2024-05-12T05:10:05.228623Z  INFO static_web_server::info: directory listing: enabled=false
2024-05-12T05:10:05.228631Z  INFO static_web_server::info: directory listing order code: 6
2024-05-12T05:10:05.228634Z  INFO static_web_server::info: directory listing format: Html
2024-05-12T05:10:05.237242Z  INFO static_web_server::info: fallback page: enabled=false, value=""
2024-05-12T05:10:05.237256Z  INFO static_web_server::info: health endpoint: enabled=false
2024-05-12T05:10:05.237259Z  INFO static_web_server::info: metrics endpoint (experimental): enabled=false
2024-05-12T05:10:05.237266Z  INFO static_web_server::info: basic authentication: enabled=false
2024-05-12T05:10:05.237269Z  INFO static_web_server::info: maintenance mode: enabled=false
2024-05-12T05:10:05.237272Z  INFO static_web_server::info: maintenance mode status: 503
2024-05-12T05:10:05.237275Z  INFO static_web_server::info: maintenance mode file: ""
2024-05-12T05:10:05.237278Z  INFO static_web_server::info: compression static: enabled=false
2024-05-12T05:10:05.237283Z  INFO static_web_server::info: auto compression: enabled=true, formats=deflate,gzip,brotli,zstd
2024-05-12T05:10:05.237286Z  INFO static_web_server::info: cache control headers: enabled=true
2024-05-12T05:10:05.237289Z  INFO static_web_server::info: security headers: enabled=false
2024-05-12T05:10:05.252081Z  INFO static_web_server::info: http1 server is listening on http://[::]:80
2024-05-12T05:10:05.252091Z  INFO static_web_server::info: press ctrl+c to shut down the server

I wonder which OS/Arch musl-binary Docker is choosing for your PI 5 in Kubernetes.
Regardless, you could try to build a new Docker image but using the dynamic-linked binary static-web-server-v2.30.0-aarch64-unknown-linux-gnu.tar.gz instead of the static one static-web-server-v2.30.0-aarch64-unknown-linux-musl.tar.gz (currently published).

What I'm also thinking is to provide dynamic-linked binaries for all Docker Debian-based images instead of using musl and leaving musl binaries only for the Alpine images.

@joseluisq the OS/Arch musl-binary chosen for the PI 5 in Kubernetes seems to be joseluisq/static-web-server:2.30.0 images for linux/arm64.
A kubectl describe pod commands returns the following information Image ID:       docker.io/joseluisq/static-web-server@sha256:4a878e15395678168c20acdf0daf7381e5b687436da06821f52c8b786582571e which matches the sha of the image on Docker Hub
Please note that with the workaround in place I switched back to the Scratch version of the image.

@joseluisq the OS/Arch musl-binary chosen for the PI 5 in Kubernetes seems to be joseluisq/static-web-server:2.30.0 images for linux/arm64.
A kubectl describe pod commands returns the following information Image ID: docker.io/joseluisq/static-web-server@sha256:4a878e15395678168c20acdf0daf7381e5b687436da06821f52c8b786582571e which matches the sha of the image on Docker Hub

Ok, then It is using the aarch64-unknown-linux-musl binary.
@fred00 Can you please build a Debian image with the aarch64-unknown-linux-gnu binary and test it in your PI 5 with Kubernetes? Let me know
if that worked.

I have the same issue on my Raspberry Pi 5. I have freshly installed Raspberry Pi OS with default settings on my Pi (the page size of 16kb is the default). According to Raspberry Pi they changed the page size to improve performance. Would be a bummer to not use this performance improvements.
Thank you all for working on a solution 👍🏻

Can some of you @sharknoon or @fred00 build a Debian image with the aarch64-unknown-linux-gnu binary and test it if works fine?
The issue is about jemalloc but it is only used in musl static-binaries like aarch64-unknown-linux-musl.

Will do so when I am home (in about 8 hours) 👍

Ok, exploring a bit more in detail. Turns out that it is a well-known problem with a solution.
Basically, we can keep musl static/linked binaries for aarch64 (a.k.a. ARM64) targets but we have to tell jemalloc to use a larger page size by default.
So we can go with using the maximal supported page size of 64KB on aarch64 which should be not a problem for system with smaller page sizes since jemalloc supports that functionality. See https://github.com/jemalloc/jemalloc/pull/769
I will prepare a fix soon.

@joseluisq I’m not sure to have the toolchain required to build a new image for aarch64. If @sharknoon can’t do it I will try my best.
If you prepare an image with a fix, I will be able to test it with both Pi 5 kernels to provide you with a feedback on the fix compatibility.

@joseluisq It this how you imagined the Debian test image? Dockerfile

Quick Update: I have managed to get a Raspberry Pi 5 at work and it works fine with the binaries that @joseluisq has provided
here

Quick Update: I have managed to get a Raspberry Pi 5 at work and it works fine with the binaries that @joseluisq has provided here

Thanks for checking. That's what I was assuming. I just wanted to double-check.
Now, two things to clarify.
First, regarding the musl static-linked binary for linux/arm64, we still want to compile jemalloc with a 64KB page size default.
Second, regarding the Debian Docker image for linux/arm64, I'm still thinking on why not provide dynamic-linked binaries (glibc) like aarch64-unknown-linux-gnu for the Debian-based images only and leave the static-linked binaries (musl) for the Alpine and the Scratch images for consistency. This has to come up later at some point. But for now, we will fix the issue by increasing the page size as discussed in https://github.com/static-web-server/static-web-server/issues/440#issuecomment-2106958346.

Thank you! I am really amazed how quickly you responded to this error. The static web server is an amazing software and I really enjoy using it. Thank you for your time and effort, I really appreciate it 😃

@joseluisq, just to confirm @sharknoon feedback, I started the binaries directly on the Pi 5 (outside of Docker/K8S) on both kernels and it starts successfully on them. Thank you very much for your exceptional support!
$ uname -a
Linux XXX 6.6.28+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux

$ ./static-web-server -p 1234
2024-05-13T16:55:50.293000Z  INFO static_web_server::info: static-web-server 2.30.0
2024-05-13T16:55:50.293030Z  INFO static_web_server::info: log level: error
2024-05-13T16:55:50.293071Z  INFO static_web_server::info: server bound to tcp socket [::]:1234
2024-05-13T16:55:50.293078Z  INFO static_web_server::info: runtime worker threads: 4
2024-05-13T16:55:50.293082Z  INFO static_web_server::info: runtime max blocking threads: 512
2024-05-13T16:55:50.293097Z  INFO static_web_server::info: log remote address: enabled=false
2024-05-13T16:55:50.293102Z  INFO static_web_server::info: redirect trailing slash: enabled=true
2024-05-13T16:55:50.293107Z  INFO static_web_server::info: ignore hidden files: enabled=false
2024-05-13T16:55:50.293111Z  INFO static_web_server::info: grace period before graceful shutdown: 0s
2024-05-13T16:55:50.293119Z  INFO static_web_server::info: index files: index.html
2024-05-13T16:55:50.293124Z  INFO static_web_server::info: directory listing: enabled=false
2024-05-13T16:55:50.293129Z  INFO static_web_server::info: directory listing order code: 6
2024-05-13T16:55:50.293133Z  INFO static_web_server::info: directory listing format: Html
2024-05-13T16:55:50.293141Z  INFO static_web_server::info: fallback page: enabled=false, value=""
2024-05-13T16:55:50.293146Z  INFO static_web_server::info: health endpoint: enabled=false
2024-05-13T16:55:50.293150Z  INFO static_web_server::info: metrics endpoint (experimental): enabled=false
2024-05-13T16:55:50.293156Z  INFO static_web_server::info: basic authentication: enabled=false
2024-05-13T16:55:50.293160Z  INFO static_web_server::info: maintenance mode: enabled=false
2024-05-13T16:55:50.293164Z  INFO static_web_server::info: maintenance mode status: 503
2024-05-13T16:55:50.293169Z  INFO static_web_server::info: maintenance mode file: ""
2024-05-13T16:55:50.293173Z  INFO static_web_server::info: compression static: enabled=false
2024-05-13T16:55:50.293177Z  INFO static_web_server::info: auto compression: enabled=true, formats=deflate,gzip,brotli,zstd
2024-05-13T16:55:50.293182Z  INFO static_web_server::info: cache control headers: enabled=true
2024-05-13T16:55:50.293186Z  INFO static_web_server::info: security headers: enabled=false
2024-05-13T16:55:50.293242Z  INFO static_web_server::info: http1 server is listening on http://[::]:1234
2024-05-13T16:55:50.293259Z  INFO static_web_server::info: press ctrl+c to shut down the server

uname -a
Linux XXX 6.6.28+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux

$ ./static-web-server -p 1234
2024-05-13T16:51:05.036837Z  INFO static_web_server::info: static-web-server 2.30.0
2024-05-13T16:51:05.036865Z  INFO static_web_server::info: log level: error
2024-05-13T16:51:05.036904Z  INFO static_web_server::info: server bound to tcp socket [::]:1234
2024-05-13T16:51:05.036910Z  INFO static_web_server::info: runtime worker threads: 4
2024-05-13T16:51:05.036914Z  INFO static_web_server::info: runtime max blocking threads: 512
2024-05-13T16:51:05.036930Z  INFO static_web_server::info: log remote address: enabled=false
2024-05-13T16:51:05.036935Z  INFO static_web_server::info: redirect trailing slash: enabled=true
2024-05-13T16:51:05.036940Z  INFO static_web_server::info: ignore hidden files: enabled=false
2024-05-13T16:51:05.036944Z  INFO static_web_server::info: grace period before graceful shutdown: 0s
2024-05-13T16:51:05.036954Z  INFO static_web_server::info: index files: index.html
2024-05-13T16:51:05.036960Z  INFO static_web_server::info: directory listing: enabled=false
2024-05-13T16:51:05.036964Z  INFO static_web_server::info: directory listing order code: 6
2024-05-13T16:51:05.036969Z  INFO static_web_server::info: directory listing format: Html
2024-05-13T16:51:05.036979Z  INFO static_web_server::info: fallback page: enabled=false, value=""
2024-05-13T16:51:05.036984Z  INFO static_web_server::info: health endpoint: enabled=false
2024-05-13T16:51:05.036989Z  INFO static_web_server::info: metrics endpoint (experimental): enabled=false
2024-05-13T16:51:05.036995Z  INFO static_web_server::info: basic authentication: enabled=false
2024-05-13T16:51:05.036999Z  INFO static_web_server::info: maintenance mode: enabled=false
2024-05-13T16:51:05.037003Z  INFO static_web_server::info: maintenance mode status: 503
2024-05-13T16:51:05.037007Z  INFO static_web_server::info: maintenance mode file: ""
2024-05-13T16:51:05.037011Z  INFO static_web_server::info: compression static: enabled=false
2024-05-13T16:51:05.037016Z  INFO static_web_server::info: auto compression: enabled=true, formats=deflate,gzip,brotli,zstd
2024-05-13T16:51:05.037022Z  INFO static_web_server::info: cache control headers: enabled=true
2024-05-13T16:51:05.037026Z  INFO static_web_server::info: security headers: enabled=false
2024-05-13T16:51:05.037095Z  INFO static_web_server::info: http1 server is listening on http://[::]:1234
2024-05-13T16:51:05.037106Z  INFO static_web_server::info: press ctrl+c to shut down the server

Fixed by #440
Thanks for reporting and testing!

You are very welcome! Thank you for your very quick response :)

v2.31.0 is out!
Give it a try and report any issues if any.

Hi @joseluisq,
Thank you for the notification.
I wasn't successful running the new version with the standard Raspberry Pi kernel. They work on the kernel8 configuration but not on the standard one.
I get the same error as before:
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed

I tested with the 3 images types: scratch, debian and alpine.

I tried to test the provided binaries outside of kubernetes / container.d to see if the would start. I used ctr to mount the image directly on the host OS. I get the same error.
$ uname -a
Linux ultra-trails.local.galette.net 6.6.28+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux

$ mkdir /tmp/sws

$ sudo ctr i mount docker.io/joseluisq/static-web-server:2.31.0-debian /tmp/sws
sha256:7ec9abf201ddaa3aa824d5711706ee755faf37220e886b2147c16a2bd54287c2
/tmp/sws

$ /tmp/sws/usr/local/bin/static-web-server
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed
Aborted

$ sudo umount /tmp/sws

$ sudo ctr i mount docker.io/joseluisq/static-web-server:2.31.0-alpine /tmp/sws
sha256:1c47b434ead451aa2dcfe6ad16a20f0492cb3d60529583ca055087dd007ed321
/tmp/sws

$ /tmp/sws/usr/local/bin/static-web-server
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed
Aborted

$ sudo umount /tmp/sws

$ sudo ctr i mount docker.io/joseluisq/static-web-server:2.31.0 /tmp/sws
sha256:9b0d3a7359d63fce6d03d295e2fe2d10e0a1da238ae89147f2457ef3af56a6b2
/tmp/sws

$ /tmp/sws/usr/local/bin/static-web-server
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed
Aborted

$ sudo umount /tmp/sws

Thanks for testing.
I forgot that we are cross-compiling via cross a tool that uses Docker so we have to pass also the Jemalloc environment variable from the host https://github.com/static-web-server/static-web-server/actions/runs/9150360695/job/25155042678#step:9:21.
I will try to test this locally and release a patch soon.

This issue is confirmed to be fixed in release v2.31.1 (see https://github.com/static-web-server/static-web-server/pull/446#issuecomment-2121738796 for details).

Thank you @fred00 for testing and @joseluisq for a very fast response


Define issue label list

We already have som issue labels (mostly GitHub default) defined, however, we could do better.
Also we could improve our usage of labels. @bburns currently uses the first part of issue titles, which is not the best practice. We should remove the ‘labels’ from issue titles and try to create such issue titles that could be eventually used as commit messages (i.e. they should be short and descriptive), however, that is a separate issue.
Just a sidenote: on GitHub, I miss scoped labels that I love on GitLab (which I prefer over GitHub).
We should use labels to define:

[required: exactly one] a top-level issue category labels:

bug:

colour: #d73a4a;
description: Something isn’t working;
rules: whenever an issue is a report of a bug anywhere in the code (apps, libs, scripts) or bug (incorrect explanation or other major mistake) in the app documentation (in docs/);

enhancement:

colour: #a2eeef;
description: New feature or enhancement of existing feature;
rules: whenever an issue is a dealing with a new feature or enhancement of an existing feature, including feature requests;

dependencies:

colour: #0366d6;
description: Pull requests that update a dependency file;
rules: whenever we update the dependencies of l99; it should not be assigned when a new feature is added that requires a dependency to be added or updated;

infrastructure:

colour: TODO;
description: Anything related to the surrounding tools and infrastructure to support romcal;
rules: whenever we update, improve or add some tools (e.g. Docker, Nx, Nest, ESLint, Prettier, etc) used by l99 not directly related to the code (apps/libs) itself; it should not be assigned when a new feature is added (in that case the tests addition should be done implicitly);

[required unless library label is used or issue is not related to any particular app] application name:

application:$appName:

colour: TODO;
description: Anything related to a specific application;
rules: whenever the issue is related to a specific application which name is part of the label after colon;

library:$libName:

colour: TODO;
description: Anything related to a specific library;
rules: whenever the issue is related to a specific library which name is part of the label after colon;

[required unless application label is used or issue is not related to any particular library] library name:
[optional: at most one] ‘additional’ labels:

documentation:

colour: #0075ca;
description: Improvements or additions to documentation;
rules: whenever an issue is modifies the documentation in docs/; it should not be assigned when a new feature is added (in that case the docs modification should be done implicitly);

tests:

colour: TODO;
description: Test improvements or additions;
rules: whenever we update, improve or add some tests; it should not be assigned when a new feature is added (in that case the tests addition should be done implicitly);

localization:

colour: TODO;
description: Anything related to localization, internationalization and locales;
rules: whenever we update, improve or add some stuff regarding l10n, i18n and locales; it should not be assigned when a new feature is added (in that case the localization addition/changes should be done implicitly if they are required);

[optional] optionally use other labels are remarks (‘optional’ labels):

duplicate:

colour: #cfd3d7;
description: This issue or pull request already exists;
rules: whenever an issue deals with the same or similar stuff as another issue;

good first issue:

colour: #7057ff;
description: Good for newcomers;

wontfix:

This will not be worked on

help wanted:

colour: #008672;
description: Extra attention is needed;

invalid:

colour: #e4e669;
description: This doesn't seem right;

Label assignment rules:

Question issues should be converted to GitHub Discussions (there is button for that in the issues). Same should be true when a discussion is not a discussion—we should convert it to an issue.
Each issue should have exactly one top-level issue category level.
application:$appName and library:$libName should be mutually exclusive labels. Whenever a particular issue is related to particular app/library, use of such label is required.
We can use at most one ‘additional’ label.
Whenever we add/remove/rename an app/library, we should reflect this in the application:$appName and library:$libName labels.

TODO and questions:

Are label colours, descriptions and rules okay with you all?
Besides application:$appName and library:$libName, do we need some other scoped labels? For example, component:$name where $name could be a driver type for adapter. It could be a module name (in Nest/Angular terminology; e.g. a monitoring feature). (Currently, possible names of the component:$name are adapter, agent, relay, shdr.) However, the question is whether we need such in-depth labelling for issues. IMHO it is too much for now, therefore I suggest to remove the component:$name labels.
We could use GitHub Actions to force some rules (like when bug label is added, enhancement label removed), however, that is not in the scope of this issue (at least right now).
As for libraries, I haven’t added a label for them, as currently, the libraries (e.g. drivers in adapter) are part of the app (microservices). Currently, I am not sure if those libraries (or plugins, as @bburns calls them) should be considered as separate parts, or if they should be later moved out of the app into separate library (like into libs/ folder) or not.
We might want to remove use case label;
Should we create separate labels for new features and enhancements of existing features instead of enhancement?
I need to choose some colours for new labels.

I suggest to use org level labels as much as possible and repo level labels for stuff that are not related to other repos.

@Ladder99/development, I am mostly done creating a list of labels I find useful to use in this repository (potentially in all repos under Ladder99 org, with some minor modifications), I haven’t updated the actual label list though.
All proposed labels have colours, description and rules when to use defined. There are stuff to consider/evaluate (see the TODO and questions in the description).
I can create the labels (ideally under org level, with some labels specifically related to l99 under repo level), however, I’d rather do that after some kind of confirmation, probably after answering the questions.

@MRIIOT, this is issue is currently in Backlog project status. I am hesitant to move it into in progress without your approval.

@bburns currently uses the first part of issue titles, which is not the best practice.

I use categories/labels as the first part of a title so they can be sorted into groups, and it's easy to see at a glance what category an issue belongs to in plain text. The table view fits better on my laptop also. But labels have color, and can have >1, so labels win 🤷

Are label colours, descriptions and rules okay with you all?

Yes, though I still prefer 'service' and 'driver' over 'application' and 'library'. I think users would get confused over the latter 2, which are more generic.

Besides application:$appName and library:$libName, do we need some other scoped labels? For example, component:$name where $name could be a driver type for adapter. It could be a module name (in Nest/Angular terminology; e.g. a monitoring feature). (Currently, possible names of the component:$name are adapter, agent, relay, shdr.) However, the question is whether we need such in-depth labelling for issues. IMHO it is too much for now, therefore I suggest to remove the component:$name labels.

Yes, let's rename the component:* labels to service:* and driver:shdr. If other scoped labels come up, we can add them.

We could use GitHub Actions to force some rules (like when bug label is added, enhancement label removed), however, that is not in the scope of this issue (at least right now).

Hmm, interesting

As for libraries, I haven’t added a label for them, as currently, the libraries (e.g. drivers in adapter) are part of the app (microservices). Currently, I am not sure if those libraries (or plugins, as @bburns calls them) should be considered as separate parts, or if they should be later moved out of the app into separate library (like into libs/ folder) or not.

Yeah, we can see when move to things to Nx.

We might want to remove use case label;

I'd keep it - we could create as many labels as makes sense to categorize issues - eg vscode is very well managed and has 400+ labels - https://github.com/microsoft/vscode/labels.

Should we create separate labels for new features and enhancements of existing features instead of enhancement?

idk - vscode seems to just have 'feature-request' - https://github.com/microsoft/vscode/wiki/Issue-Grooming#categorizing-issues

@bburns currently uses the first part of issue titles, which is not the best practice.

I use categories/labels as the first part of a title so they can be sorted into groups, and it's easy to see at a glance what category an issue belongs to in plain text. The table view fits better on my laptop also. But labels have color, and can have >1, so labels win 🤷

I understand your approach, however, filtering based on categories/labels in the title is not possible, because all you can do then, is to search for strings that might also be used in the issue description and comments, thus you cannot find what you actually need. On the other hand, filtering based on issue labels is 100 % functional (unless an issue has incorrect label assigned).

Are label colours, descriptions and rules okay with you all?

Yes, though I still prefer 'service' and 'driver' over 'application' and 'library'. I think users would get confused over the latter 2, which are more generic.

I disagree that it’ll be confusing to the users.
Are you talking about end-users? They don’t care how we call the apps. They won’t (presumably) actually work on the code, all they would at most do is to follow the docs and run some commands.
Are you talking about users who will set l99 up for a customer? They will mostly only follow the docs and run the commands.
Are you talking about contributing users/devs? They will understand it whatever we call them, whether they are apps, services, microservices, libraries, plugins …
I actually don’t really care (as long as we understand each other), however, I still suggest to use apps/ and libs/ folders, esp after we move to Nx monorepo workspace.

Besides application:$appName and library:$libName, do we need some other scoped labels? For example, component:$name where $name could be a driver type for adapter. It could be a module name (in Nest/Angular terminology; e.g. a monitoring feature). (Currently, possible names of the component:$name are adapter, agent, relay, shdr.) However, the question is whether we need such in-depth labelling for issues. IMHO it is too much for now, therefore I suggest to remove the component:$name labels.

Yes, let's rename the component:* labels to service:* and driver:shdr.

So, are you suggesting to keep the component:$name/driver:$name labels? Do we actually need that much information/details on issues?

If other scoped labels come up, we can add them.

This I meant implicitly. I added this explicitly to the rules.

We might want to remove use case label;

I'd keep it - we could create as many labels as makes sense to categorize issues - eg vscode is very well managed and has 400+ labels - https://github.com/microsoft/vscode/labels.

What would be the use case for use case labels?
Are they to be used as customer feature requests? Then I suggest to use enhancement label.
Are they to be used as questions about implementation/usage/whatever? Then I suggest to use GitHub Discussions for that use case. Example (closed) issue from that past that should be asked in the discussions: #13.
Any other use case of use case label you had in mind? Do you still disagree with me? :wink: What are your arguments?

we could create as many labels as makes sense to categorize issues

Yes and no. The more labels we have, the harder it’ll be to maintain both label list and their assignment to issues. We are a small team, we need to code more than work on issues.
Of course, the more we automate the labels, the more labels we potentially could have. That said, however, I am against useless labels. By a useless label I mean labels that have no real value to us.

vscode is very well managed and has 400+ labels - https://github.com/microsoft/vscode/labels.

Yes, but they the manpower and they set up the label automation, we have neither.

Should we create separate labels for new features and enhancements of existing features instead of enhancement?

idk - vscode seems to just have 'feature-request'

I actually don’t care about the label names. I used enhancement because it is/was the name of the default GitHub label. We can rename all of them.
On the other, semantically, I prefer not using request in the label names, as from my point of requesting a feature and suggesting a feature and working on a feature is all the same from code point of view. However, there is a difference between a new feature and improvement/enhancement of an existing feature and is what I am asking in the description.

https://github.com/microsoft/vscode/wiki/Issue-Grooming#categorizing-issues

I am open to introduce some other labels, however, I’d prefer to keep the list as slim as possible and all the labels need to have defined rules when a particular label should be used. Also, all labels need to have some value to us.
Some comments on the VSCode type labels:

under-discussion: not decided whether the issue is a bug or feature

currently, we don’t need this one, as we use proposed in the project for this use case;

debt: improve the implementation/architecture:

it more or less overlaps with infrastructure (when the technical debt is on the tooling side) and enhancement (when the technical debt is the code side);

needs more info: not possible to assign a type label due to missing information:

we might add this one;

upstream: an issue used to track an issue in an upstream component:

we might add this one;

engineering: issues related to our engineering system or our processes:

this is more or less the same use case as our infrastructure;
we could rename infrastructure to engineering if we wanted to.

application:$appName:
description: Anything related to a specific application;
rules: whenever the issue is related to a specific application which name is part of the label after colon;
library:$libName:
description: Anything related to a specific library;
rules: whenever the issue is related to a specific library which name is part of the label after colon;

Yes, though I still prefer 'service' and 'driver' over 'application' and 'library'. I think users would get confused over the latter 2, which are more generic.

Besides application:$appName and library:$libName, do we need some other scoped labels? For example, component:$name where $name could be a driver type for adapter. It could be a module name (in Nest/Angular terminology; e.g. a monitoring feature). (Currently, possible names of the component:$name are adapter, agent, relay, shdr.) However, the question is whether we need such in-depth labelling for issues. IMHO it is too much for now, therefore I suggest to remove the component:$name labels.

Yes, let's rename the component:* labels to service:* and driver:shdr. If other scoped labels come up, we can add them.

@tukusejssirs
When you are talking about application, you mean : adapter, meter, relay ?
When you are talking about library, you mean external libraries ?
@bburns
Sounds like service and application are interchangeable?  If we rename the folder from services to apps then application makes sense.
If library is an external library, then application:adapter component:modbus does make some sense to point the issue at something specific within adapter.  But I can see that the component tags will just continue growing and be a dump all.

I use categories/labels as the first part of a title so they can be sorted into groups, and it's easy to see at a glance what category an issue belongs to in plain text. The table view fits better on my laptop also. But labels have color, and can have >1, so labels win 🤷

This is the job for labels for sure, not issue title.

What would be the use case for use case labels?
Are they to be used as customer feature requests? Then I suggest to use enhancement label.
Are they to be used as questions about implementation/usage/whatever? Then I suggest to use GitHub Discussions for that use case. Example (closed) issue from that past that should be asked in the discussions: https://github.com/Ladder99/ladder99/issues/13.

use-case and enhancement are interchangeable to me and discussions to support.

we could create as many labels as makes sense to categorize issues

Yes and no. The more labels we have, the harder it’ll be to maintain both label list and their assignment to issues. We are a small team, we need to code more than work on issues.

Painting with broader strokes will work better in the beginning.  We can adjust in the future.
Everything else in the conversation looks good to me.

@tukusejssirs
When you are talking about application, you mean : adapter, meter, relay ?
When you are talking about library, you mean external libraries ?

When I talk about application, I mean any app that could run on its own, like gateway, (micro-) service, CLI app, …, therefore in l99, all apps are in services/ folder.
Regarding libraries, a library is a piece of code that cannot be run on its own, it can be imported (or used in general) by other apps/libs. A library is a separate package though. Currently, in l99 repo there are no libraries yet, although @bburns uses common/ folders albeit on app-level only. Some stuff from common/ folders could be made a libary and some stuff could be shared among multiple apps in a shared library (i.e. a library imported by multiple apps).

@bburns
Sounds like service and application are interchangeable?  If we rename the folder from services to apps then application makes sense.

Yeah, all services are apps, however, not all apps (in general) are (micro-) services. :wink:

If library is an external library, then application:adapter component:modbus does make some sense to point the issue at something specific within adapter.

A library can be an external dependency, however, in that case its code is in node_modules/ folder. Libararies that would be in libs/ folder would be libraries used by l99 apps only.
We can keep component:$type if you wish.

But I can see that the component tags will just continue growing and be a dump all.

Also the list of apps and libs might grow; then we need to update the labels accordingly.

use-case and enhancement are interchangeable to me and discussions to support.

@MRIIOT, as I understand it, you agree with my suggestion, that is:

remove use case label;
use enhancement for (requests of) both new features and old feature improvements;
use GitHub discussions for questions/support.

Did I understand you right?

One thing where @bburns and I differ is that he is a bottom up kind of guy, and I'm a top down kind of guy (https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design).

I have never heard about top-down/bottom-up approaches; I consider myself an analytist, thus I might be a top-down guy, however, I use both approaches whichever I feel the best to be used at a particular moment. :man_shrugging:

We meet somewhere in the middle after discussing specifications.  How might we get better at these approaches?  In my opinion, we have painted l99 to the best of our ability without knowing what paint to use.  Now we have a chance to step back and look at the picture, pick it apart, and really make design effort into what is to come next.

Well, I have to add to this. I’ll create labels as I suggested in the issue description, assign labels to the issues (I’ll do my best) and we’ll see.

Everything else in the conversation looks good to me.

:+1:

I have created all the labels listed in the issue description. I have removed use case and question labels.
Note that I didn’t bother much with decision of what colour should be assigned to which label; I tried to set different colours for different labels though. If someone wants to update the, feel free to choose any colour you want. :wink:
I did my best to assign labels to all issues and thus to and thus to catogorise them. If someone disagrees with my choice, it should be discussed in that particular issue. Some issues might be on the edge of the labelling rules though. :thinking:
I removed ‘labels’ from the issue titles. I also updated the titles in order to be more descriptive, use sentence case and imperative mode.
@MRIIOT, we could add this to the public docs, although it is not a hard requirement, just a nice to have.
Until I get a word from @bburns, I won’t add nor update component:$componentName labels.
I also didn’t set application:$appName labels everywhere; @bburns might be better suited to assign these labels.
We could consider adding design label for architecture/design proposals. This label could be used in addition to enhancement label.
We might want to add application:cli label which could be used when a particular issue is related to any l99 shell command (e.g. l99 start); optionally we could also add the individual shell commands (e.g. start, build) as components (e.g. component:start). For now, I used infrastructure for anything related to those l99 shell commands, albeit it is not nice choice.

@MRIIOT, we could add this to the public docs, although it is not a hard requirement, just a nice to have.

Yeah a summary would be good for us and contributors - could add to docs.

Until I get a word from @bburns, I won’t add nor update component:$componentName labels.

Converted these to application: and removed component: labels.
And renamed component:shdr to driver:shdr - would be nice to have labels for all the drivers, but adding new labels in this thing is a pain. Unless you could just tag things like #driver:foo - but you can't.

I also didn’t set application:$appName labels everywhere; @bburns might be better suited to assign these labels.

Okay, added some more where relevant.

We could consider adding design label for architecture/design proposals. This label could be used in addition to enhancement label.

Sure.

We might want to add application:cli label which could be used when a particular issue is related to any l99 shell command (e.g. l99 start);

Sounds good - added.

The current list, obtained by copy/pasting table - no export ability.
application:adapter
application:agent
application:cli
application:compiler
application:meter
application:recorder
application:relay
application:simulator
bug
dependencies
documentation
driver:shdr
duplicate
enhancement
good first issue
help wanted
infrastructure
invalid
localization
tests
wontfix


disabled primary raised button should be grey

<RaisedButton label="Submit" primary={true} disabled={!this.state.value.trim()} />

When this button is disabled, it's color is still red. I think it should be grey.

Thanks for bringing this up @weijar. Please let me know if this solution does not work for you.


This my erorr on .xyz domain

Error occured: Status: 403, Detail: Error creating new cert :: Authorizations for these names not found or expired: pemadamapi.xyz, www.pemadamapi.xyz, Type: urn:acme:error:unauthorized

This is because of the domain pemadamapi.xyz is simply redirecting HTTPS. Please remove the redirection and try agian.


[YUNIKORN-2976] Handle multiple require node allocations per node

What is this PR for?
If an allocation requires a specific node the scheduler should not consider any other node. We should allow multiple allocations that require the same node to reserve the node at the same time. A required node allocation must be placed on the node before anything else. If other non required node reservations are made on a node remove the existing reservations that do not require that node. Make sure that the releases are tracked correctly in the partition.
After the repeat count removal reservations can be simplified:

track reservations using the allocation key
removed the composite key setup
removed collection listener call on reserve or unreserve of a node

Cleanup testing of the node collection
What type of PR is it?

[X] - Bug Fix
[X] - Improvement

Todos

[X] e2e test in the shim requesting multiple daemon sets at once

What is the Jira issue?
YUNIKORN-2976
How should this be tested?
unit tests are updated new e2e test should be added

I've installed this patch on a cluster where I've spun up a kwok-based autoscaler. I encountered a scenario where a monitoring pod (daemonset member) wouldn't schedule on a full node by triggering preemption.  The logs ping-pong back and forth between these two messages now:
2024-12-03T23:37:20.251Z    INFO    core.scheduler.queue    objects/queue.go:1438    allocation found on queue    {"queueName": "root.monitoring", "appID": "monitoring-ac69ed37-d4d7-4c0f-92bd-8f89a16cec74", "resultType": "Reserved", "allocation": "allocationKey ac69ed37-d4d7-4c0f-92bd-8f89a16cec74, applicationID monitoring-ac69ed37-d4d7-4c0f-92bd-8f89a16cec74, Resource map[pods:1], Allocated false"}
2024-12-03T23:37:20.251Z    INFO    core.scheduler.partition    scheduler/partition.go:957    Application is already reserved on node    {"appID": "monitoring-ac69ed37-d4d7-4c0f-92bd-8f89a16cec74", "nodeID": "kind-worker-6fhtj"}

Events for the pod:
Normal  Scheduling     4m13s  yunikorn  monitoring/kube-prometheus-stack-prometheus-node-exporter-5b6p7 is queued and waiting for allocation
Normal  Informational  4m12s  yunikorn  Unschedulable request 'ac69ed37-d4d7-4c0f-92bd-8f89a16cec74' with required node 'kind-worker-6fhtj', no preemption victim found
Normal  Scheduling     4m5s   yunikorn  monitoring/kube-prometheus-stack-prometheus-node-exporter-5b6p7 is queued and waiting for allocation

I'm using admissionController.filtering.generateUniqueAppId: true to use per-pod App ID generation, if that makes a difference. Restarting YK doesn't seem to help.

Sorry for the late response:

The logs ping-pong back and forth between these two messages now:
2024-12-03T23:37:20.251Z    INFO    core.scheduler.queue    objects/queue.go:1438    allocation found on queue    {"queueName": "root.monitoring", "appID": "monitoring-ac69ed37-d4d7-4c0f-92bd-8f89a16cec74", "resultType": "Reserved", "allocation": "allocationKey ac69ed37-d4d7-4c0f-92bd-8f89a16cec74, applicationID monitoring-ac69ed37-d4d7-4c0f-92bd-8f89a16cec74, Resource map[pods:1], Allocated false"}
2024-12-03T23:37:20.251Z    INFO    core.scheduler.partition    scheduler/partition.go:957    Application is already reserved on node    {"appID": "monitoring-ac69ed37-d4d7-4c0f-92bd-8f89a16cec74", "nodeID": "kind-worker-6fhtj"}

One function was not updated to allow multiple daemon set pods to reserve multiple nodes. A test case was missing for that unit test also.

filed two follow up jiras to add unit tests to tryNodesNoReserve and tryPlaceholderAllocate on the application


[otns] Add radio event status emission

This PR adds code in base radio implementation to emit radio events to logs, when OTNS is turned on. This is for Silk-OTNS integration's message visualizations.
This PR works together with https://github.com/openthread/ot-ns/pull/42

@ctan-g , can you help resolve the pretty-check failure?

@jwhui Not sure why it started failing after I prettified the code. Can you try rerunning the Simulation / expects (pull_request) test for me? Thanks!


Regression tests. Closes #150

Some regression tests. I put the file in examples because it is not part of the test suite, but it is useful to save these results for future reference.

Codecov Report

Merging #152 (8377e6a) into master (c8f0e46) will decrease coverage by 0.11%.
The diff coverage is 8.33%.

@@            Coverage Diff             @@
##           master     #152      +/-   ##
==========================================
- Coverage   33.94%   33.84%   -0.11%
==========================================
  Files          36       37       +1
  Lines        2987     2999      +12
==========================================
+ Hits         1014     1015       +1
- Misses       1973     1984      +11

Impacted Files
Coverage Δ

src/RigorousInvariantMeasures.jl
100.00% <ø> (ø)

src/sample_dynamics.jl
8.33% <8.33%> (ø)

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


Suggestion: Favorite button

It would be nice to have a favorite button, easier to know what Pokemon we should keep.

Per my comment on #66, I think that any "favorite" feature exposed by this app should be internal-only. That is, I suppose it's fine to store favorite information in LocalStorage, but, since I believe we should move forward in a read-only fashion, I no longer think it's a good idea to "favorite" a monster by way of the official/unofficial API.

Just pasting my related response from #66 here:
I don't mind the rename / transfer / favorite operations being exposed here. The only caveat is that I feel like our current way of turning them off should remain. It gives the ability to have a read only app, with the flexibility to perform some non XP earning operations related to Pokemon management.
With that being said, I think favoriting would be the last write operation that we should put any work towards.


No authorization headers sent after first load/hydration (client side navigation/HMR)

Environment

Operating System: Linux
Node Version:     v16.17.0
Nuxt Version:     3.5.3
Nitro Version:    2.4.1
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      modules, runtimeConfig
Runtime Modules<EMAIL_ADDRESS>Build Modules:    -

Describe the bug
First up - great package, super simple to get set up and an awesome DX improvement. Thanks!
I'm using nuxt-graphql-client with DatoCMS which requires a bearer token to be sent in the authorization header, with each request. This is very easy to set up with the package and, at first seemed to be working great.
runtimeConfig: {
    public: {
      'graphql-client': {
        clients: {
          default: {
            host: 'https://graphql.datocms.com/',
            token: process.env.DATO_CMS_API_KEY,
          },
        }
      }
    }
  },

When a page that requires data first loads, it works perfectly and sends the header with the request. However, if I use <NuxtLink> or navigateTo() to move to another page that uses data from the API, the client side request (e.g. post initial hydration) is sent without the Authorization header.
I have created a simple demo on CodeSandbox (missed the Stackblitz link until the end sorry!) just using a dummy Dato project and a limited read only key here:
https://codesandbox.io/p/sandbox/nuxtgraphqlclient-nav-bug-pj98yk
Once the index has fully loaded (which takes a while given it's a pretty underpowered server), click one of the two links at the top which use data from Dato. The url will change but the page won't load. If you click the refresh button the page will load fine with the article title showing (e.g. SSR). Click to the second article will break again (post hydration client side). If you look at the request in dev tools, the client side request to Dato that doesn't contain the authorisation header.
--
Also this issue also happens when editing the <script setup> contents in an SFC. E.g. HMR runs and when it does the client side request to Dato is without the headers. If you edit the <template> contents it works as expected presumable because the data isn't re-fetched.
Expected behaviour
Navigating to a page with GraphQL data on it with NuxtLink or NavigateTo should make a client side request that includes the authorisation headers configued in NuxtConfig.
Reproduction
https://codesandbox.io/p/sandbox/nuxtgraphqlclient-nav-bug-pj98yk
Additional context
No response
Logs
No response

@timchesney we are also experiencing this issue, we use a hard redirect (window.location.href) to fix this for us

Also experiencing this. I mean it kind of makes sense, since client navigation makes the useAsyncGql run on client only. And since the token is set to be server only by default. This doesn't work.
Possible Solutions:
Public Token (Potential Security Risk)
If your token is not secret, meaning that it can be exposed to public, you can use the retainToken method: https://nuxt-graphql-client.web.app/getting-started/configuration#retaintoken. Some CMS' like Storyblok allow this, some don't. When using WordPress with WPGraphQL for example, you should not do this, since it exposes your application password.
Nuxt Server Components
You could change your component to be a Nuxt Server Component. Keep in mind that this is still marked as experimental. See: https://roe.dev/blog/nuxt-server-components. To do this, add experimental: { componentIslands: true }, to your nuxt.config.ts. Then move your data loading with useAsyncGql into a component named like MyPage.server.vue. In your pages/my-page.vue, just add
<template>
  <MyPage />
</template>

But I think if you have interactivity in any child component, it might not work for you.
SSG
You could also move to static site generation. But this involves much more, and when you're dealing with data that frequently changes, it doesn't make sense.
Disable client side routing
Probably the most hacky one. Also has several performance downsides. Like @Attacler said, you could

move to native <a> tags instead of <NuxtLink>
move all redirects from navigateTo to window.location.href

Please let me know if you found another solution. I went with server components, which work for now.

@madebyfabian Thanks for this reply. I had somehow missed the retainToken option (despite hunting around in the docs for a solution!). For my regular use case with DatoCMS, this solves the issue as the read-only key can be public and passed with front-end requests (much like StoryBlok's key). So that is very helpful. For other projects I will have a look into if server components could be a good work around for us.
Thanks again for the reply.

There has been many updates on the nuxt server components since that issue, and now in nuxt 3.11 it's possible to as well create server pages directly (https://nuxt.com/blog/v3-11#-server-and-client-only-pages).

But I think if you have interactivity in any child component, it might not work for you.

This is works now with the possibility to have client components in server components/pages (https://nuxt.com/docs/guide/directory-structure/components#client-components-within-server-components)


refactor: register msg service

Closes https://github.com/informalsystems/audit-celestia/issues/1
Questions

Why don't we need an rpc route for WirePayForBlob in tx.proto?
I feel like we need additional testing to have confidence in this change. Where can I find reference examples for tests on this type of Cosmos SDK msg service set-up (likely cosmos-sdk / osmosis)

Codecov Report

Merging #1080 (b2c271a) into main (3941003) will increase coverage by 0.12%.
The diff coverage is 72.47%.

@@            Coverage Diff             @@
##             main    #1080      +/-   ##
==========================================
+ Coverage   50.42%   50.54%   +0.12%
==========================================
  Files          72       70       -2
  Lines        4387     4376      -11
==========================================
  Hits         2212     2212
+ Misses       1947     1936      -11
  Partials      228      228

Impacted Files
Coverage Δ

x/blob/keeper/keeper.go
83.33% <ø> (-7.98%)
:arrow_down:

x/blob/module.go
3.63% <0.00%> (-0.07%)
:arrow_down:

x/blob/types/msgs.go
67.39% <70.83%> (ø)

x/blob/keeper/msg_server.go
84.61% <100.00%> (+84.61%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

the state machine shouldn't actually know how to handle the wire messages as they should never be included in the block

makes sense

this is super seceded by removal of the wire msg, so not sure this is worth continuing to pursue

To clarify: I won't pursue adding a route for wire msg considering the in-flight removal of wire msg. But I should continue to pursue registering the msg service (i.e. the remainder of this PR) - right?

with following the frequently changing "best practices" for naming thing in the sdk.

Yea fair enough. I haven't used Cosmos SDK long enough to know when it's appropriate to violate "best practices" so I opted to adopt what was suggested. If we aren't aligned on adopting the contents of https://github.com/informalsystems/audit-celestia/issues/1 proposal to move the discussion there? Apologies for working on this issue without gathering alignment on what's desirable.

Pausing / closing until we have alignment on what we want to adopt from https://github.com/informalsystems/audit-celestia/issues/1


Reconstruct microstructure from pymks two point correlation data

data_correlation = TwoPointCorrelation(
periodic_boundary=True,
cutoff=25,
correlations=[(0,0),(0,1)]
).transform(data)
how can i use the output from TwoPointCorrelation command in pymks package and feed it to MCRpy to reconstruct microstructure. please help.

Please excuse the delayed response, I did not receive a notification of the opened issue.
The easiest approach would be to use the TwoPointCorrelation descriptor of MCRpy, which is a differentiable approximatio to the TwoPointCorrelation in pyMKS.  Or even better, you could use the three-point correlations, which are called Correlations in MCRpy.
Alternatively, if you really need to use the version from pymks, then you can convert the two. The conversion formula is given in this work https://www.researchgate.net/publication/352036973_Reconstructing_random_heterogeneous_media_through_differentiable_optimization in Equation 27. Note that pyMKS provides all symmetrically equivalent entries of S2, which MCRpy does not. Also, the entries are sorted in a different way. An example implementation for this conversion is given here:
import numpy as np

from pymks import TwoPointCorrelation
import mcrpy

cutoff = 25
limit_to = cutoff + 1
ms = np.load('/home/paul/Dokumente/Code/pyMCR/microstructures/pymks_ms_64x64.npy')

pymks_correlations = TwoPointCorrelation(correlations=[(1, 1)], cutoff=cutoff, periodic_boundary=True).transform(
        np.expand_dims(np.stack([1-ms, ms], axis=-1), axis=0))

settings = mcrpy.CharacterizationSettings(
    descriptor_types=['TwoPointCorrelations'], limit_to=limit_to, use_multigrid_descriptor=False, use_multiphase=False)
mcrpy_correlations = mcrpy.characterize(ms, settings)['TwoPointCorrelations']

def compute_factor(settings: mcrpy.CharacterizationSettings) -> float:
    zl = 1 / (1 + np.exp(0.75 * settings.threshold_steepness))
    zu = 1 / (1 + np.exp(-(0.25 * settings.threshold_steepness) ))
    a = 1 / (zu - zl)
    b = -a * zl
    sigmoid = lambda z: 1/(1 + np.exp(-z))
    return sigmoid(-0.25 * settings.threshold_steepness) * a + b

def correct_thresholding(pcs: np.array, settings: mcrpy.CharacterizationSettings) -> np.array:
    ft05 = compute_factor(settings) # Equation 27
    factor = 2 * ft05 ** 2
    pcs[1:] = (1 - factor) * pcs[1:] + factor * pcs[0]
    return pcs

def sort_pymks_to_mcrpy(pymks_s2: np.ndarray, limit_to: int) -> np.ndarray:
    assert pymks_s2.shape[0] == 1
    assert pymks_s2.shape[-1] == 1
    assert len(pymks_s2.shape) == 4
    pymks_s2 = pymks_s2[0, ..., 0]

    out = []
    for i in range(limit_to):
        for j in range(limit_to):
            out.append(pymks_s2[cutoff + i, cutoff + j])
    for i in range(1, limit_to):
        for j in range(1, limit_to):
            out.append(pymks_s2[cutoff + i, cutoff - j])
    return np.array(out)

def convert_pymks_to_mcrpy(pymks_correlations: np.ndarray, settings: mcrpy.CharacterizationSettings) -> np.ndarray:
    return correct_thresholding(sort_pymks_to_mcrpy(pymks_correlations, settings.limit_to), settings)

def error(a, b):
    return np.max(np.abs(a - b))

print(error(convert_pymks_to_mcrpy(pymks_correlations, settings), mcrpy_correlations)) # should be around 1E-9

If you have any further questions, please send an e-mail to<EMAIL_ADDRESS>


Editorial Workflow not working (BETA)

Hi how are you?
I noticed that the editorial workflow doesn't work with Bitbucket, even with the beta feature
Below are screenshots of the error when change draft to review
"EDITORIAL_WORKFLOW_ERROR: content is not under editorial workflow"
NOTE: everything is already configured, including the necessary pull request permissions and those indicated in the official documentation

We are using editorial workflow with Bitbucket. So I'm not 100% sure about what the bug is that you have reported.

@twocs thanks for reporting this. @felipe-dr can you elaborate better on what you mean by "not working"?


Where is the visualization codes?

It is a great work. Roadside BEV is what we need right now. I want to display the results. But I could not find the visualization codes in this project。I want to view the inference results just like the graph in the paper. How to display the inference results?

Do you solve this problem?  I have the same question, I don't know how to visualize the result.

please refer to https://github.com/ADLab-AutoDrive/BEVHeight/blob/main/scripts/data_converter/visual_tools.py


Adjust actor limit counter from 10-30 based on scene size

Is your feature request related to a problem? Please describe.
Only stated in the changelog, new users sometimes expect their single screen scenes to allow up to 30 actors at once, where the limit is 10.
Describe the solution you'd like
Dynamically change the displayed actor limit between10 when a scene is 144-160, 360 tiles large, to 30 when over 1080 tiles? (3 screens tall?)
Describe alternatives you've considered
Figuring out if a scene has more than 10 actors in a screen width to warn?
Or a simpler compile time warning?
Additional context
I suppose advanced users could hide and show actors within a single screen, working around the 10 actor at once limit, but the limits being 30 per map, and 10 on screen is confusing to document either way.

I suppose advanced users could hide and show actors within a single screen, working around the 10 actor at once limit, but the limits being 30 per map, and 10 on screen is confusing to document either way.

I'm actually doing that in my game right now!


Make static website configurable

Is your feature request related to a problem? Please describe.
Static website use to be running on our free tier. So it's automatically running with 2 replicas and there is no resources consumptions. On OSS, we should add it back.
Describe the solution you'd like
Enable the configuration panel for autoscaling and resources config for static website.
There might be a change to do on kinto-builder/deploy image.

@nandiheath that will not block the dashboard but it will not work until it's done

@nandiheath https://github.com/kintoproj/kinto-builder/pull/16


Enable selection of JVM implementation for java toolchain

The current java toolchain implementation has hotspot hardcoded as the jvm impl. Since AdoptOpenJDK provides the option to select openj9 instead of hotspot for the JVM Implementation it would be great to configure that in the toolchain.
Expected Behavior
A configuration option to select the jvm_impl for downloading AdoptOpenJDK.
Current Behavior
hotspot is hardcoded in the URL for downloading from AdoptOpenJDK.
Context
I think it should be made clear, that this option only affects downloading the JDK from AdoptOpenJDK and not for selecting locally installed JDKs.
Our plan is to build our application on our CI server with OpenJ9, where gradle downloads the JDK. This way we can use a more general image for our CI build step.

This is actually not only relevant for downloading but also for selecting a toolchain in case you got both installed locally but your build requires a specific one (e.g. j9)

Thanks, @breucode for the request. This is indeed something we plan on doing. I'm closing this one in favor of a more general issue to track this feature: #14802


April 29th 2024 MicroProfile AI video for YouTube

Here is the link to the video for upload to YouTube. Please update the Meeting Minutes with a link to the recording.
Thanks!

https://www.youtube.com/watch?v=rgUHGj3aUl8 Updated


Config UI: Allow definition of editable primary key

The config UI doesn't allow you to define an editable primary key, although technically it is possible. Currently you would have to have a table with a non-auto-incremented primary key, in the UI you have to NOT tick Is editable and then in the end the field will be editable. Reason for this is that this feature was added at a later stage (kind of hacked into it) due to user requests and was originally not planned.
The goal is to allow ticking the Is editable option for primary keys in the config UI in case there is not auto-incremented primary key: This is just logical. Adjust scripts respectively.

Implemented


Error with the position of the projectiles

Describe the bug
In "Adventure" mode, when attaching a script to a button to launch a projectile, regardless of the configuration it will always be fired from the top of the scene.
This also happens in Top Down 2D mode
To Reproduce
Steps to reproduce the behavior:

Attach a script to button A
When pressed: Launch projectile
Projectile Source: Player
Launch at: Actor Direction
Direction: Player

Expected behavior
In previous versions this setup worked so that the player would shoot projectiles depending on the direction they were heading.
Now the projectile is fired only at the top of the scene.
Screenshots

Platform (please complete the following information):

OS: Debian 12 Bookworm
App version GBS 4.2 Alpha 0 Compilation for Saturday, November 9, 2024

Can confirm. Caused by commit 86905a8.

Thanks for pinpointing the exact commit @patrickmollohan definitely helped diagnose this.
It was caused when an argument to VM_PROJECTILE_LAUNCH was removed which ended up causing the actor direction value to be written over the launch Y coordinate value. I've pushed a fix which should be included in this dev build https://github.com/chrismaltby/gb-studio/actions/runs/11817161198

Thanks for fixing this guys! 95% of my current games are shooters, not being able to shoot would be a problem I think!!!
Great job everything seems to be working now!


Export empty groups (transforms) or a joint that is not used for deformation

Issue
I seem to be unable to export a null object, like a group/locator/joint - I'd like to export an additional animated transform in the hierarchy.
Is there a way to do this?

You can try to explicitly select these objects. Then they should be included in the export. If not, this is a bug I guess.

I can't seem to get them to be exported, they also don't show in the dumpMaya output at all.
It might be related to this code only processing Meshes and Cameras nor does it get processed as ExportableNode since it doesn't trigger this mixed pivot point warning on a Transform that I explicitly gave two different pivots. That warning does show as soon as I parent a mesh underneath and export the mesh instead.
Where should I be looking in the code to enable exporting selected nodes explicitly?

Indeed, it seems to be missing code to also export separate nodes that are not part of skeleton...
It should be easy to add these I guess, just an extra loop over locator nodes.

It should be easy to add these I guess, just an extra loop over locator nodes.

That's what I was hoping. :) It's hard to pinpoint where it's logical the relevant code gets added. Since even already in this Arguments class it's filtered to shapes or cameras for which a locator or empty null group is neither.
Should almost have a args.otherDagNodes or alike. You might be more familiar with the code base, what seems like the most logical approach?

I think in that code it is just missing an extra if block that checks iMFn::kLocator...
It has been a long time since I worked on the plugin ;-)
It does make sense to add a flag to remain backwards compatible.
Do want to give it a shot yourself?
I am about to leave on vacation for 3 weeks unfortunately...


Remove instrumenter in potel-base branch

The option is no longer needed in a POTel world, so we should remove it. Task split off from #3151 .

Completed in #3322


Expanded field become collapsed on value change

The expanded or not state doesn't persist between field value changes
This needs to be persisted just like the expand all option.
Check the GIF :

A workaround to make this less annoying is to click the "EXPAND" button on the top right.
It makes all fields stay open and thus reduces the overall flicker
However I think this should be fixed and each field should keep it's collapsed / expanded state on value change.