Trinket support

Hi there, I liked your grave mod and recently added trinkets to my smp server and noticed your mod didn't have support for trinket slots.
So I went searching on the internet just to find out all the other grave mods are not to my liking so I added trinket support myself!
I thought you wanted to know since the mod is still actively maintained no pressure on this feature or my code style from your side, just thought I'd like to know if someone forked my mod :)
Have a nice day!

Oh woah, thanks!
Am I supposed to do something with this? I'm still very new to modding and even newer to github so I don't really know how everything works yet, sorry.

No, you don't have to do anything.
But if you want my changes to also apply yo your code you can press the merge button! Pull requests are a way to let open source contributors contribute to any project, It's up to you whether you actually want the code.

Can I take some of the code and implement it differently? Trinkets support is great, but looking at it I'm pretty sure this would make trinkets a mandatory dependency, which is a bit of a problem. I'm fairly sure I know how to fix that, but do I merge the pull request then change it, or copy the code over some other way?

Yes you are absolutely right, trinkets is a mandatory dependency now.
If you want to reimplement trinket support I'd suggest you close this PR and use it as reference when doing it yourself.
If you want to use my branch as the base I would work further on the fork (my project) and fix it there with another PR.
Personally I would go with the first option.

Okay, thank you for your time and advice!


Update applications without english proficiency

Context
An earlier PR backfilled english proficiency records. Originally, there were 2050 candidates who had efl_compeleted marked as true, but missing proficiency records.
After running that data migration, there are still 526 candidates with unsubmitted applications who are missing english proficiency records.
We have decided (see trello ticket) to update those remaining records efl_completed to false and elf_compelted_at to nil.
Changes proposed in this pull request
Migration to update the remaining application forms still missing english proficiency data.
Guidance to review
Things to check

[x] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[x] This code does not rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
[x] API release notes have been updated if necessary
[x] If it adds a significant user-facing change, is it documented in the CHANGELOG?
[x] Required environment variables have been updated added to the Azure KeyVault
[x] Inform data insights team due to database changes
[x] Make sure all information from the Trello card is in here
[x] Rebased main
[x] Cleaned commit history
[x] Tested by running locally
[x] Add PR link to Trello card

 Backfill English as a Foreign Language (EFL) data for carried over Applications


Version 2.4

This version contains some breaking changes which add some more flexibility to Fleks and also keep it up-to-date with other technologies. The most important change is the requirement of Java 11 instead of 8. This seems to be safe nowadays, even for Android. For LibGDX users, please use Gdx-Liftoff as your setup tool which already creates proper Java11 projects.
Changelog:

Several version updates:

Kotlin 1.7.21 -> 1.9.0
Dokka 1.7.20 -> 1.8.20
Kotlinx-benchmark 0.4.5 -> 0.4.8
Gradle 7.6 -> 8.2.1

world function got renamed to configureWorld. I got several comments on my YT videos that people got confused between world and World (constructor vs DSL function). To make it clear, it got now renamed to configureWorld
Also, the order of configureWorld functions no longer matters. Before, it was mandatory to call systems last. Now you are free to call injectables, systems, family in any order.
Kotlinx-serialization got added to Fleks. The @Serializable annotation is now part of the entity and makes it easier for certain serialization topics. This was suggested by the KorGE community.
A new EntityProvider interface got added which allows to provide your own entity ID logic. Per default it will still use the Fleks built-in recycle ID logic. However, you can now define an EntityProvider inside the configureWorld function to use your own implementation. This should improve the usability for network gaming.
We now have a new built setup with Gradle 8.x, thanks to @aSemy. The entire gradle setup is now more modern and easier to maintain. Also, Snapshot and LTS releases are now automatically published when the build is successful.
In addition to the gradle setup changes, Fleks now supports more native targets:

linuxarm64
macosarm64
linuxx64
macosx64
mingwx64

ComponentHooks got replaced by normal component functions. The Component interface now has an onAddComponent and onRemoveComponent function which can be overridden to add custom functionality. Both functions run in the context of a World. This makes it easier to write such logic because you no longer need to add the ComponentHook to your world configuration. Thanks to @geist-2501 for the contribution!

For more information about the new functionality, please check out the updated wiki.

@jobe-m: as always, please let me know if everything is working in your KorGE example :)
@geist-2501: Shall we rename onAddComponent and onRemoveComponent to onAdd and onRemove? Since they are functions of a component, I think the Component part of the name is redundant. What do you think? I can add the change to this PR.
And btw, wiki is not yet updated ;) Will do that, when the version goes live.

Btw the publish workflow seems to get triggered even for PRs. Need to have a look at that but I think I already found a solution for it.

@Quillraven yeah that sounds like a sensible rename!

@Quillraven Yes, I will. :)

@aSemy : any idea why "Publish" workflow gets triggered for PRs? I thought the if condition in the job should prevent that? Obviously, I am wrong :D

@aSemy : any idea why "Publish" workflow gets triggered for PRs? I thought the if condition in the job should prevent that? Obviously, I am wrong :D

Ooh that's not very good! I don't know why that might be, I thought the condition would work too! I'll take a look...

Ok, from my side. The new onAdd and onRemove component functions work for me :)
Currently in KorGE-Fleks I cannot use the data objects from Kotlin 1.9 since kproject sets up the KorGE project with 1.8.x. But that should not be a problem for Fleks. We just need to update KorGE'S kproject to support also 1.9.

Great, thanks for checking! It is interesting to me, that you have problems with data objects. I will check that myself on the weekend in one of my projects. If this is not downwards compatible, shall we stick with 1.8.xx version for now?

data object was lately inroduced with Kotlin 1.9. Shouldn't be a big deal to update KorGE to 1.9. Soywiz is usually adapting new Kotlin versions quickly in KorGE.
But would be nice to be backwards compatible with Kotlin 1.8.xx just for some time. Maybe you can do a branch 2.4-kotlin1.8.xx after 2.4 is released  which does not use data object. The rest you do not need to change since in KorGE-Fleks we used local gradle config to build Fleks.

@jobe-m: What kind of error are you actually getting? I just tried it in a project with Kotlin 1.8.22 and I can run it just fine.

I am getting The feature "data objects" is only available since language version 1.9.
Are you sure that you build Fleks also with Kotlin 1.8 or did you only build the project with 1.8 but Fleks is build with 1.19?

I am getting The feature "data objects" is only available since language version 1.9. Are you sure that you build Fleks also with Kotlin 1.8 or did you only build the project with 1.8 but Fleks is build with 1.9?

I don't built Fleks at all. I just add it as a dependency to my projects. I use 2.4-SNAPSHOT from maven.
Building of course won't work with 1.8 but why do you have to build it?

With Soywiz's kproject we can add external modules as source delivery to a KorGE project. The benefit is that Fleks can be used on all fancy (homebrew) platforms which KorGE is available for. Thus Fleks is build with the build configuration of KorGE.

Please don't wait with 2.4 for me. I am currently unfortunately heavily loaded with private family stuff while trying also to survive at business. I won't have much time left the next month's. So my progress will be rather slow.

Ah understood - didn't know about the KorGE setup but then it makes sense. In this case, as you suggested, I will make a 2.4_8 branch with Kotlin 1.8 after the release.
And I totally understand the family and work stuff - I have similar problems at the moment ;)
Anyway, thanks for the info and updates! I will then release 2.4 this weekend.

Thanks for recommending gdx-liftoff! Would you like Fleks added to the third-party extensions in Liftoff? I don't think you need to do anything.
I decided to run the benchmark with lower entity count and update count (each 1/10 of what it is now in the repo), and I got somewhat different results. Not having "fractionally complete" results (less than 1.0 throughput) for the complex benchmark helps both artemis and, at least a little, ashley. I ran this with Java 20 on a slightly newer laptop processor than the one used for the listed benchmarks, and Fleks' add and remove performance on here is vastly better than any competitor (225% more throughput than artemis-odb); I don't know why exactly. It's a tiny bit slower on both simple and complex with the smaller entity count, which suggests there might be an algorithmic complexity difference that makes fleks relatively faster on larger entity collections. Artemis is quite a bit faster on the complex benchmark with the smaller entity count (68% more throughput than fleks).
$ C:\d\jvm\jdk20-hotspot\bin\java -jar Fleks-jvmBenchmarks-jmh-2.5-SNAPSHOT-JMH.jar -w 10 -r 10 -wi 10 -i 10 -t 1 -f 1 -gc true
...
Benchmark                    Mode  Cnt      Score     Error  Units
ArtemisBenchmark.addRemove  thrpt   10   4071.356 ┬▒ 337.725  ops/s
ArtemisBenchmark.complex    thrpt   10    178.795 ┬▒   3.415  ops/s
ArtemisBenchmark.simple     thrpt   10   9047.583 ┬▒  62.516  ops/s
AshleyBenchmark.addRemove   thrpt   10   2269.431 ┬▒  42.238  ops/s
AshleyBenchmark.complex     thrpt   10     16.279 ┬▒   0.199  ops/s
AshleyBenchmark.simple      thrpt   10   2086.183 ┬▒  68.274  ops/s
FleksBenchmark.addRemove    thrpt   10  13264.218 ┬▒  34.791  ops/s
FleksBenchmark.complex      thrpt   10    106.155 ┬▒   2.879  ops/s
FleksBenchmark.simple       thrpt   10   7433.124 ┬▒  64.739  ops/s

This only shows that Artemis is faster than fleks for the simple and complex cases with 100 entities; it isn't ever faster on addRemove that I can see. Whatever you're doing for addRemove is great, and if there's a way to do something similar with what simple and complex use, they would probably outpace Artemis in more cases.
I initially ran the benchmark because I wanted to make sure the methodology was sound, but the benchmark code looks solid. Benchmarking is such a tricky thing to get right because there are so many factors involved...

@tommyettinger: funny coincidence because I wanted to open an issue soon for gdx-liftoff and ask, if you could add this library. To answer your first question: yes please, would be great if it can be added directly :)
Regarding performance: I am personally confused by the performance measurement of JVM languages.
On my notebook (AMD processor) Fleks is always faster in addRemove and simple benchmark and in the complex one it is close.
On my PC (old Intel CPU), which was used for the benchmarks in the README.md Fleks is still faster with addRemove but in simple benchmark it is random. Sometimes faster, sometimes slower.
I don't get it 100% but in the end I didn't care that much to investigate and understand it. Important for me was, that it is faster than Ashley and relatively close to Artemis.
To give a little bit of insight:

