Application 1.6.0 crashes on startup - MediaTek bug

The current android version keeps crashing on startup.
Steps to reproduce: touch the app icon. After showing a splash screen for a few seconds, the app closes without further notice.
Earlier versions of the app did work on the same phone.
Android systems settings report that corona risk detection is active and that the German Corona Warn App is assigned to manage them. Bluetooth and location service is activated.
Error keeps recurring also after restarting the device.
App version: 1.6.0 (updated using google play store on 9 November 2020).
Android version: 7.0 (security patch 1 December 2018) Kernel 3.18.35+jslave@WUH1000074104 #3
Hardware: Huawei Honor JMM-L22
Build JMM-L22C432B136
EMU-Version 5.1.3

Avoid duplicates

[ ] Bug is not mentioned in the FAQ
[ ] Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
[ ] Bug is not already reported in another issue

Describe the bug

Expected behaviour

Steps to reproduce the issue

Technical details

Mobile device:
Android version:

Possible Fix

Additional context

Internal Tracking ID: EXPOSUREAPP-3847

Hi, I observed the same behaviour with the 1.6.0 version of the app on both my parent’s HTC Desire 12 (with Android 7.1.1, Kernel 4.4.22+); one device failed to start Friday, the other since today; the App shows the logo/splash screen and then crashes directly; the symptom appears to be identical to the description from #1053 but I tried to execute the countermeasure described there and they are not effective.
The system log begins with
F/libc (339): unable to stat "/proc/self/exe": Permission denied
F/libc (339): Fatal signal 6 (SIGABRT), code -6 in tid 339 (init.lct.bootch)

If you need more information I will try to provide that.

Hi @JHKobarg and @openmindculture ,
your issues are most likely not connected to #1053 (with #642 as the underlying root cause). However, the problem is addressed in PRs #1612 and #1604. Interpreting #1620 , a hotfix v1.6.1 should be available in the Google Play Store soon.
@d4rken : FYI. In case you need more logs, @JHKobarg could probably help out here?

A system log (logcat) from a few seconds before the app is opened till after it crashes would be very welcome.
For how long does the splash screen stay? If the splash screen stays for ~15 seconds, it would point towards the encryption issue, as the retry mechanism will give up after 15 seconds.
https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/security/EncryptedPreferencesFactory.kt#L32
https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/RetryMechanism.kt#L43

The splash screen only stays for about 2 seconds, sometimes but not always followed by a white screen for another ca. 4 seconds.
Is there an easy way to generate an error log directly on my phone, or do I have to connect to a pc running adb to do so? I can try to provide an error log tomorrow.
Am 16. November 2020 22:00:13 MEZ schrieb Matthias Urhahn<EMAIL_ADDRESS>
A system log (logcat) from a few seconds before the app is opened till
after it crashes would be very welcome.
For how long does the splash screen stay? If the splash screen stays
for ~15 seconds, it would point towards the encryption issue, as the
retry mechanism will give up after 15 seconds.
https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/security/EncryptedPreferencesFactory.kt#L32
https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/RetryMechanism.kt#L43
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-728326339

ADB would let you pull only that specific log section.
You can also catch a log via "bugreport" on the device itself.
Note that the bug report may contain sensitive information such as your phone number or log output from other installed apps. I'd recommend to not post that publicly, but you could share (email/cloud) that directly with me if that is okay for you (matthias.urhahn@sap.com).

logcat.log
Here is a logfile around a cwa crash.
As the log mentions "not enough space" on my device, I will retry to reproduce the crash after freeing up some space.

Freed up memory, force stopped cwa app, restarted the phone, then launched cwa again. Same bug keeps ocurring.

Awesome thanks for the log, so this is the stacktrace:
11-17 12:23:03.635 29303 29328 E AndroidRuntime: Process: de.rki.coronawarnapp, PID: 29303
11-17 12:23:03.635 29303 29328 E AndroidRuntime: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsJvm.kt:7)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:15)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:13)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	Suppressed: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 		... 5 more

Seems to be this:

https://github.com/Kotlin/kotlinx.coroutines/issues/1989
https://issuetracker.google.com/issues/140347159

That's a tough cookie :frowning_face:
According to b/140347159 on Google's bug tracker it's a bug in the VM of your ROM. Where the code of our app is just right to trigger it.
I can find similar stacktraces for other devices, all with Android 7.0-7.1, and all with Mediatek Chipsets.
Will analyze this further to see what would be the best way forward.
Some thoughts:

This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.
Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific :thinking:

@d4rken this looks like bad news in general, as the bug could occur anytime when the triggering byte code is compiled by chance in future updates... And even Google can fix this issue in a timely manner, will the vendors provide updates for their old devices? (Or is this something that can go through Google Play Services?)
Is there any Huawei Honor JMM-L22 with Android 7 in the Telekom test farm as a test device? If not, then it's maybe time to add one...

@JHKobarg as you are also on Android 7, and your HTC Desire 12 also owns a MediTek chipset, there is a large likelihood, that you're also experiencing the VM Bug.
@openmindculture and @JHKobarg , CWA 1.6.1 just released in Play Store in these minutes. The fixes of that hotfix release are not adressing your problem here. But it would be wonderful if you updated, and report back, if by chance the crash is gone for you (in other words, the byte code change was already good enough).
Thanks a lot!

will the vendors provide updates for their old devices?

I wouldn't get my hopes up. Devices withMediaTek chipsets are unfortunately notorious for this, few updates and ROM specific bugs :frowning:.

(Or is this something that can go through Google Play Services?)

The fix would have to come as OTA from the device manufacturer.

Es ist ja immer irgendwas :slightly_frowning_face:

@d4rken but to have a positive perspective on that issue:
Until now, at least the VM bug was not affecting CWA. And maybe after any arbitrary update, it won't occur again.
Let's keep fingers crossed.

