"Show Steam Deck Verifications Badges" option not working in full game page

Hello, thank you for making this nice extension, works pretty good except one little bug, the Steam Deck Verification info is not showing inside the full game page, I have all the options from the extension enabled so my guess is that Steam changed some code in the full game page, it works fine when I search for a game the list view shows the Steam Deck Verifications info correctly.

Can you send me the page url, the browsers you're using and maybe a screenshot how it looks for you?
I checked the game page of Portal 2 and I can clearly see the verification info. It is the default verfication info just pulled a bit higher so you can find it more easily:

@innovaciones ?

Hello, sorry for the delay I missed the notification. I tried with the same game Portal 2 and still doesn't show the Steam Deck compatibility info, here is a screenshot from my browser:

I'm using Google Chrome 114.0.5735.198 (Build oficial) (x86_64) on macOS 13.4 Ventura
Let me know if I can help you debug the problem using Chrome DevTools

@innovaciones I'm using
document.querySelector(`[data-featuretarget="deck-verified-results"]`)

to find the verification element. If you put this line in your console, what is returned?
It should look like this:

I'm getting a null

That explains why the extension isn't working for you. It only grabs that item and puts it higher up. Is the Steam Deck available in your country?

No officially, so I guess that's the problem, I tried using a private window with a vpn from USA and now I can see the Steam Deck compatibility info, I guess there is not a workaround for this, the page is served by location using IP

It would be possible to render at least something.
If no verification is found, it could check it manually and place a clone of that element.

The next release will contain a workaround. When Steam does not send the HTML element I'm modifying, a new one will be created at its place. The created element is not as great as the one Steam provides but at least you can see the status.
In d869a764b104f590b8db40ff57e3f78377934d40 this is implemented.
So v1.4.0 will have this. You can either try to install the .crx file or just wait until the webstore updates. I would consider simply waiting, usually the update doesn't take too long.

Thank you for the fast update 🙌🏻

You're welcome.
Btw you can see the version you have installed here:

I confirm that version 1.4.0 is now showing Steam Deck Compatibility info for my country, thank you!!


Update SparqlBuilder user documentation

Problem description
The SparqlBuilder is being refactored. The user docs aren't always kept up to date due to possible conflicts. The docs must be fixed when the refactoring is done
Preferred solution
Update the docs
Are you interested in contributing a solution yourself?
Yes
Alternatives you've considered
No response
Anything else?
(This is just a reminder)

Just as a reminder: Now that the javadoc is online, it's easier to verify the links in the rdf4j-spring docs, and, sure enough, some of them are broken (we need to check for a leading slash, which breaks the css resolution apparently). Also found one or two typos in classnames.


Rickroll Avatar

Description
An Avatar modifier that will return a gif of your Avatar, but turns into a rickroll
Reasoning
Just a fun trick when someone asks for your profile and if you have nitro and want it. Also, it's just a fun command lmao.
Proposed Implementation
Don't have it yet. I can't seem to find the person who's pfp looks like this lmao (or any recording). I can make one though if needed. Don't want to do unnecessary work if this gets rejected.
Would you like to implement this yourself?

[x] I'd like to implement this feature myself
[ ] Anyone can implement this feature

Ah, found it!

I'm worried about how much computational power this would take.
@HassanAbouelela random poke, what do you think about this?

Due to the concern of how long a animated avatar could be, this can cause large amounts of resources to be used up.
Maybe another feature can be created with rickrolling? If so, please make another issue.


Use sprite texture density aptly

Fixes the usage of the texture density property.
Based on the description https://github.com/tangrams/tangram/pull/234, and discussion with the JS and cartography crew, density defines divisor which is used to get the size of the sprites in css pixel units. The below implementation reflects this change and matches the behavior with the JS implementation.

Wait on this, I released, density can be applied and used for any texture and not just the use case of a spriteAtlas. Updating.

Yes - I also think density should be a Texture member if possible.


Album is fetched twice when going to next album

You get duplicate XHRs when:

navigating to next/prev album
navigating up from image or album to parent album

This was fixed by cf605e6


Broken links & broken badges in CONTRIBUTING guidelines

