text:
A piece freezes sometimes on the wrong square and does not return

Happens occasionally but repro still unknown. Looks like logically the piece is returned to its original square (when a move is not completed) but it stays in the GUI in the wrong spot (after the MouseUp event.)

Diagnosed to situations where the Mouse Down event was received while OnMouseUp was still processing. The fix rejects MouseDown under such circumstance.

source: gharchive/issue

repo: czbar/ChessForge

license: MIT

license_type: permissive

license_source: github-api


text:
Performance problem

Hello! I'm using the component in a project, but I'm having performance issues.
In an editing scenario, I have to initialize the destination list with the chosen elements in the register. I am having problems initializing, when the target list has more than 1500 elements. Pretty much my system stops working.
Any idea what might be causing this?

Yes, I did not predict that this component would be used with arrays that big!
The problem is that trueUp is, politely put, inefficient. It iterates over every item in the confirmed list and then does a array filter on the destination and potentially the source. The way moveItem is written, each time an item is added to the destination, trueUp is called. Thus, this is the performance issue you're seeing.
There is a minor code change that I can make to moveItem that will get at least 10k items in the destination. It isn't instant, but it will work. I'll publish the modification tomorrow if it passes the tests.

Try version 4.3.1 and see if that works better for your use case of more than 1500 elements in the destination list.

I just completed the tests. It has improved considerably. There is a small delay, but it is within the expected!
Thank you very much!

You're welcome. I'll look into further performance enhancements in upcoming releases too.

authors: czeckd danilomcb

repo: czeckd/angular-dual-listbox

license: mit

license_source: bigquery


text:
"Check for Note" opens the note?

I am running a Shortcut that employs the "Check for Note" action. I have noticed that running that action also opens the note being checked…is there a way to turn this off?

Hi @deanpribetic, are you talking about the Actions For Obsidian action? If so: wrong channel, this repo is for the companion plugin only. ;)
That said: I agree it's not desirable. I'll add a toggle to Check For Existence Of Note and Check For Existence Of Periodic Note in the upcoming version!

authors: czottmann deanpribetic

repo: czottmann/obsidian-actions-uri


text:
Add GetMyFeesEstimate functionality

Introduces additional enumeration function for GetMyFeesEstimate parameters (which look like this: FeesEstimateRequestList.FeesEstimateRequest.1.MarketplaceId )
Also adds get_my_fees_estimate function.
Built this to look up one price at a time, has not been tested with a list of prices. Maybe someone can give input on how this can be better, it's quick and dirty.