@d4rken one idea: did I see right, that devs put some APKs to the tracked google issue? If it's a specific byte code that triggers the crash, wouldn't it be possible to compare the compilations on binary level, and to search for similar patterns? If the triggering pattern could be identified, then at least after CWA compilation the compiled code could be scanned to be free of the trigger. Worth investigating?

@d4rken another approach could be to build yourself using https://github.com/Kotlin/kotlinx.coroutines/pull/1648#issuecomment-617143634 - this seems to fix/workaround/mitigate it. Not sure if it's possible and worth the effort.

@d4rken one idea: did I see right, that devs put some APKs to the tracked google issue? If it's a specific byte code that triggers the crash, wouldn't it be possible to compare the compilations on binary level, and to search for similar patterns? If the triggering pattern could be identified, then at least after CWA compilation the compiled code could be scanned to be free of the trigger. Worth investigating?

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

@d4rken another approach could be to build yourself using Kotlin/kotlinx.coroutines#1648 (comment) - this seems to fix/workaround/mitigate it. Not sure if it's possible and worth the effort.

That looks interesting and will be looked into.

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

I was assuming, there may be only one specific byte code that triggers the crash for all apps that contain that specific byte code (on Android 7 devices with MediaTek chipset). When comparing different apps (of different producers) experiencing the crash, maybe that triggering byte code could be identified. If you then know that code, in the end, you could check if your own compiled code contains that specific pattern that causes the crash.
If yes,

This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.

Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific thinking

If no, do nothing.
So, if my assumptions would be right, that'll just be workaround, not a fix.

That looks interesting and will be looked into.

If this looks promising for you, then this is actually the best way.
I'm off for the time - have a nice evening and rest of the week!

As of 18 November 2020 on 8:31 a.m. CET, I still do not see CWA 1.6.1 in my German Google Play Store.
As soon as I will, I will install the update and give feedback.
Am 17. November 2020 17:46:01 MEZ schrieb vaubaehn<EMAIL_ADDRESS>
@JHKobarg as you are also on Android 7, and your HTC Desire 12 also
owns a MediTek chipset, there is a large likelihood, that you're also
experiencing the VM Bug.
@openmindculture and @JHKobarg , CWA 1.6.1 just released in Play Store
in these minutes. The fixes of that hotfix release are not
adressing your problem here. But it would be wonderful if you updated,
and report back, if by chance the crash is gone for you (in other
words, the byte code change was already good enough).
Thanks a lot!
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-729054516

CWA 1.6.1 works, no more crash.
Am 17. November 2020 18:38:28 MEZ schrieb vaubaehn<EMAIL_ADDRESS>

Maybe, but I'm not sure if it's an effective approach. Each update
contains so many changes, and we don't have a locally reproduced case,
finding the byte code that causes this could take weeks if not month.
But even if we had a device where we could reproduce it locally. Once
found it's not guaranteed that there is a fix available that would help
all affected devices, it may be that each device needs it's own
specific variant of a fix.

I was assuming, there may be only one specific byte code that triggers
the crash for all apps that contain that specific byte code (on Android
7 devices with MediaTek chipset). When comparing different apps (of
different producers) experiencing the crash, maybe that triggering byte
code could be identified. If you then know that code, in the end, you
could check if your own compiled code contains that specific pattern
that causes the crash.
If yes,

This could be fixed by any update if we are lucky enough that the
code is just compiled different enough to not hit that VM bug.

Could adjust the proguard config so that R8 shrinks the code
differently so that we no longer hit this. Difficult to see which code
to target as the stacktrace is unspecific thinking

If no, do nothing.
So, if my assumptions would be right, that'll just be workaround, not a
fix.

That looks interesting and will be looked into.

If this looks promising for you, then this is actually the best way.
I'm off for the time - have a nice evening and rest of the week!
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-729087684

@openmindculture
Great, thanks a lot!
This gives some space for breathing and time for devs to adapt their testing strategy before future roll outs.
But probably @d4rken will find a long lasting solution for that unforeseen problem :slightly_smiling_face:

@openmindculture
I read some more about the bug, and obviously at might reappear also with 1.6.1 at this stage of investigating the bug:
https://issuetracker.google.com/issues/140347159#comment17
Would you be willingful to help investigating a little? In worst case, it would take a little effort on your side.
What we could try out with your device:
Leave it on the charger during the night, and also maybe for the day time if possible. This could trigger a recompilation/optimization of CWA by your device. The byte code of death could actually occur again, and then also the update 1.6.1 would crash... But hopefully not!
In case of a crash you could reactivate CWA as follows:

install 'immuni' or any other COVID tracing app that makes use of Google's ENF.
start 'immuni' (or other app), make sure that it will be used by ENF and CWA is deactivated by ENF.
uninstall CWA
reinstall CWA 1.6.1 from Google Play Store
It should work again then, until the CWA's code is recompiled/optimized again. Short but frequent charging times could prevent recompiling in future.

But full understanding from my side, if this is just too much effort for you to test, if CWA 1.6.1 might crash again.
Anyway, thanks a lot for your support here!

Hi, I just had a remote session with my parents “How to update Apps manually via Google Store” ... after the update to 1.6.1 they both report the app starts again. Thanks for your help.
As for log files, I could only provide a screenshot from the error message produced by the app. Probably that is not what you need. Though they said, they submitted a couple of that crashes (presumably via the PlayStore feedback?).

I'm very happy that 1.6.1 solved it for a few users. The nature of the bug unfortunately just means that it's "by chance", and Google Play based stack traces show that this still happens for other users :frowning:, although noticeably less often than in 1.6.0. We will keep monitoring this and are evaluating @vaubaehn's kotlin dependency update suggestion as first mitigation.

Leave it on the charger during the night, and also maybe for the day time if possible. This could trigger a recompilation/optimization of CWA by your device. The byte code of death could actually occur again, and then also the update 1.6.1 would crash...