The result in the README is quite old from a version before we moved everything to Kotlin multiplatform. It was the JVM version. There is a 1.6-JVM branch still available.
I think addRemove is faster compared to Artemis because it doesn't use reflection anymore. If I remember correctly, Artemis uses Reflection to create a new instance of a component and afterwards modifies it. In Fleks this is no longer necessary. You directly create the component without Reflection. I guess this makes it faster and easier to optimize for the compiler magic.
For the complex benchmark I cannot remember anymore if Artemis delays an entity removal/modification until the end of the frame or until the end of the system update. Fleks does the calculations always at the end of a system update. I'd need to check if the components of the entities have the same values at the end of the benchmark in both Artemis and Fleks. If Artemis does it only once per frame then this could explain why it is faster. However, I would still not change the behavior in Fleks because it makes more sense imo to make an update of families as fast as possible, which is at the end of a system update. Actually, this is not the fastest way and still includes a delay until the end of the system, but this is necessary because otherwise you get very strange scenarios in your ECS. I can elaborate on that if needed.
Fleks uses Kotlin compared to Java in Artemis. Therefore, it automatically includes the null-safety. I can imagine that the bytecode below adds some additional checks automatically which of course has an impact in performance. Most likely not a huge impact but still. I am also not sure if the kotlin multiplatform stuff has an impact here since I am not 100% sure what it does exactly to make Kotlin "automagically" compatible with multiple platforms.
Imo Fleks is now "feature complete" and all the features that people requested until now are included. I use it in most of my private projects and I don't miss any functionality at the moment. That's why I want to focus again on possible performance improvements for the upcoming versions. I have some ideas but I don't know when I will have the time to work on them. Some ideas:

From what I remember, the BitArray implementation is the bottleneck of the complex benchmark. It is used in families to check if an entity is part of it or not. And it is also used in families for the entities itself, where it gets converted to a bag for faster iteration.
My idea is that maybe a second implementation makes sense which can be optimized for the family contains function check. Since that data is based on components, which have a fixed size, it might be possible to speed that up.
Otherwise, I read about an Archetype approach in ECS where you can basically skip the entire contains function of the family. In that approach, if I understood it correctly, you use more memory because a component gets added multiple times to different archetypes it belongs, but it has the performance advantage since the expensive contains checking is no longer necessary and also the conversion from BitArray to Bag is no longer needed. This approach however requires a bigger change in the library, I guess BUT it will be a lot faster with the downside of using more memory.
github also recommended me an ECS library called Dominon which claims to be ultra fast. I looked a little into the sourcecode and it uses Unsafe calls, which are not possible in Kotlin multiplatform afaik. I think it also uses the Archetype approach. I personally don't like the syntax of that library but it is for sure worth it to check why it is so fast (if the claims are true ;) ).

I can run some more benchmarks later tonight, including ones that take hours if needed. I think the random-seeming aspect of the benchmarks has a lot to do with the OS, any existing processes running on the machine, how much time the JIT compiler has had to get things ready, etc. It's best to reduce the amount of error by running more iterations and for longer (I used 10 seconds, ideally I think I would try a minute per iteration when using many entities). I suspect GC may be a factor here because switching to Shenandoah had a (negative) performance effect, though it seemed to hurt all the benchmarks.
BitArrays are amazing data structures and I love them. 😄 If you aren't currently using bitwise operations to do steps in bulk, that would be something to consider, though I imagine you probably are doing things like masking heavily already. I suspect the conversion to a bag would be the main slow point there, or any GC that needs to be done to clean up temporary bags or bit arrays. It might be worth it to consider iterating while still in a BitArray -- if each block of bits is stored as a Long, at least on the JVM there are some very fast intrinsic candidates to work with that Long and its bits. If you want to get the lowest bit set in num, that doesn't even need a method call; it's just num and -num (I'm not 100% sure of the Kotlin syntax here, it's a bitwise AND operator).

Would be interesting to find out the code segments that take up the most time in simple/complex benchmarks and go from there. Not sure if your way of benchmarking can do that. The latest IntelliJ version contains benchmark inlay infos but I don't have experience with them yet. But might be useful as well ;)
My assumption is that following methods are the bottlenecks (family.kt and bitArray.kt):
/**
     * Returns true if the specified [compMask] matches the family's component configuration.
     *
     * @param compMask the component configuration of an [entity][Entity].
     */
    internal operator fun contains(compMask: BitArray): Boolean {
        return (allOf == null || compMask.contains(allOf))
            && (noneOf == null || !compMask.intersects(noneOf))
            && (anyOf == null || compMask.intersects(anyOf))
    }

    /**
     * Updates this family if needed and runs the given [action] for all [entities][Entity].
     *
     * **Important note**: There is a potential risk when iterating over entities and one of those entities
     * gets removed. Removing the entity immediately and cleaning up its components could
     * cause problems because if you access a component which is mandatory for the family, you will get
     * a FleksNoSuchComponentException. To avoid that you could check if an entity really has the component
     * before accessing it but that is redundant in context of a family.
     *
     * To avoid these kinds of issues, entity removals are delayed until the end of the iteration. This also means
     * that a removed entity of this family will still be part of the [action] for the current iteration.
     */
    inline fun forEach(crossinline action: Family.(Entity) -> Unit) {
        // Access entities before 'forEach' call to properly update them.
        // Check mutableEntities getter for more details.
        val entitiesForIteration = mutableEntities

        if (!entityService.delayRemoval) {
            entityService.delayRemoval = true
            isIterating = true
            entitiesForIteration.forEach { action(it) }
            isIterating = false
            entityService.cleanupDelays()
        } else {
            isIterating = true
            entitiesForIteration.forEach { this.action(it) }
            isIterating = false
        }
    }

// --> which also includes a call to

// This bag is added in addition to the BitArray for better iteration performance.
  @PublishedApi
  internal val mutableEntities = MutableEntityBag()
      get() {
          if (isDirty && !isIterating) {
              // no iteration in process -> update entities if necessary
              isDirty = false
              entityBits.toEntityBag(field)
          }
          return field
      }

// bitArray.kt

 fun intersects(other: BitArray): Boolean {
        val otherBits = other.bits
        val start = min(bits.size, otherBits.size) - 1
        for (i in start downTo 0) {
            if ((bits[i] and otherBits[i]) != 0L) {
                return true
            }
        }
        return false
    }

    fun contains(other: BitArray): Boolean {
        val otherBits = other.bits

        // check if other BitArray is larger and if there is any of those bits set
        for (i in bits.size until otherBits.size) {
            if (otherBits[i] != 0L) {
                return false
            }
        }

        // check overlapping bits
        val start = min(bits.size, otherBits.size) - 1
        for (i in start downTo 0) {
            if ((bits[i] and otherBits[i]) != otherBits[i]) {
                return false
            }
        }

        return true
    }

    /**
     * Returns the logical size of the [BitArray] which is equal to the highest index of the
     * bit that is set.
     *
     * Returns zero if the [BitArray] is empty.
     */
    fun length(): Int {
        for (word in bits.size - 1 downTo 0) {
            val bitsAtWord = bits[word]
            if (bitsAtWord != 0L) {
                val w = word shl 6

                for (bit in 63 downTo 0) {
                    if ((bitsAtWord and (1L shl bit)) != 0L) {
                        return w + bit + 1
                    }
                }
            }
        }
        return 0
    }

    /**
     * Returns number of bits that are set in the [BitArray].
     */
    fun numBits(): Int {
        var sum = 0
        for (word in bits.size - 1 downTo 0) {
            val bitsAtWord = bits[word]
            if (bitsAtWord != 0L) {
                for (bit in 63 downTo 0) {
                    if ((bitsAtWord and (1L shl bit)) != 0L) {
                        sum++
                    }
                }
            }
        }
        return sum
    }

    inline fun forEachSetBit(action: (Int) -> Unit) {
        // it is important that we go from right to left because
        // otherwise some code in toEntityBag will fail with ensureCapacity.
        for (word in bits.size - 1 downTo 0) {
            val bitsAtWord = bits[word]
            if (bitsAtWord != 0L) {
                val w = word shl 6

                for (bit in 63 downTo 0) {
                    if ((bitsAtWord and (1L shl bit)) != 0L) {
                        action(w + bit)
                    }
                }
            }
        }
    }

    fun toEntityBag(bag: MutableEntityBag) {
        var checkSize = true
        bag.clear()
        forEachSetBit { idx ->
            if (checkSize) {
                checkSize = false
                // this is working because forEachSetBit goes
                // from right to left, so idx is the highest index here
                bag.ensureCapacity(idx)
            }
            bag += Entity(idx)
        }
    }

I had an idea of caching the result of the contains call inside a family but that requires a fast hashCode function of the BitArray. The current version is pretty slow and the cache then slows down the performance :D At least in a quick&dirt try-out that I had.

There's probably a few places in BitArray that could be sped up. The bit counting method should probably use https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/count-one-bits.html , since that is more likely to use the JVM intrinsic when available or the popcnt instruction in some way from native code. Most of the per-bit loops currently do 64 iterations regardless of how many bits are set, so for sparse BitArrays they may check their inner conditional far more times than necessary. I'm not especially familiar with idiomatic Kotlin style, but I'd suggest looking for existing high-performance BitSet/BitArray implementations in Kotlin, and seeing how they do it in the source code. The hashCode() question is an interesting one; contains() seems to be implemented quite well already, so optimizing it could be a challenge (as you found).
I think I'll tinker with bitArray.kt some, and submit a PR if I see any performance gains.


Cannot build micro-ros for Android device

Issue template

Hardware description: arm64-v8a
RTOS: Ubuntu 22.04 through WSL2
Installation type: micro_ros_setup
Version or commit hash: humble

Steps to reproduce the issue

On the host machine, run:
mkdir microros_ws && cd microros_ws
git clone -b humble https://github.com/micro-ROS/micro_ros_setup.git src/micro_ros_setup
rosdep update && rosdep install --from-paths src --ignore-src -y
colcon build
source install/local_setup.bash
ros2 run micro_ros_setup create_firmware_ws.sh android generic
ros2 run micro_ros_setup configure_firmware.sh
ros2 run micro_ros_setup build_firmware.sh ~/android_sdk/ndk/25.2.9519653/build/cmake/android.toolchain.cmake