The CONTRIBUTING guidelines for this project use shield.io badges to make the labels look pretty. (Scroll down on http://shields.io to the My Badge section to see how they're made).
Some are broken though!
There are two errors as it stands in the CONTRIBUTING file:

The badge has a - in the name which is not working any more. The name of the link to the badge needs to be replaced with -- where - is supposed to be rendered in the text of the badge.
For example at the moment https://img.shields.io/badge/-no-code-207de5.svg does not render but https://img.shields.io/badge/-no--code-207de5.svg does show up as .

Some of the links are mis-typed.
For example [link_bugs] doesn't actually exist, but there is a [link_bug] in the list at the end of the CONTRIBUTING file. Same with [link_requests] which should be [link_request].

It would be great to have these fixed! Ping me if you have any questions @jlee124! 🌮 ✨

Issue can be closed?

Yep, my bad! I forgot to refer it in my PR. I'll close it now as these errors have been fixed.

No problem @faheel! Thank you so much for contributing :sparkles:


[Relay][AlterLayout] Broadcast with scalar shape

Relevant Issue - https://github.com/apache/incubator-tvm/issues/4508
Preventing insertion of layout transform and expand dims when the broadcast tensor is of scalar type.
@yzhliu

Thanks @anijain2305


Make a proofreading of the readme

Brief issue description
The readme might contain some naming issues, typos, etc...
Expected behavior
The readme wording has to be consistent with the documentation.

add the resources for the MVC widget development (proposals in the description of https://kentico.atlassian.net/browse/DCN-204)

Done here: https://github.com/Kentico/ems-mvc-component-starter/pull/6


with init-mask viewer, enable to change slice from left window

related to: https://sourceforge.net/p/spinalcordtoolbox/discussion/help/thread/70e45f83/
it would accommodate data like the one below:

@jcohenadad PR #1163 includes the changes


Update submodule sync to run buildcpp target [skip ci]

context at https://github.com/NVIDIA/spark-rapids-jni/issues/2678#issuecomment-2537708045
follow up of https://github.com/NVIDIA/spark-rapids-jni/pull/2677
verified in the internal run

build


RE8 left hand not tracking

Im in the beginning part of RE8 Village where you hold the baby, my right hand works and tracks fine, but the left hand that holds the baby is stuck where my head is, obscuring my vision.  I played a bit further and afterward, my left arm continues to not track and is stuck in front of me
The movement and buttons all seem to work fine
I am running OpenXR on a Quest 3 and a fresh install of RE8 Steam version
I tried various versions of RE8 and REFramwork (including the latest) and all have the same issue

Some additional info:
i9-13900K
Asus TUFF 4090


face_encodings method can not run on asynchronous threads

face_recognition version:
Python version: 3.4
Operating System: windows 7

Description
I want to use face_recognition.face_encodings method on asynchronous threads, Because it causes my webcam to be unsmooth, but when I use it on asynchronous threads, It has no effect at all
class CompareByThreadPool(object):
    executor = ThreadPoolExecutor(max_workers=1)

    def __init__(self):

        self.mutex = QMutex()
        self.obama_img = []
        self.obama_face_encoding = []

        self.face_locations = []
        self.face_encodings = []
        self.face_names = []
        self.process_this_frame = False
        self.can_begain_compare = False
        self.can_begain_encoding = False
        self.frame=numpy.arange(0)
        future = self.executor.submit(self.cricleRun,self.frame)

    def set_frame(self,frame):
        self.frame = frame

    def cricleRun(self,frame):
        while True:
            print('self.frame.size: ',self.frame.size)
            if self.frame.size > 0:
                self.face_rec(self.frame)
            time.sleep(0.4)

    def face_rec(self,frame):

        small_frame = cv2.resize(frame, (0, 0), fx=0.25, fy=0.25)

        # Convert the image from BGR color (which OpenCV uses) to RGB color (which face_recognition uses)
        rgb_small_frame = small_frame[:, :, ::-1]
        # rgb_small_frame = small_frame

        self.face_locations = face_recognition.face_locations(rgb_small_frame)

        rec_begain_time = time.time()
        print('begain time: ',rec_begain_time)
        if self.process_this_frame:
            self.face_encodings = face_recognition.face_encodings(rgb_small_frame, self.face_locations)
        self.process_this_frame = not self.process_this_frame
        print('face_rec compareFlag: ',self.can_begain_compare)
        if self.can_begain_compare:
            face_names = []
            for face_encoding in self.face_encodings:
                #match = face_recognition.compare_faces([obama_face_encoding], face_encoding,0.5)
                face_distances = face_recognition.face_distance([self.obama_face_encoding],face_encoding);
                print("face_distance: ",face_distances[0]);
                #if match[0]:
                if face_distances[0] < 0.6:
                    name = "Success"
                else:
                    name = "unknown"
                rec_end_time= time.time()
                face_names.append(name)
                print("name : {0} time: {1} ".format(name,rec_end_time-rec_begain_time))

What I Did
Can it run on asynchronous threads ， Please tell me how can I make my webcam smooth

There's several problems with your code.
First, don't try to use multiprocessing inside of a class like this. Having class-level flags like self.can_begain_compare just isn't going to work in a multithreaded program with multiple threads accessing it at the same time. Instead, have a single function outside of a class that gets run by each thread and make that function take in a fixed set of inputs and return a fixed result. The code that runs in the thread should not access any global/class variables.
Second, you are only calling executor.submit once on an empty array, not on an image from the webcam. You aren't ever grabbing new images from the webcam or passing them to the executor from what I can see. And you aren't ever getting the result of the future that you asked it to process.
Third, using a thread pool probably won't work well inside of python anyway because of how it has a global interpreter lock across all threads. You probably won't gain that much real-world performance increase. You'd probably get a better result using a ProcessPool instead. This is just a guess though - I haven't tested it with a thread pool.
But even if you get that working, you have a problem of synchronizing the order of frames that you get back from the threads (assuming that you have multiple threads doing the face recognition step in parallel). The threads are going to finish out of order because different frames will need different amounts of processing. If you show each frame of video as a thread finishes processing it, your final video will jump around and the frames will be out of order. You need some way of keeping the results in order even if they are processed out of order. And just putting all the frames in a queue will cause "frame pacing" freezes in your video where the video speeds up and slows down in a weird way as different frames take more or less time to process by different threads.
In other words, using threads to process video can involve writing some fairly complicated synchronization code or coming up with a more complex design where different threads do different steps of processing (like one thread to do face location, one to do face encoding, etc). It's beyond the scope of something I can answer in a github issue.

Thank you very much for your reply ! I'm not a professional python engineer，I change to use c++ to implement  it already，Thank you very much at last. You are a good man! @ageitgey

the same problem ,why face_recognition.face_encodings(rgb_small_frame, face_locations) can not run on asynchronous threads,  how to solve it


Defining and Enabling /api/v1.0 of the API

Enabling /api/v1.0

OpenAPI 3.0.0  for v1.0
Controllers (based on v0.1)
Specs added for /api/v1.0

ping @gtanzillo will take some work to remove /api/v0.0, let's do this in a followup-PR.


Fix for string values that contain double quotes

I encountered an issue using this package wherein the generated JSON did not properly escape double quotes. I wrote a very small amount of code, but from my limited testing it seems to do the job of properly escaping double quotes. I also modified an assignment statement as per recommendation from the Kotlin static analyzer.
If there is still anyone actively maintaining this project, please take a look at my meager pull request and if all is well please merge it into the main repo. Thank you and happy programming.

PR in review.

Looks good to me.
@seco560 thanks for your contribution and efforts.
Will merge this into master branch after testing few things.

I appreciate it, thank you. But you never merged the pr_zone branch back into master, which means the changes aren't published into pub.dev. If you'd like to see them reflected there, please do a merge into master. As of now I'm still using the fork I made on my own GitHub page.

Hi @seco560,
Sure. Don't worry will get it merged in master branch. I am still doing some R&D on the plugin to increase the usability, performance and etc.
Will let you know once it is merged.
Thanks


Multiple generators seed question

Hi, I'm very new to property based testing and to your library, thanks for creating it! I have a question about the seeds when using multiple Generators. I have made this small example which highlights my issue:
public class Dummy
{
    private readonly int[] m_Single;

    public Dummy(int range)
    {
        m_Single = Gen.Int[0, 10].Array[range].Single();
    }

    public void DoSomething()
    {
        if (m_Single.Sum() % 2 == 0)
        {
            Assert.IsTrue(false);
        }
    }
}

public static class GenHelper
{
    public static Gen<Dummy> GenDummy => Gen.Select(Gen.Int[1, 512], x => new Dummy(x));
}

[TestMethod]
public void seed_test()
{
    GenHelper.GenDummy.Sample(d => d.DoSomething(), null, null, -1, -1, -1);
}

When I run this test, it fails and gives me a seed, but I'm unsure if it 'belongs' to the Sample or Single method. For example, I got this seed: 00007TA2XpFw, when I provide it to both Sample and Single, the test succeeds again. When I provide it only to Sample and then run the test again it sometimes succeeds and sometimes fails with a different hash. If I provide the last hash to Single it fails every time as expected.
m_Single = Gen.Int[0, 10].Array[range].Single(x => true, "a6C8duJJ7EAJ");
...
GenHelper.GenDummy.Sample(d => d.DoSomething(), null, "00007TA2XpFw", 1, -1, 1);

My real use-case has a lot more generators, so trying these different seeds for different Generators is not that feasible. Perhaps I am misunderstanding how to use the seed? Thanks!

Hi,
You can't use Sample and Single together. Single is meant to be just a quick way of creating a random value when it doesn't matter what the value is so it doesn't have a seed. I'll make this more clear on the Single method.
In the example above instead of using Single you can create a Gen and Use Gen.SelectMany instead of Gen.Select.

Hey, thank you very much! SelectMany indeed solved my issue. Thanks again for the help.


Make MasterController method public

Make private method MasterController.getAgentRunningState() public. Access is needed for special cases where the master controller is run embedded in other applications.

Done.


Logging

Added logging on acquiring and releasing a lock

Thank you

is the a way to toggle the log? it can add tons of unwanted log when you are doing tests on other apps.

@moscoquera you can setup the filelock logging to a level higher than INFO


🚨 fix inconsistent component state updates

React component state updates using setState may asynchronously update this.props and this.state, thus it is not safe to use either of the two when calculating the new state passed to setState, and instead the callback-based variant should be used instead. (details here).
These were all found on LGTM.com, and there are a couple of other alerts for this project that would probably also be good to fix.
(Full disclosure: I'm part of the team behind LGTM.com)

Coverage remained the same at 28.092% when pulling 7864590da1bdb311eb5187dbfce18eae9d1d3528 on samlanning:inconsistent-state into 71e3f9cffb25d75cbf12c17c144ba8cc87e25f8c on react-component:master.


Update to fork as wysihtml5 isn't maintained any more

I found an annoying bug and debugging it took me wysihtml5. It seems the project is no longer maintained (last release in 2012) and as per the readme, it suggests to use the fork: https://github.com/Voog/wysihtml
The bug was if you press enter multiple times to add spacing, the cursor stays in top line even though the new lines are being added. This can lead to user believing newlines are not being added. I was able to reproduce this issue on the demo website of wysihtml5 but the fork Voog/wysihtml works as expected.

Yes, that's one of many bugs Wysihtml5 has. I can't simply move to the fork you mentioned because Bootsy actually uses bootstrap-wysithtml5, which relies on the original, discontinued Wysihtml5 (Bootsttrap-wysithml5 itself was discontinued). At this point there isn't much I can do myself but I am open to anyone who wishes to work on moving Bootsy to a different JS library.


notificationCatcher: unable to send attachements via email

It seems that the library never attachements to the notification catcher : https://github.com/notifme/notifme-sdk/blob/master/src/providers/email/notificationCatcher.js#L8
Is this a expected behavior even if its defined as available in the request : https://github.com/notifme/notifme-sdk/blob/master/src/models/notification-request.js#L17
Regards

You're right, it should be easy to send attachments (https://github.com/notifme/catcher/blob/master/scripts/send.js#L30-L32). Would you like to make a pull request?

I just noticed that I had patched this years ago, and apparently never made a PR, pretty simple fix.
NB: I've noticed another bug with the catcher where only the latest email attachments will be visible, but it's better than nothing and I think most people want to make sure the files are actually sending through correctly anyway.


Feedback from WDIB

Attaching feedback from WDIB internal review

TADAshiny_KevinsReview.docx
tada_comments_kiki.docx

Regarding adding counts to the data retrieval, see web services documentation: https://www.waterqualitydata.us/data/swagger-ui/index.html?docExpansion=none&url=/data/v3/api-docs#/Result/resultPostCountRequest

I am creating separate issues for remaining tasks identified from Kiki & Kevin's review:
https://github.com/USEPA/TADAShiny/issues/159
https://github.com/USEPA/TADAShiny/issues/158
https://github.com/USEPA/TADAShiny/issues/160
I already addressed Kevin's suggestion to switch the bar chart axis in cm-release-review-2 branch and will merge in next week. Already addressed some of Kiki's comments there as well. Remaining ones are now in the issues above.


Rename queue_free to free in Godot 3

I'm new to Godot but I'm diving very fast into it. This allowed me to see some points that could be better and the 3.0 release is intended for this.
The use of functions queue_free and free is odd to me. The default case is to use queue_free instead of free.
So I think that the functions should be renamed:
queue_free -> free
free -> force_free (just a suggestion).
This way, the use of this functions would be more natural, especially for newcomers and also produces a cleaner code, as queue_free usually just means free for the user.
When the original free function is really needed, you can use it with a different name, like force_free or immediate_free (the choice of the name I leave for you guys).
This way, you have the default case of free as just free and the non-ordinary one as the different named free.
IMHO this is kinda a simple change (but an extensively one). I could try to do it myself if that's the case. And it fits good in the breaking changes for GDScript 3.

I don't see problem in free -> force_free but queue_free -> free is not renaming, is changing the meaning  to existing word, it can be problematic? Other quest: free is shorter and this is ok, but, is more descriptive?

queue_free means that execution of free is not happened until next frame where all queued objects frees, I dont think its a good idea to rename it. force_free instead free looks more well.

Can't edit on mobile (sorry for doubleposting). Other idea: renaming queue_free -> Free_queue y free -> Free_forced you have the two options close in autocomplete and don't lose meanings.

maybe rename queue_free to qfree is more ellegant solution ?

I thing that abreviate is not the new style of godot API... By the fact get_pos was renamed get_position... We shouldn't do random abreviate - unabreviate only for the shake of do it. I like actual queue_free. But if renaming my vote goes to free_queue and free_forced for the autocomplete help

I'd vote in favor of free and free_immediate (or free_force, I don't care that much).
Not q_free though, then better leave it as-is.

I prophesy of this.
there will be someone asks that...

I do free() on instance, but I can still access the after free(). it's not freed after all.

:) :)  sure...

Any way... All renamed expressions should be completed after 3.0 launch, i'm wrong? if there are more renaming before launch... gdscript will be version 3 (cool.. Like godot :) ) and C# version 2. Faster than light...

should be completed before 3.0 launch
It should be completed before 20 november, when beta starts and feature freezes

Too much pressure to start now my "free_queue / free_force" campaign ... I'll leave it until the next elections.

I agree with Ranoller in his first post. Renaming free to be more descriptive would be a good idea. I also agree queue_free should not be renamed to free as this will essentially make an API that lies to the person using it.
My personal suggestions would be:
free_queued and free_immediate
This way auto-complete will offer both methods when typing "free".

I think the free_queued and free_immediate logic is a good compromise. For beginners, having to figure out why 2 free methods is more logical then why there is a free method but to use it in practice you should use another to make it free.

Honestly I think it's good how it is. But it could just be because I'm used to it. The way I see it "free" already implies that it will be immediately gone, and queue_free means that it will be put in a list to free at a later time.

Isn't queue_free specific to nodes though? How about objects that can only be freed?