And so it did. CWA 1.6.1 crashed. Do you need more logs?

@openmindculture
That's extremely disappointing. 😳
But thanks very much for your report. If you already took a log, could probably be useful to double check that there's not a second unrelated issue (like #642). If you didn't do yet, we could wait for @d4rken If it's worth the effort.
If you urgently need/want exposure logging, then I'd recommend to recover CWA like described above, and prevent long charging times.
Thanks again

@d4rken

Google Play based stack traces

Are they actively submitted via bug reports? Cause I didn't see any Firebase dependencies?

I can confirm the bug in version 1.6.1.
Smartphone: Motorola E4, MediaTek MT6735
Android 7.1.1
The same bug at the Smarphone of my wife: same cell phone, same bug.

The undesirable optimization, that reintroduces the bug, also happens after 1-2 hours charging.
Reactivating the original cwa 1.6.0 by installing immuni worked, but erased all my previous German tracking history!
So I had 2 days of a working cwa 1.6.0 with only 2 days of data coverage, until it crashed again yesterday.
Still no sign of 1.7.0 for me in Google app store.

Regarding the update to CWA 1.7: Please note that is a staged rollout. Over the next two days, 100% of the users should have received the update.
Best wishes,
DS

Corona-Warn-App Open Source Team

If the update to CWA 1.7 was supposed to fix it - it didn't.
I have exactly the same hardware. I skipped the 1.6 and when I updated from 1.5 to 1.7 (the new one), this exact bug occurs.

Dear community,
Thanks for contributing here.  Stand by for an update to version 1.7.1, it should be available very soon.
Regarding the update to CWA 1.7.1 (for both iOS and Android): Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.
We would appreciate very much your feedback regarding this issue over the next few days!
Best wishes,
DS

Corona-Warn-App Open Source Team

Thanks, @dsarkar - I'll look forward to it.

@openmindculture

Reactivating the original cwa 1.6.0 by installing immuni worked, but erased all my previous German tracking history!
So I had 2 days of a working cwa 1.6.0 with only 2 days of data coverage, until it crashed again yesterday.

Just to prevent any misunderstanding: What was deleted was only the Exposure Check History, the log of matching your stored contacts/exposures against the published diagnosis keys of positive tested users.
So, the most important data is still retained on your device: the received rolling proximity identifiers (RPIs), which are the beacons of other users with contact tracing apps (CWA) that your device recorded. And the temporary exposure keys (TEKs) that your device generates to provide warnings to other users in case you get tested positive and you're submitting your keys. (They would have been deleted, if you not have had installed Immuni.)
The tracking history is mostly only useful for identifiying problems.
In case you're interested in joining our community slack channel, these or other open questions/issues could be discussed there.

Regarding the update to CWA 1.7: Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.
Best wishes,
DS
Corona-Warn-App Open Source Team

Those staged rollouts always take several days for me in google play store. Other stores, like f-droid or Huawei AppGallery don't offer CWA at all. The github release tgz seems to be empty when opened on my mobile.
For a quick rollout and easy access for fellow devs willing to colloborate and give feedback, it would be helpful if you could relase apk files on github if this is possible with reasonable effort.

@openmindculture

For a quick rollout and easy access for fellow devs willing to colloborate and give feedback, it would be helpful if you could relase apk files on github if this is possible with reasonable effort.

The CWA 1.7.0 staged rollout was halted after significant bugs were found. This rollout has now been replaced by CWA Android 1.7.1 with the respective hotfixes incorporated. So the two day rollout clock has been restarted. I agree that it is awkward for fellow collaborators who would like to give quick feedback. Unfortunately going to the Google Play Store manually doesn't let you by-pass the staged rollout.
The official answer in the FAQ about the availability of apks is here. In practice though, Google Play Store apks find their way onto apkmirror.com but I would not recommend downloading 1.7.0 from there since that version has been withdrawn (unless perhaps you are just installing on a test device).
BTW: I'm also waiting for 1.7.1 to appear on my instance of Google Play Store!

V1.7.1 has not a 2 day rollout you should see the update in the playstore

Just got 1.7.1 a few minutes ago.
It opens again and doesn't crash, which is good.
However, right now, it's stuck at checking the data for at least 3minutes. Considering that I haven't been outside the house for 24 hours, that's a bit odd.

Well, there are still problems.
Same problem as yesterday. It's stuck on the checking screen, pressing the arrow sometimes makes it crash, sometimes it gets you to the screen where the hygiene rules are.
I was fiddling with it for thirty minutes whereas before, with 1.5, I was done with in under 5.
I am seriously consideing uninstalling, cleaning the cache and reinstalling fresh.

@Yanabamenara The described behavior is very likely unrelated to this issue ticket, could you create a new one such that it can be independently investigated?

However, right now, it's stuck at checking the data for at least 3minutes. Considering that I haven't been outside the house for 24 hours, that's a bit odd.
Same problem as yesterday. It's stuck on the checking screen, pressing the arrow sometimes makes it crash, sometimes it gets you to the screen where the hygiene rules are.

It should never crash, that's 100% a bug. It being "stuck" or taking longer is not necessarily a bug. From v1.5 to v1.7, the whole process changed a lot. Not only does the app download more data (days+hours), but the actual progress display is more accurate. Previously it would mostly show the progress of the file download, but now it also shows a progress indicator while Google is checking for matches out side of the CWA.
I don't have access to your type of device so I can't say if 3 minutes is an expected amount of processing time.
If the app crashed due to a UI bug, it's possible that the CWA missed the callback regarding Google's key matching being done. This would result in a progress display of ~15 minutes after which our internal check will treat it as "timeout".
If this is reproducible, maybe you could record a video to help me better understand what's going on?

I am seriously consideing uninstalling, cleaning the cache and reinstalling fresh.