Expected behavior
Micro-ros is built correctly.
Actual behavior
An error is raised when building the package micro_ros_demos_rclc.
The error is the following:
Starting >>> micro_ros_demos_rclc
--- stderr: micro_ros_demos_rclc
CMake Error at /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rosidl_typesupport_microxrcedds_c/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package):
  Could not find a configuration file for package "microcdr" that is
  compatible with requested version "".

  The following configuration files were considered but not accepted:

    /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/microcdr/cmake/microcdrConfig.cmake, version: 2.0.1 (64bit)

Call Stack (most recent call first):
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rosidl_typesupport_microxrcedds_c/cmake/rosidl_typesupport_microxrcedds_cConfig.cmake:41 (include)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rosidl_typesupport_c/cmake/rosidl_typesupport_c-extras.cmake:13 (find_package)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rosidl_typesupport_c/cmake/rosidl_typesupport_cConfig.cmake:41 (include)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/builtin_interfaces/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/builtin_interfaces/cmake/builtin_interfacesConfig.cmake:41 (include)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rcl_interfaces/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rcl_interfaces/cmake/rcl_interfacesConfig.cmake:41 (include)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rcl/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
  /home/user_ai_001/microros_ws/firmware/mcu_ws/install/share/rcl/cmake/rclConfig.cmake:41 (include)
  CMakeLists.txt:6 (find_package)

gmake[2]: *** [CMakeFiles/graph_visualizer.dir/build.make:95: graph_introspection/graph_visualizer/src/graph_visualizer-stamp/graph_visualizer-configure] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:192: CMakeFiles/graph_visualizer.dir/all] Error 2

Additional information
The following environment variables are set:
export ANDROID_HOME='~/android_sdk/'
export ANDROID_NDK='~/android_sdk/ndk/25.2.9519653'
export ANDROID_NATIVE_API_LEVEL=android-31
export ANDROID_ABI=arm64-v8a

Can you continue try this , any update this ?

Unfortunately, I did not experiment further with microROS on Android.
I went ahead with another solution.


[CHALLENGE SUBMISSION] - Day 10

What is your name? (First, Last)
Colin Bates
Where is your GitHub Repo ?(With your challenge solution)
https://github.com/ckabates/25-days-of-serverless-solutions/tree/master/Day10
What Challenge is this for? (Challenge number between 1 and 25)
10
(Optional) Anything else we should know? e.g., language used, location, blog post?
The Powershell deployment script should be run from a Powershell Core / 6.0 environment.  It deploys all required resources.  As the Twitter logic app connector uses OAuth, it needs to be authenticated with the relevant Twitter credentials after deployment.
An example script execution:
.\Deploy-AzureResourceGroup -ResourceGroupName 'DailyDeals001' -ResourceGroupLocation 'australiaeast' -TemplateFile 'logicapp.json' -TemplateParametersFile 'logicapp.parameters.json' -ArtifactStagingDirectory '.' -DSCSourceFolder '.\DSC'
All date time's in the logic app and Twitter searches are in UTC time.

From all of us on the Cloud Advocacy team at Microsoft, thank you for creating this issue!
Have a Happy Holiday season!
Feel free to share your solution on Twitter with the tag #25DaysOfServerless

@ckabates Thanks for your #25DaysOfServerless submission!
We checked out your repository. We're thrilled to say your solution is now listed in our Hall of Fame
Thank you for your contributions!
This issue is now resolved! 🎉


Added claimTemplateID to msgCreateClaim

Hi Stefania,
Can you please share some info about the rationale of this patch?
Do we need this claimTemplateProperty now because there has been API changes on the blockchain / the cell node? Or maybe this was broken before and this is needed to fix it?

Hi Stefania,
Can you please share some info about the rationale of this patch?
Do we need this claimTemplateProperty now because there has been API changes on the blockchain / the cell node? Or maybe this was broken before and this is needed to fix it?

Hi Stefania,
Can you please share some info about the rationale of this patch?
Do we need this claimTemplateProperty now because there has been API changes on the blockchain / the cell node? Or maybe this was broken before and this is needed to fix it?

Hi @gwn, we are in the process of adding a claimTemplateId to claims throughout the ixo stack, and this change is a part of that. We are applying similar changes to ixo-blockchain, ixo-blocksync, and ixo-cellnode, and you can refer to the pull requests on these repos.

Hi Stefania,
Can you please share some info about the rationale of this patch?
Do we need this claimTemplateProperty now because there has been API changes on the blockchain / the cell node? Or maybe this was broken before and this is needed to fix it?

Hi @gwn, we are in the process of adding a claimTemplateId to claims throughout the ixo stack, and this change is a part of that. We are applying similar changes to ixo-blockchain, ixo-blocksync, and ixo-cellnode, and you can refer to the pull requests on these repos.

Thank you for the clarification. Since I'm dealing exclusively with clients these days, I'm only following client related repositories and missed the updates on the other ones and that's why I asked.

Thank you for the clarification. Since I'm dealing exclusively with clients these days, I'm only following client related repositories and missed the updates on the other ones and that's why I asked.


Error linking: "undefined reference to __exp{2}_finite"

Using the AUR package ungoogled-chromium. If I'm not mistaken this is the repository for that, so I thought i'd better make an issue here instead.
[22797/22797] LINK ./chrome
FAILED: chrome
clang++ -Wl,--version-script=../../build/linux/chrome.map -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -fuse-ld=lld -Wl,--icf=all -Wl,--color-diagnostics -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O2,--sort-common,--as-needed,-z,relro,-z,now -o "./chrome" -Wl,--start-group @"./chrome.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lgthread-2.0 -ljsoncpp -licui18n -licuuc -licudata -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lcups -lxml2 -lfontconfig -ldbus-1 -levent -lresolv -lgio-2.0 -lz -lwebpdemux -lwebpmux -lwebp -lfreetype -ljpeg -lexpat -lharfbuzz-subset -lharfbuzz -ldrm -lre2 -lXrandr -lpci -lXss -lasound -lpulse -lavcodec -lavformat -lavutil -lsnappy -lopus -latk-1.0 -latk-bridge-2.0 -lva -lpangocairo-1.0 -lpango-1.0 -lcairo -latspi -lFLAC -lminizip -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt -llzma -lm -llcms2 -lopenjp2
ld.lld: error: /sbin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.1/../../../../lib64/libopenjp2.so: undefined reference to __exp_finite
ld.lld: error: /sbin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.1/../../../../lib64/libopenjp2.so: undefined reference to __exp2_finite
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...
Error making: ungoogled-chromium

Still occouring with cdad0787f5749fed81e2afd4a48b7f0def86960d (80.0.3987.87-2)

@jstkdng Same problem as you mentioned before?

@wchen342
yeah, removing the use_openjpeg2 flag fixes the problem

I recall something that may help finding the cause of this problem. So when #59 was opened Actions ran a build on it and the build succeeded without a problem. However on other machines the build failed. It turns out that there is a bug in the workflow file and Actions is building with an unmerged version of this repo (i.e. without the pull request), which I think means some change between 79.0.3945.130 and 80.0.3987.106 in either this repo or the main ungoogled-chromium repo caused this error.
@braewoods @tangalbert919  Do you have any idea whether some changes during that period can cause this?
BTW this error still occurs with 80.0.3987.122.

Those are symbols that are provided by libm from glibc. It could be as simple as a problem with the ordering of the linked libraries. I would try manually linking it with a changed order and see if it helps. If it does then maybe a patch for the linking order could help.

I'm running into the same issue.

I've found something interesting. I tried manually linking them and discovered that it links successfully if we use GNU ld but produces this error if we use Clang's ld.lld. Thoughts on what we might make from this discovery?

That's interesting discovery. My knowledge in C++ is very limited but I think either it's a difference between the implementation of ld/lld, or very unlikely, a bug.
Another possibility is the Clang version. Maybe try using Clang-9?

Not sure where I would get clang 9 on Arch. It has clang 10 now.

I'll see what disabling lld in the build flags does. I only thought to try this because I used to run into weird issues that seemed to be an issue with the linker itself during my packaging days. I can't find anything to explain this odd behavior but the fact that GNU ld seems to work whereas lld does not makes me think it's not an issue with the system libraries themselves.

I searched on AUR but there are clang-9 and llvm-9 but no lld-9.
There are clang-7, llvm-7 and lld-7 though.
Actually what clang version is Ubuntu/Debian on? The default clang is pulled from source so maybe it is not too new but too old?
I agree this is more like a problem with lonker itself, but I don't think disabling lld will be a good idea in long run since it is the only linker that is supported upstream.

Probably so. I only considered it a short term solution. As for Debian the Sid and Focal branches have been using clang 10 for over a month and have not been having linking errors with lld. They even have use_system_libopenjpeg2=true in their build flags.

Now that sounds like a problem with the patches. I am searching through the debian repository and find some modifications that are not here, like the usage of -no-static-libstdc++. Will that matter?

No idea. Only one way to find out. I also thought concurrent_links=1 might play a part. I have known builds to sometimes have issues with concurrency.

Ok. I did a difference between the build flags and found these are present in Debian but not Arch:
concurrent_links=1 use_goma=false use_allocator="tcmalloc" use_ozone=false use_unofficial_version_number=false enable_vr=false optimize_webui=false v8_enable_backtrace=true host_cpu=x64

@wchen342 I saw you close an issue earlier. Do you have authority to merge PRs here?

Ok. I'll try building with clang9 once I get it built. So far our only solutions are to switch linkers or disable the failing library. Any other ideas?

I can merge PRs here yes. I am holding #72 for one more day and if you still can pinpoint the exact cause then I will merge it.
The flags other than concurrent_links=1 v8_enable_backtrace=true use_ozone=false should be unrelated.

Just go ahead. I don't think I'm going to find anything. It could just as easily be a difference in how Arch builds clang and llvm from Debian.

Why don't you guys look at how Arch's chromium handles the problem? They don't use the flag use_system_openjpeg2. Maybe since the beginning or just removed when it caused this problem.

Yet Debian is able to build with it just fine. That's the mystery we have right now.

I actually don't know why some of the use_system flags are there in the first place. They are there since I have first come here. @Eloston probably knows.
And yes if Debian builds fine with the same flag then there is definitely a problem with Arch and it's better to find it out then just cover it up.

@wchen342 Could you merge my PR? I just finished rebaseing it with master. This issue is technically solved now so should we move what we've learned to a new one so we can revisit this flag later? It might get fixed with the next clang release or so.