Would it be possible to provide an example and/or additional info regarding data formats in which the 12 input parameters should be passed to the get_my_fees_estimate function?
get_my_fees_estimate(self, marketplaceid, idtype, idvalue, isamazonfulfilled, identifier, listingprice, shippingcost, currency="USD", shipcurrency="USD", points='0', pointsvalue='0', pointscurrency='USD')
I'm having difficulties trying to use it (for a single item, as the Aug 30 comment mentions), but I might be calling it using wrongly formatted inputs.  For instance, I tried passing in the listingprice and shippingprice as floating point, which resulted in "TypeError: 'float' object is not iterable". I notice inside the enumerate_param_additional function (called by get_my_fees_estimate for each parameter to be sent to the MWS API), the following coded lines appear to depend on every of the 12 different "values" for which it's called being iterable or at least working in enumerate():
for num, value in enumerate(values):
params['%(x)s%(y)d.%(z)s' % {"x" : param, "y" : (num + 1), "z" : partype}] = value
(Btw, I'm using Python 3.4 which might add a complication, but I suspect that even aside from any possible issues of 2 vs. 3, that I might not be providing the intended data formats.)
My code which invokes several other aspects of mws.py is working successfully, including calls to get_lowest_offer_listings_for_asin, list_inventory_supply, and get_matching_product_for_id.
Thank you very much for any tips or explanations!

Thanks for the pr.
Closing as this project is no longer maintained.
Please head over to https://github.com/python-amazon-mws/python-amazon-mws.

source: gharchive/pull-request

repo: czpython/python-amazon-mws

license: unlicense


text:
Clear guidelines for contributors, especially for wrappers

Based on https://github.com/d-gamedev-team/gfm/issues/151 history

Closed because reduced scope in GFM, wrappers are gone.

repo: d-gamedev-team/gfm


text:
🛑 Staging Webhook Public Api is down

In 9acba00, Staging Webhook Public Api ($STAGING_WEBHOOK) was down:

HTTP code: 503
Response time: 357 ms

Resolved: Staging Webhook Public Api is back up in e91b820.


text:
fix: Remove vendored types for core CAPI providers (CAPD, CABPK, KCP)

We do not need to sync the Kubeadm Control Plane or Kubeadm Bootstrap provider types,
because they are developed in the sigs.k8s.io/cluster-api module, which we define as
a dependency.
We also do not need to sync the Docker infrastructure provider types, because they in the
sigs.k8s.io/cluster-api/test module, which is developed in parallel with
sigs.k8s.io/cluster-api. For that reason, we expect no dependency conflicts.

Thank you and sorry for the confusion caused by merging your previous PR.

(Removed some trailing whitespace and force-pushed)

authors: dlipovetsky jimmidyson


text:
SSR에서 navigator 에러 발생하는 문제 해결

seed-design-plugin을 사용할 때 node 환경에서 navigator가 없어서 빌드 에러가 발생했어요.
"navigator" is not available during server-side rendering. Enable "DEV_SSR" to debug this during "gatsby develop".

정확한 문제 해결이 아닌 방향성을 제시하는 차원에서 PR을 생성했어요. (navigator를 호출하는 시점을 조정했어요)

다른 컨텍스트가 없어서 이 방향이 맞는지 다른 문제는 없을지 정확히 검증하지 못했어요.

이 부분은 디자인시스템 팀에서 코드를 검토해주시면 좋겠어요🙏

@carsonmj 해당 pr은 naviagator 삭제로 close 하겠습니당

authors: carsonmj junghyeonsu

repo: daangn/seed-design


text:
Add and document functions for discarding one or other item from a pair

Previously we had (undocumented, internal) functions called prepare_only and project_only. These were ambiguously named and didn't add much value. They have been removed in favour of directly using qs.noop or projectors.noop in a pair.
We now also have a couple of functions for discarding one or other item in the pair. This might seem a bit weird given that they are strictly equivalent to pair[0] or pair[1], but they result in much more readable code because the function name comes before the child spec rather than being an easy-to-miss [0] or [1] tagged on at the end. For example, if you wanted to use select_related instead of prefetch_related for a simple relationship:
spec = [
    "name",
    "dob",
    (
        qs.select_related_fields("favourite_widget__size", "favourite_widget__type"),
        pairs.discard_queryset_function(
            specs.process_item({"favourite_widget": ["size", "type"]})
        ),
    ),
]

Comments very welcome, particularly on:

Naming
Whether this is even necessary at all

I think the whole requirement for this comes about because of the lib insisting on using a two-tuple instead of a richer data structure (such as a named tuple). Having long named functions to get the zeroth or oneth element of a pair seems to me to INCREASE the surface area of the API, and mean there's now two ways to do the same thing to understand... For me, it's not worth it and you should instead change the tuple to a named tuple such that you can go
specs.process_item({"favourite_widget": ["size", "type"]}).queryset

and
specs.process_item({"favourite_widget": ["size", "type"]}).projector

to get the two parts

@pmg103

I think the whole requirement for this comes about because of the lib insisting on using a two-tuple instead of a richer data structure (such as a named tuple).

Maybe, but having functions that operate on primitive data structures is deliberately how I've designed the API here. For me a two-tuple is just not worth turning into a named tuple.

Having long named functions to get the zeroth or oneth element of a pair seems to me to INCREASE the surface area of the API, and mean there's now two ways to do the same thing to understand...

This is fair, and hence the "whether this is even necessary at all" bit of the description. I would be happy to just not bother doing this, but for me having the function name before the thing is more readable than a [0] or [1] at the end.

For me, it's not worth it and you should instead change the tuple to a named tuple

This would be a big change to every bit of the code in the library and would probably break existing client code. If it were a ten-tuple or something then sure, but I personally like the positional nature of the two tuple - it "feels" to me like the second thing depends on the first thing, in a way that it doesn't if we switched to attribute access. It would also actually require two different namedtuples - a QuerysetFunctionAndProducerTuple and a QuerysetFunctionAndProjectorTuple which I think would confuse things even further (this is an implementation detail that is mostly hidden at the moment). I feel like overall the result would be worse.
So I guess it boils down to: assuming we aren't switching to a named tuple, is having these functions better or worse than using [0] and [1] at the end?

Wow so sometimes the two tuple is a queryset and a producer, and sometimes its a queryset and a projector? :bigsad:
So you could call pairs.discard_projector() on a (queryset, producer) to get the queryset, or call pairs.discard_producer() on a (queryset, projector) and it'd work just fine....
This makes me think if you really want to keep it as a tuple as a first class concept, then the client code should access it like a tuple, ie with [0] and [1]. Special functions suggest there's something more going on.

Wow so sometimes the two tuple is a queryset and a producer, and sometimes its a queryset and a projector? :bigsad:

This was of course your idea 😆

This makes me think if you really want to keep it as a tuple as a first class concept, then the client code should access it like a tuple, ie with [0] and [1]. Special functions suggest there's something more going on.

I'm not sure I agree on the tradeoff there. Much of this library already consists of functions operating on tuples or other primitive data structures. I don't think that's anything new or surprising.
Without this change, you have a big spec fragment but right down at the end of it you have a little [1] to say you're discarding the queryset function part. That comes possibly after many lines of spec and so is perhaps easy to miss. With this change, you start the fragment of spec with I AM GOING TO DISCARD THE QUERYSET FUNCTION FROM THIS SPEC, then you have the spec. I find that has big readability benefits.
If I've still failed to persuade you then I'll open a new PR that just removes the internal prepare_only and project_only functions, which I still thing is a valid bit of cleanup.

repo: dabapps/django-readers


text:
BUG: String was not recognized as a valid DateTime

Exception Type: System.FormatException
Message: String was not recognized as a valid DateTime.
The exception occurred at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at Microsoft.Win32.TaskScheduler.Trigger.get_StartBoundary() in C:\Users\dahall\Documents\Visual Studio 2010\Projects\TaskService\Trigger.cs:line 347
at Microsoft.Win32.TaskScheduler.WeeklyTrigger.V2GetTriggerString() in C:\Users\dahall\Documents\Visual Studio 2010\Projects\TaskService\Trigger.cs:line 2798
at Microsoft.Win32.TaskScheduler.Trigger.ToString() in C:\Users\dahall\Documents\Visual Studio 2010\Projects\TaskService\Trigger.cs:line 501
Originally posted: 2016-10-12T13:37:08

Will you post the XML for the task that being retrieved and the Windows version you are on? The error is coming from a method that takes the string from the native library, which is usually in a specific format, and is converting it to a DateTime value. This method should not fail unless Microsoft has done something different in their library.
Originally posted: 2016-10-13T08:07:11

Unfortunately I don't have the XML data, a user simply submitted the exception data to me.
Originally posted: 2016-10-15T09:06:23

I've gone back through the code that handles parsing the StartBoundary and the only explanation I can find for the bug is that the string that the native library returns was in an unexpected format. Without more detail, I have no way to handle that error condition.
Originally posted: 2016-10-17T08:36:43

repo: dahall/TaskScheduler


text:
Request for a new GetTask() method

Is your feature request related to a problem? Please describe.
It's not related to a problem. It's a request for a convenience feature.
Describe the solution you'd like
Could you add a GetTask(Name As String) method to the TaskFolder class. While it's true that we currently have this as a method on the TaskService class, that method requires the full path to the task. TaskFolder.GetTask(Name As String) could be used in cases where we don't necessarily have the full path but we do have a TaskFolder object.
Describe alternatives you've considered
If this isn't feasible, we can always use an extension method.
Additional context
None.

Can you use myFolder.Tasks["TaskName"]?

Hm, I guess I missed that one.
OK, never mind  :-)