I don't think this is required, please wait at least a full day. If something could out of line with the day downloads I'd expect it to fix itself after a 24h and a new day package being available for download.

I can do that.
There's a progress indicator? Where can I find that?
BTW, I have the same device as listed by openmindculture, who started this thread.

@Yanabamenara you can also use the integrated screen recorder but please be aware it will record the surrounding sounds
You can upload to a cloud or e-mail me directly
https://consumer.huawei.com/en/support/content/en-us00762396/
<EMAIL_ADDRESS>

I am seriously consideing uninstalling, cleaning the cache and reinstalling fresh.

@Yanabamenara please be aware that uninstalling the app will also delete your collected RPI (contacts) of the past 14 days. Try to avoid this.
(And should you really need it: there are recommended procedures, like first installing and activating a compatible covid tracing app from another country)

@Yanabamenara you can also use the integrated screen recorder but please be aware it will record the surrounding sounds
You can upload to a cloud or e-mail me directly
[...]

I managed to get one of the crashes with the tablet, when opening and emailed you that short one.
I don't use the Huawei cloud.

Based on bug reports from @Yanabamenara I could narrow down the code the issue partly originates from, which is
https://github.com/corona-warn-app/cwa-app-android/blob/3ad97ffa06df60905eccff571ef462d24edf4f04/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/tracing/GeneralTracingStatus.kt#L22
Curiously the behavior for @Yanabamenara is slightly different than expected, as it's not a permanent crash, but the app opens on subsequent opening attempts.
11-28 21:37:05.926  5429  5429 E AndroidRuntime: FATAL EXCEPTION: main
11-28 21:37:05.926  5429  5429 E AndroidRuntime: Process: de.rki.coronawarnapp, PID: 5429
11-28 21:37:05.926  5429  5429 E AndroidRuntime: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsJvm.kt:7)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:15)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlinx.coroutines.EventLoop.processUnconfinedEvent(EventLoop.common.kt:7)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlinx.coroutines.internal.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuation.kt:23)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlin.collections.CollectionsKt__CollectionsKt.startCoroutineCancellable(Collections.kt:1)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlin.collections.CollectionsKt__CollectionsKt.startCoroutineCancellable$default(Collections.kt:1)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:16)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at kotlin.collections.CollectionsKt__CollectionsKt.launch$default(Collections.kt:7)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at de.rki.coronawarnapp.ui.main.home.HomeFragment.onViewCreated(HomeFragment.kt:46)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:115)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.addAddedFragments(FragmentManager.java:5)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:53)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:11)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:14)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:5)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:129)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.moveFragmentToExpectedState(FragmentManager.java:4)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:360)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentManager.dispatchStateChange(FragmentManager.java:3)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.fragment.app.FragmentActivity.onStart(FragmentActivity.java:9)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at androidx.appcompat.app.AppCompatActivity.onStart(AppCompatActivity.java:1)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1254)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.Activity.performStart(Activity.java:6932)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2834)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2946)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.ActivityThread.-wrap12(ActivityThread.java)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1634)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:113)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:205)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:6783)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1225)
11-28 21:37:05.926  5429  5429 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1086)

Can someone affected look into their exposure detection system log and check the frequency? I'm curious whether the issue is UI related and the app possibly executes sometimes or all the time in the background.
Based on the recent logs, I can at least say that #1707 goes into the right direction, the isTracingEnabled flow is in the code path where @Yanabamenara's stacktraces point.

Over the weekend, the app cannot be opened anymore. It's back to crash on startup. I have no idea why.

@Yanabamenara Can you post a screen of Device > Settings > Google > "Covid-19-Benachrichtungen" >  Menu > "Überprüfungen auf mögliche Begegnungen" ? It will tell us whether the app executed in the background despite crashing on opening .

Sure, can do. Doesn't look like it executed in the background.

@Yanabamenara, Thanks for reporting. Although this is a different issue, is the background actualisation now working or still stuck since 28. Nov. Thanks, DS

@Yanabamenara,  Is the background actualization now working or still stuck since 28. November? Feedback much appreciated. Thanks, DS

Well, @thomasaugsten gave me an apk link for the 1.8 eval, which I'm testing now, and it updates once a day via wifi, as I'm used to.

apk link

Aha 😁

We've bought a Sony Xperia XA, which is the most affected device by this issue. I'm currently trying to find a reliable reproduction case such that I can attempt to experiment with different solutions for this issue.

Not sure if this might be of help, but reading 'optimization' and 'mediatek' triggered me. We (the developers of c:geo) were already hit by an issue in the mediatek jit engine in 2015 (which is AFAIK still not fixed). We were able to mitigate that for the affected users by switching JIT off (adding android:vmSafeMode="true" to the manifest). If you are interested, https://github.com/cgeo/cgeo/issues/4097 gives you our full story.

@d4rken okay, let's continue our conversation started under #1731 in this thread here. Thanks for your explanations.
Actually, I tried a few reinstallations of the app (1.7.0 and 1.7.1) before I did the system upgrade. All with the same result: App closes a few seconds after start. After the system update all apps were gone, so I had to reinstall all apps including cwa of course.
The first start of the app showed the following screens: "Gemeinsam Corona bekämpfen"->"Datenschutz"->"Wie Sie die Risiko-Ermittlung ermöglichen"->"COVID-19-Benachrichtigungen aktivieren?"->"Falls Sie Corona-positiv getestet werden..."->"Warnungen erhalten, Risiken erkennen" -> "Corona-Warn wurde beendet"
After that the app always crashes about 4 seconds after starting it. This can be changed by deleting the app data via "Einstellungen"-> "Apps"->"Corona-Warn"->"Speicher"->"Daten löschen". After that the app starts like during the first start as described above. However, this also appears to delete my previous contacts (under Einstellungen->Google->COVID-19-Benachrichtigungen->).
Perhaps I should mention that the system update did not work from inside Android via menu "->Einstellungen->Über das Telefon->Systemaktualisierung". That method stuck somewhere during the process and did not complete. After a reboot the system appeared unchanged. Therefore I had to use the flashtool. Would you expect that the app optimizations that you mentioned would also occur with the flashtool method ? My understanding is that this flashes a fresh image without any apps installed.
I attach 2 screenshots of the flashtool. Do you think unchecking "userdata" would help to avoid that I have to reinstall all apps after the flashing process ?

