Migrate: If DB password contains an @-symbol, part of the password is printed in migrate log

I'm using migrate with a database that has the @-symbol as part of the password - as a result, the connection string has two @'s. This is valid, and works fine.
I noticed today however that when I execute migrations, part of the printed log looks like the below. Assume the password is lulz@truncated-password-here for sake of demonstration, and a full connection string would be similar to: mysql://user-name:lulz@truncated-password-here@database-host-here:database-port-here
Datasource "db": MySQL database "database_name_here" at "truncated-password-here@database-host-here:database-port-here"

I believe the platform is chopping off at the first @, when in fact it should chop at the last @ instead.

Special characters in passwords need to be encoded here - that probably includes @ similar to #. @tomhoule can probably provide a link to how exactly the encoding needs to look like.

There are two separate issues at play:

The @ character does need to be url-encoded. I don't have a specific tutorial/reference document to recommend, but there are a variety of resources. @ would be encoded as %40. We could treat this as first issue about ergonomics.
The parser used by the Typescript CLI parses that without throwing and leaks passwords in the process. This is the more serious issue.

Fixed by https://github.com/prisma/prisma/pull/6546


Add date field for trainee checkout extension

The Person model/view should include a date field where we can note that a checkout extension was granted.  The date should be the date the extension was granted on. We do not need to record the length of the extension.  This field should be visible to the Person and to the admin.  It should only be visible if the Person has a Learner task at a TTT event and has "Passed" status on "Training" as a progress step.

How should the field be labelled on the form and in person's profile? Simply Checkout extension date?

Sorry I missed this question!
It should say Checkout extension granted date -- to make it clear this is the date it was granted, not actually setting a new deadline.  We are not strict about the extension length so this does not need to be tracked.

Question to take to instructor training team - do we want to track multiple checkout extensions?

Will not be completed as part of the checkout project. Moved to misc issue backlog.


Metric and visualization bugs with visualize_and_compare_testing_models.py

Issue description
There was an error first reported by @llasanudin here https://github.com/ivadomed/ivadomed/issues/1135#issuecomment-1142225824 when running the visualize_and_compare_testing_models.py script.
Current behavior
There are 2 errors:

The script runs without the --metric flag, which outputs dice_class0 by default.
However, it fails with the --metric flag (even when using --metric dice_class0).
So there seems to be something wrong with the argument parsing.

They also reported that the scripts runs without the --metric flag but the visualization still fails here.

I'm not very familiar with this script and could use some help to figure it out.
Maybe @mpompolas you have some insights?

Would it make sense to instead do this visualization with WanDB, which has recently be made compatible with ivadomed? @naga-karthik @kiristern @Nish228

There are 2 errors:

The script runs without the --metric flag, which outputs dice_class0 by default.
However, it fails with the --metric flag (even when using --metric dice_class0).
So there seems to be something wrong with the argument parsing.
I second this... I could debug this

Without --metric flag:

with --metric flag (raises an error)

They also reported that the scripts runs without the --metric flag but the visualization still fails here.

I guess the visualization failure seems to be specific to Google Colab bcz I couldn't reproduce it on my machine.
I'll open a PR shortly.

Would it make sense to instead do this visualization with WanDB, which has recently be made compatible with ivadomed? @naga-karthik @kiristern @Nish228

Absolutely! So much so that Yang had created an issue for the same (#1088) but it was on a slightly lower priority as compared to other issues.


save function on store not persisting

I'm trying to persistently save a settimeout in the store to refresh the token, but when the page is updated the function is lost.
import { defineStore } from 'pinia'

export const useAuthStore = defineStore({
  id: 'auth',
  state: () => ({
    refreshTokenTimeout: null
  }),
  persist: true,
  actions: {
    async refreshToken  () {
      const { jwt, user } = //endpoint refresh token
      this.jwt = jwt
      this.user = user
      this.startRefreshTokenTimer()
    },
    startRefreshTokenTimer () {
      const jwtBase64 = this.jwt.split('.')[1]
      const jwtToken = JSON.parse(atob(jwtBase64))
      const expires = new Date(jwtToken.exp * 1000)
      const timeout = expires.getTime() - Date.now() - (60 * 1000)
      this.refreshTokenTimeout = setTimeout(this.refreshToken, timeout)
    },
    stopRefreshTokenTimer () {
      clearTimeout(this.refreshTokenTimeout)
    }
  }
})

Has anyone had a similar problem and know of a solution? Thanks.

Well if you refresh the page you lose any timeout, that's a normal thing with nothing to do with the plugin ?

Closing as stale. Feel free to reopen.


error launching tclapp/entry.tcl

I'm having the following error durinf tclapp init
can't find package as::tdk::obfuscated
while executing
"package require as::tdk::obfuscated"
(file "/usr/src/tdk/tdk.git/trunk/lib/wrapengine/wengine.tcl" line 30)
invoked from within
"source /usr/src/tdk/tdk.git/trunk/lib/wrapengine/wengine.tcl"
("package ifneeded tclapp::wrapengine 1.0" script)
invoked from within
"package require tclapp::wrapengine"
(file "/usr/src/tdk/tdk.git/trunk/lib/wrapengine/tclapp.tcl" line 35)
invoked from within
"source /usr/src/tdk/tdk.git/trunk/lib/wrapengine/tclapp.tcl"
("package ifneeded tclapp 1.0" script)
invoked from within
"package require  tclapp"
(file "/usr/src/tdk/tdk.git/trunk/app/tclapp/lib/app-tclapp/tclapp_startup.tcl" line 56)
invoked from within
"source /usr/src/tdk/tdk.git/trunk/app/tclapp/lib/app-tclapp/tclapp_startup.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $file]"
(procedure "go" line 17)
invoked from within
"go [file join $starkit::topdir lib app-tclapp tclapp_startup.tcl]"
(file "entry.tcl" line 56)

Could you explain what did you do to reproduce it?

Just sourcing app/entry.tcl from tclsh. A debug trace/log would be useful?
El mar, 16 ago 2022 a las 4:05, David Peralta @.***>)
escribió:

Could you explain what did you do to reproduce it?
—
Reply to this email directly, view it on GitHub
https://github.com/ActiveState/tdk/issues/9#issuecomment-1216287355, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AGVC5E2C7NLR7OVGPIO24IDVZNDVXANCNFSM56Q6JGPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

The package you are missing is located under lib/misc/as-tdk-obfuscated.tm. Ensure you have it on your tm::path.

I would like to ask you how to compile into an executable TDK program?

Hi, @ColdfireMC. I just take a few days to make it works, please refer to this link.

Following the tutorial makes it work. Thanks for the advice. It would be useful to have an install makefile or something like that


Add managements methods for web apps

Hey there! So you want to contribute to a Firebase SDK?
Before you file this pull request, please read these guidelines:
Discussion
Related to https://github.com/firebase/firebase-admin-python/issues/472

[x] Create web app
[x] List web apps
[x] Get web app
[x] Get web app config

Testing

[x] Unit tests
[x] Integration tests

API Changes
N/A

Thanks @radyz for the PR. This will probably require an internal API review as it adds to the existing API surface. Please sit tight.


Env vars aren't updating PalWorldSettings.ini

Describe the bug
As directed in the readme, I've updated the environment variables, but <mount_folder>/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini continues to show default values.
To Reproduce
Steps to reproduce the behavior:

Both deleting PalWorldSettings.ini while the server is running or powered off and starting the server again with the specified env. vars, the PalWorldSettings.ini file regenerates to default values.

Expected behavior
I expect the env. var values like SERVER_NAME to populate in PalWorldSettings.ini, but it remains default:
; This configuration file is a sample of the default server settings.
; Changes to this file will NOT be reflected on the server.
; To change the server settings, modify Pal/Saved/Config/LinuxServer/PalWorldSettings.ini.
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(Difficulty=None,DayTimeSpeedRate=1.000000,NightTimeSpeedRate=1.000000,ExpRate=1.000000,PalCaptureRate=1.000000,PalSpawnNumRate=1.000000,PalDamageRateAttack=1.000000,PalDamageRateDefense=1.000000,PlayerDamageRateAttack=1.000000,PlayerDamageRateDefense=1.000000,PlayerStomachDecreaceRate=1.000000,PlayerStaminaDecreaceRate=1.000000,PlayerAutoHPRegeneRate=1.000000,PlayerAutoHpRegeneRateInSleep=1.000000,PalStomachDecreaceRate=1.000000,PalStaminaDecreaceRate=1.000000,PalAutoHPRegeneRate=1.000000,PalAutoHpRegeneRateInSleep=1.000000,BuildObjectDamageRate=1.000000,BuildObjectDeteriorationDamageRate=1.000000,CollectionDropRate=1.000000,CollectionObjectHpRate=1.000000,CollectionObjectRespawnSpeedRate=1.000000,EnemyDropItemRate=1.000000,DeathPenalty=All,bEnablePlayerToPlayerDamage=False,bEnableFriendlyFire=False,bEnableInvaderEnemy=True,bActiveUNKO=False,bEnableAimAssistPad=True,bEnableAimAssistKeyboard=False,DropItemMaxNum=3000,DropItemMaxNum_UNKO=100,BaseCampMaxNum=128,BaseCampWorkerMaxNum=15,DropItemAliveMaxHours=1.000000,bAutoResetGuildNoOnlinePlayers=False,AutoResetGuildTimeNoOnlinePlayers=72.000000,GuildPlayerMaxNum=20,PalEggDefaultHatchingTime=72.000000,WorkSpeedRate=1.000000,bIsMultiplay=False,bIsPvP=False,bCanPickupOtherGuildDeathPenaltyDrop=False,bEnableNonLoginPenalty=True,bEnableFastTravel=True,bIsStartLocationSelectByMap=True,bExistPlayerAfterLogout=False,bEnableDefenseOtherGuildPlayer=False,CoopPlayerMaxNum=4,ServerPlayerMaxNum=32,ServerName="Default Palworld Server",ServerDescription="",AdminPassword="",ServerPassword="",PublicPort=8211,PublicIP="",RCONEnabled=true,RCONPort=25575,Region="",bUseAuth=True,BanListURL="https://api.palworldgame.com/api/banlist.txt")

Screenshots
n/a
Desktop (please complete the following information)

OS: K3s on TrueNAS