@CowThing @Zylann I'd be fine if it stayed how it is also, but if it were to change it would be good to make it as clear as possible what they do. I can see new users being confused and always using "free" on nodes as it's obvious what it does, but queue_free isn't obvious.
However, if the example code and projects all use queue_free and if people in the forums/Q&A/Discord/etc give them correct advice they will learn to generally use queue_free instead for nodes.
So, from a self documenting API perspective changing the name is a good idea. From a practical point of view I think it ultimately doesn't matter too much. :)

new users should read what a method does before using it. also queue_free is actually quite descriptive in my opinion, of course as everything it needs you to know waht it does and when you should use it (there is no way around this).

The autocomplete "thing" of free_immediate /free_queue is a point to considerate too i think, it isn't?

I'm for free() and free_queue(). Not a big change and autocomplete find both.

I don't know if free and free_queue would be good alternative names. I think they're a bit more confusing than what we currently have (free_queue as a name could imply to the user that it's freeing a queue, not queuing a free like queue_free does). Additionally, I also think it might be a good idea to keep the name the same, so that people coming from 2.1 don't have to relearn how to free a node of all things.
However, if a name change is really really needed (I don't think it is, but if it is), why not something like delete_immediately and queue_delete? I'm suggesting replacing free with delete because of another function we have, is_queued_for_deletion (basically, has queue_free() been called for this node during this frame?). This would not only keep the self-describing aspect of the functions, but in turn also help users to figure out another function that they may want.

I agree with @AllanDaemon that queue_free is confusing for beginners who neither understand the idea of a queue nor freeing memory.
However, I'd advocate to keep queue_free and free the same, because of compatibility and they are semantically correct to the operation.
That being said, I would also very much stand behind creating an alias function for queue_free, such as remove. PHP has both exit and die function to do the same thing for example. This would maintain compatibility and make the engine more intuitive to beginners.

What is better for beginners may not be convenient, if beginners learn about how free and the deletion queue works will be better for them in the long term (and they will be beginners for a few weeks anyway, better learn the basics right).
Documentation need clear examples of free, queue_free and remove (the later is the most confusing of all IMO).

I don't think there should be a "remove" that means the same thing as "queue_free". Since Nodes already use "remove_child" to mean removing a child node from the scene tree without freeing it.

I think free and queue_free are just fine. If they're confusing, it just means that more documentation should be written about them. free_immediate or free_now is redundant, as all Godot methods are run directly when they're processed, unless you call them with call_deferred (which queue_free just conveniently wraps for you). As someone mentioned above, if queue_free was renamed to free, people would start wondering why they can still access the free'd node in the same loop.
So nothing to change IMO.

Documentation need clear examples of free, queue_free and remove (the later is the most confusing of all IMO).

What even is remove? First I've heard of it.
And agree fully about documentation.

@Zireael07 I was basically referring to remove_child, but we can add remove_and_skip (which is queue_free_and_reparent_children) and all the other remove_something.

Beginner story: When I started with godot I learned to use free() to remove/delete a node, but during game jams we got crashes. Then I read about it is better to use queue_free, but also this give sometimes strange problem .  Finally we implemented our own free function.
For a beginner it must be clear when to use which function and what are the known problems.

This is a common problem and I've seen it a couple of times too. I am also
in favor of renaming free, but i don't think any of the naming options
convince me that will avoid the problem. Maybe this is also a documentation
problem..
On Fri, Nov 10, 2017 at 10:31 AM, puppetmaster-<EMAIL_ADDRESS>wrote:

Beginner story: When I started with godot I learned to use free() to
remove/delete a node, but during game jams we got crashes. Then I read
about it is better to use queue_free, but also this give sometimes strange
problem . Finally we implemented our own free function.
For a beginner it must be clear when to use which function and what are
the known problems.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12727#issuecomment-343473830,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z29pjy87Ngkv6f04kMma9B-sEoikKks5s1FA5gaJpZM4QVK2U
.

I am also in favor of renaming free, but i don't think any of the naming options convince me that will avoid the problem

Why not use destroy() ? It is short, easy to understand and it fits the purpose.
It is what Unity uses.

Unity actually has the same problem.
The second Debug.Log will still print the name since it has only been queued for deletion at the end of the frame.
Debug.Log(gameObject.name);
Destroy(gameObject);
Debug.Log(gameObject.name);

I think better naming is ideal, but I really don't think it's that big of a deal. Once a beginner runs into this and finds out what's really happening it will likely stick in their memory and no longer be an issue. As long as the example projects contain correct usage most beginners will likely stay with recommended coding conventions.

Unity actually has the same problem.

Agree on that, still "destroy()" is more astraightforward name that "queue_free()", at least for such a common function. Also it avoids a confusion with "free()". :)

I 100% agree, for beginners node.destroy() would be something I would try before trying node.free()

Agree on that, still "destroy()" is more astraightforward name that "queue_free()", at least for such a common function. Also it avoids a confusion with "free()". :)

No, that's super confusing. destroy and free both mean "get rid of that resource and free the memory". If one is queued like in Unity and the other happens immediately, it's a mess.
If you don't like the name free we could have destroy (immediate) and queue_destroy (deferred), but I don't really see the point.
It's starting to look like bikeshedding to me. Semantically free and queue_free are correct, and the most explicit way to convey what they do (unless we nit pick on the free/destroy/annihilate naming). We just need better documentation in the classref if it isn't good enough, and maybe a tutorial in the official docs on managing nodes and resources, and explaining what are free and queue_free and when to use each.

While it is true that once a beginner understands what queue_free means, then it is easy to associate the label with the meaning, it is only fair to also say that once a more skilled dev understands that destroy defers deletion until the end of the frame, then they too would associate the label with its meaning.
Moreover, name a popular game engine where "destroy" immediately frees the memory.
Unity's destroy defers deletion to the end of the frame (https://docs.unity3d.com/ScriptReference/Object.Destroy.html)
Unreal's destroy defers deletion to the end of the frame (https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/AActor/Destroy/index.html)
Lumberyard's DestroyPhysicalEntity defers deletion to the end of the frame (http://docs.aws.amazon.com/lumberyard/latest/developerguide/physics-entities.html)
So in fact if destroy did immediately delete, then it would likely in fact confuse the developer by accepted convention of the 3D game dev community. Having an alias like destroy would only serve to make the transition easier to Godot and offer a semantically more intuitive function for beginners.

I agree that to those of us who are more technical that destroy and free mean the same thing, but to a less technical (more artistically minded) person destroy means "obliterate it out of existence" and free means "let it go and wander off somewhere". We really need to remember that Godot isn't just for technical people. Artists have used and will use Godot in the future.

An alternative could be to move queue_free() to Object, and rename to
free_immediate() free_deferred() , so both appear to the user when trying
to free stuff. This way we can better documment this behavior in both
GDScript, and the free_immediate() function (where it is documented to use
free_deferred() unless needed)
On Fri, Nov 10, 2017 at 2:36 PM, Nathan<EMAIL_ADDRESS>wrote:

I agree that to those of us who are more technical that destroy and free
mean the same thing, but to a less technical (more artistically minded)
person destroy means "obliterate it out of existence" and free means "let
it go and wander off somewhere". We really need to remember that Godot
isn't just for technical people. Artists have used and will use Godot in
the future.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12727#issuecomment-343537590,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z28y7p-25NItx4yBJBDfUDDmd_aqnks5s1ImdgaJpZM4QVK2U
.

so both appear to the user when trying to free stuff

While I'd be cool with moving the function, as I pointed out in my previous comment, I feel intentionally showing both in auto-complete may be even more confusing to the user, at least to new people. Even if we note in the documentation to use free_deferred() unless you really need it, I'm not quite sure it'll be a good idea to have both show up in the auto-complete for just that reason.

While I'd be cool with moving the function, as I pointed out in my previous comment, I feel intentionally showing both in auto-complete may be even more confusing to the user, at least to new people. Even if we note in the documentation to use free_deferred() unless you really need it, I'm not quite sure it'll be a good idea to have both show up in the auto-complete for just that reason.

First time can be confusing, second time you know exactly what method is needed, third time (and the rest of the times) simply you got both methods near in autocomplete and the last 200 times you need to use .free_immediate/deferred are time saved. It´s usability improvement, not only new user guide.
Actualy the method queue_free is a bit hidden (and in 2.1 totally undocumented), if a new user need to delete a node, probably type free, destroy ,delete ,etc... in help (results for free are now: Node.queue_free // Object.free, that´s ok) or search directly for free(), destroy(), delete(), etc... in method list... if he/she uses second method, it will not find queue_free, only free().
Last opinion about autocomplete. If the method renaming is free_deferred // free_immediate, and autocomplete follow alphabetical order, free_deferred is first choice, and that is good for new people, because this method shouldn´t crash execution throwing : "....invalid method lost_one_point_of_life() call in null instance....." :):):)

@NathanWarden what I was saying in my previous post is that even "technical people" understand destroy to mean free deferred, since that's what destroy means in at least Unreal, Unity, and Lumberyard. This suggests that the convention, even among more experienced game developers is that destroy means free deferred.
And for the record, I 100% get that Godot is def not a Unity/Unreal clone and should never be. Godot is way too unique and elegant for that. At least to the extent of core features and paradigms. However, there are conventions that don't compromise Godot's specialness that should be considered. Imho destroy alias is one of them =).

@Oranjoose I agree with you 100% :) and think destroy is a great option. To clarify my point, I was saying that destroy is a word that both technical and non-technical people will immediately understand (which is a very good thing), whereas free_* makes perfect sense to technical people, but may not make sense to those who are inexperienced or non-technical. I say go with the one that makes sense to as many people as possible, which would be destroy. And like you said, it's a common function/name used in almost every other game engine out there :)
But, with that said, if a person makes Godot their main engine then they will get used to whatever word is used after maybe a few weeks. Not to say that free and queue_free are bad, but almost anything mentioned above would be quite a bit better. :)
My two preferences are:

destroy and free
free_deferred and free_immediate

First time can be confusing, second time you know exactly what method is needed, third time (and the rest of the times) simply you got both methods near in autocomplete and the last 200 times you need to use .free_immediate/deferred are time saved. It´s usability improvement, not only new user guide.