Feedback from developers: Fixed in 1.9.

Dear community,
In order to be more specific regarding the previous post https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-744321362: There are several PRs that possibly mitigate the issue, but not necessarily fixes this problem for all users.
We would appreciate feedback regarding this issue after the rollout of releases 1.8 or 1.9.
Thank you for your understanding. Best wishes, DS

Corona-Warn-App Open Source Team

I've tested the 1.8 Eval, and it seems to be fine for me.  (Hardware: Huawei Honor JMM-L22, Build JMM-L22C432B136, EMU-Version 5.1.3, Android 7.0)
@thomasaugsten asked me to start testing the 1.9 Eval - I started with that today.

@Yanabamenara, thanks for letting us know! DS

I have the same Problem with Android 7 and the cwa 1.7.1 on a Moto C Plus. The app works in the background but crashes whenever I try to open the user interface. If anyony could tell me, where I find the apk-links to the eval version, I would test if the updates work for me.

Hi @jmw168,
Thanks for reporting. see https://github.com/corona-warn-app/cwa-app-android/issues/1609#issuecomment-744403230.
Best wishes, DS

Corona-Warn-App Open Source Team

Hi @dsarkar , @d4rken ,
just received the app update.  cwa 1.9.1 solved the issue on my Cubot Kingkong running with Android 1.7.1
Thanks !
HR

Hi@HilRick5.  Thanks for the feedback. We will forward this feedback to the developers. Best wishes, DS

Corona-Warn-App Open Source Team

Hi @jmw168, @JHKobarg, @openmindculture, and community,
We would appreciate feedback on this issue. Did CWA 1.9.1 mitigate the problem for you? Thanks. DS

Corona-Warn-App Open Source Team

Installed CWA 1.9.1 from Google Play Store yesterday and have been keeping the charger on all night for about 11 hours now. Restarted the phone this morning. The app is still working fine. The error did not occur again until now.

@openmindculture, thanks for the feedback, will forward the info to devs. DS

I can confirm that version 1.9.1 doesn't seem to have the bug anymore. I also charged overnight and so far there has been no more crash.
Moto G4

I installed version 1.9.1 yesterday and till now there was no crash.

@jmw168,   @Batterypack200, thanks for the feedback, will forward the info to devs. DS

No further negative reports on this. The bug seems to be fixed for everyone who upgraded to 1.9. We'll close the isse then.

Corona-Warn-App Open Source Team


Quake III Arena Demo

Project link: https://ioquake3.org/
Project license: GPLv2
Does it work on 64-bit only Linux: YES
Is source code available?: YES
Is source code stored in Git?: YES

https://github.com/ioquake/ioq3/

List of Steam AppIds of supported games:

https://steamdb.info/app/9080/

Additional information
ioquake3 demo version info:
https://ioquake3.org/help/players-guide/#demo
https://ioquake3.org/help/players-guide/#sharedlibraries
I couldn't make the demo version work with ioquake3. But following person seems to have managed;
https://slackalaxy.com/2015/07/05/quake-iii-demo/

Steam is not allowing me to download the demo to test this, probably because I own the game. Do you not own this game currently?

I own Quake III, yet I also can download and play the demo version. I requested demo via Steam console:
app_license_request 9080
app_install 9080

I am unable to. Are you able to create a pull request with the changes necessary to make it work?

As mentioned in the other ticket, I'm unable to download these demos.
Are you able to provide steps as to how to get the demo to work with ioquake3? As in the commands needed to get it to load and run?


Delete history command

Adds command for deleting automations that are older than the specified number of days, defaulting to 30 days.

[x] Add command
[x] Add documentation
[x] Add tests

Resolves #12

Codecov Report

Merging #13 (e61b6c9) into master (77b707c) will increase coverage by 0.26%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
+ Coverage   94.13%   94.39%   +0.26%
==========================================
  Files          17       18       +1
  Lines        1193     1214      +21
==========================================
+ Hits         1123     1146      +23
+ Misses         70       68       -2

Impacted Files
Coverage Δ

...s/management/commands/automation_delete_history.py
100.00% <100.00%> (ø)

src/automations/tests/test_automations.py
99.22% <100.00%> (+0.02%)
:arrow_up:

src/automations/models.py
94.17% <0.00%> (+1.94%)
:arrow_up:

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 77b707c...e61b6c9. Read the comment docs.

Wonderful! Thank you very much! Feel like publishing 0.9.4. Or do you have something more worth including now?


add local_as and local_address to get_neighbors()

I am closing this task. We will discuss how to do that later on.


feat: add devices/list_device_providers endpoint

Maybe the issue is you need to use --? From the docs https://github.com/seamapi/javascript/pull/171

@razor-x
ugh yep that was it, good catch. Forgot npm run would consume those arguments itself otherwise


File upload Error 'NoneType' object has no attribute 'encode'

I'm encountering an error when attempting to upload files through UI, as indicated by the following message: 'NoneType object has no attribute "encode"'.
To better understand the issue, I've included some additional details below.
UI Screen print:

UI Resonse:

Backend Request:

Backend Response:

Platform: Windows 10
Browser: Chrome - 131.0.6778.86 (Official Build) (64-bit)
Open WebUI: 0.4.7
Attachment:

Note: I tried after cleaning the browser cookies as well but no luck.

I have encountered it as well. v0.4.7