docker-compose.yml contents
root@truenas[~]# k3s kubectl -n ix-palworld describe pod palworld-ix-chart-64577                                         5d9cf-5v5tr
Name:             palworld-ix-chart-645775d9cf-5v5tr
Namespace:        ix-palworld
Priority:         0
Service Account:  default
Node:             ix-truenas/<IP_ADDRESS>
Start Time:       Thu, 25 Jan 2024 19:38:59 -0600
Labels:           app.kubernetes.io/instance=palworld
                  app.kubernetes.io/name=ix-chart
                  pod-template-hash=645775d9cf
Annotations:      k8s.v1.cni.cncf.io/network-status:
                    [{
                        "name": "ix-net",
                        "interface": "eth0",
                        "ips": [
                            "<IP_ADDRESS>"
                        ],
                        "mac": "e2:dd:02:b3:31:84",
                        "default": true,
                        "dns": {},
                        "gateway": [
                            "<IP_ADDRESS>"
                        ]
                    }]
                  rollme: IIzTP
Status:           Running
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/palworld-ix-chart-645775d9cf
Containers:
  ix-chart:
    Container ID:   containerd://5ca905068d9d98200c92ea94619188c3e53b702437b6842                                         d13f6f065f1d41a0b
    Image:          thijsvanloef/palworld-server-docker:latest
    Image ID:       docker.io/thijsvanloef/palworld-server-docker@sha256:0a88e6b                                         edaa1510817c52f987404f450921818c529cd67ade7705333b8d642d7
    Ports:          10826/TCP, 27015/TCP, 25575/TCP
    Host Ports:     0/TCP, 0/TCP, 0/TCP
    State:          Running
      Started:      Thu, 25 Jan 2024 19:39:02 -0600
    Ready:          True
    Restart Count:  0
    Limits:
      amd.com/gpu:         0
      gpu.intel.com/i915:  2
      nvidia.com/gpu:      0
    Requests:
      amd.com/gpu:         0
      gpu.intel.com/i915:  2
      nvidia.com/gpu:      0
    Environment:
      PORT:             ****
      MULTITHREADING:   true
      COMMUNITY:        true
      UPDATE_ON_BOOT:   true
      PLAYERS:          16
      SERVER_PASSWORD:  ****
      ADMIN_PASSWORD:   ****
      TZ:               CST
      SERVER_NAME:      ****
      PUBLIC_PORT:      8221
      PUBLIC_IP:        ****
    Mounts:
      /palworld from ix-host-path-palworld-0 (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-qqm9c (                                         ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  ix-host-path-palworld-0:
    Type:          HostPath (bare host directory volume)
    Path:          /mnt/Canonball/set1/Palworld
    HostPathType:
  kube-api-access-qqm9c:
    Type:                    Projected (a volume that contains injected data fro                                         m 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 fo                                         r 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists                                          for 300s
Events:
  Type    Reason          Age   From               Message
  ----    ------          ----  ----               -------
  Normal  Scheduled       10m   default-scheduler  Successfully assigned ix-palw                                         orld/palworld-ix-chart-645775d9cf-5v5tr to ix-truenas
  Normal  AddedInterface  10m   multus             Add eth0 [<IP_ADDRESS>/16] fro                                         m ix-net
  Normal  Pulled          10m   kubelet            Container image "thijsvanloef                                         /palworld-server-docker:latest" already present on machine
  Normal  Created         10m   kubelet            Created container ix-chart
  Normal  Started         10m   kubelet            Started container ix-chart

Container/Host Logs
2024-01-25 19:39:02.115105-06:00*****EXECUTING USERMOD*****
2024-01-25 19:39:02.116874-06:00usermod: no changes
2024-01-25 19:39:02.693311-06:00*****STARTING INSTALL/UPDATE*****
2024-01-25 19:39:32.067025-06:00tid(22) burning pthread_key_t == 0 so we never use it
2024-01-25 19:39:32.067139-06:00Redirecting stderr to '/home/steam/Steam/logs/stderr.txt'
2024-01-25 19:39:32.067166-06:00Logging directory: '/home/steam/Steam/logs'
2024-01-25 19:39:32.067199-06:00[  0%] Checking for available updates...
2024-01-25 19:39:32.067216-06:00[----] Verifying installation...
2024-01-25 19:39:32.067231-06:00[  0%] Downloading update...
2024-01-25 19:39:32.067247-06:00[  0%] Checking for available updates...
2024-01-25 19:39:32.067262-06:00[----] Download complete.
2024-01-25 19:39:32.067276-06:00[----] Extracting package...
2024-01-25 19:39:32.067291-06:00[----] Extracting package...
2024-01-25 19:39:32.067316-06:00[----] Extracting package...
2024-01-25 19:39:32.067332-06:00[----] Extracting package...
2024-01-25 19:39:32.067347-06:00[----] Installing update...
2024-01-25 19:39:32.067362-06:00[----] Installing update...
2024-01-25 19:39:32.067377-06:00[----] Installing update...
2024-01-25 19:39:32.067391-06:00[----] Installing update...
2024-01-25 19:39:32.067406-06:00[----] Installing update...
2024-01-25 19:39:32.067430-06:00[----] Installing update...
2024-01-25 19:39:32.067446-06:00[----] Installing update...
2024-01-25 19:39:32.067461-06:00[----] Installing update...
2024-01-25 19:39:32.067476-06:00[----] Cleaning up...
2024-01-25 19:39:32.067491-06:00[----] Update complete, launching Steamcmd...
2024-01-25 19:39:33.216766-06:00tid(34) burning pthread_key_t == 0 so we never use it
2024-01-25 19:39:33.216797-06:00Redirecting stderr to '/home/steam/Steam/logs/stderr.txt'
2024-01-25 19:39:33.216804-06:00Logging directory: '/home/steam/Steam/logs'
2024-01-25 19:39:33.216809-06:00[  0%] Checking for available updates...
2024-01-25 19:39:33.216815-06:00[----] Verifying installation...
2024-01-25 19:39:33.216820-06:00Steam Console Client (c) Valve Corporation - version<PHONE_NUMBER>
2024-01-25 19:39:33.216826-06:00-- type 'quit' to exit --
2024-01-25 19:39:33.440522-06:00Loading Steam API...OK
2024-01-25 19:39:33.440555-06:002024-01-25T19:39:33.440555166-06:00
2024-01-25 19:39:35.621949-06:00Connecting anonymously to Steam Public...OK
2024-01-25 19:39:35.622116-06:00Waiting for client config...OK
2024-01-25 19:39:46.037128-06:00Waiting for user info...OK
2024-01-25 19:39:46.037212-06:00Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
2024-01-25 19:39:46.037238-06:00Update state (0x5) verifying install, progress: 0.09 (2097152 /<PHONE_NUMBER>)
2024-01-25 19:39:46.037280-06:00Update state (0x5) verifying install, progress: 43.67 (981679719 /<PHONE_NUMBER>)
2024-01-25 19:39:46.037302-06:00Update state (0x5) verifying install, progress: 92.88<PHONE_NUMBER> /<PHONE_NUMBER>)
2024-01-25 19:39:46.037323-06:00Success! App '2394010' fully installed.
2024-01-25 19:39:46.205966-06:00*****CHECKING FOR EXISTING CONFIG*****
2024-01-25 19:39:46.206038-06:00*****GENERATING CONFIG*****
2024-01-25 19:39:46.559439-06:00setrlimit() failed with error 22 (Invalid argument)
2024-01-25 19:39:46.559478-06:00- Max per-process value allowed is 1 (we wanted infinity).
2024-01-25 19:39:46.957546-06:00[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
2024-01-25 19:39:47.088337-06:00CAppInfoCacheReadFromDiskThread took 2 milliseconds to initialize
2024-01-25 19:39:47.112534-06:00Setting breakpad minidump AppID = 2394010
2024-01-25 19:39:47.113460-06:00[S_API FAIL] Tried to access Steam interface SteamUser021 before SteamAPI_Init succeeded.
2024-01-25 19:39:47.113477-06:00[S_API FAIL] Tried to access Steam interface SteamFriends017 before SteamAPI_Init succeeded.
2024-01-25 19:39:47.569036-06:00[S_API FAIL] Tried to access Steam interface STEAMAPPS_INTERFACE_VERSION008 before SteamAPI_Init succeeded.
2024-01-25 19:39:47.634163-06:00[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
2024-01-25 19:40:06.235191-06:00RCON_ENABLED=true
2024-01-25 19:40:06.245243-06:00RCON_PORT=25575
2024-01-25 19:40:06.258161-06:00*****STARTING SERVER*****
2024-01-25 19:40:06.258260-06:00./PalServer.sh -port=10826 -players=16 EpicApp=PalServer -publicip=<IP_ADDRESS> -publicport=8221 -servername=Them Bucky Boys -serverpassword=**** -adminpassword=**** -queryport=27015 -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
2024-01-25 19:40:06.659776-06:00setrlimit() failed with error 22 (Invalid argument)
2024-01-25 19:40:06.659808-06:00- Max per-process value allowed is 1 (we wanted infinity).
2024-01-25 19:40:06.991414-06:00Shutdown handler: initalize.
2024-01-25 19:40:06.991447-06:00Increasing per-process limit of core file size to infinity.
2024-01-25 19:40:06.991421-06:00[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
2024-01-25 19:40:07.118884-06:00CAppInfoCacheReadFromDiskThread took 2 milliseconds to initialize
2024-01-25 19:40:07.137265-06:00Setting breakpad minidump AppID = 2394010
2024-01-25 19:40:07.138266-06:00[S_API FAIL] Tried to access Steam interface SteamUser021 before SteamAPI_Init succeeded.
2024-01-25 19:40:07.138282-06:00[S_API FAIL] Tried to access Steam interface SteamFriends017 before SteamAPI_Init succeeded.
2024-01-25 19:40:07.590220-06:00[S_API FAIL] Tried to access Steam interface STEAMAPPS_INTERFACE_VERSION008 before SteamAPI_Init succeeded.
2024-01-25 19:40:07.646441-06:00[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.

Additional context
the blank values in the PalWorldSettings.ini were not intentionally removed, that is the state of the file after deleting and rebooting or powering off, deleting, and booting

Oh and I forgot to mention, you can see in my logs that some of the env vars are getting set as program arguments. The ones that aren't, like the server name, are getting default values in the .ini. There just seems to be a disconnect in k3s sourcing the env vars correctly for .ini, bu the program arguments are working fine. I am able to connect directly with the set password via environment variables.

When I was looking at the startup scripts, every server control from env vars was startup args. There was no sed-fu on the .ini file.

I think I see the issue, the server startup command isn't in quotes, so spaces wouldn't be supported. I'm going to submit a pull request to encapsulate those in quotes. I'll test it first though.

Yup, that was exactly it. For some reason, it's not showing up in Community servers, but it shows up in Recent Servers. When I had spaces it shows as "Them"

#124

Unfortunately it looks like my issue persists. I assumed it was consistent across deployments, but this looks to be a k8s issue vs. docker, specifically k3s running on TrueNAS. There must be some subtle difference in bash versions in how they are handling start.sh and the STARTCMD. I'll continue to debug.

I'm sure this has been fixed by now. His deployment sounds a little different, but I've been running this server on an iX Systems custom docker image on TrueNAS since week 1 of Palworld release and I have no issues. It runs k3s in the background. It sounds like this deployment may be directly k3s instead of via docker, and I imagine there was some misconfiguring or simply the bug has already been fixed.

If you're going to claim that, please provide evidence?
The server runs fine, but it does not allow for spaces in configuration values which should allow them, like the server name or password.
See my above comment that explicitly shows this in the output from the startup script:
2024-01-25 19:40:06.258260-06:00./PalServer.sh -port=10826 -players=16 EpicApp=PalServer -publicip=<IP_ADDRESS> -publicport=8221 -servername=Them Bucky Boys -serverpassword=**** -adminpassword=**** -queryport=27015 -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

Closing this as @xHyperElectric was correct, spaces are now honored in environment variables.
It's totally possible that iX systems updated their libraries that execute the start script and this was entirely unrelated to any changes here.
For what it's worth, I have also been running this since week 1 of palworld and this was an issue long after. Thanks for bringing it back to my attention to check if the issue persisted, as it does not for one reason or another!


Add commands for managing deployment locations

Adding commands to LMCTL for adding/removing deployment locations would help developers through their CICD process.

Fixed in release 2.1.0


Fix types menu mobile

specific menuStyle for 'more' menu

Fixed also this use case, for desktop.


External DNS service using service name

Hello
In my Kubernetes environment,  I’m trying to use the Route53 external DNS service to create records for services based on the service name in route53.
Is there’s a way I can get it to use the kubernetes raw ingress name instead the rancher with the prefix: "default-rancherlb-elb-"
o.e:
My ingress name is kubernetes is x-y-z-1
In Rancher, this gets turned into default-rancherlb-x-y-z-1 and that is the entry added in route53.
Rancher versions:
rancher/server: 1.6.14
Infrastructure Stack versions:
route53: external-dns:v0.7.9
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
Bare Metal with Route53 zone
$ kubectl get ing
NAME      HOSTS     ADDRESS         PORTS     AGE
kuard     *         <IP_ADDRESS>   80        18h

Thanks in advance

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


JobScheduler.Hangfire throws a BinaryFormatter error at runtime

Hello,
I have created a fresh XAF Blazor 22.1.5 project and installed the JobScheduler.Hangfire 4.221.8 version from nuget.  The entire solution compiles without a problem but throws the following error at runtime.
[2022-10-13T04:42:12.854Z] Error: DevExpress.ExpressApp.DC.ObjectCreatingException: Unable to create an instance of the "Xpand.XAF.Modules.JobScheduler.Hangfire.JobSchedulerModule" type.
Reason: "The type initializer for 'Xpand.XAF.Modules.Reactive.ReactiveModuleBase' threw an exception."
---> System.TypeInitializationException: The type initializer for 'Xpand.XAF.Modules.Reactive.ReactiveModuleBase' threw an exception.
---> System.NotSupportedException: BinaryFormatter serialization and deserialization are disabled within this application. See https://aka.ms/binaryformatter for more information.
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph)
at HarmonyLib.PatchInfoSerialization.Serialize(PatchInfo patchInfo)
at HarmonyLib.HarmonySharedState.UpdatePatchInfo(MethodBase original, MethodInfo replacement, PatchInfo patchInfo)
at HarmonyLib.PatchProcessor.Patch()
at HarmonyLib.Harmony.Patch(MethodBase original, HarmonyMethod prefix, HarmonyMethod postfix, HarmonyMethod transpiler, HarmonyMethod finalizer)
at Xpand.Extensions.Harmony.HarmonyExtensions.PatchWith(MethodInfo method, HarmonyMethod prefix, HarmonyMethod postFix, HarmonyMethod transpiler, HarmonyMethod finalizer)
at Xpand.Extensions.Harmony.HarmonyExtensions.PreFix(HarmonyMethod harmonyMethod, MethodInfo method)
at Xpand.XAF.Modules.Reactive.ReactiveModuleBase..cctor()
--- End of inner exception stack trace ---
at Xpand.XAF.Modules.JobScheduler.Hangfire.JobSchedulerModule..ctor() in D:\a\1\s\src\Modules\JobScheduler.Hangfire\Module.cs:line 25
at Create_JobSchedulerModule()
at DevExpress.ExpressApp.Utils.Reflection.TypeData.CreateInstance(Object[] args)
--- End of inner exception stack trace ---
at DevExpress.ExpressApp.Utils.Reflection.TypeData.CreateInstance(Object[] args)
at DevExpress.ExpressApp.ModuleBase.CreateModule(Type moduleType, ModelStoreBase diffsStore)
at DevExpress.ExpressApp.Core.ModuleFactory.ModuleFactoryWithResourcesDiffsStore.CreateModule(Type moduleType)
at DevExpress.ExpressApp.ModuleList.EnsureModuleInList(Type moduleType, IList1 moduleList, List1 requiredModules)
at DevExpress.ExpressApp.ModuleList.AddModuleIntoList(ModuleBase module, IList1 moduleList, List1 requiredModules)
at DevExpress.ExpressApp.ModuleList.RefreshRequiredModules()
at DevExpress.ExpressApp.Utils.BindingListBase1.EndInit()    at DevExpress.ExpressApp.Blazor.ApplicationBuilder.BlazorApplicationBuilder.Build(IServiceProvider serviceProvider)    at DevExpress.ExpressApp.Blazor.Services.XafApplicationFactory1.DevExpress.ExpressApp.AspNetCore.Core.IXafAspNetCoreApplicationFactory<DevExpress.ExpressApp.Blazor.BlazorApplication>.CreateApplication()
at DevExpress.ExpressApp.AspNetCore.Core.Internal.XafApplicationServiceProviderInitializer1.CreateApplication()    at DevExpress.ExpressApp.AspNetCore.Core.Internal.XafApplicationSecurityInitializer1.CreateApplication()
at DevExpress.ExpressApp.AspNetCore.Core.Internal.ApplicationCustomizerCore1.CreateApplication()    at DevExpress.ExpressApp.Blazor.Services.XafApplicationFactory1.DevExpress.ExpressApp.AspNetCore.Core.IXafAspNetCoreApplicationFactory<DevExpress.ExpressApp.Blazor.BlazorApplication>.CreateApplication()
at DevExpress.ExpressApp.Blazor.Services.XafApplicationProvider.CreateApplication()
at System.Lazy1.ViaFactory(LazyThreadSafetyMode mode)    at System.Lazy1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
at System.Lazy`1.CreateValue()
at DevExpress.ExpressApp.Blazor.Pages.LoginPageBase.CreateControl()
at DevExpress.ExpressApp.Blazor.Pages.LoginPage.b__0_0(RenderTreeBuilder __builder2)
at DevExpress.ExpressApp.Blazor.Components.XafExceptionHandler.BuildRenderTree(RenderTreeBuilder __builder)
at Microsoft.AspNetCore.Components.ComponentBase.<.ctor>b__6_0(RenderTreeBuilder builder)
at Microsoft.AspNetCore.Components.Rendering.ComponentState.RenderIntoBatch(RenderBatchBuilder batchBuilder, RenderFragment renderFragment, Exception& renderFragmentException)
I have here the sample project for reference.
DXApplication2.zip
Please advise.  Thank you.

Hello @apobekiaris. I hope you don't me asking if you have any ETA for a fix on this bug please? Thank you.

sorry I forgot to answer here, sample please without sample I will not schedule resources.
The case looks very strange as harmony which cause it does not use BinaryFormatters any more so I do not have a context how you repro this.

No problem @apobekiaris.  The example is in the first message I sent over above.  I uploaded it with filename DXApplication2.zip.

oops yes, I will see to it, hopefully soon as this build has many problems.

Looking forward to a swift resolution @apobekiaris so I can move forward with my project.  As always, I appreciate your contribution to the XAF community and thank you very much for attending to my issues.

fyi I will always reply cases that I am assinged especially with samples. I suggest you have a very easy to upgrade downgrade process/script and do not stop your works because of such bugs.

e.g. downgrading eXpand/DX should be as easy as find/replace their versions in you solution csproj.

Yup I do have branches to my projects so I can stop and switch to other tasks.  But thank you for your tip.  I appreciate it.  What I wanted to convey is that I am now in the stage of my project where automation is key in order for me to truly see the benefit of realizing the application I am building for XAF Blazor.  I can do away with creating the Hangfire integration from scratch but I do believe in not reinventing the wheel since your extension is what I am looking for.

cool here another one some times you could also search this repo for a temp solution :)
https://github.com/eXpandFramework/eXpand/issues?q=BinaryFormatter
there lies your temp fix but as I say it shoul;d not happen with latest harmony somthing is really wrong there

Looks like adding the <EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization> flag to the csproj resolved the BinaryFormatter issue but now it throws a new one that I am not sure how to address.
[2022-10-17T05:16:59.515Z] Error: System.InvalidOperationException: Exception occurs while initializing the 'Xpand.XAF.Modules.Blazor.BlazorModule' module: Install the Xpand.XAF.Modules.Blazor package in the front end project and add: [assembly: HostingStartup(typeof(Xpand.XAF.Modules.Blazor.BlazorStartup))]
---> System.InvalidOperationException: Install the Xpand.XAF.Modules.Blazor package in the front end project and add: [assembly: HostingStartup(typeof(Xpand.XAF.Modules.Blazor.BlazorStartup))]
at Xpand.XAF.Modules.Reactive.Services.XafApplicationRxExtensions.CheckBlazor(XafApplication xafApplication, String hostingStartupType, String requiredPackage)
I have already added the nuget package like so...

Hello @apobekiaris. Would you know a version of your JobScheduler.Hangfire extension that works with XAF 22.1.5?

did u tried following the instructions

---> System.InvalidOperationException: Install the Xpand.XAF.Modules.Blazor package in the front end project and add: [assembly: HostingStartup(typeof(Xpand.XAF.Modules.Blazor.BlazorStartup))]
at Xpand.XAF.Modules.Reactive.Services.XafApplicationRxExtensions.CheckBlazor(XafApplication xafApplication, String hostingStartupType, String requiredPackage)

also I see 1.7.31 hangfire version  which does not match the one the package uses, but I am not certain why
Get-NugetPackageDependencies Xpand.xaf.modules.Jobscheduler.Hangfire|sls hang

Hangfire.AspNetCore [1.7.30, )
Hangfire.Core [1.7.30, )

did u tried following the instructions

---> System.InvalidOperationException: Install the Xpand.XAF.Modules.Blazor package in the front end project and add: [assembly: HostingStartup(typeof(Xpand.XAF.Modules.Blazor.BlazorStartup))]
at Xpand.XAF.Modules.Reactive.Services.XafApplicationRxExtensions.CheckBlazor(XafApplication xafApplication, String hostingStartupType, String requiredPackage)

I apologize @apobekiaris but I am still learning XAF so even though I installed this package, I am uncertain how to add the BlazorStartup to the Startup.cs class.  Can you share some code on how to do this please?

also I see 1.7.31 hangfire version which does not match the one the package uses, but I am not certain why
Get-NugetPackageDependencies Xpand.xaf.modules.Jobscheduler.Hangfire|sls hang

Hangfire.AspNetCore [1.7.30, )
Hangfire.Core [1.7.30, )

I went ahead and downgraded Hangfire package to 1.7.30.

@ramilcatalandomingo I guess you work veru hard you need a break :)
the exception instructs you:

Install the Xpand.XAF.Modules.Blazor package in the front end project and add: [assembly: HostingStartup(typeof(Xpand.XAF.Modules.Blazor.BlazorStartup))]

what is not clear in this message

here a sample registration from the easutests project
https://github.com/eXpandFramework/Reactive.XAF/blob/6ac0a6c27281c9d55c7ac53256fb058a204806fa/src/Tests/EasyTests/TestApplication/TestApplication.Blazor.Server/Startup.cs#L20-L23

Thank you so much @apobekiaris.  I apologize for the newbie questions.  I appreciate your help.  By the way, would you know when is the timeline of the next release of your extension that fixes this issue?

yesterday but appearently there are delays working on them, cannot estimate the unknown

Okay understood.  Thank you @apobekiaris

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


Checkpoints Simplified

What does this PR do?
Refactors checkpoint workflow to be simpler and cleaner. Fixes bug resulting in timeout with checkpoints.
Top lines are old way, bottom lines are corrected code:

Future work

fix autoresume in same way

What issue(s) does this change relate to?
CO-1881
CO-1883

Nicely done! Sorry I didn't see it time, but LGTM since I was there when you made the fix


[Java] Using sinceVersion from field instead of type declaration

Generated if statement in decoder's methods must use sinceVersion from fields declaration, not type declarations.

I also added sinceVersion static methods for composite type members.

In general, this looks quite good. Thanks for adding the test!

Should probably remove the extension to the MessageHeader, though.

Extending a message header is tricky. The message header itself does not come with its own length fields thus it will break existing code which expects message headers to be constant length. It is a part of the specification I've never been comfortable with. The fact that the schemas cannot cross reference makes this more tricky and the only practical way to do anything cross schema is to relay on fixed message headers and other types like group and var data header encodings.

Okay, I removed message header extension, but I still would like to have sinceVersion methods in composite decoder classes, if it is not a problem.
I also made similar changes to enums and bitsets.
BTW, don't you think that for enum fields it would be better to remove NULL_VAL constant instead of null reference?

@zyulyaev The NULL_VAL and SBE_UNKNOWN make it easy to deal with an enum in a switch statement. Without them you could get a NullPointerException.

@mjpt777 Sorry, I meant “return”, not “remove”. And that’s exactly my point. But now generated “if” block returns null reference, not the NULL_VAL for enums.

@zyulyaev Yes it would make more sense to return the NULL_VAL from the property getter if not present. Good spot.

@zyulyaev I've made a change to return the NULL_VAL like you suggested.

@mjpt777 Great, thank you!


Over resource limits on Streamlit Cloud

Hey there :wave: Just wanted to let you know that your app on Streamlit Cloud deployed from this repo has gone over its resource limits. Access to the app is temporarily limited. Visit the app to see more details and possible solutions.

Thanks for the heads up! I restarted the server and it should be up and running again.


Duplicate with Licenses are missing Service Plan (Exchange Foundation) #76488

Hello Teams,
The licensee (ENTERPRISE MOBILITY + SECURITY E5 | b05e124f-c7cc-45a0-a6aa-8cf78c946968) still missing the service plan
image
Please help to update that service plan (Exchange Foundation | 113feb6c-3fe4-4440-bddc-54d774bf0318)

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

ID: 7c245452-161d-89a1-c026-99a0721cf071
Version Independent ID: 16dec59a-eb83-1837-4efd-4645e7aeaed2
Content: Product names and service plan identifiers for licensing - Azure AD
Content Source: articles/active-directory/enterprise-users/licensing-service-plan-reference.md
Service: active-directory
Sub-service: enterprise-users
GitHub Login: @daveba
Microsoft Alias: daveba

Thank you for reaching out and bringing this to our notice. At this time we are reviewing the feedback and will provide an update as appropriate.

A change with the missing service plans was published and this is now available online. Closing this issue.
#Please-close


Issue with editing Logic App (Process team request).

The deployment completed successfully, without any errors.
Following the document I tried to edit the Logic app to adjust the SharePoint site collection settings
When I tried to edit: Update status to Team Creation, the following message appears:
Swagger not found for connector '/subscriptions/c499ec5d-3ce0-4cb3-ac54-XXXXXXf/providers/Microsoft.Web/locations/West Europe/managedApis/sharepointonline'

Any ideas what went wrong?

The deployment completed successfully, without any errors.
Following the document I tried to edit the Logic app to adjust the SharePoint site collection settings
When I tried to edit: Update status to Team Creation, the following message appears:
Swagger not found for connector '/subscriptions/c499ec5d-3ce0-4cb3-ac54-XXXXXXf/providers/Microsoft.Web/locations/West Europe/managedApis/sharepointonline'

Any ideas what went wrong?

Just out of interest when did you get the latest code? There was a previous issue where if the 'Display Name' (West Europe) of the Azure Region was passed to the deployment script as opposed to the 'Internal Name' (West Europe) then the API connections would be created incorrectly.
This should have now been resolved.

I have downloaded the code on Monday May 11th.

The deployment completed successfully, without any errors.
Following the document I tried to edit the Logic app to adjust the SharePoint site collection settings
When I tried to edit: Update status to Team Creation, the following message appears:
Swagger not found for connector '/subscriptions/c499ec5d-3ce0-4cb3-ac54-XXXXXXf/providers/Microsoft.Web/locations/West Europe/managedApis/sharepointonline'

Any ideas what went wrong?

Just out of interest when did you get the latest code? There was a previous issue where if the 'Display Name' (West Europe) of the Azure Region was passed to the deployment script as opposed to the 'Internal Name' (West Europe) then the API connections would be created incorrectly.
This should have now been resolved.

I have downloaded the code on Tue May 12th. When has this been changed/fixed exactly?

The deployment completed successfully, without any errors.
Following the document I tried to edit the Logic app to adjust the SharePoint site collection settings
When I tried to edit: Update status to Team Creation, the following message appears:
Swagger not found for connector '/subscriptions/c499ec5d-3ce0-4cb3-ac54-XXXXXXf/providers/Microsoft.Web/locations/West Europe/managedApis/sharepointonline'

Any ideas what went wrong?

Just out of interest when did you get the latest code? There was a previous issue where if the 'Display Name' (West Europe) of the Azure Region was passed to the deployment script as opposed to the 'Internal Name' (West Europe) then the API connections would be created incorrectly.
This should have now been resolved.

I have downloaded the code on Tue May 12th. When has this been changed/fixed exactly?

See the following pull request - https://github.com/OfficeDev/microsoft-teams-apps-requestateam/pull/13.
There is a function in the deploy.ps1 script which should automatically replace any spaces in the 'Location' parameter. Can you double check that this function is indeed in your script? And also did you use -Location 'West Europe' when you executed the script?

The deployment completed successfully, without any errors.
Following the document I tried to edit the Logic app to adjust the SharePoint site collection settings
When I tried to edit: Update status to Team Creation, the following message appears:
Swagger not found for connector '/subscriptions/c499ec5d-3ce0-4cb3-ac54-XXXXXXf/providers/Microsoft.Web/locations/West Europe/managedApis/sharepointonline'

Any ideas what went wrong?

Just out of interest when did you get the latest code? There was a previous issue where if the 'Display Name' (West Europe) of the Azure Region was passed to the deployment script as opposed to the 'Internal Name' (West Europe) then the API connections would be created incorrectly.
This should have now been resolved.

I have downloaded the code on Tue May 12th. When has this been changed/fixed exactly?

See the following pull request - #13.
There is a function in the deploy.ps1 script which should automatically replace any spaces in the 'Location' parameter. Can you double check that this function is indeed in your script? And also did you use -Location 'West Europe' when you executed the script?

Yes, I have used the following parameter:

This is in the script:
#Check that the provided location is a valid Azure location
function ValidateAzureLocation {
$locations = Get-AzLocation
$Location = $Location.Replace(" ","")

# Validate that the location exists
if($null -eq ($locations | Where-Object Location -eq $Location)) {
    throw "Invalid Azure Location. Please provide a valid location. See this list - https://azure.microsoft.com/en-gb/global-infrastructure/locations/"

}

}

This is in the script:
#Check that the provided location is a valid Azure location
function ValidateAzureLocation {
$locations = Get-AzLocation
$Location = $Location.Replace(" ","")

# Validate that the location exists
if($null -eq ($locations | Where-Object Location -eq $Location)) {
    throw "Invalid Azure Location. Please provide a valid location. See this list - https://azure.microsoft.com/en-gb/global-infrastructure/locations/"

}

}

Ok so that should solve your issue - let me test and get back to you.

@dspooren ok so I have fixed this issue and created a pull request for it, in order to get around it for now, please provide the location in lowercase e.g. west europe.
See linked pull request.
Thanks


bzip2-sys build fails on Windows when its path contains non-latin characters

Using up-to-date master of bzip2-rs with i686 MSVC nightly Rust.
When bzip2-rs directory is in C:\Users\Александр\:
Александр@VAIO-FZ13 MINGW64 ~/bzip2-rs (master)
$ pwd
/c/Users/Александр/bzip2-rs

Александр@VAIO-FZ13 MINGW64 ~/bzip2-rs (master)
$ rustc -vV
rustc 1.5.0-nightly (168a23ebe 2015-10-01)
binary: rustc
commit-hash: 168a23ebe1729386138fa71643382fdd64fac205
commit-date: 2015-10-01
host: i686-pc-windows-msvc
release: 1.5.0-nightly

Александр@VAIO-FZ13 MINGW64 ~/bzip2-rs (master)
$ cargo build
   Compiling winapi v0.2.4
   Compiling libc v0.1.10
   Compiling winapi-build v0.1.1
   Compiling advapi32-sys v0.1.2
   Compiling gcc v0.3.17
   Compiling bzip2-sys v0.1.3 (file:///C:/Users/%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80/bzip2-rs)

build script output was not valid utf-8

When I place bzip2-rs in C:\, the build works.

This is quite odd... The bug is probably with gcc-rs of some form rather than this crate itself, but regardless it shouldn't be happening! I haven't been able to reproduce locally yet, unfortunately, however. Do you know of a way I could do so?

Did I understand you right, you tried non-latin characters in path and it didn't reproduce?
Anyway, this is not that critical, because I know a workaround and have already applied it.
The most unpleasant thing is that I don't have an idea how to debug this sort of bugs. AFAIK cargo runs the executable compiled from build.rs with tons of environment variables, and I have to know them all to  catch it.

Hm yeah I'm not 100% sure if I did the right thing or not, but I ctrl-c + ctrl-v'd the directory name from above (Александр) into a terminal and then ran cargo build inside of that with a checkout of this repo.
Perhaps you could provide a program which when run exhibits this behavior? (e.g. programatically creates a directory with an offending character)

Seems you're doing right things.
I tried the following: I patched gcc-rs so it dumps everything from the build script into a file and reproduced the bug. Here is the result: https://www.dropbox.com/s/9y6rmt7mqj1sbtk/build.txt?dl=1

Hm it looks like that file is valid UTF-8, so it may not be precisely what Cargo is choking on. Is there a script that I could run to reproduce this?

I'm working on it and I'll provide it as soon as it's ready and reproducing consistently.


lib/helpers: add deprecation.mkTransitionOptionModule

helpers.deprecation.mkTransitionOptionModule is similar to lib.mkRenamedOptionModule, however it instead warns users that the option was renamed to avoid confusion, and will eventually be transitioned to the new option.
The implementation is basically identical to lib.doRename.
This is intended as one possible solution to #1371 and #1352.
If we go down this route, we would introduce the new plugins as -nvim variants, rename the old plugins to -vim and add a transition alias warning users that the un-suffixed name will transition to the -nvim option.

Users with plugins.surround in their config would get a transition warning.
After we transition, we'd also need to maintain a surround-nvim alias
That alias could eventually switch to a rename (with warning)
We might also want a post-transition warning, telling users the transition has happened.

I've tested this by adding the following to surround.vim's imports and changing name to "surround-vim":
imports = [
  (helpers.deprecation.mkTransitionOptionModule {
    from = [ "plugins" "surround" ];
    to = [ "plugins" "surround-vim" ];
    future = [ "plugins" "surround-nvim" ];
    takeover = "2024-09-09";
  })
];

This produces the following warning when used with a config that contains plugins.surround.enable = true:
trace: warning: The option `plugins.surround' defined in `/nix/store/lylx2xpibp09k24ihrkf8pyn22kv0kcf-source/nvim/config/main.nix' has been renamed to `plugins.surround-vim'.
This has been done to avoid confusion with the new option `plugins.surround-nvim'.

At some point after 2024-09-09, `plugins.surround-nvim' will be moved to `plugins.surround'.

It's a shame multiline trace warnings are so ugly, so I'd appreciate suggestions for making it more readable. The first line of the warning is based on the warning used by lib.doRename.

Maybe we should use NixOS releases as takeovers globally in nixvim?

Maybe we should use NixOS releases as takeovers globally in nixvim?

I agree, I think that'll make things easier for stable users upgrading and we'll also have an obvious reminder of when we need to go through and remove old deprecations.
Although, personally I'm in favor of not removing old deprecations where possible.* Instead we could move them somewhere less obnoxious, like ./warnings.nix files?
* e.g. you can't avoid a transition warning needing to be removed when future takes over from's path.
* or if we can't find a less obnoxious way to maintain the warning (e.g. keymaps.*.lua), then removal is fine.


set-output deprecated

Warning: The `set-output` command is deprecated and will be disabled soon

I believe this can be resolved by updating @actions/core

https://github.com/zendesk/action-create-release/pull/24


Transition from var to let/const

@jsatk @cusackalex
I've already been writing all of my code this way, but didn't realize there were eslint rules to enforce it.
    "no-var": 2,
    "prefer-const": 2,

These two rules will block the use of the deprecated var keyword, and require const over let when a variable is never reassigned. Change suggested by @ryanpon. If this sounds reasonable I can submit a PR.

Putting together a PR for this now. "no-const-assign": 2, is also really important.


padding on DECAPs creates overlap error with tapcells

Summary
While running the temperature sensor design, I got a new error related to how padding is used. Padding seems to be applied to sky130_fd_sc_hd__decap_4  cell and the tool thinks there is an overlap with the tapcells.
Observed behavior:
Design fails at detail placement:
[INFO DPL-0020] Mirrored 63 instances
[INFO DPL-0021] HPWL before            5213.7 u
[INFO DPL-0022] HPWL after             5133.0 u
[INFO DPL-0023] HPWL delta               -1.5 %
[WARNING DPL-0005] Overlap check failed (7).
 TAP_119 overlaps PHY_13
 TAP_123 overlaps PHY_17
 TAP_128 overlaps PHY_25
 TAP_133 overlaps PHY_33
 TAP_138 overlaps PHY_41
 TAP_143 overlaps PHY_49
 TAP_146 overlaps PHY_53
[ERROR DPL-0033] detailed placement checks failed.
Error: detail_place.tcl, 121 DPL-0033
0:00.48elapsed 99%CPU 84476memKB
make[1]: *** [results/sky130hd/tempsense/3_4_place_dp.def] Error 1
make[1]: Leaving directory `/shared/OpenFASOC/generators/temp-sense-gen/flow’

Expected Behavior
Design should not fail at detail placement. My work around is to remove padding for the decap cells as follows:
set_placement_padding -left 0 -right 0 -masters “sky130_fd_sc_hd__decap_4” in tapcell.tcl
set_placement_padding -left 0 -right 0 -masters “sky130_fd_sc_hd__decap_4” in detail_place.tcl
Test case is provided here
floorplan_tempsense_sky130hd__2021-12-17_03-43.tar.gz

DPL checks based on the LEF MACRO class. For sky130_fd_sc_hd__decap_4, the class is CORE which is probably not correct. It should be CORE SPACER.

I'm happy to update the PDK rather than trying to work around it.

@rovinski why should decap be a SPACER?  It isn't a fill cell.  sky130_fd_sc_hd__fill_* are marked as SPACER.
@msaligane is there a reason to use decap rather than fill?

@maliberty It would be nice if there was a LEF class for decap but there isn't. Decap cells don't have any pins except power/ground, so they fit the same profile as filler cells. Most (all?) commercial PDKs I surveyed mark their decaps cells as such (CORE SPACER).

@rovinski I see you are correct.  @QuantamHD can you update the PDK?


Implements RFC0013 for generating app source project metadata

when fetching the git repository it creates as for https://github.com/buildpacks/lifecycle/pull/230 a project-metadata.toml file containing information about the git repository
the layers volume need to be mounted on a different path because if mounted on /layers because the prepare container is built itself using pack and already contains a /layers directory. The specific failure is the launcher failing to read some expected file.
this change can work independently from https://github.com/buildpacks/lifecycle/pull/230

Example of generated toml file
[source]
type = "git"

  [source.version]
  commit = "3b5a3...698317"

  [source.metadata]
  repository = "https://github.com/carlo-colombo/java-maven.git"
  revision = "3b5a3d...698317"

Codecov Report

Merging #287 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #287      +/-   ##
==========================================
+ Coverage   67.38%   67.44%   +0.06%
==========================================
  Files          77       77
  Lines        3097     3115      +18
==========================================
+ Hits         2087     2101      +14
- Misses        762      764       +2
- Partials      248      250       +2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8c736f6...d2cb94d. Read the comment docs.

Holding off on the merge until  buildpacks/lifecycle#230 gets merged

@ashwin-venkatesh https://github.com/buildpacks/lifecycle/pull/230 has been merged

Thanks for the contribution @carlo-colombo 😄


Update About.html file

Update About.html file in wild Guard

you can assigned me for this issue

\assign

/assign


Render mermaid diagrams

I don't really have a current use-case for this, but I think that it would be cool if doc rendering could use mermaid.js to render mermaid diagrams. This is something supported by GitHub.
The most obvious way to do it would be to render code blocks with the mermaid language label, like:
```mermaid
  graph TD;
      A-->B;
      A-->C;
      B-->D;
      C-->D;
```

This would render as:
  graph TD;
      A-->B;
      A-->C;
      B-->D;
      C-->D;

But since Doc is a regular Unison data type, the UI could potentially support some more programmatic way of creating diagrams. Even then I think that it would be nice to support the simple markdown format.

This would be really cool!

This is actually complete.


Switch breaks on Release Touch in Middle

Steps to Reproduce

Create new Switch and initialize it.
Run App
Toggle Switch Normally
Then Toggle Switch Half Way and Release

Flutter Doctor
[flutter] flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, v0.2.8, on Mac OS X 10.13.3 17D102, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 9.3)
[✓] Android Studio (version 3.0)
[✓] VS Code (version 1.22.2)
[✓] Connected devices (1 available)
• No issues found!
exit code 0

Seems to be a dup of #17773 and fixed.


[BUG] Cannot connect to host-local resources via host.k3d.internal

I have configured my host to use local instances of Docker registry as a pull-through cache.
Versions 5.0.1 and earlier could connect to the local registry, versions 5.0.2 and later cannot.

Actual behavior in v5.0.2, v5.0.3, v5.1.0 is that the connection stalls and eventually times out.  After significant delay, the cluster pulls from docker.io possibly triggering the pull rate limiter.
Which OS & Architecture

MacOS / amd64

Which version of k3d

Affected: v5.0.2, v5.0.3, v5.1.0

Which version of docker

docker version
  Client:
   Cloud integration: v1.0.20
   Version:           20.10.10
   API version:       1.41
   Go version:        go1.16.9
   Git commit:        b485636
   Built:             Mon Oct 25 07:43:15 2021
   OS/Arch:           darwin/amd64
   Context:           default
   Experimental:      true

  Server: Docker Engine - Community
   Engine:
    Version:          20.10.10
    API version:      1.41 (minimum version 1.12)
    Go version:       go1.16.9
    Git commit:       e2f740d
    Built:            Mon Oct 25 07:41:30 2021
    OS/Arch:          linux/amd64
    Experimental:     false
   containerd:
    Version:          1.4.11
    GitCommit:        5b46e404f6b9f661a205e28d59c982d3634148f8
   runc:
    Version:          1.0.2
    GitCommit:        v1.0.2-0-g52b36a2
   docker-init:
    Version:          0.19.0
    GitCommit:        de40ad0

docker info
  Client:
   Context:    default
   Debug Mode: false
   Plugins:
    buildx: Build with BuildKit (Docker Inc., v0.6.3)
    compose: Docker Compose (Docker Inc., v2.1.1)
    scan: Docker Scan (Docker Inc., 0.9.0)

  Server:
   Containers: 8
    Running: 8
    Paused: 0
    Stopped: 0
   Images: 23
   Server Version: 20.10.10
   Storage Driver: overlay2
    Backing Filesystem: extfs
    Supports d_type: true
    Native Overlay Diff: true
    userxattr: false
   Logging Driver: json-file
   Cgroup Driver: cgroupfs
   Cgroup Version: 1
   Plugins:
    Volume: local
    Network: bridge host ipvlan macvlan null overlay
    Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
   Swarm: inactive
   Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
   Default Runtime: runc
   Init Binary: docker-init
   containerd version: 5b46e404f6b9f661a205e28d59c982d3634148f8
   runc version: v1.0.2-0-g52b36a2
   init version: de40ad0
   Security Options:
    seccomp
     Profile: default
   Kernel Version: 5.10.47-linuxkit
   Operating System: Docker Desktop
   OSType: linux
   Architecture: x86_64
   CPUs: 4
   Total Memory: 15.64GiB
   Name: docker-desktop
   ID: SBXI:LUN7:X7VF:DONQ:YRNR:I6G2:XXKD:OZLZ:OAR5:CB5X:GS5Q:RDF5
   Docker Root Dir: /var/lib/docker
   Debug Mode: false
   HTTP Proxy: http.docker.internal:3128
   HTTPS Proxy: http.docker.internal:3128
   Registry: https://index.docker.io/v1/
   Labels:
   Experimental: false
   Insecure Registries:
    localhost:5000
    <IP_ADDRESS>/8
   Registry Mirrors:
    http://localhost:5000/
   Live Restore Enabled: false

I believe this has the same underlying cause as #858

Hi @oursland , thanks for opening this issue!
This should be fixed by #872 which will land in k3d v5.2.0 which will be released today :+1:
Feel free to reopen this issue if you're still having problems with the new release.


SoulissApp 1.5.2 Scroll is not working

All scrolling (sliders, color wheel) are not working with this release, simply get the first command at first touch, but doesn't get any other while moving the finger on the screen.
Rolled back to 1.5.0 and this were working fine.

Done some test, on my Motorola MotoG Android 4.4.1, once open the T16 the Color Wheel accept only the first tap, switching to RGB Channel and then back to Color Wheel makes things working fine.


The controller need upgrade to AWS SDK Go v2

What would you like to be enhanced:
From July 31, 2024, the v1 SDK will not receive API updates for new or existing services, or be updated to support new regions.
https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-sdk-for-go-v1-on-july-31-2025/
Why is the change needed and what use case will it solve:

Hi @haouc, @jaydeokar, Im ready to contribute. But can you confirm this one is suitable for new contributor ?
Why: taking reference from this PR https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/3844, can estimate that it will also be quite the same (although not as huge) for this repo.
If you still think it suitable, i can take it. Thanks


Return property mapping on get

I'm not entirely sure if this is something you want to allow, but since it closes #4, until there's a better solution this is better than nothing.

Merging main should solve the CI issue (was lacking a pin of the Python version, fixed here: https://github.com/5monkeys/enum-prop/pull/7)


Create harsha

@harsha0140 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@harsha0140 use your own fork to test Github's features.


Literals errors include validation errors for wrong literal type

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and still think this is a bug

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
pydantic = {extras = ["dotenv", "email"], version = "^1.8.1"}

I would like to create type validations for different literals, but unfortunately I always get validation errors for all literal types not only the one that was used.
Am I doing something completely wrong here or is this a limitation from Python/Pydantic?
from enum import Enum
from typing import ClassVar, List, Literal, Union

from pydantic import HttpUrl
from pydantic.main import BaseModel, Extra

class DessertTypes(str, Enum):
    CAKE = "cake"
    ICE_CREAM = "icecream"
    PANCAKE = "pancake"

class Cake(BaseModel):
    kind: Literal[DessertTypes.CAKE]
    test: str

class IceCream(BaseModel):
    kind: Literal[DessertTypes.ICE_CREAM]
    test2: str

class Pancake(BaseModel):
    kind: Literal[DessertTypes.PANCAKE]
    test3: str

class Meal(BaseModel):
    dessert: Union[Cake, IceCream, Pancake]

print(type(Meal(dessert={"kind": "cake"}).dessert).__name__)

Produces
pydantic.error_wrappers.ValidationError: 5 validation errors for Meal
dessert -> test
  field required (type=value_error.missing)
dessert -> kind
  unexpected value; permitted: <DessertTypes.ICE_CREAM: 'icecream'> (type=value_error.const; given=cake; permitted=(<DessertTypes.ICE_CREAM: 'icecream'>,))
dessert -> test2
  field required (type=value_error.missing)
dessert -> kind
  unexpected value; permitted: <DessertTypes.PANCAKE: 'pancake'> (type=value_error.const; given=cake; permitted=(<DessertTypes.PANCAKE: 'pancake'>,))
dessert -> test3
  field required (type=value_error.missing)

Expected
pydantic.error_wrappers.ValidationError: 1 validation errors for Cake
dessert -> test
  field required (type=value_error.missing)

Indeed and this should work even better in V2!


github.io.bls

Describe the bug
Msmsm
Link to the Bolt URL that caused the error
https://bolt.new/?gad_source=1&gclid=EAIaIQobChMIxfTm4rfPigMV12xBAh1_bxvAEAAYASAAEgJSgfD_BwE
Validations

[X] Please make your project public or accessible by URL. This will allow anyone trying to help you to easily reproduce the issue and provide assistance.

Steps to reproduce
Ke
Expected behavior
Keke
Screen Recording / Screenshot
Nen
Platform
Browser name = Firefox
Full version = 133.0
Major version = 133
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Android 14; Mobile; rv:133.0) Gecko/133.0 Firefox/133.0
performance.memory = undefined

Additional context
Error:
webcontainer-startup-error: _0x4923c5</</_0x5ac12c/<@https://zp1v56uxy8rdx5ypatb0ockcb9tr6a-oci3.w-credentialless-staticblitz.com/iframe.main.c8c182a3.js:1:75277
_0x5ac12c@https://zp1v56uxy8rdx5ypatb0ockcb9tr6a-oci3.w-credentialless-staticblitz.com/iframe.main.c8c182a3.js:1:74560
apply@https://zp1v56uxy8rdx5ypatb0ockcb9tr6a-oci3.w-credentialless-staticblitz.com/iframe.main.c8c182a3.js:1:72649
init@https://zp1v56uxy8rdx5ypatb0ockcb9tr6a-oci3.w-credentialless-staticblitz.com/iframe.main.c8c182a3.js:4:38643

Ksk

Oo


Network Policy Not Enforced on Initial Creation

I am experiencing an issue with network policies not being enforced upon their initial creation in my Kubernetes cluster using the AWS Network Policy Agent. The policies only take effect after being deleted and re-created. Below are the details of my configuration.
Kubernetes YAML resources
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-ingress
  namespace: demo
spec:
  podSelector: {}
  policyTypes:
  - Ingress
Kubernetes Resources:
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: demo
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: demo-app
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-app-index
  namespace: demo
data:
  index.html: |
    <!DOCTYPE html>

        <title>Welcome to Amazon EKS!</title>

Welcome to Amazon EKS!

If you see this page, you are able successfully access the web application as the network policy allows.

For online documentation and installation instructions please refer to
          Amazon EKS Networking.

          The migration guides are available at
          Amazon EKS Network Policy Migration.

Thank you for using Amazon EKS.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  namespace: demo
spec:
  selector:
    matchLabels:
      app: demo-app
  replicas: 1
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: demo
        image: public.ecr.aws/docker/library/nginx:stable
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nginx-index-volume
      volumes:
      - name: nginx-index-volume
        configMap:
          name: demo-app-index
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: client-one
  name: client-one
  namespace: demo
spec:
  containers:
  - image: curlimages/curl:latest
    name: client-one
    command:
    - sleep
    - "360000"
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: client-two
  name: client-two
  namespace: demo
spec:
  containers:
  - image: curlimages/curl:latest
    name: client-two
    command:
    - sleep
    - "360000"

What happened:
When the network policy is initially created, it does not enforce the ingress rules as expected. I am still able to access the demo-app service from the client-one pod. However, after deleting and re-creating the network policy, the policy is enforced correctly, and access is denied as expected.
Attach logs
Initial Network Policy Creation logs from Network Policy agent:
not-working-infra.json
Delete of Network Policy logs:
delete-log-infra.json
Recreation of Network policy logs:
working-infra.json
What you expected to happen:
The network policy should enforce the ingress rules upon initial creation without requiring deletion and re-creation.
How to reproduce it (as minimally and precisely as possible):

Create the namespace and apply the network policy:

kubectl create namespace demo
kubectl apply -f network-policy.yaml

Deploy the Kubernetes resources:
kubectl apply -f kubernetes-resources.yaml

Test connectivity:
kubectl exec -it client-one -- curl demo-app # This returns HTML

Delete and re-create the network policy:
kubectl delete -f network-policy.yaml
kubectl apply -f network-policy.yaml

Test connectivity again:
kubectl exec -it client-one -- curl demo-app # This times out

Anything else we need to know?:
I have verified the CNI plugin configuration and ensured that it supports network policies. This issue seems to be related to the timing or synchronization of the policy application.
Environment:
EKS Version: 1.27
CNI Plugin: v1.18.1-eksbuild.1

@kervrosales Are you saying deleting and recreating the NP solved it? or are you trying to restart pods as well? Pods will be in default allow mode until the network policies are reconciled against them and this can take up to 2-3s based on the cluster load. Please check if this situation applies to you and if it does please try with Strict mode and let us know if it helps..

@achevuru Thanks for your reply!
That is correct; deleting and recreating the NetworkPolicy resolved the issue. I had to do this for each namespace that requires a NetworkPolicy. However, restarting the pods did not resolve the issue, which leads me to believe that the problem I am experiencing might be different from what was previously mentioned.
Can you please confirm that enabling "strict" mode on AWS CNI is achieved by updating the DaemonSet in the kube-system namespace? I have done this, but for some reason, it does not seem to work. None of my new pods get the default-deny policy by default.
I confirm that the container has the correct environment variables:
``
containers:
- env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: strict
- name: ADDITIONAL_ENI_TAGS
value: '{}'
- name: ANNOTATE_POD_IP
value: "false"
- name: AWS_VPC_K8S_CNI_CONFIGURE_RPFILTER
value: "false"
- name: AWS_VPC_CNI_NODE_PORT_SUPPORT
value: "true"
- name: AWS_VPC_ENI_MTU

Thanks!

This is expected, albeit I do not know why the AWS implementation

[...] The Amazon VPC CNI plugin for Kubernetes configures network policies for pods in parallel with the pod provisioning. Until all of the policies are configured for the new pod, containers in the new pod will start with a default allow policy. [...] (https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy.html#cni-network-policy-considerations)

deviates from the official K8s spec for network policies:

All newly created pods affected by a given NetworkPolicy will be isolated before they are started. Implementations of NetworkPolicy must ensure that filtering is effective throughout the Pod lifecycle, even from the very first instant that any container in that Pod is started.  (https://kubernetes.io/docs/concepts/services-networking/network-policies/#pod-lifecycle)

This choice results in severe security implications, mainly that pods might not be isolated for the first few seconds they are started, which would give a malicious actor the opportunity to perform network actions in this short time frame.
@achevuru, imo this should be addressed immediately, as a breach in network allow rules during pod startup poses a high security risk, especially for workloads that cannot be scanned for security issues.

@samox73 Above doc calls out a Strict mode option under the same section, that starts with either default deny instead or the current set of policies configured against the pod.
https://github.com/aws/amazon-vpc-cni-k8s/tree/master?tab=readme-ov-file#network_policy_enforcing_mode-v1171

@achevuru This is not exactly the desired behavior either though. This blocks all traffic by default. Thus, one would have to write policies for all workloads that run in the cluster and need either ingress or egress connections, which can pose a time consuming task that takes multiple days for big clusters.
It would be very cool, if pods that are associated with a network policy have traffic blocked from the start and pods that match no network policy to have default allow.

@samox73 So, I'll summarize the options available right now,

Standard Mode --> Pod creation and Network Policy reconciliation are parallel workflows with Network Policy reconciliation kicking in after the Pod is assigned an IP address. Reconciliation can't start until an IP is assigned to a Pod and the pod Interface is UP and running. Downside of this is that it can (potentially) leave the pod's interface in Default Allow mode for the first few seconds (usually 1-3 seconds) of the pod's lifecycle. However, as I called out above any unexpected (ongoing) connection will be blocked once NP comes in to effect.

Strict Mode --> Pod Creation is blocked until either a Default Deny (or) the current active set of policies are configured against the pod. Usually the initial pod of a deployment/daemonset etc., will come up with default deny and subsequent replicas of the same deployment will come up with current set of active firewall rules against the pods. Will ensure no unauthorized network access is allowed from any pod on the cluster until the reconciliation is complete against the newly launched pod. As you called out, this mode requires an user to have a Network Policy defined for all the pods in the cluster and we landed at this requirement mainly from the customer feedback we received. I understand your concern, that it takes some work to create an NP for every pod in the cluster but you can just create a simple allow all Network Policy per namespace instead and pods in a particular namespace with no specific Network policy will inherit this allow all policy. So, one per namespace would suffice. Downside of this approach is that some pods can (potentially) stay in default deny mode until NP reconciliation is complete against the newly launched pod (usually 1-3 seconds). We're considering providing an option to user, where they can exclude some namespaces from Strict mode enforcement.

Also, If you want to reduce the initial time period (1-3 seconds based on the load) during which a pod is either in default allow (or) default deny mode(based on the NP enforcement mode selected), you can use the ANNOTATE_POD_IP feature of VPC CNI. We introduced this feature precisely for this scenario but for Calico Network policy solution and we extended this to VPC CNI's Network Policy implementation as well. With this feature, it should reduce the initial 1-3s period down to less than a second (or even lower in most cases).

ANNOTATE_POD_IP seems to fix the issue on my side too.

Using ANNOTATE_POD_IP doesn't seem to bring the time down for me.

it should reduce the initial 1-3s period down to less than a second

It appears that setting this only drops the initial period down by maybe a second? And so it still takes a while for either the network policy to be enforced, or if I set the enforcement mode to strict, it still takes a grand total of 7-9 seconds for very small (~30Mb) containers to be addressable.
I have confirmed that the annotation includes the pod IP, etc.
Is there something that I can do to help speed up the pod start up even further?

@achevuru the comment @samox73 made is being somewhat underestimated, I think.
With enforcing mode standard, there's a window during pod start where pods have allow-all access. This is a serious security issue - by the time the policy is enforced, I can already exfiltrate IMDS tokens (for example); it doesn't matter if connections are closed post hoc if the damage is already done.
With enforcing mode strict, there are a number of comon services - external-dns and autoscaler seem to be affected - which attempt to create a client once on pod start; that client creation can fail with errors such as
F0904 10:17:07.344111       1 aws_cloud_provider.go:455] Failed to create AWS Manager: MissingRegion: could not find region configuration

We really need an implementation that follows the k8s spec for network policies.

Hi @achevuru @jayanthvn @jaydeokar,
I wanted to follow up on the deviation of the AWS VPC CNI from the Kubernetes specification. Could you clarify whether this is an intentional divergence or if there are plans to align it with the official spec in the future? If there are ongoing efforts in this direction, any insights on the timeline would be greatly appreciated. Maybe you could also guide a new contributor on where to start to fix this? I would be open to work on this.
Thanks!

I have sone crow to eat here I think.
Looking closely at the netpol behaviour spec, I think what it says "pods are brought up in isolation" describes the behaviour of the vpc-cni in strict mode.
The non-normative text explicitly calls out that pods should be able to operate if their required networking appears after they have started.
We have in fact seen issues with coredns where that didn't happen, but I think that's just a bug.
I am led to conclude that the misbehaviour of things like external-dns (which tries on startup to create an aws client and fails because it can't retrieve a region, for instance) is actually a bug in that software; I think pods should retry client creation until it's successful in those circumstances (and report via readiness when they are running coreectly).


proposing change

updating article to reflect that VMSS work with SDK 2.9 and adding links to Portal and Explorer

Hi @4c74356b41, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@gbowerman - Here's another PR from @4c74356b41 for you to review.

@tysonn @4c74356b41 thanks, looks good.
#sign-off


[NETWORK UPTIME]  Approach one

WHAT DOES THIS PR DO?

Jira cards

GitHub issues

Closes #

HOW DO I TEST OUT THIS PR?
WHICH ENDPOINTS SHOULD BE READY FOR TESTING?:
IS THERE ANY JENKINS CONSOLE LINK FOR CODE COVERAGE AND BUILD INFO?
ARE THERE ANY RELATED PRs?

Thanks @NoahNsimbe for this.
I just have a quick feedback comment that is about strategy for managing different version of uptime calculations.
Is there a way for us to keep current version's code for the future? More like do versioning for uptime calculations?
Context:
In case there is a change of mind in the future (as I highly expect), we shall just switch to any version without writing any new code.
Alternatives to shed more light on the suggestion:

URL versioning: In this approach, the version number is included in the URL for the API endpoint. For example, the endpoint for version 1 of the API might be /api/v1/data and the endpoint for version 2 might be /api/v2/data.
Header versioning: In this approach, the version number is included in the request headers. For example, the client might send a request with a header Accept-Version: v2 to indicate that it wants to use version 2 of the API.
Query string versioning: In this approach, the version number is included in the query string of the URL. For example, the endpoint for version 1 of the API might be /api/data and the endpoint for version 2 might be /api/data?version=2.
etc....

cc: @NsubugaAnold @sserurich

Thanks @NoahNsimbe for this.
I just have a quick feedback comment that is about strategy for managing different version of uptime calculations. Is there a way for us to keep current version's code for the future? More like do versioning for uptime calculations?
Context: In case there is a change of mind in the future (as I highly expect), we shall just switch to any version without writing any new code.
Alternatives to shed more light on the suggestion:

URL versioning: In this approach, the version number is included in the URL for the API endpoint. For example, the endpoint for version 1 of the API might be /api/v1/data and the endpoint for version 2 might be /api/v2/data.
Header versioning: In this approach, the version number is included in the request headers. For example, the client might send a request with a header Accept-Version: v2 to indicate that it wants to use version 2 of the API.
Query string versioning: In this approach, the version number is included in the query string of the URL. For example, the endpoint for version 1 of the API might be /api/data and the endpoint for version 2 might be /api/data?version=2.
etc....

cc: @NsubugaAnold @sserurich

Hi @Baalmart, this is still work in progress.

Thanks @NoahNsimbe for this.
I just have a quick feedback comment that is about strategy for managing different version of uptime calculations. Is there a way for us to keep current version's code for the future? More like do versioning for uptime calculations?
Context: In case there is a change of mind in the future (as I highly expect), we shall just switch to any version without writing any new code.
Alternatives to shed more light on the suggestion:

URL versioning: In this approach, the version number is included in the URL for the API endpoint. For example, the endpoint for version 1 of the API might be /api/v1/data and the endpoint for version 2 might be /api/v2/data.
Header versioning: In this approach, the version number is included in the request headers. For example, the client might send a request with a header Accept-Version: v2 to indicate that it wants to use version 2 of the API.
Query string versioning: In this approach, the version number is included in the query string of the URL. For example, the endpoint for version 1 of the API might be /api/data and the endpoint for version 2 might be /api/data?version=2.
etc....

cc: @NsubugaAnold @sserurich

Hi @Baalmart, this is still work in progress. I shall notify you once its ready for review

Hi @Baalmart
This PR is ready for review.


Fix CI error of PyTorch

Expected behavior
CIs should be passed without error.
Environment
This repo's Github CI: https://github.com/optuna/optuna-examples/actions/workflows/pytorch.yml
Error messages, stack traces, or logs
Error message is as follows:
Run python pytorch/pytorch_lightning_simple.py
Traceback (most recent call last):
  File "pytorch/pytorch_lightning_simple.py", line 19, in <module>
    from optuna.integration import PyTorchLightningPruningCallback
ImportError: cannot import name 'PyTorchLightningPruningCallback' from 'optuna.integration' (unknown location)
Error: Process completed with exit code 1.

Steps to reproduce
See https://github.com/optuna/optuna-examples/actions/workflows/pytorch.yml
Additional context (optional)

Optuna's main repo doesn't see this CI error
ubuntu-latest  has been released after this CI had been broken, the version of ubuntu were same:

From the first failed CI's log
Current runner version: '2.286.0'
Operating System
Virtual Environment
  Environment: ubuntu-20.04
  Version: 20211219.1
  Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20211219.1/images/linux/Ubuntu2004-README.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20211219.1

From the last complete CI's log
Current runner version: '2.285.1'
Operating System
Virtual Environment
  Environment: ubuntu-20.04
  Version: 20211219.1
  Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20211219.1/images/linux/Ubuntu2004-README.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20211219.1

the current runner versions were not the same between the two messages above, but I'm not sure that causes CI error...

The error does hot happen anymore on the main branch...
https://github.com/optuna/optuna-examples/actions/runs/1736220267
Let me close this issue once.


web.magenta-tv.de broken

Site
web.magenta-tv.de
Description
web.magenta-tv.de guide stopped working:
> grab
> npx tsx scripts/commands/epg/grab.ts --site=web.magentatv.de --maxConnections=1 --delay 1000 --days 1

(node:730767) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("file%3A///root/epg/node_modules/tsx/dist/loader.mjs", pathToFileURL("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)
starting...
config:
  output: guide.xml
  maxConnections: 1
  gzip: false
  site: web.magentatv.de
  delay: 1000
  days: 1
loading channels...
  found 348 channel(s)
run #1:
FetchError: request to https://api.prod.sngtv.magentatv.de/EPG/JSON/Authenticate?SID=firstup&T=Windows_chrome_118 failed, reason: connect ENETUNREACH <IP_ADDRESS>:443 - Local (<IP_ADDRESS>:0)
    at ClientRequest.<anonymous> (/root/epg/node_modules/node-fetch/lib/index.js:1491:11)
    at ClientRequest.emit (node:events:517:28)
    at TLSSocket.socketErrorListener (node:_http_client:501:9)
    at TLSSocket.emit (node:events:517:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  type: 'system',

It was a IP v4 issue which is fixed now. It's working again.


feat(live-preview): adding live preview to the template [TOL-1081]

Purpose of PR

Adding live preview SDK with inspector mode (field tagging) and live updates
remove X-Ray
Configure security headers for live preview
Show the settings panel not inside the live preview iframe

Approved the CI build - waiting for that to finish to QA it

One oddity that I spotted, which I can't reproduce locally, the the following:

Enable preview mode
Request is refetched client-side, with the correct CPA token, and preview: true
Disable preview mode
Request is refetched client-side, however it's still using the CPA token instead of the CDA token. preview: false is passed.

Locally it switched tokens correctly but it doesn't seem to on the preview. Can you reproduce?

fwiw; I plan on adding the Next.js preview functionality into this repo today (just the preview API routes itself, not actually integrated anywhere), and then we could consider removing the entire clientside re-fetching logic in favor of Next's approach

One oddity that I spotted, which I can't reproduce locally:

Enable preview mode
Request is refetched client-side, with the correct CPA token, and preview: true
Disable preview mode
Request is refetched client-side, however it's still using the CPA token instead of the CDA token. preview: false is passed.

Locally it switched tokens correctly but it doesn't seem to on the preview. Can you reproduce?

Locally it is working fine, but on the deployment I also get the always the same token - as I can't see it: the secrets are configured correctly for the deployment?
Tested yarn dev and yarn build && yarn start and both is working fine locally

One oddity that I spotted, which I can't reproduce locally:

Enable preview mode
Request is refetched client-side, with the correct CPA token, and preview: true
Disable preview mode
Request is refetched client-side, however it's still using the CPA token instead of the CDA token. preview: false is passed.

Locally it switched tokens correctly but it doesn't seem to on the preview. Can you reproduce?

Locally it is working fine, but on the deployment I also get the always the same token - as I can't see it: the secrets are configured correctly for the deployment?
Tested yarn dev and yarn build && yarn start and both is working fine locally

Tokens are configured correctly in Vercel; anyways, it's not a blocker. The preview boolean is passed correctly so it'll fetch the right content


Core Dump error on plot validation on CentOS 9

This plot was created with a server with 24 CPU Cores and 512 GB of RAM.
the compressed plot was build with CPU not GPU. I am running the validation on the same server that made the plot.
#./bladebit -t 12 validate -u  /mnt/ChiaFarm2/Test/plot-k32-c01-2023-03-16-18-08-xxxxxx.plot
Validating plot /mnt/ChiaFarm2/Test/plot-k32-c01-2023-03-16-18-08-xxxxxx.plot.plot
K               : 32
Unpacked        : true
Maximum C3 Parks: 429442
Unpacking f7 values...
Actual C3 Parks : 429442
Reding park 7...
Loading back pointer tables...
Loading table 6
Loading table 5
Loading table 4
Loading table 3
Loading table 2
Loading table 1
Floating point exception (core dumped)

when I try without the -u option, not only does it fail... it seems to take way longer and only use 8 cores no matter what -t xx setting I use.
./bladebit -t 24 validate /mnt/ChiaFarm2/Test/plot-k32-c01-2023-03-16-18-08-xxxxxxxxxxxxx.plot
Validating plot /mnt/ChiaFarm2/Test/plot-k32-c01-2023-03-16-18-08-xxxxxxxxxx.plot
K               : 32
Unpacked        : false
Maximum C3 Parks: 429442
[ 17] Park range:     304191..322084      Park count: 17893
[  4] Park range:      71576..89470       Park count: 17894
[  2] Park range:      35788..53682       Park count: 17894
[  7] Park range:     125258..143152      Park count: 17894
[ 11] Park range:     196833..214726      Park count: 17893
[  0] Park range:          0..17894       Park count: 17894
[  6] Park range:     107364..125258      Park count: 17894
[ 15] Park range:     268405..286298      Park count: 17893
[  3] Park range:      53682..71576       Park count: 17894
[ 12] Park range:     214726..232619      Park count: 17893
[ 23] Park range:     411549..429442      Park count: 17893
[ 13] Park range:     232619..250512      Park count: 17893
[  8] Park range:     143152..161046      Park count: 17894
[ 14] Park range:     250512..268405      Park count: 17893
[ 20] Park range:     357870..375763      Park count: 17893
[  1] Park range:      17894..35788       Park count: 17894
[ 18] Park range:     322084..339977      Park count: 17893
[ 10] Park range:     178940..196833      Park count: 17893
[ 16] Park range:     286298..304191      Park count: 17893
[  9] Park range:     161046..178940      Park count: 17894
[ 19] Park range:     339977..357870      Park count: 17893
[ 21] Park range:     375763..393656      Park count: 17893
[ 22] Park range:     393656..411549      Park count: 17893
[  5] Park range:      89470..107364      Park count: 17894
[  4] Park 71576 proof fetch failed for f7[715760013] local(13) = 715893389 ( 0x000000002aabaa8d )

I also tried this with zero compression and the bladebit validation still failed.

Tried this again with Alpha 4 -- same issue


Feat/headless browser (retargeted)

Why are these changes needed?

Related issue number

Checks

[x] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[x] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[x] I've made sure all auto checks have passed.

There were some issues with headless tests. Fixed with test: fix headless tests

Added the headless example to the notebook as example 3. ChatResult is being returned by default in the latest version of initiate chat - this is making the notebook unreadable.
Other than this, added a new way to convert bing search page (from selenium) into text -  we can remove a lot of content by converting only the information with main tag.

@INF800 Looks great. Merged into headless_web_surfer. I will add my own PR on to this base, for additional format support and local file browsing. I probably won't get to that tonight though.

@INF800  Ok, I merged your work into the headless_web_surfer branch and created a PR that introduces some of my recent work on supporting multiple file formats and webpages in one common mdconvert utility. It also adds local file browsing and find-in-page support.
More work to do, for sure. And, as noted earlier, I think we might try using Playwright rather than Selenium for file-downloading support.