This whole paragraph seems to make the assumption that new people will always know which should be used when prompted with the choice (and in reference to your last paragraph, even if they're in alphabetical order). I'm not going to deny that with practice people will figure out which they should use, because how else do you think big name games like GTA V came out on time? What I am denying is the ideas that we can assume every new user will look at the docs (let alone even know they're there), and that even then they'll pick the "right" one (considering that technically neither of them are wrong). That feels like a pretty big assumption, one I don't think we should be making.
Of course, we could always rename them too, but then that needs to be solved somehow, something that we can't do with a simple suggestion.
Might I propose gathering suggestions for new names and throwing out a poll within as many of Godot's discussion channels (Discord, Twitter, the IRC, etc.) as possible? Making sure, of course, to include a "I don't think it should be changed" option. I'm starting to think it'd be a better idea to poll the community on this rather than let a few people choose for them, because then at least we know that the whole community knows of us considering a change of name for such an important function.

Might I propose gathering suggestions for new names and throwing out a poll within as many of Godot's discussion channels (Discord, Twitter, the IRC, etc.) as possible? Making sure, of course, to include a "I don't think it should be changed" option. I'm starting to think it'd be a better idea to poll the community on this rather than let a few people choose for them, because then at least we know that the whole community knows of us considering a change of name for such an important function.

"I don´t think it should be changed"option always win. I will vote for that all time, but this is not reality. I did wan´t fixed_process change, and set_pos change, set_rotd missing, OS -> engine, etc... because i´m user of godot now and this changes invalidate some of my code, but if the changes are going to happen inevitably it is better to try to give an alternative at least better than the current one, it isn´t?

So in fact if destroy did immediately delete, then it would likely confuse the developer by accepted convention of the 3D game dev community. Having an alias like destroy would only serve to make the transition easier to Godot and offer a semantically more intuitive function for beginners.

I don't agree. I don't have any experience with the other game engines you mentioned, and to me if I see destroy I expect it to destroy the node when the statement is run, not deferred.
Since we're all bikeshedding about what is more user-friendly for first time users (since we all agree that after using it once/reading the docs, there's no issue whatsoever with queue_free and free), I would not accept to rename queue_free to something that hides its deferred nature.
Godot's API is meant to be very explicit about what it does. If other engines are happy with less explicit names hiding the deferred status of the call, that's cool for them, but we don't have to copy them. Many first time Godot users don't have any experience with other engines, we shouldn't assume that copying Unity would make us more user friendly.

If I may suggest a middle-ground without attempting to cause more bikeshedding, could we perhaps add destroy() as an alias for queue_free(), and label it as such in the docs? Regardless of how many users we have that don't have prior game engine experience, Godot is directly competing with other engines, and thus we can expect that a good chunk of them might be coming from those other engines - thus, I think it would be a good idea to make the transition smoother through an alias if nothing else.

I don't like aliases personally. Either there's an issue with the current name, and it should be changed (now that we still have the opportunity for 3.0), or it's good enough as is. If we think destroy is easier to understand than free, we could have destroy and destroy_deferred, autocompletion would make it obvious the first time you type destroy that the former is not deferred.

Programming in unity is hard and less user friendly than programming in godot. There are other things to copy from unity or unreal, more deeper, not the "user friendlyness" that unity doesn't have. With mono we have now the unity hard way of programming, and with visual script the spagetti blueprint way of unreal. Please, don't copy from this engines more, there are better apps (spine, blender...) to inspirate in useful stuff.

I'm not sure there's a better middle-ground than the alias I suggested, though
I want to avoid forcing people to look through the docs to find the new name. I'd be fine with destroy and destroy_deferred if they had the old names as aliases (or the new names were aliases to the old methods) so that people coming from 2.1 don't have to look at the docs to know how to destroy nodes... but you know how that goes.
Plus, if we're really suggesting destroy and destroy_deferred, I want to point out how likely it might be that people will bring it up as an issue in the Github and ask it to be switched around (destroy being the deferred version, and destroy_immediate being the immediate version). And I don't think it'd be right to just push away the idea because "the current names are explicit, we're not gonna change it."
I don't know what else to suggest to help this issue, because I understand both sides of it and can't justify one side more than I can justify the other. So I guess this comes back around to my suggestion to throw around a vote to our users? Maybe this time, to see if they think an alias would be useful?

There are other things to copy from unity or unreal, more deeper, not the "user friendlyness" that unity doesn't have.

This user friendliness point, I'm unsure where it came from. Can someone help me with that? The only mention of Unity/Unreal/whatever was in regards to the related function being called destroy in those engines. Where does the user friendliness of other engines come into play in this conversation?

User friendliness related to code, we throw arguments to api changes, and i throw mine (to this case): the fact that unity have a destroy method doesn't imply that godot need that. Queue_free (or free_deferred) is more descriptive, and any person coming from untity, that can write some code, catch this in 1 second, so thinking in unity users to made api changes (if unity methods have less meaning).. Make sense?

IMHO the current naming make sense.
free() sounds like the default destructor who simply delete the object and queue_free() is a more sophisticated function to delete objects.

I can see that  free is very C-like and might throw off people unused to the term. I don't agree that queue_free should change to remove its deferred nature from the name.
I don't understand the argument about completion to show both, since it already does:

I'm okay with destroy or delete, as long as the deferred is explicit in the name. The compatibility with 2.1 is not an issue since it's already broken anyway, people are expected to relearn some stuff for 3.0.
Do we have statistics of how much people were confused by the terms? Or at least some actual examples of confusion (besides the ones in this thread)?

@vnen Statistics? Next semester, I can try things out on my university workshop-based class of 50+ students if you like. None of them are going to have any Godot Engine experience, and I could get to a point where I tell them "okay, we have this ball object. Go figure out how to remove it in the code" and then watch to see how long it takes them to figure it out. Based on anecdotal observations from this semester, I can tell you that they're going to struggle a lot to figure it out by themselves, unless there's a function alias that's more intuitive like destroy.
I have already done a number of one on one tests with students while developing the curriculum, in order to figure out the parts that students struggle with more. I do this side by side with a different game engine, so that we have a comparison point. There are lots of things Godot does that are more intuitive than other engines, but there are definitely a few pain points. The queue_free function is one of those aspects that give them a lot of trouble figuring out themselves. It simply doesn't occur to them to search "free", let alone "queue_free". Another pain point, just as an aside, is collision handling (in fact, this one might be the worst for beginners in relation to other engines in my experience).
If have a pretty continuous supply of amateur developers willing to sit down and perform these kinds of user tests if you have any suggestions.
PS: if there is insistence that destroy be accompanied by some way of explicitly conveying that it defers to the end of frame (which other engines do implicitly), then I recommend avoiding words like "deferred". There are more beginner-friendly words that imply it well enough to the kind of people you're afraid are going to get confused by just destroy. I don't have a good suggestion, but something like destroy_safely or set_to_destroy.  If you absolutely have to do destroy_deferred, then I recommend doing something like Unreal does with a star icon for popular functions or a little text that says "(recommended for most cases)". Sorry for bikeshedding again... You can tell by now my stake in the engine is for getting beginners into game development, and so I have a one-track mind here.

@Oranjoose Please don't take this personally. I'm not saying it doesn't cause confusion (in fact, I said the opposite in my previous post). My point is that we can't simply change it because someone "think" it might cause trouble. We need a foundation to base the claim. If you have it, great! Then we have a real reason to change it.
When someone asks to change something that was in Godot from the very beginning I get a little skeptical because if I don't recall anyone complaining in the over two years I've been following it, I wonder if it's really a general issue. But if new users are indeed struggling with it, especially now that Godot is really gaining popularity, then it's totally fine to change to something more user-friendly.
I still stand my points though: I'm okay with destroy or delete and a descriptive name to indicate the deferred nature of it, even if it's a synonym like "delayed" or "stalled". I believe that a descriptive API is better both for beginners and experienced users.

If this change will not be merged before beta, i ask for not do... We want to start writing code in godot 3, please don't rename API after beta.

I like free_immediate and free_deferred, and we could put both in Object
On Nov 18, 2017 8:46 PM, "Ranoller"<EMAIL_ADDRESS>wrote:
If this change will not be merged before beta, i ask for not do... We want
to start writing code in godot 3, please don't rename API after beta.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12727#issuecomment-345480006,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z26s_z73KGmlKww64yWL5M-a9KE0Aks5s32xCgaJpZM4QVK2U
.

This discussion is so convoluted that I'm not sure what is the best. It started as the queue problem, but then the problem was in the word free too.
Summing up the original point, the issue is that queue_free is used more often than free so the name of the former should be simpler.
free_immediate and free_deferred make the names more explicit, putting a greater burden in the game programmer to pick the best one for their use case, so it might solve the misuse issue.
As for the word free, it is very C-like in nature so it might be an issue for people not used to the language, but it is also a established standard (I'm in the fence for that one, since I'm already used to the word).

@reduz
Personally I'm against free_immediate simply because of the awkward way it's named. Explicit or not, it's just... awkward, in my opinion. free_deferred is fine, though. Maybe we'll have free and free_deferred?

@vnen
Just reread one of your comments.

But if new users are indeed struggling with it, especially now that Godot is really gaining popularity, then it's totally fine to change to something more user-friendly.

I'm actually curious if we have any proof that many new users are struggling or might want it changed.

@LikeLakers2

I'm actually curious if we have any proof that many new users are struggling or might want it changed.

That was exactly my point. If a lot of users are struggling, then we have a reason to change. Otherwise it is just void speculation. And AFAIK we don't have data.

TBH renaming queue_free to free_deferred is good on its own, since it's consistent with call_deferred. Moving it to Object would also give an advantage, so 👍 for both. OTOH free can remain the same, since for the lack of qualifier it should be obvious that it is immediate.
And we improve the documentation with a better explanation.

@vnen While I like some of the other suggestions, I agree that giving it a name that's consistent with other functions sounds like the best idea. Even if free_deferred is a little strange at first (and doesn't match other engine's paradigms) it will catch on once new users notice it's used regularly throughout the sample projects and documentation and it will just become second nature.

I like "free" and "free_deferred" too.

I like "free" and "free_deferred" too.

Me to

I like "free" and "free_deferred" too.

That's the same as what we have now, and des not solve the (potential?) problem mentioned above. given the case not sure if it's worth changing anything

Is better to no change nothing yet, there is people making projects, there is people doing tutorials, ... Scripting system could add methods/identifiers but if we change names after beta we will stop people using godot (i know... Godot web says that is not for production, but people don't like only test and there are tons of bugs that only shows the face in deep testing or production...)

@Ranoller either we change it now or we don't change it ever. Beta is not a final version, and even though we try to avoid breaking changes, if it's needed then now is the time to do it.
It seems most people are okay with the current naming, so it'll likely remain the same anyway.

well, it seems most people prefers we don't touch this.

so, closing..

I'm thinking is nathan gdquest, in gamefromscratch and in the people who make demos.... All this work is better pre-oficial release...

Jeje... I start writing with issue open...  Slowly writer here!


Howcome Alphawallet is not listed on F-droid?

Would you be able to add this on F-droid please? Some users arent comfortable downloading from playstore.

That's a good idea. Need to figure out how to submit it there. @AW-STJ might we look into that together?

+1 submit on F-Droid
@jecogeo

Request for packing done:
https://gitlab.com/fdroid/rfp/-/issues/1633
Please consider a build with Firebase striped (and others Non-Free dependencies)
https://f-droid.org/docs/Inclusion_Policy/

Yes, you're right. We won't package a app based on properitary libraries, that we can't build self.
There is an option, for an version without Crashlytics and these stuff. But maybe switch to another Crash reporting library, like ACRA. F-Droid is also using ACRA.
If you still want have these propertiary dependencies, you can do a own repository for F-Droid. See here the docs: https://f-droid.org/en/docs/Setup_an_F-Droid_App_Repo/

@colourful-land F-Droid maintainer here. I'm not an Android dev, so I do not fully understand your implementation. It seems you're already using build flavors, and even have a noAnalytics flavor – but then, Crashlytics is integrated using
 implementation 'com.google.firebase:firebase-crashlytics:17.3.1'

where I'd have expected something like analyticsImplementation. See my full comment here – corrections and explanations welcome. If you could provide an APK that was built using the noAnalytics flavor, I gladly check it for you for its "contents".

Hello,
currently we cannot get https://gitlab.com/fdroid/rfp/-/issues/1633 done, as this issue here isn't done yet.
If there is no activity here or in the F-Droid issue in the next 4 weeks, we will close our issue to reduce the number of open issues.
In our wiki you can see more details about this process.
Please contact us when you need help.
Thank you for helping us spreading FOSS apps in the world :)

@hboon Any progress on this one? Kind reminder.

@hboon Any progress on this one? Kind reminder.

There was some outstanding preparation work we needed to do to get it listed, which is now complete. I have re-submitted the inclusion issue here:
https://gitlab.com/fdroid/rfp/-/issues/1916

Nice, can we try here as well? https://github.com/AlphaWallet/alpha-wallet-android/issues/1215

@hboon Shall we transfer this issue to AlphaWallet-web3-provider repo?

@seabornlee @justindg Can you take care of this issue?

MR created, waiting for merge.

Out of phase 1

Team, any update on this?

@JamesSmartCell @micwallace ^


Recipes not unlocked until item is obtained?

Is this intentional?
It seems strange that ingots wouldn't unlock horse armors and leather not unlock the saddle.

Yes. I agree. Possibly another requirement would be you have to have mounted a horse at least once, because it wouldn't make sense to think of a recipe tailored to a mob that you aren't familiar with.

Yes. I agree. Possibly another requirement would be you have to have mounted a horse at least once, because it wouldn't make sense to think of a recipe tailored to a mob that you aren't familiar with.


ListView::set_model() takes the wrong type

According to https://developer.gnome.org/gtk4/3.98/GtkListView.html#gtk-list-view-set-model
ListView::set_model() should take a ListModel, and then if it's not a SelectionModel, it should wrap it in a SingleSelection.
Currently, it only takes a SelectionModel.

You're looking at an old version of the docs. See https://developer.gnome.org/gtk4/stable/GtkListView.html#gtk-list-view-set-model. It does require a SelectionModel.
You're supposed to use gtk::NoSelection


Added option to send updates to attendees

As response to issue #50. Adds option to send updates to attendees for all methods supporting sendUpdates and currently implemented in gcsa.
Open points for discussion:

Location of the class encapsulating the values: Currently at the top of google_calendar.py
Default value: Currently "None". No explicit default given in docs, but google behaves that way currently apparently.
No tests added yet, as I couldn't identify a matching testing infrastructure

Thank you for the PR. Very appreciated. One small change is required. Apart from that, looks perfect. Will merge it and add appropriate documentation, when I have time.

Adjusted to use snake case, which it really should have been initially :)