I had this error. It seems that in my case, the error was caused by the Embedding Model in the Admin Panel. I had to retype the default embedding model and then press the button on the right. After that, the error disappeared.

I dont see Embedding model engine in the version# 0.4.7

Am I missing something?

@Simi5599 : It works for me too after following your workaround. Thanks!
Nevertheless, keep the defect opened for the fix.

I am looking for the source code to see if i can get this to work or maybe the maintainer of the repo will do this before me ;)

UPDATE: I think i did it!
In the file located in /backend/open_webui/apps/retrieval/main.py I made the following corrections:

I created a variable default_embedding_model="sentence-transformers/all-MiniLM-L6-v2"

In the function save_docs_to_vector_db I added the following lines at the very beginning:

If the embedding model is empty i am setting it back to the default value
if not app.state.config.RAG_EMBEDDING_MODEL or app.state.config.RAG_EMBEDDING_MODEL.strip() == "":
    app.state.config.RAG_EMBEDDING_MODEL=default_embedding_model
    update_embedding_model(app.state.config.RAG_EMBEDDING_MODEL)
    app.state.EMBEDDING_FUNCTION = get_embedding_function(
        app.state.config.RAG_EMBEDDING_ENGINE,
        app.state.config.RAG_EMBEDDING_MODEL,
        app.state.sentence_transformer_ef,
        (
            app.state.config.OPENAI_API_BASE_URL
            if app.state.config.RAG_EMBEDDING_ENGINE == "openai"
            else app.state.config.OLLAMA_BASE_URL
        ),
        (
            app.state.config.OPENAI_API_KEY
            if app.state.config.RAG_EMBEDDING_ENGINE == "openai"
            else app.state.config.OLLAMA_API_KEY
        ),
        app.state.config.RAG_EMBEDDING_BATCH_SIZE,
    )
    log.info(f"Embedding model was empty. Set to default: {default_embedding_model}")

The code basically resets the empty RAG_EMBEDDING_MODEL to the default value stored in a variable.
If @tjbck can review this, I can create a PR or let him handle the commit ;)
PROOF:

Let's set the Embedding Model to "" to recreate the issue
Let's feed the LMM with a .pdf file and ask a question
We can observe that the Embedding Model has beed restored to the default value

Apparantly this can also be triggered if the embedding model could not be downloaded due to bad network conditions.

Sometimes I encounter this issue even without modifying the embedding model configuration, and it only returns to normal after resetting the vector database.

Sometimes I encounter this issue even without modifying the embedding model configuration, and it only returns to normal after resetting the vector database.

Possibly fixed on the dev branch with this commit: https://github.com/open-webui/open-webui/commit/4b7f0c5be11ef437301f9ffa5c68fc52fbb37516


EBI-9696567 - never stops dancing

https://www.ebi.ac.uk/intact/complex/details/EBI-9696567

Stops for me. But it's rather big and takes a while to build.

I can increase the ''friction' on the layout algorithm so that it stops more quickly but i think this is more likely to end in a sub-optimal layout

Yes, @bmeldal is right (or @colin-combe fixed it!). It's a large complex and takes a few seconds to build.
Looks great!


Define null characters in convert processor

Is your feature request related to a problem? Please describe.
The convert_entry_type processor requires that the input match the expected type. In some pipelines, this may be provided through a special character that does not convert.
For example, in VPC Flow Logs, reading the CSV file using the csv codec may have some such as srcport (source port) come as - when there is no such value.
I have to delete this entry to provide conversion.
processor:
    - delete_entries:
        with_keys:
          - srcport
        delete_when: '/srcport == "-"'
    - convert_entry_type:
        key: srcport
        type: integer

Describe the solution you'd like
Provide a new configuration in the convert_entry_type processor which allows a list of strings which are explicitly defined to be null (that is removed).
processor:
    - convert_entry_type:
        key: srcport
        type: integer
        null_values: [ '-' ]

The convert_entry_type processor will know to treat any value in the null_values list as null.
Describe alternatives you've considered (Optional)
An alternative solution would be to update the CSV processor and codec to have a concept of null strings. But, these are not mutually exclusive solutions. Not all pipelines will go through CSV.

Assign please it to, it will be finished soon

Thank you @saydar31 !

@saydar31 will you be able to pick up ? https://github.com/opensearch-project/data-prepper/issues/2823


Feature Request: Play videos using Invidious

Could be cool if invidious was built into the site and could be enabled or if you could proxy videos through an already existing invidious instance
Invidious: https://github.com/iv-org/invidious
Invidious instances: https://docs.invidious.io/Invidious-Instances.md

Absolutely not. It does not contribute back views nor support channels through monetization. While I'm of the opinion that superchat > premium > ads in revenue power, Holodex shouldn't actively take a creator-hostile stance at any point.


Sprig 'Load More' and SEO

Hi there,
We have a client that's very focussed on SEO and ensuring that their articles listing is a 'crawlable' as possible.
Are you able to share any examples of using s-boost, specifically when using a 'Load More' button/link? I'm trying to find a way to ensure that the content listed behind their 'Load More Articles' button is still crawled by a search engine. Is s-boost the right solution for this or should I be looking elsewhere?
Here's my current template code:
<button sprig s-val:offset="{{ offset + limit }}" s-target="this" s-swap="outerHTML">
    Load more articles
</button>

We're keen to make this as SEO friendly as possible? Is that doable? Keen to get your thoughts.
Look forward to hearing from you.
Thanks,
Gary

What’s wrong with just using a Sitemap, which are intended exactly for search engines letting know which pages to crawl?

Yeah, fair point. We're using sitemaps, so that should do the trick. Curious to know if this is doable though, in case the client pushes back. If not that's OK. Just want to ensure it's as search engine friendly as possible.

I’m not really sure how to answer your question. If they really want a page that lists all articles then you can simply create one in addition to the Sprigified page, right?