Oops, it throws an exception if the task doesn't exist.

Here's my extension method:
Friend Module Extensions
  <Extension>
  Public Function GetTask(Folder As TaskFolder, Name As String) As Task
    Return TaskService.Instance.GetTask($"{Folder.Name}\{Name}")
  End Function
End Module

If you want to make it folder-centric, you could also do
Return Folder.GetTasks(Name).FirstOrDefault()

Yes, I did consider the FirstOrDefault / SingleOrDefault approach, but I didn't want to drag out RegEx for that. (RegEx is far from comfortable for me, I must admit.)

Given that there are multiple ways to accomplish this same task, I'm reticent to add yet another. Of the two approached above, the second (which I proposed) is likely faster. Using a full string with RegEx effectively just does a string compare. By querying from the folder, you reduce the number of tasks that have to be searched.

OK, no problem.

authors: InteXX dahall


text:
PreventShutdownContext does not work.

Describe the bug
PreventShutdownContext does not prevent the user from shutting down the system and no dialog window is shown.
This does not seem a bug, but I think the author must improve its implementation to determine at runtime whether or not using PreventShutdownContext will really prevent the shutdown (and then throw an exception or something when the instance is initialized, this way the end-user can catch it to be aware that the system CAN be shutdown during a critical operation), but for improving that first we should figure why it is not preventing shutdown... and I don't have idea about why it does not.
What code is involved
WIndows.Forms/Contexts/PreventShutdownContext.cs
Expected behavior
You know...
Screenshots
Better than a screenshot:
https://stackoverflow.com/questions/54842853/calling-shutdownblockreasoncreate-function-does-not-prevent-the-user-from-shut