Working directory tree highlighting

Hi @isagalaev,
Probably, this purpose will not be provided by highlight.js since it deals with concrete language definitions. Considering this case, we just created a new language definition for tree structures. Perhaps, anyone can make use of it and contribute: https://github.com/asciidocfx/highlight-treeview.js

Looking deeper this cannot be simply merged now due to data URLs for icons. Maybe we can come back after styles reorganisation in #348.

Just to confirm, I also think it would be useful to have it as a language: people do often display directory structures along with code snippets. I don't have an easy solution as to where put those icons either. They probably have to live in a separate style and we could document it somewhere.

Yes, we can look how this language looks without any styles and make decision.
Anyway, I'll not close any issues with on hold label.

So… I was thinking about this idea lately and it still feels to me like a bit of a stretch to bundle a very special case with a very special CSS along with the library. So I think we could just live with it being a nice derivative project until a better idea comes up.
@ozlerhakan thanks for doing this anyway!


Added proper formatting for different currencies.

CHF: The thousands- separator should be an apostroph ' not a comma , see eg.
http://www.thefinancials.com/Default.aspx?SubSectionID=curformat
SEK: The decimal should be a comma , and thousand should be a dot .
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/
http://www.thefinancials.com/Default.aspx?SubSectionID=curformat
CZK: The decimal should be a comma , and thousand should be a dot .
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/
LTL: The decimal should be a comma , and thousand should be a dot .
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/
NOK: The decimal should be a comma , and thousand should be a dot .
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/
PLN: The decimal should be a comma , and thousand should be a dot .
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/
DKK: The decimal should be a comma , and thousand should be a comma ,
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/
RON: The decimal should be a comma , and thousand should be a dot .
https://www.edufukunari.com.br/en/world-currency-formats-iso-4217-information/

+1

As a library user, I think that is a great improvement to the library but I believe it is missing tests covering the changes.


Enable Download of Export Template Results Via API

As ...
Nelly - Network Engineer
I want ...
The capability to download the generated results of an Export Template formatted file via the API.
So that ...
I'm able to programmatically retrieve a pre-formatted list of object information without having to go into the UI.
I know this is done when...
I'm able to query the API and download the results of a preconfigured Export Template.
Optional - Feature groups this request pertains to.

[ ] Automation
[ ] Circuits
[ ] DCIM
[ ] IPAM
[ ] Misc (including Data Sources)
[ ] Organization
[ ] Plugins (and other Extensibility)
[ ] Security (Secrets, etc)
[ ] Image Management
[X] UI/UX
[ ] Documentation
[ ] Other (not directly a platform feature)

Database Changes
I don't think this should require database changes.
External Dependencies
No response

Similar to FR https://github.com/nautobot/nautobot/issues/2225

2.1 moves csv and export templates to a system job. We will use this story to support retrieval of those files over the jobs API.

Implemented for 2.1 by #4860


Question: is there any version of this wrapper that supports iOS 9?

Is there any version of this wrapper that can be used on iOS 9? I know that version 4 SDK will not be supported soon but our application needs to support iOS 9.

Hi, the minimum supported iOS version for the V5 SDK is iOS 10.0, therefore the wrappers also have a minimum SDK version of iOS 10.0.

@nporter-adbe Ok, thank you. We managed to implement the solution that still allows to use this wrapper, even if the target platform is iOS 9. I think it might be useful for others that struggle with the same issue. Do you think it is worth documenting this, e.g. in the README file or should I rather add a comment with the description?

It's currently documented in the README and in the official docs several times.

The AEP SDK's require at least iOS 10.0 to function properly. If you see this error, ensure your Podfile specfies at least iOS 10.0.

https://aep-sdks.gitbook.io/docs/resources/upgrading-to-aep#upgrade-checklist
https://aep-sdks.gitbook.io/docs/resources/frequently-asked-questions#what-os-and-platform-versions-are-supported

@nporter-adbe I think I wasn't clear enough. I understand that SDK requires at least iOS 10 but we managed to install it (of course not use it) on device with iOS 9. Our requirements is that for iOS 10 and above, SDK is available but below is not. However, you need to install SDK also for iOS 9 which gives you an error. We found the solution for that which might be useful for others.

Hi @Olgagr  - Good to see that you were able to get this to work with iOS 9. As @nporter-adbe mentioned we do not have any official support for iOS 9 with the latest SDKs, and while there may be workarounds, we would not wish to promote this. Thanks!


Print msg timestamp

Example print message timestamp

Thank you for creating a PR. I will take a look tomorrow late night

@24seconds  i ran fmt. sorry i used default format in my editor

@24seconds  next task ?

@docongminh #126 or #138 ?


Add timeout to the client

There didn't seem to be an existing way to pass a timeout on to the underlying requests calls so I've added a constructor argument to set the timeout

Coverage increased (+0.01%) to 97.382% when pulling 89126ce7f3f254de75bc4daab9590d8c0567054b on meadsteve:feature/timeouts into 727b01afe8ea42dcf3db2c08c6072b022090c5f7 on Nexmo:master.

@meadsteve thank you very much for your contribution!!

@superdiana thanks for the quick merge 👍  How often do you normally do a release from master? Is the next release planned yet?

@meadsteve there's a release coming very soon with some exciting changes, I don't want to promise a date but it's in the approval process!. As the person in charge of the SDK I love contributions like yours, I would also love to know what specific features would you like to see?