You asked several questions and I tried to provide the most informative answer, but if anything is unclear then let me know.

Hey Ben – Really sorry if my original question was ambiguous. Let's forget about the SEO aspect. I completely agree with you that sitemaps will solve that problem. However, (rephrasing my original question) I'm still curious to know if you have a Sprig recipe for creating a 'Load More' button that works when javascript is disabled? I've been watching a couple of videos on YouTube which references 'hx-boost' but I'm struggling to see how to implement that in the context of Craft/Sprig.
Again, if the answer is 'no', that's totally cool. This is as much about satisfying my curiosity for future reference as much as anything 🙂

Yeah, of course...that would work. I think I've been massively overthinking this one. Thanks for your patience and support Ben 🙂

Sure thing!


flaky test - Custom Operation.Command steps should not be executed twice

Describe the bug

Flaky system test.
Test name
Tests.Tedge Agent.Workflows.Custom Operation.Command steps should not be executed twice

Failure
	Matching messages on topic 'te/device/main///cmd/issue-2896/test-1' is less than minimum.
wanted: 1
got: 0

messages:
[]

Test run

https://github.com/thin-edge/thin-edge.io/actions/runs/9975734448?pr=3000

To Reproduce

The failed test run has only been seen on the CI Runner (to date).
Expected behavior

The test should pass consistently.
Screenshots

Logs:
report-x86_64-unknown-linux-musl (28).zip
Environment (please complete the following information):

OS [incl. version]: Ubuntu 22.04
Hardware [incl. revision]: Github Runner - Ubuntu 22.04
System-Architecture [e.g. result of "uname -a"]: x86_64
thin-edge.io version [e.g. 0.1.0]: 1.1.2~245+gef95336

Additional context

For some reasons, the device failed to restart before the test timeout.
==> /var/log/tedge/agent/workflow-issue-2896-test-1.log <==

==================================================================
Triggered issue-2896 workflow
==================================================================

topic:     te/device/main///cmd/issue-2896/test-1
operation: issue-2896
cmd_id:    test-1
time:      2024-07-17T14:25:02.789915894Z

==================================================================

----------------------[ issue-2896 @ init | time=2024-07-17T14:25:02.790967144Z ]----------------------

State:    {"logPath":"/var/log/tedge/agent/workflow-issue-2896-test-1.log","status":"init"}

Action:   move to executing state

=> moving to issue-2896 @ executing

----------------------[ issue-2896 @ executing | time=2024-07-17T14:25:02.79452961Z ]----------------------

State:    {"logPath":"/var/log/tedge/agent/workflow-issue-2896-test-1.log","status":"executing"}

Action:   execute restart as sub-operation

=> moving to issue-2896 @ await_restart

----------------------[ issue-2896 @ await_restart | time=2024-07-17T14:25:02.798065063Z ]----------------------

State:    {"logPath":"/var/log/tedge/agent/workflow-issue-2896-test-1.log","status":"await_restart"}

Action:   await sub-operation completion

=> sub-operation not yet launched

----------------------[ issue-2896 > restart @ init | time=2024-07-17T14:25:02.801805625Z ]----------------------

State:    {"logPath":"/var/log/tedge/agent/workflow-issue-2896-test-1.log","status":"init"}

Action:   move to scheduled state

=> moving to issue-2896 > restart @ scheduled

----------------------[ issue-2896 > restart @ scheduled | time=2024-07-17T14:25:02.804661149Z ]----------------------

State:    {"logPath":"/var/log/tedge/agent/workflow-issue-2896-test-1.log","status":"scheduled"}

Action:   builtin

----------------------[ issue-2896 > restart @ executing | time=2024-07-17T14:25:02.813999087Z ]----------------------

State:    {"logPath":"/var/log/tedge/agent/workflow-issue-2896-test-1.log","status":"executing"}

Action:   builtin


Running Euroscope via OpenFSD

I tried to run the OpenFSD successully; I wonder if if I can run Euroscope via this FSD server? since the built-in FSD server of Euroscope only restricted 2 controller connections only.

Currently, ATC connections aren't supported. Eventually it may be added; I'll keep this issue open as a feature request.

When will ATC connect be available

Currently, ATC connections aren't supported. Eventually it may be added; I'll keep this issue open as a feature request.

There is a way to work with Euroscope by replacing the URL in Euroscope, but it may be against EULA.

Currently, ATC connections aren't supported. Eventually it may be added; I'll keep this issue open as a feature request.

There is a way to work with Euroscope by replacing the URL in Euroscope, but it may be against EULA.

Maybe so, but to be clear: there's no openfsd support for the ATC-specific FSD protocol. There are also other API endpoints hardcoded into Euroscope & other clients (aside from the plain FSD server address) that need to be addressed as well.


something is wrong with your browser-netron

1.Netron version:  4.4.5 Python Server
2.OS and browser version:   ubuntu16.04 + Firefox 77.0.1(64-bit)
Both of them  worked well  until last night, but now the webpage can't be fully loaded. I tried many times but failed.

Please pip uninstall netron and pip install netron.


Scale error in NEM aggregates

Scale error in aggregate outputs in year/month
https://opennem.org.au/energy/nem/?range=1y&interval=1M
off by factor of two

Dailies are correct
This is likely from push of data to prod this morning and updated facility aggregate query

corrected ... updated all.json query was the fault - has been reverted.

There's a revert commit in the backlog for this - will be in v3.11.0

migrated to mitigation in #211

also #120


Different siglum of same element on "source" in the Apparatus