Does this implementation do more of what you'd expect?

Does this implementation do more of what you'd expect?

Thanks for the interest of support, and effort. I assume now the code is better than the previous version, however it does not prevent shutting down on my system even when tryToPreventShutdown is true. Any ideas about why?.

Hey, I started doing a trial-and-error snapshooting in a fresh Virtual Machine with Windows 10 and I discovered what the problem is: If the user has the AutoEndTasks registry value set (found in HKCU\Control Panel\Desktop registry key), then the shutdown does not show any UI to let the user cancel shutdown, so its useless to create a "cancel shutdown reason" in these circumstances because the app will be forced to close instantly in any case to continue the shutdown.
So, in order to make this thing to work as expected, the registry data of AutoEndTasks registry value must be 0 (zero); otherwise any app that attempts to prevent shutdown will be terminated and no UI will be shown at shutdown.
With this info you should determine what to do now with PreventShutdownContext, I mean, if you will check for that registry key o not. This is now sholved for me.
Thanks again.

Thank you for doing that testing and discovery. I'll look at how Microsoft officially supports that value and will add that check to the PreventShutdownContext constructor.

I'll look at how Microsoft officially supports that value

Maybe this is not what you mean for "how Microsoft officially supports that value", but I forgot to share this link with you that maybe could be useful: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978604(v=technet.10)
PD: its all in my commentaries in the linked StackOverflow question.

Note: I discovered that the AutoEndTasks value can be added to "HKEY_USERS.DEFAULT\Control Panel\Desktop", that overrides the value established in HKCU hive and HKU{SID}.
This means, if AutoEndTasks is false (0) in HKCU but is true (1) in HKU.DEFAULT, then the app will not prevent from shutting down and no shutdown UI will be shown.
if AutoEndTasks is false in HKU.DEFAULT but is true in HKCU, then the app will prevent from shutting down and the shutdown UI will be shown.
Also a good point about this is that the AutoEndTasks* value does not require to restart/log-off the system to take effect. So, once it is established to false in the proper key  (HKU.DEFAULT), the app will prevent shut down, and we can revert this value to its previous state when we finish to use the PreventShutdownContext class.
That's all. I also ensured that the disabling of important Window Services will not affect this behavior.

So the class now checks those values and throws an exception if nothing can be displayed (AutoEndTasks == 1). I didn't want to change that value and then change it back as there is no way to lock it to prevent other processes from editing it while the context is live. I didn't want any artificial side-effects. Thanks for pointing this out. It really makes it much better.

authors: ElektroStudios dahall

repo: dahall/Vanara