that's good to know. Thanks. So the reason for actually adding this timeout is that we're writing a health_check so we can be sure our connection is working. Not sure if this is something that you'd want to generalise into the SDK (otherwise I'm happy to PR that as well). We're doing something like this at the moment:
class ClientWithHealthCheck(nexmo.Client):
    def health_check(self) -> bool:
        # If our connection to the service is healthy we should be able to ask it for the numbers
        try:
            account_numbers_response = self.get_account_numbers()
            return account_numbers_response["count"] > 0
        except:
           return false

This is interesting. I think it's a very specific feature but we could consider it, would love to see that PR!. Again, we love contributions from the community and we are super grateful for your time and effort!

@superdiana looks like the timeout code added in this PR is gone from master? Should I open another PR or is there a reason it doesn't make sense for nexmo?

(or was it broken 😆 )

Yikes, this was merged aaaaaages ago. Let's open it again!

@alphacentauri82 yeah it was removed after merger here: https://github.com/Vonage/vonage-python-sdk/commit/502914137310ca726c0973cf64447efb123bc8c4#diff-449916119c7f4d767a4c1973a045ab71 I wasn't sure if there was a good reason or if it was just an accident


Line 143, corrected command

Namespace name is case sensitive. Changed the namespace name from "Velero" to "velero" in line 143.

@msubhro Thank you for the contribution! #sign-off


Interpret empty-strings as null, in string arguments.