Dear Axelle,
I find the case of the different representation of source attribute with the same element in the Apparatus. When we put  "source bib:Atja+SalehDanasasmita1983_03" inside <lem> then the siglum becomes  Ed, but if it is placed on <rdg>, then it becomes EDASD. Here is the example:
<app><lem type="norm" source="bib:Atja+SalehDanasasmita1981_03">nañjərkən</lem><rdg wit="#A">najərkən</rdg><rdg wit="#B"/></app> saṅ hyaṅ sasana krəta, pakənən hәbәl hirup həbəl     <app><lem type="emn">ñovana</lem><rdg wit="#A #B">ñavana</rdg><rdg source="bib:Atja+SalehDanasasmita1981_03">ñevana</rdg></app>
The result is as follows:

I would prefer to have EDASD on both cases, just to avoid the ambiguity of the siglum.  What do you think?
Best,
Aditia

Just add a little bit: it works well as I expect in the main text (with mouse slide preview), but not in Apparatus at the bottom page. Thanks.
Best,
Aditia

It should work now

@aditiagunawan : is this problem solved now? if so, please close the issue. (for some reason, at this moment I am unable to trtansform your file to test this myself.)

the use <witDetail> isn't really stable in SiksaKandangKaresian-CritEd, so I withdrew the code to transform this feature from the code. You should be able to transform it now.


golang gorm app should CREATE DATABASE automatically

CREATE DATABASE gormdemo; is a mandatory step before the golang gorm code can be started. This should not be the case and this database should be auto-created every time the app is started (it can drop the previous database using DROP DATABASE)

To achieve uniform behavior across all apps, the database would be created manually. I have updated ReadMe with instruction to create database.


path.GetClosest functions extremely slower compared to previous versions

Hello there! First of all thanks a ton for this great tool.
I've upgraded from a previous version (1.0 or 1.1, not sure) via the asset store and I've noticed that GetClosestDistanceAlongPath is about 10-15 times slower compared to the previous implementation.
For many users this change might be negligible but in my use case I'm sampling the value of the curve over a grid hundreds of times.
What previously took around ~100 ms now jumped to ~1250 ms.
This is caused by the new world to local transformation enforced in GetPoint() for example.
While this can be helpful for many, it would be good to allow skipping the transformation when not necessary (for example my curves are already frozen at Pos=000, Rot=000, Scale=111) using a bool parameter transformToWorldSpace with a default value of true.

I'm experiencing the same issue. When I removed the local to world transformation my fps was substantially higher.

If you use the latest github version, that issue should be fixed. Pull request #53, which is merged into master already, fixes many of those performance issues.

Any plans to release this to the asset store?

I am using the latest version and I'm still taking quite a performance hit. Right now I'm simply omitting the conversion completely.


Cannot handle 404

Hey All,
I'm using Angular-meteor using the AngularUI Router and i cannot handle the 404 errors, I'm wondering if anybody had to deal with that specially it's ABC for SEO.
Currently i'm redirecting any not found entities to the route /404 but with status code is 200.
For more information i'm also using Meteor's spiderable package for rendering the page.
Also i found Prerender.io has their own solution using this metatag :
<meta name="prerender-status-code" content="404">

Will Prerender be my solution or there's another way without dealing with other services !

Hi @dyaa ,
The 404 issue is a Meteor's issue, and not Angular-Meteor.
Also, we recommend using AngularJS routers (such as ngRouter or angular-ui-router) which eliminates the need to handle routes on the server side.
You can also try to use iron-router inside a package, load it only in the server side, and create a route for 404 with the correct header.
For more information about Meteor and 404, please follow https://github.com/iron-meteor/iron-router/issues/1055


Relicense libcimpp

It would be great to align the libcimpp license with cimgen. The Apache 2 license facilitates commercial use of the library and contributions.
Please let me know if you approve this motion to relicense libcimpp under Apache 2.

[x] @achim-voelker
[x] @MaxKissgen
[x] @dknibbe
[x] @stv0g
[x] @richardmarston
[x] @guelfey
[x] @lukasrazik
[x] @pdressen
[ ] @mohkoh19
[ ] @SimonGrimmACS
[ ] @taojunli

I support a relicensing to Apache-2.0

Sure, I agree to relicense my contributions under Apache-2.0.

I agree to relicense my contributions under Apache-2.0.
On Wed, 19 Jun 2024, 18:27 Georg Reinke, @.***> wrote:

Sure, I agree to relicense my contributions under Apache-2.0.
—
Reply to this email directly, view it on GitHub
https://github.com/sogno-platform/libcimpp/issues/25#issuecomment-2179086878,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHS2YOHQ62VN3NPL72AD6LZIGWNRAVCNFSM6AAAAABJSK2LTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZZGA4DMOBXHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I also support the motion to relicense libcimpp under Apache 2.

I support relicensing libcimpp under Apache 2.

I support relicensing libcimpp under Apache 2.

I support a relicensing to Apache-2.0

I support relicensing libcimpp under Apache 2.

Thanks everyone! Looking at the contributions, we cover the relevant parts of the project :-)


[Feature]: rename "examples" repository to "shuttle-examples"

Describe the feature
https://github.com/shuttle-hq/examples
"Examples" is a very generic name. In the context of "shuttle-hq/examples" it's clear enough.
It is used as a submodule of "shuttle-hq/shuttle" however. When a contributor forks "shuttle-hq/shuttle" to (by default) "contributor/shuttle" the .gitmodules file expects "shuttle-hq/examples" to be similarly forked to "contributor/examples". This is less clear and runs the risk of the repository name already being taken since it is a common word.
The contributor could rename their fork of "examples" to something else. Then however they would need to update .gitmodules, and then make sure they never commit that change.
Suggestion or Example of how the feature would be used
No response
Duplicate declaration

[X] I have searched the issues and this feature has not been requested before.

This has been implemented now: https://github.com/shuttle-hq/shuttle-examples , we just need to update some links and then we'll close this. Thanks for the suggestion Paul!


Dev oauth double slash

bugginess in ajax- the uri had too many /s in it, and the token wasn't being added to the header correctly

👍