@wchen342
The PKGBUILD was based on some version of inox, but I think nobody thought about refactoring it. Actually, Arch used to do the same, but then started using the flags array in their PKGBUILD.
@braewoods
That may be so, that doesn't mean it has to be solved. If both ways will take to the same destination, choose the one that takes the least amount of effort.

@jstkdng I see. My guess of including these flags is because 1) to decrease package size 2) prevent upstream from providing malicious libs, which I think is reasonable to have.
@braewoods I have merged the PR. Feel free to open a new issue.

Moving discussion to #73.


Dockerfile cleanup for Alpine 3.3

Eliminates some package-manager wrangling which has become unnecessary since the Dockerfile was written (~half a year ago, targetting alpine 3.2). In particular, by eliminating the edge pin, we're a bit more insulated from possible breaking changes in edge (package upgrades in stable are not supposed to be breaking).

s6 is in main in 3.3, so we no longer need to mangle the repos file
official image is periodically updated, so it's not preferred to do
upgrades downstream (usually harmless, but inelegant)
apk-tools in 3.3 supports --no-cache to avoid leaving the APKINDEX
files in the image

Thanks your PR!
cc @0rax

Hi, I did not check if s6 was push to main in 3.3 and was not aware of this new feature of apk-tools, thanks for your PR and those different infos !
This can be merged with no problem at all (just tested the change). I will just have to add this --no-cache argument in docker/build.sh, as APKINDEX will still be created while building the software.

Thanks!
@muhmuhten would you mind update this file as well?

@Unknwon It doesn't look like I can, sorry. The image it's based off hasn't had an update for 3.3, and while there are other ARM alpine bases (e.g. container4armhf/armhf-alpine, armbuild/alpine), I couldn't vouch for them and I don't have the hardware to test them.

Sure, that's OK!

@muhmuhten To be sure that the same version of alpine is used for both container, I upgrade to 3.3 before doing anythin so I will try to make the change. (And also see if there is an alpine 3.3 image worth, but yeah currently I am using this one as I trust the maintainer and just update to 3.3 to be sure that both container runs on the same version of the OS).
I will do the necessary testing and update what's needed today.


Autoscroll broken when iframe is resized

I believe this is now fixed, as of https://github.com/Microsoft/BotFramework-WebChat/commit/1706c53e53b286bff0b76e51baadea8b987e5288


feat: add cvToJSON

Description
Developers of web apps want to use values of the transaction results
This PR

adds cvToJSON
fixes #861

Developers can then use e.g.
cvToJSON(hexToCV(tx.tx_result.hex))
Type of Change

[x] New feature
[ ] Bug fix
[ ] API reference/documentation update
[ ] Other

Does this introduce a breaking change?
No
Testing information
Additional tests have been added to clarity.test.ts.
Checklist

[x] Code is commented where needed
[x] Unit test coverage for new or modified code paths
[x] npm run test passes
[ ] Changelog is updated
[x] Tag 1 of @yknl or @zone117x for review

@yknl Shouldn't we use json objects instead of arrays for tuples? Like suggested here: https://github.com/blockstack/stacks.js/issues/861#issuecomment-732812716

Yes, returning objects would be better 👍

Replaced by #874


wrap and use RTCIceGatherer

wraps the RTCIceGatherer and uses it in the peerconnection-shim

Codecov Report

Merging #112 into master will increase coverage by <.01%.
The diff coverage is 96.87%.

@@            Coverage Diff             @@
##           master     #112      +/-   ##
==========================================
+ Coverage   99.36%   99.37%   +<.01%
==========================================
  Files           3        4       +1
  Lines         949      961      +12
==========================================
+ Hits          943      955      +12
  Misses          6        6

Impacted Files
Coverage Δ

rtcicegatherer.js
100% <100%> (ø)

rtcpeerconnection.js
99.29% <90%> (-0.01%)
:arrow_down:

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 785579f...f046848. Read the comment docs.

timing issue, not unexpected...

apparently this causes too many null candidates to be sent. Should be easy to fix...


Lobby methods do not work

in cache.js :
 switch(obj.type_id)