For first-level task arguments, this is correct (as in #203).
For nested objects it also will work, but let's review it:

I have a list[str] argument, with two non-empty values: x = ["aaa", "bbb"].
In the input form, I replace "bbb" with an empty string.
fractal-web transforms the empty in null
I click save, and ajv validation will fail, because x = ["aaa", null]

This may be annoying for the user, but the reason is that the correct way of removing bbb is to click the "remove item" button, so that the list becomes x = ["aaa"].

Same for dict[str,str].
Say we start with x = {"key": "value"} and replace "value" with "", which is then transformed into null. This leads to the same behavior as in the previous comment.


Add mouse/keyboard resizing of views

My proposal:
Tiled Mode:
Mouse:

Dragging Border top or bottom resizes the view vertically
Dragging Border left or right resizes the view horizontally

Keyboard:

Hit Ctrl-F10 to enable drag/resize mode
A line will get a ◊ indicating it's active for resizing. Left/Right/Up/Down will size.
Tab to move to next line
Shift-Tab to move back
Ctrl-F10 to exit drag/resize mode

Overlapped mode:
Mouse:

Dragging Border top moves the view
Dragging Border bottom resizes the view vertically
Dragging Border left or right resizes the view horizontally

Keyboard:

Hit Ctrl-F10 to enable drag/resize mode
A line will get a ◊ indicating it's active for resizing.

If the selected line is Border top, then Left/Right/Up/Down will move the view.
If the selected line is Border bottom, left, or right, then Left/Right/Up/Down will size.

Tab to move to next line
Shift-Tab to move back
Ctrl-F10 to exit drag/resize mode

This needs to fix #2536 too

Y'know, I like the idea in general, but I'm personally not thrilled about those spinners in particular.  I feel like one of these might be better (if not perfect).
2 frames, horizontal and vertical:

3 frames, horizontal and vertical:

@BDisp this is another Issue related to #2994

If one of the goals of this feature is to support TGD resizing use cases then I think that the solution needs to be decoupled from Borders.
It must be possible to drag and resize any view (regardless of whether it has a Border).  For example:

It also needs to be possible to drag multiple views at once e.g.

The relevant code in TGD is in:
MouseManager
DragOperation
DragMemento
ResizeOperation

If one of the goals of this feature is to support TGD resizing use cases then I think that the solution needs to be decoupled from Borders.
It must be possible to drag and resize any view (regardless of whether it has a Border). For example:

It also needs to be possible to drag multiple views at once e.g.

I'll start thinking about this...
I can't see anything really challenging, but it will require some thought...
Are you interested in collaborating with me on it?

Are you interested in collaborating with me on it?

Definetly! lets see what we can do.

Drag
Drag Phases (i.e. State)
In order to support Undo and other stuff (like cancelling an ongoing drag) I think we should keep state in the same way TGD does with DragOperation and it's DragMemento:

Only one drag operation can be running at once
Use ContinueDrag style

So the process is:
// Establishes the origin from which all vectors are measured
StartDrag (x,y)

// Updates positions of Views, each vector replaces the last (i.e. they are not additive)
ContinueDrag(new Vector(2,5))
ContinueDrag(new Vector(3,5))
ContinueDrag(new Vector(4,5))

// View is moved to x+4 y+5 and drag state is cleared
EndDrag()

Drag Multiple At Once
TGD lets you select multiple views with a selection box.  I think this can be left in TGD.  But we do need the ability to drag multiple views at once.
For sanity sake probably we should require that all views in a multiple drag should be in the same parent View.
Drag Boundary
When a drag results in some/all of a view spilling out of it's parent:
    /// <summary>
    /// True to allow dragging a view such that part/all of it is
    /// outside of its parent View's viewport
    /// </summary>
    bool AllowDragOffscreen;

Drag Initiation
There are 3 options for a View when it comes to initiating a drag
enum Dragability
{
    /// <summary>
    /// View cannot be dragged
    /// </summary>
    NotDraggable,

    /// <summary>
    /// View can be dragged by clicking and dragging at row 0 of
    /// the view.
    /// </summary>
    DragFromTop,

    /// <summary>
    /// The view can be dragged by clicking and dragging anywhere
    /// in the view
    /// </summary>
    DragFromAnywhere
}

Drag into another View
This is an opt in feature.  It could be a global value or View specific.  But if it is tied to Views then it makes multiple view drags more complicated.
bool AllowDragToOtherViews;

To support dragging a view into another view we must think:

Does it make sense to drag a view into a Button (probably not)
Does it make sense to drag a view into a FrameView (yes)

So we need some kind of confirmation probably an event with a Cancel member is easiest
event EventHandler<DragEventArgs> EndDrag;

internal class DragEventArgs
{
    /// <summary>
    /// Describes the views being moved and where they are being moved to
    /// </summary>
    public DragOperation DragOperation { get; }

    /// <summary>
    /// Set to true to abandon the <see cref="DragOperation"/> and return
    /// all views to original positions
    /// </summary>
    public bool Cancel { get; set; }
}

Composite views
Some views have sub views that complicate click and drag.  For example TabView.  We need something more structured than the current hacky implementation I have:
/// <summary>
/// <para>
/// Sometimes <see cref="View.FindDeepestView"/> returns what the library considers
/// the clicked View rather than what the user would expect.  For example clicking in
/// the <see cref="Border"/> area of a <see cref="TabView"/>.
/// </para>
/// <para>This works out what the real view is.</para>
/// </summary>
/// <param name="hit"></param>
/// <returns></returns>
public static View? UnpackHitView(this View? hit)
{
    if (hit != null && hit.GetType().Name.Equals("TabRowView"))
    {
        hit = hit.SuperView;
    }

    // Translate clicks in the border as the real View being clicked
    if (hit is Border b)
    {
        hit = b.Parent;

    }

    // TabView nesting of 'fake' views goes:
    // TabView
    //   - TabViewRow
    //   - View (pane)
    //     - Border (note you need Parent not SuperView to find Border parent)

    if (hit?.SuperView is TabView tv)
    {
        hit = tv;
    }

    return hit;
}

A few years ago I was interested in implementing mouse/keyboard drag and drop and resizing. Then I lost the will to continue.
Indeed, @tznind is right in stating that some of the features only make sense in TGD, otherwise any user could create another IDE very easily if TG already provides it. For example, it doesn't make sense that a TextField can be resized or moved in TG, but only in TGD. Drag from FileDialog to a TextView is valid in TG to open a file but in TGD it is moving the FileDialog to the limits of the TextView. Drag from ListView over the selected item to a TextField is valid in TG, and a ContextMenu can be opened to choose to copy or move the item, but in TGD it is moving the ListView to the limits of the TextField, or possibly linking the TextField.Text with the selected item.
In fact, the resizing and movement of a view must be decoupled from the border and only be coupled to the limits of the frame for resizing and within the limits of the frame for movement. In TG, only views that need to be resized and movable, their code must be overwritten in the border. In TGD the behavior will be normal, activating the necessary properties to be able to use them.
In TG, by default, a view cannot be resizable or movable, but only in some derived classes, such as Window and Dialog, if they are configured for that purpose. If it is resizable then a border must exist in order to select the appropriate glyph on either side of its limits. If it is simultaneously movable, in addition to the border, the thickness of the top of the border must be at least two, which will allow the view to be moved if the mouse is placed from the second thickness.
I'm glad this is being debated and will be very relevant for the advancement of this resource.

Good stuff.
Not a lot of thoughts so far. But one...
Add a flag to Arrangement:

DesignMode

When set, effectively hides the Viewport from the mouse hit test code. Thus press and drag anywhere from Border-in works. Even if Border thickness is 0.

Also, look at Highlight/HighlightMode. Can be extended to be combined with Arrangement.DesignMode to enable the whole view to be highlighted.

But it would be useful if Arrangement.DesignMode was only visible internally, therefore only to TG and TGD.

But it would be useful if Arrangement.DesignMode was only visible internally, therefore only to TG and TGD.

Why would we not want someone else to build a design-time tool like TGD?

Why would we not want someone else to build a design-time tool like TGD?

I thought you wanted TGD exclusivity that belongs to gui-cs. If that's not the case then I take back what I said.

It sucks so much for us that every platform and use tha forces us to have to have a "driver" to jump through different hoops to make this all happen. 😤
It's things like this that make libraries like TG so damn nice to use - abstracting away all the BS so the consumer can have a more consistent experience without worrying about it.
/gripe 😆

In #3705 we now have this:

FWIW, this model supports Views without a Border.
Right now mouse doesn't work when in "Arrange Mode", but it willl....

And now....
We have full mouse move/resize capability!


[BUG] Cannot Click on the Deck

I have noticed that after I  finish going through a deck, I can't click on the deck again to go back through. I have to exit out of the plugin and reload it. It is the same on my Macbook and iPhone. It seems to be a bug.

I have encountered the same issue, unable to click on the deck to access the cards.
https://github.com/st3v3nmw/obsidian-spaced-repetition/assets/41268511/befec5f0-aa6b-477a-a60a-aebb75111548

I'm also unable to click on the deck. Updating Obisdian to version 1.4.5 seems to have caused this issue.

I found that it is only possible to open a deck by clicking right on the deck title, not on the free space of the row.

https://github.com/st3v3nmw/obsidian-spaced-repetition/assets/5498095/b6847c04-3f8c-48e6-b9d3-579291d98dfc
I'm having issues even when clicking directly on the text like @Dima2014 mentioned. My Obsidian version is 1.4.5. My plugin version is 1.10.1.

@manthonygfp FWIW I am on Obsidian 1.4.13 and I can review by clicking directly on the text, thanks @Dima2014 for the tip. Still think this is a bug that should be addressed though.

The deck wasn't opening until I clicked on the text. Thanks for the tip, I hope this will be improved for better user experience

Also experienced this problem in Version 1.4.14 (Installer 1.4.14) and I didn't think to click the text because the entire box around the deck row element highlights, so I was clicking that empty space. Version 1.4.14 (Installer 1.4.14).

Hi @Jls0948
This has been fixed in the latest release 1.10.2.
Please update to the latest version of the plug-in, and if all good, close off this issue report.
Cheers
Ronny

Thanks! I'm not the original reporter of the issue, but updating to the latest release does fix the bug for me.


⚠ Not building

I noticed that the project does not build correctly 🥲
rmarkdown::render_site(encoding = 'UTF-8')

I'm trying to load dependencies. While doing that, I'm having a hard time installing ggtext
Error: package or namespace load failed for ‘png’ in dyn.load(file, DLLpath = DLLpath, ...):

It looks like png cannot be installed. I understand that the system dependency libpng should be installed. I checked that I have it on my system (brew install libpng), but then it's still not working..
⏭ Continuing investigation
Full Error Message

Error: package or namespace load failed for ‘png’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/opt/homebrew/lib/R/4.4/site-library/00LOCK-png/00new/png/libs/png.so':
  dlopen(/opt/homebrew/lib/R/4.4/site-library/00LOCK-png/00new/png/libs/png.so, 0x0006): symbol not found in flat namespace '_png_create_info_struct'
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/opt/homebrew/lib/R/4.4/site-library/png’
Warning in install.packages :
  installation of package ‘png’ had non-zero exit status
ERROR: dependency ‘png’ is not available for package ‘gridtext’
* removing ‘/opt/homebrew/lib/R/4.4/site-library/gridtext’
Warning in install.packages :
  installation of package ‘gridtext’ had non-zero exit status
ERROR: dependency ‘gridtext’ is not available for package ‘ggtext’
* removing ‘/opt/homebrew/lib/R/4.4/site-library/ggtext’
Warning in install.packages :
  installation of package ‘ggtext’ had non-zero exit status

The downloaded source packages are in
	‘/private/var/folders/8_/mprzk_0s30zdd_nsbz55rzpc0000gn/T/RtmpUoi4A9/downloaded_packages’


Sub button click on slider moves the slider value

For any feature request you can open a new discussion here:
https://github.com/Clooos/Bubble-Card/discussions/categories/feature-requests
For any question you can open a new discussion here:
https://github.com/Clooos/Bubble-Card/discussions/categories/q-a
Describe the bug
When you have a slider type button and have sub buttons in it, clicking the sub button also bubbles up the event to the slider and changes its value.
To Reproduce
Steps to reproduce the behavior:

Create a new button with type slider
Add a sub button
Click on the sub button

Expected behavior
Clicking a sub button performs the sub button action and does not move the slider.
Thank you! 🍻

Hi and thank you for the feedback, you are the fourth to open this issue 😅
But I'm already on it, I will release a new version really soon!

Ah, sorry. I should have searched first. I'll close this issue if there are other's existing.
Loving the project, great work!

This issue is now fixed!
https://github.com/Clooos/Bubble-Card/releases/tag/v2.2.1


Update servers docs from RC1 to RTM (Part 2)

https://github.com/aspnet/Docs/pull/1633 somehow got reverted. This is just a rebased version of that.

@halter73 can I merge this?

Absolutely.


[HTML5] Type not found : js.html.webgl.Texture

Compiling project in HaxeDevelop or cmd openfl test html5 gives me this:
C:/HaxeToolkit/lime/3,2,1/lime/graphics/opengl/GLTexture.hx:18: characters 20-41 :
Type not found : js.html.webgl.Texture

OpenFl 4.2.0
Lime 3.2.1
Haxe 3.3.0

Sounds like this issue https://github.com/HaxeFoundation/haxe/issues/5577

Yes indeed, file is missing. Just reinstalled haxe - and it works. Thanks!


[REQ] Add a (GH-compliant) license file

Hi there, 1st of all thanks for this awesome work !
Since we've 'doxed' it in our HyMPS project (under AUDIO section \ AI-based category \ Enhancers page \ Aligners), can you please add a GH-compliant license file for it ?
As you know, expliciting licensing terms is extremely important to let anyone better/faster understand how to reuse/adapt/modify sources (and not only) in other open projects and vice-versa.
Although it may sounds like a minor aspect, license file omission obviously causes an inconsistent generation of the relative badge too:

(badge-generator URL: https://badgen.net/github/license/yoongi43/music_audio_enhancement_conformer)
You can easily set a standardized one through the GH's license wizard tool.
Last but not least, let us know how we could improve - in your opinion - our categorizations and links to resources in order to favor collaboration between developers (and therefore evolution) of listed projects.
Hope that helps/inspires !

Bump (request updated).


appbundle release build is crashing on stable versions 1.17.0 and 1.17.1

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel unknown, v1.17.0, on Mac OS X 10.15.3 19D76, locale en-US)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
[✓] Android Studio (version 3.5)
[!] VS Code (version 1.45.1)
    ✗ Flutter extension not installed; install from
      https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[!] Connected device
    ! No devices available

! Doctor found issues in 2 categories.

I'm probably experiencing the same bug.

My app crashes when I launch apk with emulator

Hi. @abuzarsaddiqui
can you please provide your flutter doctor -v and flutter run --release?
Also, to better address the issue, would be helpful if you could post a minimal code sample to reproduce the problem
Thank you

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, minimal reproducible sample code (if related), logs and the output of 'flutter doctor -v'  please.


Address at University of Missouri breaks in all sorts of ways

Address: 115 Business Loop 70 w, Mizzou North, Rm 501 Sponsored Programs Administration Columbia MO 65211
There's a few things going on here:

Directional words in the recipient cause the recipient to be parsed as a street name (see also: Kanye West, 1234 Main Street)
Possibly because of 1, 115 and 70 are both parsed as street names (this doesn't seem to happen if 'Mizzou North' is removed)
"Sponsored Programs Administration Columbia" is parsed as the PlaceName.

Address was found on the SAM.gov website:
https://www.sam.gov/portal/SAM/?navigationalstate=JBPNS_rO0ABXdcACJqYXZheC5mYWNlcy5wb3J0bGV0YnJpZGdlLlNUQVRFX0lEAAAAAQApdmlldzoyM2E4MjAyMS1iOGVhLTRjYTYtOTk3NC02MjM4YWU1OWU0Y2UAB19fRU9GX18*&portal:componentId=7b9b1ff4-9b43-460c-9313-a2fabdc07366&interactionstate=JBPNS_rO0ABXdGABBfanNmQnJpZGdlVmlld0lkAAAAAQAlL2pzZi9lbnRpdHlTZWFyY2gvZW50aXR5U2VhcmNoTmF2LmpzcAAHX19FT0ZfXw**&portal:type=action##11

I'm not sure I know what the true parsed result should be - what should Mizzou North be labeled as?
Also, can you describe how to get to that address, or other addresses, on the SAM.gov website? The link goes to a generic about page.

Howdy-
Yeah, I'm not sure how Mizzou North should be parsed either, to be honest. This address is all sorts of messed up. That said, it led me to discover that directionals in the recipient name also break (try Kanye West) (on further inspection, this maybe only happens with a comma after the recipient name ('Kanye West 1234 Main Street' works, but 'Kanye West, 1234 Main Street' doesn't).
The fact that the parser not knowing what to do with 'Mizzou North' breaks the parsing of the preceding portion was interesting to me, as well.
Sorry about that link, I didn't think to check it before pasting. Their links don't seem to work that well. I actually got it from the SAM API (http://gsa.github.io/sam_api/sam/) using DUNS number 153890272, but you can also find it by going to sam.gov, clicking Search Records, searching by DUNS number 153890272, clicking "View Details", and then "Entity Record".
Mizzou North seems to be the name of the campus, so I'm not sure why it's even needed in the address (it likely isn't).
Hope that helps! This library is awesome, BTW! Thanks for the awesome work!

looks like Mizzou North is the name of a building: https://www.google.com/maps/@38.9672964,-92.3393151,313m/data=!3m1!1e3
this is a good example for teaching the parser, I'll add it to the training data. thank you!
re: directionals in the recipient name, it's tough to do anything about it w/o examples from real data to train on. a directional near the beginning of an address is still much more likely to be a street direction than a recipient, so let's table this for now.

also, keep us posted if you encounter more weird addresses from the SAM API! this looks like a great potential source of messy addresses


Concourse allows a numeric tag value to be uploaded in config, but can't use it when running tasks

I'm using the image_resource attribute in my task, to define its docker image. I specified the tag: 1.4 in my yaml. This appears to have been uploaded to concourse as a number, without causing any issues. However, when I tried to run the task, I get the below error about the tag being a number, and not a string.
I feel like this should either JustWork(tm), or error when fly uploads the config, indicating that the value needs to be a string. I'd prefer that it JustWork.
resource script '/opt/resource/check []' failed: exit status 1

stderr:
failed to read request: json: cannot unmarshal number into Go value of type string

Maybe this issue/fix belongs in the docker-image-resource repo instead?

Yeah, this is an issue solely with the Docker image resource. You can also just open issues on concourse/concourse.

consolidating this into https://github.com/concourse/docker-image-resource/issues/43


maxDuration doesn't seem to work

I used the following code to try to ramp up a bunch of users, let users reach maximum and maintain that request per second level for a while:

setUp(scn.inject(rampUsersPerSec(10) to(200) during(1 minute))).protocols(httpProtocol).maxDuration(5 minutes)

and it doesn't seem to work. So how does maxDuration work and when it takes effect? Instead of the test running for the expected 5 minutes, it completes in 1 minute.
then I tried to following as shown in your example:

setUp(scn.inject(rampUsers(200) during(1 minute))).protocols(httpProtocol).maxDuration(5 minutes)

again, the simulation finished in 1 minute instead of the expected 5 minutes.

From maxDuration's documentation:

It is useful if you need to bound the duration of your simulation when you can’t predict it.

maxDuration abruptly forces a run to terminate on a time limit, even though virtual users are still running.
It doesn't make your run last longer.
Virtual users lifespan is determined by their scenario.


Dssp and hover name

Reference Issues/PRs

Fixes #171 (was not properly fixed by #172 )

What does this implement/fix? Explain your changes

Includes refactoring of g.graph to always include the parameters "name", "pdb_code", and "pdb_path".
adds hover titles to the correlation graphs, so that we know which residue we are looking at.

Rational for refactoring:
Before this PR, after we read a pdb and make a DataFrame out of it, as far as I know, we didn't save the original path to the pdb in the graph metadata. This is why previously, once we wanted to get the dssp features of a local pdb, we ran into problems as long as the structure was not in the pdb_dir. I wanted to make G.graph always contain the following three separate parameters from here on out: name, pdb_code, pdb_path. This way, when pdb_code is not None, we know we have a pdb from the protein database (and can also use download_pdb(pdb_code) etc.); Otherwise, we know are dealing with a local pdb and we keep the path to where it was originally stored.
It is important to note that the pdb file might be moved after a graph was generated, therefore yielding a dead pdb_path.
For getting dssp features, this PR also provides the option to provide a new pdb_path in such a case.
What testing did you do to verify the changes in this PR?
I ran the Jupyter notebooks from the protein tutorials as well as my own local pdb + dssp graph conversion workflow and it all works.

Codecov Report

Merging #176 (167b5e2) into master (8123f42) will increase coverage by 8.76%.
The diff coverage is 56.38%.

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
+ Coverage   40.27%   49.03%   +8.76%
==========================================
  Files          48       74      +26
  Lines        2811     4264    +1453
==========================================
+ Hits         1132     2091     +959
- Misses       1679     2173     +494

Impacted Files
Coverage Δ

graphein/grn/parse_trrust.py
37.77% <ø> (ø)

graphein/ml/diffusion.py
0.00% <0.00%> (ø)

graphein/ppi/edges.py
100.00% <ø> (ø)

graphein/ppi/graph_metadata.py
0.00% <ø> (ø)

graphein/ppi/graphs.py
54.34% <ø> (ø)

graphein/ppi/parse_biogrid.py
75.00% <ø> (ø)

graphein/ppi/visualisation.py
0.00% <0.00%> (ø)

graphein/protein/analysis.py
0.00% <0.00%> (ø)

graphein/protein/features/sequence/sequence.py
71.42% <0.00%> (+2.67%)
:arrow_up:

graphein/protein/features/sequence/utils.py
28.00% <0.00%> (+3.00%)
:arrow_up:

... and 59 more

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 dcf294f...167b5e2. Read the comment docs.

Would you like me to me to also add a test for dssp with both a pdb code a local pdb structure?
I could also add the show_edges visualization from #167 to the corresponding notebook while I'm already on it.

I think a test & example of the edges in the asteroid plot would be great :)


Erratic click handling

Consider the use of d3-zoom in combination with a click handler. The zoom is called on the SVG and manipulates a g's transform attribute. There is an element that responds to a click.
The problem is that not every click is being processed. See this minimal example. Move the mouse a little between clicks. You will see that the circle is not pulsing for every click which it should. Without d3-zoom, there is no problem. However, for me, if I do not move the mouse between clicks, everything is fine.

Duplicate of #65.

Well, OK. I have tried capturing mousedown, mousemove and mouseup and haven't captured a mousemove after the mousedown but maybe they have been stopped by the zoom behavior.


How do I run this?

There's no instructions, and I'm not familiar with this type of project.

Nvm, I downloaded the zip from releases and that has an exe file.


Add setting to toggle device reported warning levels

Some devices don't report warning levels, so default to using percentage-based warning levels

Add a setting to enable device reports so those with supported devices can use those reports

Closes #48

Currently, I haven't tested both paths still work with devices at low battery. None of my devices are low enough right now to trigger the code paths properly, so I'll test in the evening :)


Audit xplat target changes

We've made some changes to .props and .targets files that ship with MSBuild in the xplat branch. Many just conditionalize behavior based on engine runtime--those are probably fine. But there shouldn't be any changes to standard desktop builds, unless they're intentional and correct.

Marking this as complete: we shipped VS2017 RC from the xplat branch and haven't yet seen any break-the-world changes. We believe the way forward is to fix any problems that we discover in xplat, rather than revert to the two-branch world.


Bug: Auth on beta.hot.opensauced.pizza is broken

Describe the bug
https://github.com/open-sauced/hot/assets/79809121/2e559966-c960-439e-afec-8fc3b9dee6f7
Steps to reproduce

Visit beta.hot.opensauced.pizza
Click on the signing button

Browsers
Chrome, Firefox
Additional context (Is this in dev or production?)
The variables in the .env file must be outdated I think :thinking:
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Contributing Docs

[ ] I agree to follow this project's Contribution Docs

https://github.com/open-sauced/landing-page/issues/135#issuecomment-1662665880
this could also work here so there will be only one supabase authentication set up (which will be in the insights repo)


gc: config gc io limit dynamically (#5769)

Signed-off-by: youjiali1995<EMAIL_ADDRESS>
What have you changed?
Cherry pick #5769

/run-all-tests

/merge

@AndreMouche Merge failed.

@AndreMouche

/merge


python3Packages.python-gvm: 21.6.0 -> 21.10.0

Motivation for this change
Update to latest upstream release 21.10.0
Change log: https://github.com/greenbone/python-gvm/releases/tag/v21.10.0
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.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.

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

4 packages built:

gvm-tools (python39Packages.gvm-tools)
python38Packages.gvm-tools
python38Packages.python-gvm
python39Packages.python-gvm


10.0.0-beta.1 componentWillUnmount does not fire when using Preact.render() with replaceNode

When calling preact.render() with the third optional replaceNode argument, re-rendering over a component does not call the componentDidMount lifecycle hook.
Consider the HTML:

I want to change what component is rendered in the #component div, and because our app is not 100% preact, we use a separate call to preact.render to swap out the components.
First render ComponentA:
render(<ComponentA />, document.getElementById('app'), document.getElementById('component'));
Resulting in:

I am ComponentA

Sometime later render over ComponentA with ComponentB:
render(<ComponentB />, document.getElementById('app'), document.getElementById('component'));
Which does actually render correctly resulting in:

I am ComponentB

But ComponentA did not call componentWillUnmount before it was overwritten. In my specific case this causes a setInterval to go uncleared, and results in some strange behavior when that interval continues to be called.
I have a codesandbox  which shows the behavior more clearly: https://codesandbox.io/s/preactwillunmountbug-fi1d5
If you open a console and click the Overwrite clock doesn't call willUnmount button you will see the interval continue to log statements into the console. At first the clock isn't present, and then it gets appended next to the other placeholder component, I think as a result of the call to setState inside the interval.
If you instead click the Unmount clock calls willUnmount button you will see the unmount functional runs and the interval is cleared.
It was my expectation that both of these methods of overwriting a component with another should result in the same behavior.

@LukasBombach I saw your nicely documented PR here https://github.com/developit/preact/pull/1557
It seems like we are using very similar use cases, I was wondering if you are rendering with something similar to this strategy? I thought you might have some good thoughts since you were just in this code and have a similar use case!  Thanks!

Hey,
First, I want to thank you for your thorough research and comprehensive reproduction.
I have looked into this a bit and found that the problem is probably caused here: https://github.com/developit/preact/blob/master/src/render.js#L24
When using replaceNode we disregard the previous dom meaning our diffing can't know what to unmount and what it shouldn't.

@1campbellj I am currently writing on a lengthy medium article about this which I hope to publish today. Along with the article I have implemented a working proof of concept that does partial hydration with preact and next.
You can already check out the repo here: https://github.com/spring-media/next-super-performance

Nice fix

Here it is: https://medium.com/spring-media-techblog/how-we-achieved-the-best-web-performance-with-partial-hydration-20fab9c808d5


Correct specification of getGroupByUUID () method is to ignore the Root group?

	@Test
	public void testGetGroupByUUID(){
        final KeePassFile keePassFile = new KeePassFileBuilder("testDB").build();
        Assert.assertEquals(keePassFile.getGroupByUUID( keePassFile.getRoot().getUuid() ), keePassFile.getRoot());
	}

The very basic root group will never be returned because it does not make any sense to modify this group.


Debug remix-test

It would be nice if we could debug remix-tests

what do you mean by that - isn't already possible?


Add search to Settings

Add Search field only to main Settings screen https://zpl.io/bzjKoJ8

Search result highlight with blue color https://zpl.io/40y08A8

Search by ...

3.1) setting title (notifications, privacy, utilities,. etc - I guess this is relevant only for node.. but if a user wants to search "privacy" let's show it as result also)

3.2) parameters titles (show amounts in, minimum confirmations, ask for password, show utxo etc)

3.3) parameters value that set

Search by setting title and parameter https://zpl.io/EmEmrKy

Search by parameter https://zpl.io/40y08A8

Search by parameter value https://zpl.io/mDKDQ99

No results. If user search by parameter value that not set https://zpl.io/B1o1rRQ

From the search results screen user go to the inner screen (in this case it is a node). Then when he wants to get back and click the arrow it goes to the search results screen back.

Please make the text italic

Checked