"obj" hasn't field type_id, but typeId has, anyway
var lobby = dota_gcmessages_common.CSODOTALobby.parse(obj.object_data[0]);
common does't declared in cache.js
Perhaps I'm doing something wrong? Is there some way to create a lobby, because I couldn't :(
Thanks a lot for answer

PR 90 should fix it, when it is deployed.

Fixed in branch node-dota2/node-steam1.1.0, which will be deployed with 1.0.0 release in a couple of weeks, if not sooner.


Add integration test with napari

This adds some test to ensure the plugin can be programmatically added as a widget to the napari viewer.

Codecov Report

Merging #65 (cbec8cc) into main (efdcc89) will increase coverage by 0.08%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main      #65      +/-   ##
==========================================
+ Coverage   93.41%   93.49%   +0.08%
==========================================
  Files          19       20       +1
  Lines        1609     1614       +5
==========================================
+ Hits         1503     1509       +6
+ Misses        106      105       -1

Impacted Files
Coverage Δ

src/napari_metadata/_tests/test_napari.py
100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes


visual graph in build widget is not visible

Trying to setup the dashboard locally.
In the build widget, i could see the job details. But the graph is not visible. Have tried in IE, chrome and Microsoft edge. Only below details are published,

Kindly check and assist to display the graph in build widget

I have again configured Hygieia from initial setup. And now the graph is visible. Hence closing this issue.
Thanks,
Gowri


[WIP] Add Matrix Scalar Add Programming Example

This PR adds a programming example of matrix scalar addition using channels and tiling. It includes 5 different ways to do tiling in this context.
This PR also includes some changes to the python API with the goal of providing a clean interface:

Wrap AllocOp and DeallocOp to clean up AllocOp interface, and then wrap DeallocOp to maintain a symmetric interface
Add default values for the ChannelGet/ChannelPut operations, as well as automatic conversion from python ints where it seems useful.

Wrap AllocOp and DeallocOp to clean up AllocOp interface, and then wrap DeallocOp to maintain a symmetric interface
Add default values for the ChannelGet/ChannelPut operations, as well as automatic conversion from python ints where it seems useful.

It would be nice to make these their own PR(s).

from air.dialects.air import Alloc

I'm a bit hesitant to wrap (i.e. diverge from) upstream operators to save a couple characters of typing. Alloc is not an air dialect op. Do we already do this to AllocOp in mlir-aie? Or maybe everything is objfifo there...

Wrap AllocOp and DeallocOp to clean up AllocOp interface, and then wrap DeallocOp to maintain a symmetric interface
Add default values for the ChannelGet/ChannelPut operations, as well as automatic conversion from python ints where it seems useful.

It would be nice to make these their own PR(s).

from air.dialects.air import Alloc

I'm a bit hesitant to wrap (i.e. diverge from) upstream operators to save a couple characters of typing. Alloc is not an air dialect op. Do we already do this to AllocOp in mlir-aie? Or maybe everything is objfifo there...

I believe the aie uses AllocOp internally but users at the python level do not use it (at least, I can't find an example of direct use in the examples in the mlir-aie repo).
My thinking was that it's best not to expose options/interfaces that are basically wholly undocumented in air because if you leave them open, the only way to know how to use AllocOp/DeallocOp in this context is to copy/paste from an existing example and hope for the best - which doesn't exactly build programmer confidence.
However, I'm happy to remove/table the AllocOp/DeallocOp changes. And I'm also happy to put the ChannelGet/ChannelPut changes in a separate PR as well for further discussion.

My thinking was that it's best not to expose options/interfaces that are basically wholly undocumented in air because if you leave them open, the only way to know how to use AllocOp/DeallocOp in this context is to copy/paste from an existing example and hope for the best - which doesn't exactly build programmer confidence.

Upstream dialects and bindings are documented upstream, e.g. https://mlir.llvm.org/docs/Dialects/MemRef/, https://mlir.llvm.org/docs/Bindings/Python. Maybe usability and documentation improvements can be proposed there?

Added separate PR for toggling the aircc emit-while-loop option: https://github.com/Xilinx/mlir-air/pull/613

My thinking was that it's best not to expose options/interfaces that are basically wholly undocumented in air because if you leave them open, the only way to know how to use AllocOp/DeallocOp in this context is to copy/paste from an existing example and hope for the best - which doesn't exactly build programmer confidence.

Upstream dialects and bindings are documented upstream, e.g. https://mlir.llvm.org/docs/Dialects/MemRef/, https://mlir.llvm.org/docs/Bindings/Python. Maybe usability and documentation improvements can be proposed there?

Okay, yes, that makes sense! I believe I was thinking about this more as a Python programmer and less like an MLIR programmer. Since we import this operations through air.dialects... it makes me think it's an air specific python packages and not a representation of a library that exists outside of MLIR-AIR. But I believe this import structure is an artifact of the MLIR build structure (that the dialect python code is generated uniquely for this repo), so it's probably fine as-is.

Closing this PR in favor of:

aircc option for emit-while-true-loop: https://github.com/Xilinx/mlir-air/pull/613
matrix scalar add example: https://github.com/Xilinx/mlir-air/pull/621
Improvements to ChannelGet and ChannelPut python wrappers: https://github.com/Xilinx/mlir-air/pull/622


Enable Sourcegraph

I want to use Sourcegraph for scipy code search, browsing, and usage examples. Can an admin enable Sourcegraph for this repository? Just go to https://sourcegraph.com/github.com/scipy/scipy. (It should only take 30 seconds.)
Thank you!

That seems to be a useful site. Does anyone see a problem with enabling this?

+1, why not

done

didn't need any Github permissions, so anyone could have done this


krohnkite: 0.8.2 -> 0.9.7

Description of changes
Routine update with source change, looks like it is forked
Fixes #324406
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

That's really not routine. Are we sure this fork is good?

Can't really vouch for it tbh, not using plasma for a long time now.
Original repo actually seems stale, and people on issues mentioned the new one, which has visible differences over the original. Looked good enough.

Have other distributions switched over to this fork?

yes this has become the version of the script that became dominant on the kde get new stuff store and it is reasonable to switch to it
what about plasma 6? i am not up to date with packaging addons since the change from 5 to 6 but given the libsForQt5 bit i will assume this also needs packaging for plasma 6? the addon itself is compatible with both 5 and 6, btw

Makes sense, but I couldn't see plasma-6 in the tree, nor libsforqt6. If there is such distinction please send me an example so I can try to adjust.

i haven't done any packaging for plasma 6 so i am out of the loop...
i did notice this package which works for plasma 6... so maybe nothing special needed?
sorry, i wish i knew more but haven't looked into it yet

Hello,
I didn't learn nix properly yet, so I can't help with technicalities about packaging, etc. But I'm using Plasma 6 so I can be your test dummy. So far I see that packages changed from libsForQt5 to kdePackages for Plasma 6.
Also from what I saw on the internet it's the best tiling kwin script available as of now. I've personally used Polonium but it has issues which can be quite annoying at times. Krohnkite could be the one that gets me to use tiling 24/7 again.
I'll be testing it soon enough (if it works from the store) and I'll see how it goes. I'll update you once I get everything setup.

I see that the package is still under plasma-5. Shouldn't it be moved, or copied, to plasma-6?

I've just pulled Krohnkite from Nixpkgs instead of building it myself. It's at 0.9.7, upstream is at <IP_ADDRESS> as of 4 days ago, and everything seems to work just fine.

I think we can close this MR, as another package for krohnkite was created for Plasma 6 (#340606) and the version here is not backwards compatible. This would allow the Plasma 5 version (0.8.2) to still be installable along the Plasma 6 one (<IP_ADDRESS>). I will close the linked issue as completed

Nice to hear, closing


Translation of webui json to spanish

Want to translate the webui-LANGUAGE.json
there is no translation file to spanish
I guess file should be something like this " ipfs-webui/dist/locale/webui-es.json"

Hello @davidalencia!
A new version of WebUI is coming soon so I think it would be better to put the new efforts on that branch. Although, we still don't have internationalization working, it is on the roadmap (#675 and #749).
/ping @ipfs-shipyard/gui

@davidalencia  we now have a fancy crowdsourcing website for translations:

https://www.transifex.com/ipfs/public/

If you want to contribute to Spanish version of new WebUI, log-in/register with your github account  and join team at https://www.transifex.com/ipfs/ipfs-webui/language/es/ :rocket:  :)


[PSCore 6.1] In WSL, PSReadLine color for parameter values is black (doesn't work on default black background)

After updating PowerShell Core 6.0.4 to 6.1 in WSL (Ubuntu distro), I've noticed that I don't see what I type when I type parameter values.

Removing PSReadline module made everything visible again.

I think this is an issue with the Windows WSL default console color scheme.  If you look at the color properties:

You'll probably see that DarkGray (index 8) is set to the same value as Black (index 0).  Try lightening the index 8 color (DarkGray) to 169,169,169 (hex a9a9a9).  That's why you can't see parameters (and operators) because PSRL is configured by default to use index 8 (or  "`e[90m" - bright foreground).

@rkeithhill All I know is that it worked with PowerShell Core 6.0.4. And I haven't played with console properties.
Proposed values 169,169,169 are too light on my system.

Make sure you set the Screen background back to index 0 before closing the dialog.  Then it should look better.  But ultimately, perhaps PSRL should use a different parameter/operator fg color.

@rkeithhill I forgot to mention that I don't see the same issue on PSCore 6.1 installed on Windows where background color is also black. Parameter values are here printed in bright color and are visible.

The PowerShell Core console configuration is different by default than the WSL color config.  So that doesn't surprise me.  I, OTOH, don't use the default PS Core color config.  I use colortool to set my color scheme to OneHalfDark and that does exhibit this same issue - Black and DarkGray use the same color value.

The same issue (DarkGray being displayed as black) also affects Windows Powershell on Windows Server 2016 when used via Win32-openssh (as of version 8.9) and Powershell Core (as of 7.2.2) on Windows Server 2012 R2 and 2016.
A workaround is to add
Set-PSReadLineOption -Colors @{ "Parameter" ="`e[39m"; "Operator" = "`e[39m";"InlinePrediction" = "`e[39m" }

to your Powershell Core profile and
Set-PSReadLineOption -TokenKind Operator -ForegroundColor Gray\nSet-PSReadLineOption -TokenKind Parameter -ForegroundColor Gray

to your Windows Powershell profile on the affected systems.


Improves retry logic of cluster deletion

Not ready to review
Which issue this PR addresses:
Work item 7792816
What this PR does / why we need it:
After this change RP should not give up trying to delete a cluster after few attempts: it will continue trying.
Test plan for issue:
TBD

Is there any documentation that needs to be updated for this PR?
TBD

TODO:

[ ] In the current implementation we do not provide any feedback to CLI in case of errors. Either need to change approach (use terminal provisioning state, but reset Dequeues & update dequeue query, for example) or come up with a way to provide feedback
[ ] Add tests

The changes in this PR make RP to retry deleting the failed deletion operation by keeping cluster object in the Deleting provisioning state and resetting dequeue count to 0 when we need to retry.
I'm a bit concerned that we do not provide any feedback to the caller in case where we see and issue and want to retry:

How will Azure cli react to document being stuck in deleting provisioning state?

I believe that currently az cli will just hang in waiting forever. I tried to unravel command execution code and it looks like when az cli runs a puller returned by a command (az aro delete in our case) it doesn't set a timeout for a pulling thread (wait is called via result here).
I don't currently see a way to set a timeout.

How will Azure portal behave when there is an issue with deletion?

Not a concern right now, but might be an issue later.

Puting this on hold for now


Persistent waveform broken in Processing 3

As noticed by Bobby Lewis via YouTube comments, the persistence or 3D 'tracer' style draw behavior seems broken when running this on Processing version 3.x.
I was able to reproduce on:

OS: Linux / Ubuntu 18.04 (bionic)
Processing version: 3.5.4

Welp if someone wants to fix it, have at it and I'll merge the PR. I don't really have time to do this myself.
I had an older version of this set up with a more normal looking 3D wireframe and it still looked pretty cool, I think it's on the git history somewhere.

Fixed in master https://github.com/fadookie/Super3dvisualizer/commit/7f8a2551da2a917b88bdc2009eff04519374fd84


ERROR: no matching manifest for linux/arm/v8 in the manifest list entries

This issue can come up when running docker-compose up and it tries to pull docker.io/groundlight/monitoring-notification-server-backend:latest from dockerhub.

linux/arm/v8 is not a supported tag at https://hub.docker.com/r/groundlight/monitoring-notification-server-backend/tags.
We should probably add it as a supported tag, but AFAICT it's only requested in somewhat strange situations.  Specifically we've seen this on a machine with 64-bit hardware, and a 64-bit kernel (as shown by uname -m returning aarch64, but 32-bit userland processes.  e.g. file /usr/bin/docker returning ELF 32-bit.  This indicates the OS is a bit of a strange 32-bit/64-bit hybrid.
ARM chips which support the v8 instruction set are necessarily 64-bit capable.  By asking for arm/v8 it seems to be asking for a 32-bit version of the image, but using the v8 instruction set which generally runs at 64 bit.
For these reasons, we currently advise fixing the OS / docker installation to use linux/arm64 images.  But we'll leave this open until we properly support this scenario, because it's not crazy to think somebody would have good reason to want arm/v8.


.csv file clears after it hits over 9kb in size

Create plugging, only issue is that it clears the logs one the file gets to 9kb + or so.
Could we get this patched?

Any chance to look at this?


Tests: ability to mark test with 'ignore'

Add optional ignore keyword in front of test - which will result in that test not being run and - when tests are run, the status Not run will be shown on the test - and, hence, the overall status of Test shown in the IDE will also be Amber.
Stef: This is now implemented. To ignore a test, select test frame and hit Ctrl-i (same to then un-ignore). This is explained on tooltips.
This then shows/hides the ignore keyword and sets the property ignored on the TestFrame - to be picked up by the compile stage.
Please implement this so that ignored tests don't run, and are displayed with the 'Not run` status (amber) when tests are run.


compose: Fix duplicate warning banners for the same private stream.

Earlier, a new banner would be showed for each mention of the same private stream in the compose box. This commit fixes that by checking if the private stream warning banners already shown include the private stream just mentioned, and if so, not showing a new banner.
This implementation is in line with the one for warnings for mentions of users not subscribed to the current stream.
Fixes: #26914.
Screenshots and screen captures:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

This looks great. Merged, thanks @N-Shar-ma!


Change all title font to Inter font style

Pushed code to dev-title-font-change. Closing this issue!!!


IVS-79/LAY000 - Presentation Layer Assignment

A couple of remarks;

The schema does not allow for any other entity type than IfcPresentationLayerAssignment for the attribute LayerAssignments (of IfcShapeRepresentation). It seems it's not possible to assign any other entity than mentioned above due to the assigning taking place by the AssignedItems (of IfcPresLayerAssign) attribute. Therefore, I think it would be redundant to add this explicitly in a gherkin steps; solely Its attribute LayerAssignments suffices.

The not-activated file has the following list in context.instances that is getting handled by the then step.

The activated file has the following instances in the stack for the last then step. Index 5 and 7 (both IfcPresentationLayerAssignment) activate the rule.

Outdated https://github.com/buildingSMART/ifc-gherkin-rules/pull/281


[Fix] available tags safe guard

This PR added a sanity safe guard on Interface.make_tag_available method, to avoid accepting None here, which could lead to other errors since available_tags is supposed to be a list of TAGs.
Bumped 2022.2.1 version since this needs to be patched.

This is to avoid a traceback since NApps rely on iterating on available_tags with the expected type, keeping the list as NApps would expect, otherwise it can lead to this issue here https://github.com/kytos-ng/topology/issues/106 that @italovalcy has reported, we didn't fix it before the release since we thought all the cases were eliminated but today when I was fixing this e2e test https://github.com/amlight/kytos-end-to-end-tests/issues/145 I hit the same issue where mef_eline passed a None to Link.make_tag_available, so we'd better fix this on core to be safe:
2022-08-19 15:47:00,208 - ERROR [kytos.core.helpers] (thread_pool_app_2) listen_to handler: <function Main.on_link_available_tags at 0x7f67d44c2670>, args: (<Main(topology, stopped 14007
9662089792)>, KytosEvent('kytos/mef_eline.link_available_tags', {'link': Link(Interface('s1-eth2', 2, Switch('00:00:00:00:00:00:00:01')), Interface('s2-eth2', 2, Switch('00:00:00:00:00:0
0:00:02'))), 'src_func': None}, 0)) traceback: Traceback (most recent call last):,   File "/home/viniarck/repos/kytos/kytos/core/helpers.py", line 146, in handler_context_apm,     result
 = handler(*args),   File "/home/viniarck/repos/napps/napps/kytos/topology/main.py", line 602, in on_link_available_tags,     self.handle_on_link_available_tags(event.content.get("link")
),   File "/home/viniarck/repos/napps/napps/kytos/topology/main.py", line 610, in handle_on_link_available_tags,     values_a = [tag.value for tag in endpoint_a.available_tags],   File "
/home/viniarck/repos/napps/napps/kytos/topology/main.py", line 610, in <listcomp>,     values_a = [tag.value for tag in endpoint_a.available_tags], AttributeError: 'NoneType' object has
no attribute 'value',

Later on mef_eline we'll get to the root of the cause and making all s_vlan being make available are all set, at least it won't crash other NApps like topology anymore when handling this event which could lead to other implications.

LGTM. Excellent to have this sanitization at the core! Regarding the mef_eline fix, let's work on this right away. Thanks for the PR, @viniarck

:+1:


Dragging threshold

Right now dragging starts on mousedown and touchstart which means it basically starts on click which is wrong. I am constantly moving elements on mobile when I am scrolling and toggling things. There should be dragging threshold (minimal number of pixels which element needs to be moved in order to be considered dragged).

We've run into similar needs and were hoping something like this was available in ember-sortable.

@estshy This LGTM, and I will try to get this tested either today or tomorrow. Fixing @lukemelia's catch with the typo's probably not a bad idea though 😉

@estshy any chance of getting a rebase and some changes re: the above?

Some other libraries have delay option. Maybe this is something that can be added instead of the draggingThreshold?

Forgot about this - closed by #137 as it fixes the issue present in this PR.


add new terms for INCLUDE DCC

cardiac surgery
congenital heart defect repair
vision treatment
glasses usage
nasolacrimal duct surgery
strabismus surgery

close #319

@LCCarmody FYI, I add instructions how to use ROBOT templates to your wiki: https://github.com/monarch-initiative/MAxO/wiki/Add-terms-(or-annotations)-using-ROBOT-templates

I ended up adding manually a logical def for heart repair. I will accept your other PR for surgical repair pattern, but I won't build out terms at the moment. But we could use that further.


add engine to package.json (v4)

This helps in detecting compatibility issues right during the npm installation. Fix for #1 for node4 branch

Awesome, thank you!


is it usable with terranix to cache .terraform folder(fixed derivation from terraform.lock)?

I don't know how terranix is being setup, it's better to ask them. Typically the .terraform and terrafork.lock and created by terraform and we don't control that content.


Autogenerated files in the repository

Some files have a comment like "Autogenerated C header for registers in TMC2160". Where can I find the generator that was used to generate these files, and what they were generated from?
Here is the list of files with such comment:

MAX22216_Fields.h
MAX22216_Register.h
TMC2160_Fields.h
TMC2160_Register.h
TMC5271_Fields.h
TMC5271_Register.h
TMC5272_Fields.h
TMC5272_Register.h
TMC7300_Fields.h

Hi there,
We use our internal generator and it is not publicly available.
Thank you for your interest in our products. If you need any further assistance then feel free to contact us!


I think the word follow typedef should be pasred to a type in c++ file,but vsc didn't do this

I think the word follow typedef should be pasred to a type,but vsc didn't do this

We get our C++ grammar from https://github.com/jeff-hykin/cpp-textmate-grammar/
The folks over there know a lot about how C++ tokens should be categorized so I recommend posting in issue in that repo and seeing if they agree with you. If they do, then the change will make it into VS Code eventually.


Support compression in roachprod put

If roachprod put shelled out to scp (or rsync) instead of using the go ssh implementation, we could compress the files we copy over to speed things up a bit. (Something like google's old treedist would be even better, but that's a refactor for another day)

The tradeoff here is that we'd have to give up the per-node progress bars. Unless you know of some way to programmatically extract progress information from scp/rsync.

On a related note, I was thinking that it would make sense to be able to move files from one node to another. For example, starting a 10 node cluster means uploading the binary ten times, which is quite a drag. Instead, you could c.Put it on the first node and then c.Copy it to another one.
Another option is that when you don't care that the binary is locally built, the remote could use binfetcher to grab it from our buckets. But making that tool right is an interesting problem. I suppose we could pass --cockroach binfetcher://LATEST or something like that to enable this use case.

Hmm, yeah. Why are we building up all this functionality ourselves from
scratch again instead of using ansible/salt/puppet/etc?

I think @petermattis is scarred by terraform.
On Thu, Mar 29, 2018 at 1:58 PM, Ben Darnell<EMAIL_ADDRESS>wrote:

On a related note, I was thinking that it would make sense to be able to
move files from one node to another.
Yeah, that's what treedist did. It used heuristics based on google's
machine naming conventions to figure out a spanning tree using the cheapest
network connections.
The tradeoff here is that we'd have to give up the per-node progress bars.
Unless you know of some way to programmatically extract progress
information from scp/rsync.
Hmm, yeah. Why are we building up all this functionality ourselves from
scratch again instead of using ansible/salt/puppet/etc?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cockroachdb/roachprod/issues/142#issuecomment-377320244,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA15IBy6XUicpPgM9EwqJC3FZSaP8Vwbks5tjSC7gaJpZM4TAuVC
.

I think @petermattis is scarred by terraform.

Aren't we all?


change in IP addressing

Hi @bclasse
I have changed IP addressing in the lab, to make it more clear. Also lowered the bandwidth requirement with iperf
please check if those changes make sense to you

Sounds good for me. We can go higher in terms of flows, but really MTU has to be set in this scenario

Sounds good to me, I just increased the number of flows and set the MTU value


User Submitted Issue: # 76

Type: bug
Device: desktop
OS: windows
Browser: googlechrome
Selected Game:
Description: The newest update just deleted all of my nuzlocke data and the custom rulesets I spent hours making. Was there a way to avoid this? Any warnings that this might happen? I can't find them anywhere.

Add message at the beginning notifying the user the app uses localStorage/cookies to maintain data


Expose a metadata getter

What are we solving here?

Hmmm personally I'm torn with the internal_openapi method. On one hand I understand why you want to protect it but on the other hand I use it right now because I have a separation between my Zod Types, Registry and Generator.
I actually register some of my types like this:
eg.
// types package
const myType = z.object({str: z.string()}).openapi({refId: 'myObject'})

// scripts/generate-schema.ts
const registry = new OpenAPIRegistry()
const registeredSchemas = [myType];
registeredSchemas.forEach((schema) => {
  registry.register(schema._def.openapi?.refId as string, schema);
});

// ... generator code

Just because it feels a little a little clunky to create the zod type, then refer to the registered version? 🤔
const registry = new OpenAPIRegistry()

const myType = z.object({str: z.string()})
const registeredType =  registry.register('myObject', myType);

const newType = z.object({t: registeredType});

@samchungy I am not sure I understand your last example. Why can't you just do:
// types package
//registry
export const registry = new OpenAPIRegistry()

// foo.ts
import {registry} from './registry';
const myType = registry.register('myObjec', tz.object( { str: z.string() } ))

const newType = z.object({t: myType});

//bar.ts
import {registry} from './registry';
const myType2 = registry.register('myObject2', z.object( { str: z.string() } ))

This is exactly what we do in out own project. In our case we do have a types package as well. Everything that needs to be registered is getting registered there. In the build script you just import the registry and pass it to the generator. I see no reason to separate the "schema" and the "registered schema".
Saying all that internal_openapi is "deprecated" but anyone can still use it ~at your own risk~ - it's just that we do not encourage you to do it since it might break something in the generation logic.

@AGalabov all good 😄 Just thought I could get away with not initialising and creating a register to register() within my types package. I ran into issues with my way later on anyway with needing to register things in order so I might just do it the register way from now on.

There's no chat feature but that's a bunch for the release guys @AGalabov @georgyangelov Appreciate your work 🙌 🎉

@samchungy  thank you for the kind words. And even more so - once again thank you for contributing. Quite a bit of the latest release was down to your work :bow:.


Support for inline comments

Is there a way to inject a comment that you'd like to appear in the ~/.ssh/config file? If not yet, that'd be dope to add.

:+1:


Upstream review two-redo

About the PR

New upstream stuff, but this time I get serious
Why / Balance

Technical details

Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

THE ASPID AND ORIGIN MERGE CONFLICTS WILL CONTINUE UNTIL MORALE IMPROVES.


Support mixed INT8 + FP16 in one model

Type of Change
feature
API changed or not
Description

[x] Support convert unquantized linear into fp16
[ ] Extend the fp16 ops list to align with https://pytorch.org/docs/stable/amp.html#cpu-ops-that-can-autocast-to-bfloat16 in a separate PR

Usage
model = export(model, example_inputs=example_inputs)

quant_config = get_default_static_config()
quant_config.set_local(torch.nn.Linear, StaticQuantConfig(w_dtype="fp16", act_dtype="fp16"))
# prepare
prepare_model = prepare(model, quant_config)
# calibrate
for i in range(2):
    prepare_model(*example_inputs)
# convert
converted_model = convert(prepare_model)

Expected Behavior & Potential Risk
How has this PR been tested?
Pre-CI
Some extension test later.
Dependency Change?
None

Shall we add logger.info to teach user that ipex doesn't support fp16? quant_config.set_local(torch.nn.Linear, StaticQuantConfig(w_dtype="fp16", act_dtype="fp16"))

Thanks for your suggestions, will refine it by a separate PR.


448: Correct value for FORCE_COLOR env var

The "support-color" package expects to parse an integer value. Code was wrongly assigning a boolean
when envvars are strings. Don't see how this ever worked. Additionally removed line setting
process.exitCode to its default value (0), and migrated process.exitCode = 1 to top of both catch blocks.
Fixes #448

Nice! Thanks!


Add Earl Server to list of servers

Adding a server I started working on to the list.

@mrletourneau Thank you so much for your contribution! 🌈 🐝


'Could not find rake-10.5.0 in any of the sources' when trying to Initialize Database

Hi, I'm trying to install huginn on Debian Wheezy, everything went smoothly except when I tried to initialize database, it prompted up:
Could not find rake-10.5.0 in any of the sources
Run bundle install to install missing gems.
I tried sudo gem install rake -v '10.5.0' ,rake -v '10.5.0 installed successfully but it didn't work. Did anyone have the same question here?
Thanks.

Did you bundle?

Thx cantino, I found I did miss something, when I bundle, it prompt

Thanks, cantino, I found I did miss something, when I run bundle, there was an error, "invalid byte sequence in US-ASCII (ArgumentError)" and I missed it out. I tried the solution in this thread and bundle successfully. But I haven't gone through the whole process until now, so not sure this is the silver bullet to my problem, I will come back to update after I complete it. Thanks!

Hi, I managed to complete the install process and huginn finally ran.
run: huginn-jobs-1: (pid 11015) 1071s; down: log: 1s, normally up, want up
run: huginn-web-1: (pid 11012) 1071s; run: log: (pid 11091) 1066s
I configure apache with this example, all needed mods enabled, https works fine and I can see Huginn's logo on the tab, but got 503 error.

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.2.22 (Debian) Server at moli.teaink.com Port 443

I have no idea what't going wrong here. Could you help please? Thanks!

I think you need to change listen "#{wd}/tmp/sockets/unicorn.socket" in config/unicorn.rb to listen "<IP_ADDRESS>:3000" and restart Huginn afterwards.

Thank you so much sir! I just find your previous relpy about this error in anthor thread, it works. It is awesome! :+1:


UN-482: Upgrade Wagtail to version 4.1.2

Ticket URL: https://national-archives.atlassian.net/browse/UN-482
About these changes
Upgrading Wagtail to v4.1.2
How to check these changes
Check that the app works locally, and make sure the version is 4.1.2
Before assigning to reviewer, please make sure you have

[ ] Checked things thoroughly before handing over to reviewer.
[ ] Checked PR title starts with ticket number as per project conventions to help us keep track of changes.
[ ] Ensured that PR includes only commits relevant to the ticket.
[ ] Waited for all CI jobs to pass before requesting a review.
[ ] Added/updated tests and documentation where relevant.

Merging a feature or bug fix?

Use the Squash and merge option to keep the target branch's commit history nice and clean.
Where relevant, include the ticket number in commit title, e.g. DF-XXX: Ticket name / short description.

Merging a release branch?

Use the message format release/<major.minor.patch> when merging.

Deployment guidance

Post to the appropriate Slack channel to check that it is okay to continue.
To start a deployment, push the relevant branch to the platform remote.
Update the appropriate Slack channel when the deployment is complete.
Update the status on the corresponding Jira ticket (where relevant).

Issue found: https://docs.wagtail.org/en/stable/releases/4.1.html#rebuild-references-index-management-command
This throws an issue when running ./manage.py rebuild_references_index. This has something to do with the Record model and will need further inspection.
Error: ValueError: ("Can not resolve <class 'etna.records.models.Record'> into a model", <class 'etna.records.models.Record'>)

Issue found: Record chooser button not showing, but clickable.

We can see that there is no chooser button here, but it's still clickable where it's supposed to be. Andy mentioned this is an issue he's encountered before.
I'll have a further look at it, but it may need fixing by Torchbox/the Wagtail team.
Andy also mentioned it could be to do with a third-party library, so it may just be a case of upgrading this.

Issue found: Record chooser button not showing, but clickable.

We can see that there is no chooser button here, but it's still clickable where it's supposed to be. Andy mentioned this is an issue he's encountered before.
I'll have a further look at it, but it may need fixing by Torchbox/the Wagtail team.
Andy also mentioned it could be to do with a third-party library, so it may just be a case of upgrading this.

This has been fixed by applying the same CSS that is applied to the normal chooser buttons. It was being missed on the record chooser buttons.

Issue found: https://docs.wagtail.org/en/stable/releases/4.1.html#rebuild-references-index-management-command
This throws an issue when running ./manage.py rebuild_references_index. This has something to do with the Record model and will need further inspection.
Error: ValueError: ("Can not resolve <class 'etna.records.models.Record'> into a model", <class 'etna.records.models.Record'>)

This has been resolved by returning [] in the def extract_references(self, value): function.


[ Nuxt ] Cannot read property 'focus' of undefined

Hi! I don't know if it is related or not with Nuxt but I get this error:

client.js?06a0:77 TypeError: Cannot read property 'focus' of undefined
at VueComponent.eval (UserInput.vue?b499:149)
at Array.eval (vue.runtime.esm.js?2b0e:1980)
at flushCallbacks (vue.runtime.esm.js?2b0e:1906)

Here:

focusUserInput() {
this.$nextTick(() => {
this.$refs.userInput.focus();
})
},

Good component. Thx !

I'm getting same issue.

This issue is due to the data 'messageStyling' value has been put to 'true' while the package 'msgdown' has not been installed.
To solve this issue, you need to change : 'messageStyling' to 'false'.

Ok, I succeed to solve this issue by modifying the app code.
Into UserInput.vue
Line 233,
replace this :
mounted() {
this.$root.$on('focusUserInput', () => {
this.focusUserInput()
})
}
by this :
mounted() {
this.$root.$on('focusUserInput', () => {
if (this.$refs.userInput) {
this.focusUserInput()
}
})
}
and the focus error goes away...

make use DOM is mounted before you use beautiful chat component then this wont wont happend

<beautiful-chat>

mounted(){
this.isMounted=true
}

make use DOM is mounted before you use beautiful chat component then this wont wont happen

<beautiful-chat>

mounted(){
this.isMounted=true
}

this doesn't work for me... I asked for a pull request with my solution without response yet... waiting...


chore: Remove unused exports

Summary
Resolves #188.
We have a lot of unused exports in the recorder, our current linting setup does not catch these.

Implementation details
This adds a new dev dependency, ts-unused-exports, and a new script that calls it. It can be run using npm run unused-exports. The script throws an error when unused exports are detected.
This will have a slightly annoying side effect of calling out exports that aren't referenced outside of the immediate file, but do have references in the same file. In this case these symbols shouldn't technically be exported, but are still used internally. This rule might be a little draconian, but I think it's worthwhile to prevent the existence of entire files and other objects that are completely dead.
I'm open to improvement suggestions, if people think this is too strong of an imposition.
How to validate this change
You can create an unused export in any ts/tsx file, like export type Unused = "nothing" and run the script, it should throw with a reference to the filename and offending line.
I've also updated the CI to run this script, I will be debugging that before requesting review from others.

:broken_heart: Build Failed

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-04-05T18:41:48.305+0000

Duration: 15 min 49 sec

Steps errors
Expand to view the steps failures

npm build

Took 1 min 26 sec . View more details here
Description: npm run build

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.


CFG_WITHOUT: parameter not set error

Original report.
I'm using Linux Mint on VirtualBox. After curl -sSf https://static.rust-lang.org/rustup.sh | sh process that official site recommend i'm having this error.
Here is the full result of process:
sudo curl -s https://static.rust-lang.org/rustup.sh | sudo sh

Welcome to Rust.

WARNING: This script appears to be running as root. While it will work
correctly, it is no longer necessary for rustup.sh to run as root.

This script will download the Rust compiler and its package manager, Cargo, and
install them to /usr/local. You may install elsewhere by running this script
with the --prefix=<path> option.

The installer will run under 'sudo' and may ask you for your password. If you do
not want the script to run 'sudo' then pass it the --disable-sudo flag.

You may uninstall later by running /usr/local/lib/rustlib/uninstall.sh,
or by running this script again with the --uninstall flag.

Continue? (y/N) y

rustup: gpg available. signatures will be verified
rustup: downloading manifest for 'stable'
rustup: downloading toolchain for 'stable'
######################################################################## 100,0%
gpg: Prş 14 May 2015 13:26:24 EEST imzası, RSA anahtarı ve 7B3B09DC kullanıcı kimliği ile yapılmış
gpg: "Rust Language (Tag and Release Signing Key<EMAIL_ADDRESS>deki imza iyi
gpg: UYARI: Bu anahtar güven dereceli bir imza ile sertifikalanmamış!
gpg:          Bu imzanın sahibine ait olduğuna dair bir belirti yok.
Birincil anahtar parmak izi: 108F 6620 5EAE B0AA A8DD  5E1C 85AB 96E6 FA1B E5FE
     Yardımcı anahtar parmak izi: C134 66B7 E169 A085 1886  3216 5CB4 A934 7B3B 09DC
rustup: extracting installer
rustup: installing toolchain for 'stable'
/home/khons/.rustup/tmp/tmp-2780-10/rust-1.0.0-x86_64-unknown-linux-gnu/install.sh: 904: /home/khons/.rustup/tmp/tmp-2780-10/rust-1.0.0-x86_64-unknown-linux-gnu/install.sh: CFG_WITHOUT: parameter not set
rustup: command failed: sudo sh /home/khons/.rustup/tmp/tmp-2780-10/rust-1.0.0-x86_64-unknown-linux-gnu/install.sh --prefix=/usr/local
rustup: failed to install toolchain

Any solution to offer? Thank you.

I am using my Lubuntu with Turkish language. I downloaded linux binary and i ran install.sh with LANG=en_US parameter.
$ sudo LANG=en_US ./install.sh

It fixed the problem.


Treat throw in implicit-return position as a statement

-> if a then throw b

should become
(function() { if (a) { throw b; } });

This comes from #103.

Fixed in v1.43.0.


Release 2021.6.0 - 2021.6.0 broke Home-Card

I love Home-Card. It is the centerpiece of my HA dashboard.
2021.6.0 appears to have broken Home-Card.  Any thoughts?
Let me know what information you need, if you think can be corrected.

Yes, same thing on my side after update to 2021.6.0

After investigation, this seems to be linked to the upgrade to Lit 2.0: https://developers.home-assistant.io/blog/2021/05/19/lit-2.0/
I have changed the header of the /home-card/home-card.js as follows and it seems to have done the trick without having to update the whole code.
`
import { THEMES } from './themes.js';
import {
LitElement,
html,
css
} from "https://unpkg.com/lit-element@2.0.1/lit-element.js?module";
// const LitElement = Object.getPrototypeOf(
//   customElements.get("ha-panel-lovelace")
// );
// const html = LitElement.prototype.html;
// const css = LitElement.prototype.css;
`

No change here
I see the code references './themes.js' - is there something on your machine that I may not have here?

Actually, I have kept the './themes.js' in the home-card.js
My frontend skills are close to none but from the 2021.6 breaking change notes I noticed that LitElement and lit-html have been deprecated in favor for Lit 2.0.
I have just commented out these lines:
'const LitElement = Object.getPrototypeOf(
customElements.get("ha-panel-lovelace")
);
const html = LitElement.prototype.html;
const css = LitElement.prototype.css;'
and added this instead:
'import {
LitElement,
html,
css
} from "https://unpkg.com/lit-element@2.0.1/lit-element.js?module";'

that looks like what I have, but it doesn't seem to cooperate with me here.
'import {
LitElement,
html,
css
} from "https://unpkg.com/lit-element@2.0.1/lit-element.js?module";'
// const LitElement = Object.getPrototypeOf(
// customElements.get("ha-panel-lovelace")
// );
// const html = LitElement.prototype.html;
// const css = LitElement.prototype.css;
const VERSION = 3;

When any of you guys have anything that works, please open a PR so I can merge it. I'm quite passive when it comes to maintaining this project right now.

Works fine on my side but I had to restart HA and clear my browser's cache first.
Thanks for the good work BTW :)

Sorry, I had not cleared my cache. Clearing my cache worked here, too.

I have cleared cache and rebooted it still puts all the image parts to one side stacked on top of each other.

When any of you guys have anything that works, please open a PR so I can merge it. I'm quite passive when it comes to maintaining this project right now.
@postlund  #26 should take care if it.

Merged!


Does Lookahead Bias Exist

I'm trying to apply the kalman filter to historical data. Although i understand that the _filter function is applied in a nested for loop, will it ever use future observations in each predicted state mean?

Hi yes according to freqtrade lookahead-analysis pyalman has a problem with lookahead bias...
If someone know a way to resolve it it would be great to share!
Thanks


Make getAuthor return purchased resources

So, I was thinking, instead of #8 which would require more work and seems to be harder to implement, the getAuthor method could return the IDs of the purchased resources of the user. I think this would be a really good way for authors to verify real buyers I don't know whether some people will consider it a privacy issue.

Yeah, I don't think it's a good idea to do that, lol.
What resources somebody brought shouldn't be public.


Disable the dragging?

I see that gridster js got disable method however I could not yet figured out how to disable the dragging here. :/
Appreciate any help/pointer. Thanks.

Thanks @dcollazo - now it doesn't drive me mental when I use a smaller tablet! The items trick totally worked.


To-Do App Page

Is your feature request related to a problem? Please describe.
No, The request is related to a new feature I would like to contribute and add to the repository.
Describe the solution you'd like
A To-Do app with basic CRUD methods, and with readable clean code.
Describe alternatives you've considered
I can add some animations if applicable.
Additional context
Issue created under the contributions of GSSOC'22

Please assign me this issue. I think I can work on this.

Hey I'm a beginner to open source and want to make contribution to this issue. Please assign it to me as it will help me to explore more


Add hotplug net device support for cloud hypervisor

Is your feature request related to a problem? Please describe.
Add hotplug net device support for cloud hypervisor
Describe the solution you'd like
Use cloud hypervisor /vm.add-net API to hotplug net device
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Currently executing docker connect test_container test_net has no effect, and the log shows the following error

Jul 24 17:09:46 A23074915-33 kata-runtime[9023]: time="2020-07-24T17:09:46.142298499+08:00" level=error msg="Error attach virtual ep" arch=amd64 command=kata-network container=aec7f1d3a255f9132a2e33326e312549de87eb1c01c8ddd41dcc11da1db859a4 error="cannot hotplug device: unsupported device type '2'" name=kata-runtime pid=9023 sandbox=aec7f1d3a255f9132a2e33326e312549de87eb1c01c8ddd41dcc11da1db859a4 source=virtcontainers subsystem=network

Move to https://github.com/kata-containers/kata-containers/issues/453


Upgrade TypeScript to version 5

What version of Remix are you using?
1.14.3
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
Try to upgrade typescript to version 5.x
    "typescript": "^5.0.0",

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>
Expected Behavior
Remix should be able to work with typescript version 5.  Multiple packages contain the following
  "devDependencies": {
    "typescript": "^4.7.4"
  },
  "peerDependencies": {
    "typescript": "^4.0.0"
  },

Actual Behavior
Upgrading typescript is not possible:
npm WARN ERESOLVE overriding peer dependency
npm WARN While resolving<EMAIL_ADDRESS>
npm WARN Found<EMAIL_ADDRESS>
npm WARN node_modules/typescript
npm WARN   dev<EMAIL_ADDRESS>from the root project
npm WARN   5 more (@remix-run/eslint-config, ...)
npm WARN
npm WARN Could not resolve dependency:
npm WARN peerOptional<EMAIL_ADDRESS>from<EMAIL_ADDRESS>
npm WARN node_modules/@remix-run/eslint-config
npm WARN   dev<EMAIL_ADDRESS>from the root project

Yup, @remix-run/eslint-config currently has a peer dependency on<EMAIL_ADDRESS>

I created #5881 to add TS 5 support

Closed by https://github.com/remix-run/remix/commit/6b6ee66a2fef1a7b00ce4c95abed144ab80017e3 & #5881


[BREAKING CHANGE] root level kuadrant extensions

What
[BREAKING CHANGE] Openapi info level kuadrant extensions moved to root level
Requires #77 first
Added some happy path tests
Verification Steps

OpenAPI doc with kuadrant extensions at the root level

cat << EOF > openapi.yaml
---
openapi: "3.0.3"
info:
  title: "Pet Store API"
  version: "1.0.0"
x-kuadrant:
  route:
    name: "petstore"
    namespace: "petstore-ns"
    hostnames:
      - example.com
    parentRefs:
      - name: gw
        namespace: gw-ns
servers:
  - url: https://example.io/v1
paths:
  /cat:
    x-kuadrant:  ## Path level Kuadrant Extension
      backendRefs:
        - name: petstore
          port: 80
          namespace: petstore
    get:  # Added to the route and rate limited
      operationId: "getCat"
      responses:
        405:
          description: "invalid input"
  /dog:
    get:  # Added to the route and rate limited
      x-kuadrant:  ## Operation level Kuadrant Extension
        backendRefs:
          - name: petstore
            port: 80
            namespace: petstore
      operationId: "getDog"
      responses:
        405:
          description: "invalid input"
EOF

Compile kuadrantctl

make install

Generate HTTPRotue object

bin/kuadrantctl generate gatewayapi httproute --oas openapi.yaml

The result should be
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  creationTimestamp: null
  name: petstore
  namespace: petstore-ns
spec:
  hostnames:
  - example.com
  parentRefs:
  - name: gw
    namespace: gw-ns
  rules:
  - backendRefs:
    - name: petstore
      namespace: petstore
      port: 80
    matches:
    - method: GET
      path:
        type: Exact
        value: /v1/dog
  - backendRefs:
    - name: petstore
      namespace: petstore
      port: 80
    matches:
    - method: GET
      path:
        type: Exact
        value: /v1/cat
status:
  parents: null

cheers for verification steps, looks good:
cat << EOF > openapi.yaml            git:(openapi-kuadrant-extensions-at-root|⚑3)
---
openapi: "3.0.3"
info:
  title: "Pet Store API"
  version: "1.0.0"
x-kuadrant:
  route:
    name: "petstore"
    namespace: "petstore-ns"
    hostnames:
      - example.com
    parentRefs:
      - name: gw
        namespace: gw-ns
servers:
  - url: https://example.io/v1
paths:
  /cat:
    x-kuadrant:  ## Path level Kuadrant Extension
      backendRefs:
        - name: petstore
          port: 80
          namespace: petstore
    get:  # Added to the route and rate limited
      operationId: "getCat"
      responses:
        405:
          description: "invalid input"
  /dog:
    get:  # Added to the route and rate limited
      x-kuadrant:  ## Operation level Kuadrant Extension
        backendRefs:
          - name: petstore
            port: 80
            namespace: petstore
      operationId: "getDog"
      responses:
        405:
          description: "invalid input"
EOF

➜  kuadrantctl git:(openapi-kuadrant-extensions-at-root -> upstream/openapi-kuadrant-extensions-at-root) ✗ cat openapi.yaml                  git:(openapi-kuadrant-extensions-at-root|…1⚑3
---
openapi: "3.0.3"
info:
  title: "Pet Store API"
  version: "1.0.0"
x-kuadrant:
  route:
    name: "petstore"
    namespace: "petstore-ns"
    hostnames:
      - example.com
    parentRefs:
      - name: gw
        namespace: gw-ns
servers:
  - url: https://example.io/v1
paths:
  /cat:
    x-kuadrant:  ## Path level Kuadrant Extension
      backendRefs:
        - name: petstore
          port: 80
          namespace: petstore
    get:  # Added to the route and rate limited
      operationId: "getCat"
      responses:
        405:
          description: "invalid input"
  /dog:
    get:  # Added to the route and rate limited
      x-kuadrant:  ## Operation level Kuadrant Extension
        backendRefs:
          - name: petstore
            port: 80
            namespace: petstore
      operationId: "getDog"
      responses:
        405:
          description: "invalid input"
➜  kuadrantctl git:(openapi-kuadrant-extensions-at-root -> upstream/openapi-kuadrant-extensions-at-root) ✗ make install                      git:(openapi-kuadrant-extensions-at-root|…1⚑3
go fmt ./...
go vet ./...
GOBIN=/Users/jmadigan/Work/kuadrantctl/bin go install

➜  kuadrantctl git:(openapi-kuadrant-extensions-at-root -> upstream/openapi-kuadrant-extensions-at-root) ✗ bin/kuadrantctl generate gatewayapi httproute --oas openapi.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  creationTimestamp: null
  name: petstore
  namespace: petstore-ns
spec:
  hostnames:
  - example.com
  parentRefs:
  - name: gw
    namespace: gw-ns
  rules:
  - backendRefs:
    - name: petstore
      namespace: petstore
      port: 80
    matches:
    - method: GET
      path:
        type: Exact
        value: /v1/cat
  - backendRefs:
    - name: petstore
      namespace: petstore
      port: 80
    matches:
    - method: GET
      path:
        type: Exact
        value: /v1/dog
status:
  parents: null

Given the backwards compat change, we'll tag as 0.3.0?

Following semantic versioning rules, we can't. But it is not ready yet for v1.0.0, is it?
I believe that v0.X.Y means alpha and braking changes can occur. So, semantic versioning should start on v1.X.Y. But whatever is fine with me

I believe that v0.X.Y means alpha and braking changes can occur. So, semantic versioning should start on v1.X.Y. But whatever is fine with me

Yeah, you're right - I'd forgotten that everything in v0 in semver is considered unstable. Patch version bump probably fine.


Update validations.py python script

Fixed the behavior of validate_user function in validations.py.
Close: #1
Fixes #11

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

@googlebot I signed it!

@googlebot I signed it!