postgresql: add python support

Can you split this into two commits, one adding the python override to postgres and one adding the option, please?


feat: consistent handling of source map options

This changes the default behavior when handling source-map-related compiler options so that it matches tsc's behavior.
Note that this introduces somewhat of a breaking change: calls to bundle() used to always emit inline source maps — now it only occurs if the option is explicitly set to true.
Closes #105.

Waiting for #98 to be merged.


Traceback KeyError: 'id' on snactor repo link

With leapp-repository installed, I'm trying to create new actor repo and link it with the rest of the world.  This code used to work (with ~ leapp-0.3...):
snactor repo new foo
pushd foo
snactor repo link --path /etc/leapp/repos.d/offline-upgrade
snactor new-actor --tag IPUWorkflowTag --tag ApplicationsPhaseTag MyActor
...

Now the same code fails at the snactor repo link ... line, with this traceback:
Traceback (most recent call last):
  File "/usr/bin/snactor", line 9, in <module>
    load_entry_point('leapp==0.4.0', 'console_scripts', 'snactor')()
  File "/usr/lib/python2.7/site-packages/leapp/snactor/__init__.py", line 68, in main
    cli.command.execute(version='snactor version {}'.format(VERSION))
  File "/usr/lib/python2.7/site-packages/leapp/utils/clicmd.py", line 80, in execute
    args.func(args)
  File "/usr/lib/python2.7/site-packages/leapp/utils/clicmd.py", line 102, in called
    self.target(args)
  File "/usr/lib/python2.7/site-packages/leapp/utils/repository.py", line 20, in checker
    return f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/leapp/snactor/commands/repo/__init__.py", line 162, in link_repo
    if add_repository_link('.', get_repository_id(path)):
  File "/usr/lib/python2.7/site-packages/leapp/utils/repository.py", line 147, in get_repository_id
    return get_repository_metadata(path)['id']

OK, turns out that the path is not valid anymore.  However, I guess an actuall error message would be better than traceback, so let's just say this is the proper interpretation of this Issue.

Sorry, my bad; fixed!


dense sparse dense training

Hi, I am wondering if distiller has a way to specify a schedule that decreases the sparsity level of a neural network, initializing the new weights at zero. This is to implement the dense sparse dense training technique of Han et al.
If this is not possible, can you give me some pointers on how to add a pruner scheduler class? Can I just copy a pruner class I currently find? Do I have to specify the name of the new class somewhere else in the source code? Thank you!

Apologies for the delayed reply.
I don't believe we have "native" support for dense-sparse-dense using a single schedule (take a look at #76).
However, a while ago we added the option to load just the parameters of the model from a checkpoint, and nothing else (specifically, it will not the pruning masks). So you can execute a pruning session, save a checkpoint, and then do a separate run where you load the model parameters checkpoint and continue to train without any pruning.
If you're running compress_classifier.py, you can use the --exp-load-weights-from <path-to-checkpoint> command line option. If you're running your own script, you can call distiller.apputils.load_lean_checkpoint instead of distiller.apputils.load_checkpoint.
If needed you can couple that with a dedicated scheduler to control LR scheduling.
Hopefully this gets you what you need. I don't think you need to implement a new pruner for that.
Just in case I missed something, I'm assigning @nzmora to this. Please note he won't be able to respond this week.

Hi @marsupialtail,
@guyjacob's suggestion for "implementing" DSD is sound.  I want to point out some things:

You mention that you're looking for a schedule that decreases sparsity.  You don't need this for DSD, which does (you can repeat this several times):

Train the DNN
Prune the weights below some value (we prune by maintaining a mask on the weights)
Fine-tune the DNN while keeping the mask
Discard the mask and train at 1/10 the learning rate

I think that in DSD they do one-shot pruning (which Distiller supports), but I don't remember if they threshold the weights of all layers at once (which we don't do).
It's easy to discard the weights programatically (instead of loading using --exp-load-weights-from <path-to-checkpoint as @guyjacob suggested): The pruning masks are stored in an instance of CompressionScheduler which is loaded from the checkpoint.   But you should feel free to change the maskers in the CompressionScheduler in any way you see fit.  Specifically you can set them to None.   See: https://github.com/NervanaSystems/distiller/blob/5c2e9f54b052cc8eefaf109ec8d52537d41b1e34/distiller/scheduler.py#L81-L94).
There are several examples of programmatically using the Distiller APIs outside of the "standard" pruning schedule loop.  E.g. in SA and Greedy pruning.
I hope this extra info helped.
Neta


Git Providers: in 1.9 we'll need a new page describing that we support GitHub and GitLab

type: new page
status: needs update / final review
location: /index.md

https://github.com/kubefirst/kubefirst/pull/391


how to Save initial object content in history only when object is updated or deleted?

Hi,
I have a huge database and wanted to start using django-simple-history on it. After install I have applied python manage.py populate_history --auto to save initial object contents so that when an object is modified by a user I can revert to the initial version of this object. I have noticed that if I don't do that then when a user modifies an object the initial state of the object is not saved.
The problem is that python manage.py populate_history --auto will basically copy thousands of objects from my models in the history models although most of these objects will never be changed by anybody, therefore increasing the size of my database for backups by a lot... is there an option to only save the initial state of an object in the history WHEN and only when this object is modified-deleted?
Thanks a lot for this great feature, I hope we can find a solution to my issue.
Thanks

there's a pre_create_historical_record signal that you could use to check if history exists for the object and create it if it doesn't exist

Excellent. Why not adopting this behavior by default then?
Le 3 août 2020 à 15:03, Ross Mechanic<EMAIL_ADDRESS>a écrit :

there's a pre_create_historical_record signal that you could use to check if history exists for the object and create it if it doesn't exist
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/jazzband/django-simple-history/issues/692#issuecomment-668010270, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKFMG6ISNHSIDIQOQCXYAVTR62YQ3ANCNFSM4PTGRKNQ.

I'm trying to use pre_create_historical_record but there is not much doc related to that. would you have an example of how to use it?
thanks

sorry to come back on this but after a few weeks of use I feel like it would be great to start saving objects in history once they are really modified and not when they are created. Imagine that I have a mysql database with a 200 columns table and 500'000 objects, django-simple-history will clone this table and double the size of the database at start even when just a few of these objects will finally be edited and modified by users... I think there is something to optimise here no?

It's an optimization that you can make. However, it's difficult to make part of the library as you first have to check to see whether or not the instance already has history, and then you need to figure out whether the object is being added or updated. It's something that, to me, makes more sense for you to handle in your calls.

I understand, I managed to make it work for my case but it was quite tricky indeed…
Thanks for amazing work. Soooo useful.
On 26 Aug 2020, at 16:59, Ross Mechanic <notifications<EMAIL_ADDRESS>wrote:
It's an optimization that you can make. However, it's difficult to make part of the library as you first have to check to see whether or not the instance already has history, and then you need to figure out whether the object is being added or updated. It's something that, to me, makes more sense for you to handle in your calls.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/jazzband/django-simple-history/issues/692#issuecomment-680934000, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKFMG6OGPAJ6ZMF6WXNQ3FDSCUPLRANCNFSM4PTGRKNQ.


panic: runtime error: slice bounds out of range

goroutine 9 [running]:
code.google.com/p/gopacket/layers.(*TCP).SerializeTo(0xc20a10e140, 0x7fb8b8104328, 0xc20a0facf0, 0x410100, 0x0, 0x0)
/root/xxx/src/code.google.com/p/gopacket/layers/tcp.go:101 +0x8d8
code.google.com/p/gopacket.SerializeLayers(0x7fb8b8104328, 0xc20a0facf0, 0xc209dd0100, 0xc20a0fc620, 0x2, 0x2, 0x0, 0x0)
/root/xxx/src/code.google.com/p/gopacket/writer.go:190 +0xc1

Any chance you could send us a way to recreate a TCP{} struct that exhibits this behavior?

just got a new one:
panic: cannot currently serialize IPv4 options

goroutine 9 [running]:
fastCat/fcVpn.gopacketserialize(0x7f0d4d520d60, 0xc20a2c8dc0, 0x0, 0x0, 0x0)
        /root/xxx/src/fastCat/fcVpn/iprewrite.go:87 +0x43f
fastCat/fcVpn.recomputeIpPacketChecksum(0xc20a1f8b4d, 0x34, 0x38)
        /root/xxx/src/fastCat/fcVpn/iprewrite.go:28 +0xd8

It turn out that the clients of my project have some data races.
Arbitrarily bytes has treated as ipv4/tcp packet to gopacket to unserialize a tcp packet,and to serialize and compute checksums to bytes.
Does gopacket need to protect against arbitrarily bytes input,(return error but not panic)?


[Performance] Low performance of vectorized kernels

🐛 Describe the bug
It is found that the vectorized kernels are not performing well. For instance, copy_() is just utilizing only 40-50% of the theoretical bandwidth.
Versions
Collecting environment information...
PyTorch version: 2.6.0a0+git95f869c
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A
OS: Ubuntu 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35
Python version: 3.10.15 | packaged by conda-forge | (main, Sep 30 2024, 17:51:04) [GCC 13.3.0] (64-bit runtime)
Python platform: Linux-5.15.0-73-generic-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
CPU:
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Address sizes:                   52 bits physical, 57 bits virtual
Byte Order:                      Little Endian
CPU(s):                          96
On-line CPU(s) list:             0-95
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Xeon(R) Gold 6336Y CPU @ 2.40GHz
CPU family:                      6
Model:                           106
Thread(s) per core:              2
Core(s) per socket:              24
Socket(s):                       2
Stepping:                        6
CPU max MHz:                     3600.0000
CPU min MHz:                     800.0000
BogoMIPS:                        4800.00
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 invpcid_single ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la57 rdpid fsrm md_clear pconfig flush_l1d arch_capabilities
Virtualization:                  VT-x
L1d cache:                       2.3 MiB (48 instances)
L1i cache:                       1.5 MiB (48 instances)
L2 cache:                        60 MiB (48 instances)
L3 cache:                        72 MiB (2 instances)
NUMA node(s):                    2
NUMA node0 CPU(s):               0-23,48-71
NUMA node1 CPU(s):               24-47,72-95
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Retbleed:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Versions of relevant libraries:
[pip3] numpy==2.1.2
[pip3] optree==0.13.0
[pip3] torch==2.6.0a0+git95f869c
[conda] numpy                     2.1.2                    pypi_0    pypi
[conda] optree                    0.13.0                   pypi_0    pypi
[conda] torch                     2.6.0a0+git95f869c          pypi_0    pypi
~$ xpu-smi discovery
+-----------+--------------------------------------------------------------------------------------+
| Device ID | Device Information                                                                   |
+-----------+--------------------------------------------------------------------------------------+
| 0         | Device Name: Intel(R) Data Center GPU Flex 170                                       |
|           | Vendor Name: Intel(R) Corporation                                                    |
|           | SOC UUID: 00000000-0000-0000-947c-ef6e26c509ae                                       |
|           | PCI BDF Address: 0000:4d:00.0                                                        |
|           | DRM Device: /dev/dri/card1                                                           |
|           | Function Type: physical                                                              |
+-----------+--------------------------------------------------------------------------------------+

Note that it's reasonable not to hit the peak bandwidth for broadcast and dynamic cast cases, because the input/output layout can't be read/write coalescently.

Found the root cause.
The root cause is that when we get an API to get the vector_size / SIMD lane from the LevelZero runtime, the runtime returns just half of the vector width. e.g.: For float32, it returns width 2 instead of width 4.
I have created an internal JIRA ticket for the related teams to solve the problem
@xytintel Shall we add a hotfix on our side? We can add a simple heuristic to correct the width 2 to width 4. I have tried that on copy_() operator and the performance shows 70% improvement. This will help all other vectorized kernels.

Found the root cause. The root cause is that when we get an API to get the vector_size / SIMD lane from the LevelZero runtime, the runtime returns just half of the vector width. e.g.: For float32, it returns width 2 instead of width 4. I have created an internal JIRA ticket for the related teams to solve the problem
@xytintel Shall we add a hotfix on our side? We can add a simple heuristic to correct the width 2 to width 4. I have tried that on copy_() operator and the performance shows 70% improvement. This will help all other vectorized kernels.

I think we should wait for the related teams to fix this issue rather than using a WA.  @EikanWang What's your opinion?

In general, we should always wait for a formal solution rather than patching code. From the execution perspective, it depends on the impact. Back to this issue, I'd prefer to leave it as it is and push the driver team to fix it. Since we always encourage users to install rolling drivers, the performance issue will be addressed at some point.


Telegram bot keeps resetting - even mid-task

Hello,
It looks like my Telegram bot keeps resetting every day, even mid-task and I have to re-send service accounts again and set up folders again. It's tedious and annoying, especially when the bot is running and it just says 'Welcome to CloneBot. Let's copy some data!' Could anyone help me please? I've attached some screenshots below.
Thank you :)

Another example is when the bot will just stop working and after a few hours send a welcome message after resetting...
Thank you for any help!

Another example is when the bot will just stop working and after a few hours send a welcome message after resetting...
Thank you for any help!

Another example is when the bot will just stop working and after a few hours send a welcome message after resetting...
Thank you for any help!

Its bcoz heroku dunos gets reset every after 24hrs, thats why bot also restarts after 24 hrs. Make sure your task doesnt last more than 24 hrs.

BTW i just wanna know this bot is working fine in heroku without getting banned?

BTW i just wanna know this bot is working fine in heroku without getting banned?

Sorry for the late reply. Bot works fine with no problems at all :) no ban


Handle paths with array indices called on nil context objects

Fixes #30

@ClaytonPassmore sure, done.


Apple Privacy Manifest: Abseil not updated to supporting version when using Firebase 10.22.0

Description
When updating Firebase iOS SDK to version 10.22.0 using SwiftPM to gain access to Google provided Privacy Manifest, the Abseil SDK dependency is untouched not updating to the least minimum version also providing a Privacy Manifest. This manifest file seams to be required when checking Apples list of SDK required to provide an own manifest.

I have the same issue.

The binary SPM distributions for Abseil, gRPC, and BoringSSL have now been updated and released. The latest version of Firebase should pick them up if you update your SPM workspace. Each of the three SDKs also now has a privacy manifest.
I'm going to mark this as closed. Please try updating to pull these new dependency versions in.

@ncooke3 I can only see latest version 10.22.0 which still has the issue?

Hi @helloniklas, Firebase 10.22.0 is compatible with the latest Abseil version I published today. If you update your SPM workspace, Firebase will remain on 10.22.0, but its Abseil dependency will update to a new patch release.

@ncooke3 ah, got you. Thanks.


Bumped version of cosmos-sdk-proto in cosmos_sdk

cosmos_sdk still uses cosmos-sdk-proto v0.6

Oops, saw this after merging #125.
Also this isn't strictly necessary: a 0.6 expression in Cargo.toml is actually a SemVer ^0.6 expression, which expands to >= 0.6.0.
So it will always use the latest version, and in a project you just need to run cargo update -p cosmos-sdk-proto to update that particular package in your Cargo.lock.
Gonna go ahead and close this, but I'm about to cut an initial release of cosmrs under the new name, and will go ahead and pin to at least 0.6.3 for that.


Integration of Daphne with HDFS in Distributed Mode

Issue Description:
As part of our project, Daphne, we require an integration of Daphne with Hadoop Distributed File System (HDFS) when executing Daphne in distributed mode. This GitHub issue serves as a detailed summary of our progress so far, remaining tasks, and an invitation for contributions, alternative approaches, or suggestions for future steps.
Procedure Followed:

Researched C++ libraries providing the necessary APIs to communicate with HDFS from within C++ code.
Identified "libhdfs3" as the most suitable option, although it is primarily used as a Python API for HDFS.
Installed and configured Hadoop locally for running HDFS in a pseudodistributed mode.
Question: Should we document the steps for downloading, installing, and configuring Hadoop alongside Daphne, or include these steps in the Dockerfile? It may be possible to include the Hadoop installation in the Docker image, but clarification is needed regarding the configuration steps.
Made modifications to the Docker run command to ensure the container "sees" the same network as the local machine. Also added arguments to mount the Hadoop user and the Hadoop root installation with the container.

Detailed notes on these modifications will be added to the Daphne container files.

Successfully tested HDFS communication from inside an interactive mode container.
Addressed the need to automate the building of libhdfs3 alongside Daphne and link its libraries with Daphne.

Added necessary additions to Daphne's build.h, CMakeLists.txt, and the CMakeLists.txt file in the src/runtime/local/kernels path.
However, encountered an issue due to the inactivity of libhdfs3's C++ support. Made changes to libhdfs3's CMakeLists.txt and installed additional required libraries on the container.
Note: These library installations should also be added to the Dockerfile. Additionally, since libhdfs3 is used as a third-party library in Daphne, the changes to its CMakeLists.txt should be included in the Daphne patches.

Successfully built and linked libhdfs3 with Daphne, allowing communication with HDFS from within a Daphne kernel.

Noted the absence of a formal C++ API in libhdfs3. Extracted the required API from the libhdfs3 source files.

Next Steps:
The next step is to design the architecture of the Daphne .h files that will include the necessary functions for Daphne kernels to read from or write to HDFS using libhdfs3. Feedback and input are welcomed at this stage.
Based on the existing structure, it appears that the Read.h kernel is used for reading files from the local filesystem, and it includes templates that define a struct and a function to create a Daphne DenseMatrix, Daphne SparseMatrix, or Daphne Frame. For writing to files, there is the Write.h kernel.
The Read.h kernel is currently used for reading files from the local filesystem and relies on the following Daphne I/O .h files:

File.h
ReadCsv.h
ReadParquet.h
ReadDaphne.h

It is suggested that the integration with HDFS introduces new .h files specific to HDFS operations:

HdfsFile.h: Similar to File.h, it provides utilities for opening, reading, and writing files in HDFS.
HdfsReadCsvFile.h: Similar to ReadCsvFile.h, it utilizes HdfsFile.h to open a CSV file in HDFS and write its contents to a Daphne DenseMatrix or SparseMatrix using a template, struct, and function.
HdfsReadCsv.h: Builds upon ReadCsv.h by utilizing HdfsReadCsvFile.h to read specific parts of a CSV file (e.g., rows 3-5 or columns 7-9) passed as arguments.
HdfsRead.h kernel similar to the Read.h kernel that will rely on the above io files.

Also the additional corresponding write .h files
Keep in mind that for now, we intend to work with Daphne DenseMatrix and SparseMatrix.
We have created the proposed .h files, incorporating the necessary templates, structs, and functions.
However, the functionality is not yet working as expected, and extensive debugging is required.
We welcome contributions and guidance from individuals experienced in Daphne's I/O operations to review and provide feedback on the suggested architecture or assist in producing the required source code.
Please feel free to add your input, suggest modifications, or contribute to any part of the integration process.
(It is important to note that the current progress has been accomplished in a "quick and dirty" style and requires further cleaning before pushing the changes to the repository. We appreciate your understanding and collaboration in this regard.)

Hi!
Adding the necessary steps to set up an HDFS environment would be a nice piece of documentation to get users started. But generally I'd say that the setup steps for HDFS that do not directly concern DAPHNE are out of scope. So the user is expected to have their filesystem set up according to their needs.
All the additional dependencies should also be added to the list of required packages in the table in GettingStarted.md.
If DAPHNE can run just fine if libhdfs3 is compiled in but no HDFS installation is present, then this is just another dependency that we precompile in build.sh. If this is not the case, e.g., DAPHNE can not run without an HDFS environment being present, then we need to cover this functionality behind a run-time flag ($ daphne --hdfs my/script.daph).
You already mention that libhdfs3 does not receive much attention by their developers anymore. This sounds a bit like trouble.  Furthermore I read about dependencies to boost, kerberos and others. So far we managed to circumvent the boost dependency. If we can continue that path we'd be avoiding a quite heavy additional dependency imho.
If there's code to look at concerning this issue, please add a link to the repo/branch here.
Regards, Mark

Hi!
So,  I have made some minor cleanup and changes to the codebase. I have pushed the changes to the hdfs-test branch in the repository located at the following URL: https://github.com/KostasBitsakos/daphne-kbitsak/tree/hdfs-test
Please note the following:
The files hdfscsvfile, hdfsreadcsv, and hdfsread have not been pushed to the repository yet as I am currently in the process of reconstructing them. I will push them as soon as they are ready.
The changes made to the CMakeLists.txt file for libhdfs have not been pushed either, as libhdfs is installed as a third-party library.
I welcome any comments or feedback on the proposed workflow or the changes made. Your input and suggestions are greatly appreciated.
Regards,
Constantinos

I guess the commit that implements this is tagged with the wrong number #767 now. I'll leave this issue open though. Maybe the test cases and documentation can go with this ticket number :thinking:


std.math: Move pow function into submodule.

Moving pow to submodule seems to be a little bit more problematic, so I'm doing this in a single step. Let's see if it works...

Some windows computers fail with a unittest in std.internal.math.gammafunction.d. Here the log of the x64 version, which is more verbose:
core.exception.AssertError@std\internal\math\gammafunction.d(1053): unittest failure
----------------
0x00007FF71340BB12 in d_unittestp
0x00007FF7131D508B in std.internal.math.gammafunction.__unittest_L1024_C7 at D:\a\1\phobos\std\internal\math\gammafunction.d(1054)
0x00007FF7131D8F27 in void std.internal.math.gammafunction.__modtest()
0x00007FF71342F139 in int core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*)
0x00007FF71341B9A7 in int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*))
0x00007FF713432794 in int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_win64.SectionGroup)
0x00007FF7134326FF in int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*)))
0x00007FF71341B967 in int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*))
0x00007FF71342EF87 in runModuleUnitTests
0x00007FF713418D25 in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll()
0x00007FF713418C7F in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate())
0x00007FF713418A86 in d_run_main2
0x00007FF713404FB3 in d_run_main
0x00007FF7110F9122 in unittest._d_cmain!().main at D:\a\1\phobos\../druntime\import\core\internal\entrypoint.d(30)
0x00007FF7134F1378 in __scrt_common_main_seh at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
0x00007FFAD01E84D4 in BaseThreadInitThunk
0x00007FFAD2221821 in RtlUserThreadStart
1/130 modules FAILED unittests
std\internal\math\gammafunction.d(1053): [unittest] unittest failure

Anyone an idea, what's the reason here?

MS win has double == real and the gamma function tests in particular test more precision than they really should.
I take it this PR is a cut and paste job for the most part?
evaluate the failing assertion
feqrel(betaIncompleteInv(5, 10, 0.2000002972865658842L), 0.229121208190918L) >= real.mant_dig - 3  and see how far off it is.

I take it this PR is a cut and paste job for the most part?

Aside from a few needed imports it's cut and paste...

It's only one digit: .0...799 instead of .0...800.
Anyway I wonder, why the calculation changed. It shouldn't.

eBay/tsv-utils fails too, due to the same problems as encountered with the gamma function.
IMHO, we should find out, why dmd produces different code here and fix that...

I wonder if might be possible that the compiler searches for pow in both druntime and std.math. Maybe these have different implementations and now since pow is moved from std.math, the compiler picks the one in druntime?
Also, there's the style checker:
std/internal/math/gammafunction.d(26:1)[warn]: A unittest should be annotated with at least @safe or @system
`

Also, there's the style checker:

I'm aware of that, but I see no merit in starting the testers again, when the main issue is not fixed... ;-) (Ideally, the gammafunction should not be touched at all.)

Ok, I was just pointing that out :-"

The compiler lowers ^^ operator to
static import std.math;
std.math.pow(x, y);

Hazarding a guess, but you might need to force that the std version takes precedent with:
alias pow = std.math.exponential.pow;

In the package module.
Ideally pow should really be in druntime because it is a compiler interface, however the non-trivial template implementation makes it awkward to move without also privately copying a good chunk of meta and traits along with it.

Hazarding a guess, but you might need to force that the std version takes precedent with:
alias pow = std.math.exponential.pow;

In the package module.

For round and trunc this didn't work. But maybe here it does. Let's try...

For round and trunc this didn't work. But maybe here it does. Let's try...

No, unfortunately not...

For round and trunc this didn't work. But maybe here it does. Let's try...

No, unfortunately not...

Another shot in the dark. Remove the public import of core.math from the std.math package.
In its place, use public selective imports in the appropriate submodules.
// e.g in std.math.exponential
public import core.math : pow;

An intentional side effect being new core.math built-ins aren't implicitly pulled into std.math.

Another shot in the dark. Remove the public import of core.math from the std.math package.

core.math isn't publically imported, only static. I moved it into the functions anyway to see, if this has any effect...

Another shot in the dark. Remove the public import of core.math from the std.math package.

core.math isn't publically imported, only static. I moved it into the functions anyway to see, if this has any effect...

Oh, then I suppose it'll likely have no effect at all them, except if there're bugs in the import visibility system.

core.math isn't publically imported, only static. I moved it into the functions anyway to see, if this has any effect...

Oh, then I suppose it'll likely have no effect at all them, except if there're bugs in the import visibility system.

Saying that though, it all seems to be green?

Saying that though, it all seems to be green?

Unfortunately not. Still the same problem.

@berni44 - I've managed to find some time to check this proper.
Compiling gammafunction.d on x86_64-linux using -vcg-ast and diff'd the generated dump before and after this patch.  This difference in codegen has no relation to a change in this PR.
@@ -5473,7 +5474,8 @@ pow!(real, real)
 				}
 				x = -x;
 			}
-			return sign * exp2(yl2x(x, y));
+			real w = exp2(y * log2(x));
+			return sign * w;
 		}
 		return impl(x, y);
 	}

Looks like the culprit is that you forgot to define version = INLINE_YL2X; for DigitalMars platforms.

Just realised I can commit the suggestions myself.

New error:
D:\a\1\dmd\test\..\..\phobos\std\math\exponential.d(667): Error: `yl2x` cannot be interpreted at compile time, because it has no available source code
compilable\test5227.d(120): Error: cannot interpret `<error>` at compile time
compilable\test5227.d(120):        while evaluating `pragma(msg, powf)`

Which is correct, when LDC/GDC is building DMD, the resultant compiler can not interpret yl2x at compile-time.

So this is blocked by the compiler now.
https://github.com/dlang/dmd/blob/e658df1cc3a1622dea8e3614a5c3d94742ebbf52/src/dmd/builtin.d#L89-L93
It looks only for module names ending with math (i.e: core.math, std.math), so it returns BUILTIN.unimpl so tries to interpret the body.

So this is blocked by the compiler now.
https://github.com/dlang/dmd/blob/e658df1cc3a1622dea8e3614a5c3d94742ebbf52/src/dmd/builtin.d#L89-L93
It looks only for module names ending with math (i.e: core.math, std.math), so it returns BUILTIN.unimpl so tries to interpret the body.

Wilsonator pointed me to the same line in PR #7943.

So this is blocked by the compiler now.
https://github.com/dlang/dmd/blob/e658df1cc3a1622dea8e3614a5c3d94742ebbf52/src/dmd/builtin.d#L89-L93
It looks only for module names ending with math (i.e: core.math, std.math), so it returns BUILTIN.unimpl so tries to interpret the body.

Wilsonator pointed me to the same line in PR #7943.

Just validating a fix just now with compilable/test5227.d, it looks like fabs stopped being matched in #7941, but this wasn't noticed because the body just forwards to core.math.

No longer blocked by compiler built-ins support. Looks like one remaining failure is due to missing symbols.

Many thanks for your help!


Update data.ts

Hi Sudheer,
I guess you have raised PR by mistake. Sample data won't be changed to any specific persons data


Updated angular dependency to 1.4 (was 1.3)

@cgross I believe you can merge this one safely :smile:

@cgross Are you planning on updating this project to use Angular 1.4?  Is the project alive?

Hi, we've continued development over here -> https://github.com/faceleg/angular-busy-plus


Error when starting brigadeterm

When I start brigadeterm, sometimes I see below error repeatedly logging in the terminal. I dont face this issue often, but sometimes for a few minutes.
ERROR: logging before flag.Parse: E0919 16:18:11.366720    1057 reflector.go:205] github.com/slok/brigadeterm/vendor/github.com/Azure/brigade/pkg/storage/kube/apicache/liststore.go:36: Failed to list *v1.Secret: Unauthorized

Hi! That's Kubectl connection error, maybe your token has expired or similar, depends on how you authenticate with your own cluster. It's not something related with brigade or brigadeterm.
Closing.


Making and Reverting Changes

This pull request's purpose is to revert the changes made previously.

I am afraid of this as it has no changes.  You could always start a new fork and abandon existing one.


Add undefined to the return type of indexers generated by getters?

Doing this will make inconsistency with arrays. Strictly array indexers should also return | undefined but it's currently not. https://github.com/microsoft/TypeScript/issues/9235


Deprecate TrainerProperties and move them to the trainer

🚀 Feature
Deprecate the TrainerProperties: https://github.com/PyTorchLightning/pytorch-lightning/blob/938a191406fff5f51fba03fcf824f22d8d23c2e0/pytorch_lightning/trainer/properties.py
Move the properties directly to the trainer: https://github.com/PyTorchLightning/pytorch-lightning/blob/938a191406fff5f51fba03fcf824f22d8d23c2e0/pytorch_lightning/trainer/trainer.py#L104-L161
Motivation
It's confusing to have trainer properties in multiple different classes. It would be more clear to have them all directly in trainer.py
Pitch
Alternatives
Additional context

If you enjoy Lightning, check out our other projects! ⚡

Metrics: Machine learning metrics for distributed, scalable PyTorch applications.

Flash: The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, finetuning and solving problems with deep learning

Bolts: Pretrained SOTA Deep Learning models, callbacks and more for research and production with PyTorch Lightning and PyTorch

Lightning Transformers: Flexible interface for high performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.

@daniellepintz maybe we could keep this issue specific to the properties, and file separate issues to discuss the other mixins.
I agree with the push though; these mixins are historical artifacts of the prior trainer design. The mixins are not self-contained at all.
It is very confusing having the properties listed separately, especially for what's on the public trainer API vs what's supposed to be private
I know @awaelchli had similar thoughts in the past

Sounds good, updated the description

This is only about moving the code from one file to the trainer.py right? And there is no deprecation necessary because we won't rename any attributes, right?

It's confusing to have trainer properties in multiple different classes. It would be more clear to have them all directly in trainer.py

Just to give context of why things are the way they are:
The feedback for PL 1.0 was that the trainer is not easy to read for users. We wanted to make the trainer accessible so that users who start reading the code are guided to the right place from the very start (without needing to scroll hundreds of lines) and they can easily follow the code path.
By merging all mixins into one, the trainer will now be cluttered again with a long list of properties, dataloading methods etc. where we will sacrifice readability and lose focus of what's important and what's not.
To justify these changes, we can argue this is only a temporary state and we will invest efforts in making the trainer less a god class in the future.

@awaelchli yes it is about moving the code. by deprecation I just meant deleting the TrainerProperties class and file.
thanks for the context! that makes sense. I am also wondering, do we really need all those properties? are they all used? Maybe we should try to reduce the number of properties.
If we can't remove any of the properties, maybe this issue isn't super hi-pri as there are pros and cons either way.

I'll also add, psychologically, we will be more incentivized to invest in efforts to make the trainer less of a god class if this is all in trainer.py.
Because so much of the trainer logic is split across files like properties.py, the connectors, and the mixins, the problem is out-of-sight, out-of-mind. Stashing the code elsewhere is not a real solution and I'm looking forward to improving the current situation. I think it'll also force us to reckon with how complex the trainer has gotten, what do we absolutely have to live with, and what can we better organize.
Given Lightning's claim to fame is that it's organized pytorch (not abstracted pytorch), it'll be critical that users and others in the community see this is true within the framework-internal codebase too!

@ananthsub I completely agree! I add this task to my queue then.

I am also wondering, do we really need all those properties? are they all used? Maybe we should try to reduce the number of properties.

We can try, but most of them are exposed for convenience access for users.

Hey @awaelchli @carmocca, do you think we should do it. I am a bit perplex as i would prefer to come directly with an alternative instead of making an intermediate step there.

I'd say this is very low priority. Additionally, when a "state/engine" interface is passed to the LightningModule to avoid the trainer reference, these properties could be part of it so they would naturally move there.

@carmocca @tchaton - this wouldn't be anything more than copy/paste the trainer property definitions into trainer.py and deleting the mixin. there's no other API changes that are part of this. it's simply to keep the trainer properties in one place to avoid extra hops when reading the code

I can work on this if we decide to do it now. Agree it should be a simple PR

Fixing this could also help avoid issues like #9427

Since none of us have strong feelings against it, I think we can go forward with this.
I suggest you put all the properties at the end of the file as if you were concatenating the two files.

Since none of us have strong feelings against it, I think we can go forward with this.

None of the team will have strong feelings about this because no Lightning engineer actually reads the trainer.py code anymore. We just navigate to where we need to be because we know where to go. But for users this is a different experience. The Trainer and LightningModule are the central objects of Lightning and people will attempt to read the code (and I wish I could encourage them!!). We used to have this somewhat readable structure:
class Trainer:
   init
   fit  <- entry point, the interesting stuff!
   test  <- entry point, the interesting stuff!
   ...
   100's of useless lines of code making the trainer a god class

and now we have (and even more so after this PR):
class Trainer:
   init
   ...
   100's of useless lines of code nobody should read to understand Lightning
   ...
   fit <- entry point, the interesting stuff! (after PR at line 1124!!)

For this reason I suggest to put the properties at the bottom, even though I don't like this at all, maybe we can make a compromise?

@awaelchli sure that's fine by me. I see other classes in Lightning don't follow a consistent style in terms of properties at top or bottom, so that sounds fine.

actually, in which classes did you see that? I believe we should fix that. Consistency is key.

Some examples:
https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pytorch_lightning/loggers/base.py
https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pytorch_lightning/accelerators/accelerator.py
I agree we should fix it

But for users this is a different experience. The Trainer and LightningModule are the central objects of Lightning and people will attempt to read the code (and I wish I could encourage them!!) and miserably fail. We used to have this somewhat readable structure:

I fully echo this. we have to make it as easy as possible for people to read & navigate the code. even in the examples @daniellepintz shared, we currently don't have a consistent style around how files are named. the base logger is in loggers/base.py ,  the base accelerator is in accelerators/accelerator.py - all of these minor discrepancies can add up when trying to navigate the codebase. this also came up here: https://github.com/PyTorchLightning/pytorch-lightning/pull/9414#discussion_r706770199
@awaelchli @tchaton - I think it would be very beneficial if we had a style guide written down, and which reviewers can enforce, to prevent these issues from occurring. we could then make it part of the contributing doc. What do you think?

Having a style document to ensure future consistency on new addition definitely seem quite relevant today.
Personally, I am not a huge fan of properties being at the bottom, where the Trainer components will be several thousands of lines.
But I don't have a good alternative to propose for this one.


Allow custom code coverage results

#9962 breaks https://github.com/MicrosoftDocs/pipelines-go which uses a custom coverage tool and https://github.com/dmundt/goquery.
The code coverage tab at https://dev.azure.com/dmundt/goquery/_build/results?buildId=222&view=codecoverage-tab is empty since this change.

@nigurr - can you please look at this?

@nigurr @PBoraMSFT - I think the problem is already fixed with #10128.  The custom code coverage generation seems to work (e.g. https://dev.azure.com/dmundt/goquery/_build/results?buildId=222&view=codecoverage-tab is visible again).
IMHO the PR can be closed/rejected.


Change TM scope for primitive types to be consistent with other typed languages

Other typed languages use the support.type scope instead of storage.type for primitive type tokens. I am proposing this change so that LPC is consistent with other languages in how primitive types are colored.

This looks good to me. However, I'm sleep deprived at the moment and will merge later.


Close of Deadletter Message edit window refreshes the current connection

Open any Dead-lettered message.
Click on "Close" or "X"
It can be noticed that Explorer will refreshes the entire connection

PR #298 will address this issue. Thanks @rahulseth01 for reporting the problem.

Hi,
I see this issue resurrect in build: 4.1.112. @SeanFeldman  Can this issue be re-opened?

@rahulseth01 did you run into this with the latest?

Yes, it is happening again in the latest release.

Hi,
Please let know any update of this bug. Can this be picked up on priority as it is delaying entire process while analyzing dead-lettered messages

There is an issue with some older versions of Service Bus Explorer incorrectly reporting as being the latest version. So please make a screen shot of the About box and put it in this thread to help us determine the actual version you are using.
Service Bus Explorer is 100% community driven so there are no dedicated developers.

Thank you Eric. I do understand its a community driven and really appreciate the hard work being put by you all.
My only intention was to bring this bug up to the notice as its been quite long.
I am hereby attaching the required screenshot.
P.S: The topic refresh get triggered only when dead-letter message-box is closed (either on clicking on close button or X button) not when normal message-box is closed.

Close of below message box triggers refresh

Yes, you are using the latest release. There are some commits concerning this after the 4.1.112 release. @rahulseth01 , have you tried build the develop branch and testing that?

Thanks Eric. Yes it works perfectly fine on develop branch.

Thanks @ErikMogensen! @rahulseth01 can I close the issue?

Yes it can be closed. Btw when are you planning to cut one release from develop branch?

As I see it, once #410 and #411 are solved.


Youtube titles containing "|"s break the script.

The "|" gets turned into a "_" and then repair.fix_music can't find the file because it is still looking for the "|" version.

To reproduce you can search "| song" on youtube and use one you found there.

I have fixed this issue. Try upgrading musicnow. It was occurring because youtube_dl would replace characters such as '|' and ' " '.

that worked, thanks!


Environment file

Need to delete the .yaml file as created it first by mistake but the milestone instructions ask for an environment.yml file.

Close #9


[FLINK-19536][network] Fix inconsistent priority notification.

What is the purpose of the change
This commit fixes a range of smaller bugs introduced in #13228. They all affect the (priority) availability of InputGate and trigger various kinds of preconditions that have been in embedded into the network stack.
Brief change log

Fix union gate polling gates through iterator. That may leave PriorityDeque in inconsistent state.
Double-check if gate still has priority buffer when enqueuing in UnionInputGate. Since notification is not atomic in respect to gate enqueuing, priority event already polled by task thread when netty enqueues the gate.
Only notify data available when there is a non-priority buffer. This avoids StreamTaskNetworkInput to poll empty gates.

Verifying this change

Added tests for each bug (WIP).

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Subsumed by https://github.com/apache/flink/pull/14073 and https://github.com/apache/flink/pull/14141.


feat: case-insensitive search and pagination for users

Date: 3rd August, 2024

Developer Name: @Achintya-Chatterjee

Issue Ticket Number

Closes #2060

Description
This PR adds case-insensitive search capabilities and proper pagination for user data. Modified the backend to ensure searches by username, first name, and last name are handled in a case-insensitive manner. Additionally, updated the fetchPaginatedUsers function for consistent and efficient pagination.

Documentation Updated?

[ ] Yes
[ ] No

Under Feature Flag

[ ] Yes
[ ] No

Database Changes

[ ] Yes
[ ] No

Breaking Changes

[ ] Yes
[ ] No

Development Tested?

[ ] Yes
[ ] No

Screenshots

Screenshot 1

Test Coverage

Screenshot 1

Additional Notes

Added case-insensitive search capability in the fetchPaginatedUsers function.
Modified addOrUpdate function to store lowercase values for username, first name, and last name for consistent search functionality.
Enhanced the controllers logic to utilize fetchPaginatedUsers for consistent and efficient user search and pagination.

Closing this PR, this issue is fixed in an another PR #2105


125 implement foreign function interface

At the moment the base branch is #124, this will be changed later.


Macos build problems

Tracking

Have you tried the extension on MacOS? This is the one platform I have no means of working with, so I have no idea what the state of things are.

No github action builds exist for the mac

The current state of things are easy to summarize: You cannot build on mac because there's no config for it.
❯ scons
scons: Reading SConscript files ...
Auto-detected 16 CPU cores available for build parallelism. Using 15 cores by default. You can override it with the -j argument.
Building for architecture universal on platform macos
KeyError: ('macos', 'universal'):
  File "/Users/lukas/dev/godot/godot-python-extension/SConstruct", line 289:
    prepared_python_config = prepare_python.platform_configs[(env['platform'], env['arch'])]

I work on a mac, so I should be able to whip up a config in prepare_python.py to support the platform. Might take a while though, depending on when I have time.


I need a copy of your website.

What do you mean ? If you want to have a copy on microweber.com you can write us here  https://whitelabel.microweber.com/


Skill :  Spur Skills

Added Spur Skills : Adjacent allies gain +4 to their respective stat.

mind the your code style and indentation issues

https://github.com/MokhaLeee/fe8u-cskillsys-kernel/commit/76328b2992c05f98a3d23f1658bc60e92398fb2e

https://github.com/MokhaLeee/fe8u-cskillsys-kernel/commit/b5ea8898ec2a3843021ef7f47b686d80f171896f


strictProperties

it would be great to add strictProperties support
https://github.com/fge/json-schema-validator/wiki/v5:-strictProperties

I am not sure I understand what problem this keyword solves that is not already solved by existing keywords.

because additionnalProperties only apply to properties declared at the same level.
In the following (schema3) exemple, if my schema is a mix between 2 schema (part of each), i have no way currently to restrict to properties i require. The only way would be stictProperties.
{
    "$schema": "http://json-schema.org/schema#",
    "id": "http://xy.com/schema/schemaC.json",
    "allOf": [{
        "$ref": "schemaA.json"
    }, {
        "$ref": "schemaB.json"
    }, {
        "required": [
            "propA1",
            "propA3",
            "propA4",
            "propA7",
            "propB2",
            "propB4",
            "propB5"
        ],
        "strictProperties": true
    }]
}

I see nothing in the proposal that would suggest it is the case.
I generally disagree with the idea of having keywords that has wider effects than the schema they are used in - there are quite a few edge cases that make it both unexpected and difficult to implement.

According to the proposal, this schema:
{
  "required": [
    "propA1",
    "propA3",
    "propB2",
    "propB4",
  ],
  "strictProperties": true
}

is equivalent to:
{
  "properties": {
    "propA1": {},
    "propA3": {},
    "propB2": {},
    "propB4": {}
  },
  "required": [
    "propA1",
    "propA3",
    "propB2",
    "propB4",
  ],
  "additionalProperties": false
}

So it is just a syntax sugar that can be added with macro keyword definition. Can be added to ajv-keywords I think

it is not equivalent.
"has no other properties than the ones defined in properties, patternPropertyGroups and required."
that means if i use a shema with external properties using $ref and i use required in the parent shema with "strictProperties" it will require and only accept properties in "required" property. With external properties, the property "additionalProperties" will not work.

What do you mean by "external properties"? In any case strictProperties should be only affected by properties and other keywords in the same schema object, it can't take into account properties in other objects.

Closing the issue. I will not be implementing any keywords with global visibility until they are added to the standard. And I am strongly against it, I think keywords should only have local visibility.
I haven't been presented with a single use-case for properties that cannot be expressed using existing JSON-schema vocabulary. I like the idea of $merge/$patch keywords though, extending the schema is indeed not supported and it is needed to extend meta-schemas, for example.
If you are interested in strictProperties keyword with local visibility, we can add it to ajv-keywords as I suggested (I already wrote the code, just need to add test cases...)

See $merge and $patch keywords.


do not use become: true in all playbooks

causes the following error against windows hosts:
msg: The powershell shell family is incompatible with the sudo become plugin

So let's define where to use become: true (is needed anyway).

Will be defined in group_vars or host_vars using ansible_become: true.


Application package RP operatinos added.

Generated output added for application packages for the resource provider. A new account property was added to say if the account supports auto storage or not. Bumped the package number to from 1.5.0 to  1.6.0 and API version bumped from 2015-09-01 to 2015-12-01.

Can one of the admins verify this patch?

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

It looks like you're working at Microsoft (mrollitt). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@azuresdkci add to whitelist

@matthew-rollitt Please respond to comments in hydra-specs-pr before this is merged.  This looks OK assuming the build passes


Fix transitionTo in order to support the full API of the super class

The change seems good, but can you give me an example of what this fixes (i.e. a code snippet that doesn't work before but does work after)?

This was breaking for QP-only transitions. So stuff like:
this.transitionTo({ queryParams: { direction: 'asc' } });

Also, fixes replaceWith not being scoped it seems.

Awesome, thanks for the explanation!


Make ngram similarity calculation faster.

#1363
After profiling it a bit, it turns out that Set.addAll() was the most time-consuming and dominating factor for a search request, and rewriting this small method should provide a quick win for the search latencies.

How much faster is this?

On my Macbook, a random, non-representative query took 70ms with the old version, and 11ms with the new version.


Derived columns with Table?

Currently Table requires that data is an iterable of objects, and pulls out named properties for each field in each row:
https://github.com/observablehq/inputs/blob/ec971827bb39ce09462a5dc7047d8f93f9101a6e/src/table.js#L87-L90
While it’s true that data can be a lazy iterator, there could be an easier way to express a derived column without needing to resort to array.map and greedily materializing all the objects. And while it’s true that a format function could return a derived value (leaving d[column] as undefined), that’s not recommended because it will break sorting.
So, what if there were a map option that let you override the definition of a column:
Table(data, {map: {foo: d => d.bar}})

But how would this interact with the columns option? Maybe the map keys would get implicitly added to the default columns value?
(Also, it might be nice to use per-column iterators internally, and per-column arrays when materializing. This would be particularly nice in conjunction with column-based data structures such as Arquero.)

I’m going to leave this as a question because I think more thought is required to figure out how this would work and if we want it.

derivedColumns? That still doesn’t cover how they should be rendered — perhaps at the end by default, or you could specify their names in the column list?

Also, I think this is unnecessary for the case of simply labeling columns in a user friendly manner. For that, there could be an option with the TypeScript type { [rowKey: string]: string | Node } where the value of a given key would be turned into a text mode (if necessary) and used in the header of the table instead of the key name by itself.


bug-fix: handle complex file names

Please check below, if the PR fulfills these requirements:

[ ] The commit message follows the guidelines.
[ ] Tests for the changes have been added (for bug fixes / features).
[ ] Docs have been added / updated (for bug fixes / features).

What kind of change does this PR introduce?

bug fix for https://github.com/rancherfederal/hauler/issues/175

What is the current behavior?

https://github.com/rancherfederal/hauler/issues/175

What is the new behavior (if this is a feature change)?

hauler will unescape url file paths when creating the reference name.
hauler will make sure that file names are converted to lower case when creating the reference name.
hauler will replace "+" with "-" when creating the reference name.
hauler will keep the original file name intact despite the above conversions for image reference name.

Does this PR introduce a breaking change?

N/A

Other information:
My testing:
apiVersion: content.hauler.cattle.io/v1alpha1
kind: Files
metadata:
  name: rancher-airgap-packages
spec:
  files:
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/l/libstdc%2B%2B-11.4.1-2.1.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/p/perl-TermReadKey-2.38-11.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/p/perl-Text-ParseWords-3.30-460.el9.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/d/dbus-common-1.12.20-8.el9.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/l/libxcrypt-4.4.18-3.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/p/python-unversioned-command-3.9.18-1.el9_3.1.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/l/libevent-2.1.12-6.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/l/libxcrypt-4.4.18-3.el9.i686.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/b/basesystem-11-13.el9.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/c/container-selinux-2.221.0-1.el9.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/s/setup-2.13.7-9.el9.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/p/python3-distro-1.5.0-7.el9.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/s/selinux-policy-targeted-38.1.23-1.el9_3.2.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/s/selinux-policy-38.1.23-1.el9_3.2.noarch.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/n/nettle-3.8-3.el9_0.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/p/pcre-8.44-3.el9.3.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/j/json-c-0.14-11.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/l/libcbor-0.7.0-5.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/l/libacl-2.3.1-3.el9.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/g/glibc-gconv-extra-2.34-83.el9.7.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/g/glibc-common-2.34-83.el9.7.x86_64.rpm
    - path: https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/g/glibc-2.34-83.el9.7.x86_64.rpm

❯ hauler store sync -f quick-test.yaml
8:08PM INF syncing [content.hauler.cattle.io/v1alpha1, Kind=Files] to store
8:08PM INF added 'file' to store at [hauler/libstdc---11.4.1-2.1.el9.x86_64.rpm:latest], with digest [sha256:30ac1ad1a0e90c93ebe3dfd5a05f731b4f7f25b6537dba9d9ecf8174cd17e7bc]
8:08PM INF added 'file' to store at [hauler/perl-termreadkey-2.38-11.el9.x86_64.rpm:latest], with digest [sha256:cb95da0a3190dd79cc39aebda359bebdfea1e619671296923d78ed2e875335c4]
8:08PM INF added 'file' to store at [hauler/perl-text-parsewords-3.30-460.el9.noarch.rpm:latest], with digest [sha256:aed280292d2c6e45a3c0cecfd8e0d57b165c0c041affa0712b23470d7fbd965e]
8:08PM INF added 'file' to store at [hauler/dbus-common-1.12.20-8.el9.noarch.rpm:latest], with digest [sha256:8139c8dd8b8dfce069e20e4ec9a42d9989555ac44a609d4abf96decdb5d5024b]
8:08PM INF added 'file' to store at [hauler/libxcrypt-4.4.18-3.el9.x86_64.rpm:latest], with digest [sha256:e55139115dabaed38fa0255681ab67bf0e3099fba40939c97e037b53895fb130]
8:08PM INF added 'file' to store at [hauler/python-unversioned-command-3.9.18-1.el9_3.1.noarch.rpm:latest], with digest [sha256:779d709465be347efd9f5ff60ad20c4d8a613f2ad92cef8998ccac2d8e723d9f]
8:08PM INF added 'file' to store at [hauler/libevent-2.1.12-6.el9.x86_64.rpm:latest], with digest [sha256:1504527b5f8101e3b18fa4709bd52b1e4e0aab1589b3fa7450f13bc626d0f456]
8:08PM INF added 'file' to store at [hauler/libxcrypt-4.4.18-3.el9.i686.rpm:latest], with digest [sha256:8758b6148e1f1cbc42bce8778596bdbdde528380f2edc124a0a77610e20ed5d4]
8:08PM INF added 'file' to store at [hauler/basesystem-11-13.el9.noarch.rpm:latest], with digest [sha256:51d6e3bbae29a480c139b119278a0a143f778a5c0f7b8b75796583dcc46f9e2b]
8:08PM INF added 'file' to store at [hauler/container-selinux-2.221.0-1.el9.noarch.rpm:latest], with digest [sha256:0bc95fe39b032298e4760b4354e4237dda52f4286b4f9f1366e4d2f24322ebdf]
8:08PM INF added 'file' to store at [hauler/setup-2.13.7-9.el9.noarch.rpm:latest], with digest [sha256:c43bde781b9e59f1e509afd60724b41732ea27d542011478ba5fd8bf20275560]
8:08PM INF added 'file' to store at [hauler/python3-distro-1.5.0-7.el9.noarch.rpm:latest], with digest [sha256:45573dacccf0b0142f4e96ff3f4be7a66a6fba367815c3f5e815bbffb05c764f]
8:08PM INF added 'file' to store at [hauler/selinux-policy-targeted-38.1.23-1.el9_3.2.noarch.rpm:latest], with digest [sha256:9c2549c146760aa2f9b110d88f1f1b6bf30fc911fb5d1e23c3ef61a7a78b9b04]
8:08PM INF added 'file' to store at [hauler/selinux-policy-38.1.23-1.el9_3.2.noarch.rpm:latest], with digest [sha256:c25589b15bfb5e0a10d7f69be5de0f61d4305a645a9d3735db5437c67927cc16]
8:08PM INF added 'file' to store at [hauler/nettle-3.8-3.el9_0.x86_64.rpm:latest], with digest [sha256:99c10668ce506ad4562f51af11e6440f69b1ab0a70916811b0839783756f1c03]
8:08PM INF added 'file' to store at [hauler/pcre-8.44-3.el9.3.x86_64.rpm:latest], with digest [sha256:32a2a9e1568c53c733ae4aaa1142a078967eda418248dcb2e2be5f0d510f5e67]
8:08PM INF added 'file' to store at [hauler/json-c-0.14-11.el9.x86_64.rpm:latest], with digest [sha256:8ead98d28b262b217af7c5c8b23f227f163f96f9f99c8de2ead9872dafa3f182]
8:08PM INF added 'file' to store at [hauler/libcbor-0.7.0-5.el9.x86_64.rpm:latest], with digest [sha256:41c26c1f8561719ad0227530dfcf07ad62172b6faca35c94fca1ab37b3b86bef]
8:08PM INF added 'file' to store at [hauler/libacl-2.3.1-3.el9.x86_64.rpm:latest], with digest [sha256:cd3e4be67d89671f7a81e8b4e9d17eb9095f3888b447b6b44fe50cdf75eb1928]
8:08PM INF added 'file' to store at [hauler/glibc-gconv-extra-2.34-83.el9.7.x86_64.rpm:latest], with digest [sha256:f929312a0e1360dd6e957eab115efac7d714c304fe4598ad5ecb92f0861d92dd]
8:08PM INF added 'file' to store at [hauler/glibc-common-2.34-83.el9.7.x86_64.rpm:latest], with digest [sha256:483976c696746e1de5bb17e754f833e2f1744ebdacc8397b0e4efaa8e4be72ba]
8:08PM INF added 'file' to store at [hauler/glibc-2.34-83.el9.7.x86_64.rpm:latest], with digest [sha256:706dfb2c08a5f6415ddea9b9e1cf4169697a5e6f845fdfb8d986867356b2e4cb]

❯ hauler store extract hauler/libstdc---11.4.1-2.1.el9.x86_64.rpm:latest
❯ ls -la
-rw-r--r--   1 amartin  staff  753710 Feb 15 20:10 libstdc++-11.4.1-2.1.el9.x86_64.rpm

Thanks for tackling this @amartin120. Did you do any testing with local files? Remote files did fail for me, so that's good to see they were fixed, but so did local files.

@zackbradys Yes sir!
❯ hauler store add file libstdc++-11.4.1-2.1.el9.x86_64.rpm
8:19PM INF added 'file' to store at [hauler/libstdc---11.4.1-2.1.el9.x86_64.rpm:latest], with digest [sha256:f5635d341ecaa9587e1cfa94c4e0a3f343b3b0ae83b8c295abf5c228291be652]

If anyone is curious on the use case: https://github.com/zackbradys/rancher-airgap/blob/main/examples/os-packages-example.md


Test: playback ends up sending out live requests

The test error looks like, msrestazure.azure_exceptions.CloudError: Azure Error: SubscriptionNotFound Message: The subscription '00000000-0000-0000-0000-000000000000' could not be found.
2 notes:

It does pass sometimes through.

The stack below shows live connection is being constructed
HTTPSConnectionPool._validate_conn in connectionpool line 788	Python

HTTPConnectionPool._make_request in connectionpool line 345	Python
HTTPConnectionPool.urlopen in connectionpool line 559	Python
HTTPAdapter.send in adapters line 376	Python
Session.send in sessions line 576	Python
Session.request in sessions line 468	Python
ServiceClient.send in service_client line 189	Python
RoleAssignmentsOperations.create in role_assignments_operations line 297	Python
_create_role_assignment_with_retries in custom line 2130	Python
assign_vmss_identity in custom line 2089	Python
_execute_command in create_command in init line 527	Python
CliCommand.call in init line 351	Python
Application.execute in application line 211	Python
main in main line 36	Python
ExecutionResult._in_process_execute in base line 149	Python
ExecutionResult.init in base line 94	Python
ScenarioTest.cmd in base line 74	Python
MSIScenarioTest.test_vmss_msi in test_vm_commands line 1985	Python
_preparer_wrapper in AbstractPreparer.call in preparers line 60	Python
TestCase.run in case line 601	Python
TestCase.call in case line 649	Python
TestSuite.run in suite line 122	Python
BaseTestSuite.call in suite line 84	Python
TestSuite.run in suite line 122	Python
BaseTestSuite.call in suite line 84	Python
TextTestRunner.run in runner line 176	Python

wrong repo.


When SOAP or ITK validation fails, should it be Client error (4xx) rather than Server error (5xx)

Description
When validation fails should it be a client error status in the HTTP status code?
At the moment is 500
The implication of this is the status code implies something wrong in the server, so it implies the server needs a fix (deployment, or implementation code), while actually, the problem is the client needs to send a correct message with the correct configuration. So, when the client received this error, they assume the server may be temporarily down and retry it later. While if the client receives 400x (client), they should assume something wrong with their configuration or code.
Component
NHS111 adapter
Version
0.2.0
Step to Reproduce
Send a message with invalid SOAP
Test Data
Any data
Preconditions
None
Environment
local environment
Severity
high
Priority
low
Expected Behavior
should return 4xx HttpStatus Code

Hi @Kusnaditjung  l've spoken to a couple of other people here at NHS Digital about this one.
While we would agree that it might seem strange to return a 500 error for something that the client got wrong, the following suggests that in particular when using SOAP any SOAP faults (which would include malformed or incorrect soap headers)  MUST be returned with a code 500.
See https://www.ibm.com/support/pages/soap-faults-must-be-sent-http-500-error-code
And https://www.w3.org/TR/2000/NOTE-SOAP-20000508/ section  6.2
“In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error.”
So for typical http usage its rather odd but for SOAP we would say the spec was correct.

I see this issue can be closed.

It seems if the error is SOAP related there seems specs to mandate 500, just wonder if ITK or CDA related error, or we treat them all the same anyway?


does theanets support gradient of subtensor?

this is useful for large lookup table

As far as I know theanets supports any ops that theano supports.
This would probably be a better question for the mailing list! https://groups.google.com/forum/#!forum/theanets


Feature Request: Display As Bool

Alternatively, since this most often happens in if (var == 1) lines, it could be solved by removing the == 1 when the variable is a bool.

We talked about this a little bit on Slack 2-3 weeks ago and I'm still leaning heavily wontfix on this.
There's no guarantee that a bool, in a lot of compiled languages, will actually be constrained to the values 0 and 1. If the underlying code is explicitly checking for the value 1, I pretty firmly believe that emitting if (var == 1) is the right thing to do. The only time I would want if (var) to be shown instead is if, through value set analysis, we can prove that only two values are possible.
And, in case anyone thinks negative bool values aren't a thing, Windows has something to say about that.
Open to arguments to the contrary and would be willing to reopen this, but I think we're doing the right thing here.

What about the bool type that BN supports? This is not the same as Win32 BOOL (which is just an int alias). AFAICT, BN's bool is the same as C++ bool, which just has true and false.
Consider this code:

(Both conditions in the if are using bool-typed values.)
Readability here would be improved considerably if BN just trusted that when I type something as bool, it really means Boolean.

The original issue wasn't talking about a bool type specifically, it was talking about any comparison to 0 or 1.
But, even in C++, you can put a value other than 0 or 1 into a bool. It being a keyword doesn't actually change the fact that the underlying implementation is just the same as C's.
When compiling, most C++ compilers will convert any non-zero value to a 1 in the absence of any trickery because the language specifies that it should be 0 or 1. But, during execution, what happens is entirely compiler-defined. For example, gcc will check for the exact value of 1 while clang will check for the lowest bit being set. Feel free to use this link to see the difference and switch between compilers.
This can make this simplification gnarly: Which sequence(s) of checks do we lift to !__scrt_is_ucrt_dll_in_use() && nested versus what's in your screenshot? And, post-simplification, can you really trust that we're showing you the right thing? Your example doesn't even match the current default behavior of msvc when handling the return value from the function (which I'm guessing is because it's actually an int, but may also be older or optimized behavior) - it would treat any non-zero value as true.
If the variable is explicitly typed as a bool (lowercase only), I could see a potential argument for making the simplification in that exact case only. I would assume, at that point, that the user has either had to apply outside type information that suggests the compiler itself saw that as a bool (and likely emitted code that conformed) or is trying to hint to us that they would prefer simplified output. But, I'm not really sold that this simplification would improve readability "considerably" or that it's worth us spending time on with so many other, more pressing readability concerns.
Open to additional discussion, but I'm keeping this closed for now. I think the current implementation is the least error-prone and least surprising.

I was searching for an issue on comparisons for bool-typed variables. I interpreted "when the variable is a bool" to mean "when the variable is typed as bool" so I just figured I'd comment here. 🙂 We can definitely spin this discussion off into a separate issue if that's more appropriate.
To be clear, I would only advocate for Boolean simplifications to happen on variables/locations that are explicitly typed as bool (i.e. the C++ bool or C _Bool). I also think it would be reasonable to make it an off-by-default feature so users have to opt in and, in the process of doing so, hopefully see the setting description that warns appropriately.
But, even if you don't want to do the full simplification effort here (which is understandable), I think a simple transformation for the patterns x != 0 -> x and x == 0 -> !x (where x is bool) would go a long way for what I assume would be relatively little effort to implement. I think this simpler transformation is unambiguously safe (and so could always be on), and is philosophically somewhat similar to how BN will already show true/false when assigning 1/0 to a bool location.
Regarding compiler behavior, it varies even further if you compile with -O3. 😆 I think the default behavior is intended to help you catch UB in unoptimized mode, since it's clearly not the optimal way to do the check. Anyway, unfortunately I only ever really analyze Windows binaries, so I have limited knowledge on how these patterns tend to get lifted by BN. All I can say is that in my experience analyzing Windows binaries, I've only come across x != 0 and x == 0 for bool.

For the particular example I gave, it is in fact bool - you can verify by comparing to CRT source code that ships with MSVC and the Windows SDK. I believe that particular code is also compiled as C++, but is effectively written as "slightly better C" using e.g. enum class and other such features.
Here's the assembly for that function:

(The usage of 8-bit registers in this way is usually a good tell that the source used bool.)

Okay, I've thought about this a lot more and had a few extra side conversations about it, and I think it could make sense to do this in a very limited set of scenarios behind an option.
I'm reopening this issue, but tagging it with appropriately low priority since I think this could be a fair amount of work to get right and we have a number of other, more pressing display issues. But, I'm no longer completely resistant to the idea and I think we could make something that would work for the users that would prefer to have output be less verbose.


Implement support for WasmEdge

WasmCloud could support multiple alternative wasm runtimes to take advantage of the unique features and performance characteristics of each.
I would like to propose that WasmCloud add support for the WasmEdge Runtime through WasmEdge's Rust SDK.
https://github.com/WasmEdge/WasmEdge/tree/master/bindings/rust
If there is anything we could do to help. Please let me know. Thanks.

Hey @juntao, it's been a little while! With the effort that @tessi recently just put into refactoring from wasmer to wasmtime, I think implementing wasmedge as well would really require the largest effort in writing the custom NIF. Are you aware of any efforts here? I just don't want this issue to go too stale 🙂

Hey! sorry @juanto
Wasm and with it all the different wasm engines is just moving to fast for me to maintain multiple engines. I just can't do that besides family and day job. If you or someone wants to give it a try, I'd be happy to give you an intro into the problem space and wasmex code base :)

Hey! sorry @juanto
Wasm and with it all the different wasm engines is just moving to fast for me to maintain multiple engines. I just can't do that besides family and day job. If you or someone wants to give it a try, I'd be happy to give you an intro into the problem space and wasmex code base :)

You've been putting in amazing effort. I don't think anybody would expect you to support swapping in and out of "all the engines"

No worries!
We have recently worked with several companies and projects to support WasmEdge together with wasmtime. The process is typically to replace wasmtime's GO or Rust SDKs with WasmEdge's. Those APIs are fairly similar. We have done it many times -- we are actually thinking about creating an abstract API on top of those SDKs to support easy switching. ;)
The typical reasons to support both runtimes are:
1 Supply chain security -- since wasmtime and WasmEdge are based on completely different tech stacks (Rust + Cranelift vs C++ + LLVM), they are unlikely to be affected by the same bugs.
2 Additional features provided by WasmEdge such as web service, database, AI inference, Kubernetes / Docker and JavaScript support.
Of course, I understand different projects have different priorities. I am not that familiar with the Erlang / Elixir ecosystem but would love learn more to understand how we can better support it! 🙏🙏🙏

😊 thanks everyone! didn't mean this to be hunting for compliments 🙈

we are actually thinking about creating an abstract API on top of those SDKs to support easy switching

sounds very interesting especially if it's not a vendor lock-in and well maintained and on-par with wasmtime!
I probably continue the port to wasmtime first and investigate further steps from there.

I [...] would love learn more to understand how we can better support it!

Is there anything specific you'd like to know? Feel free to reach out on twitter or @tessi on the elixir slack for wasmex-specifics and a more real time'ish chat and to not sidetrack this issue any further :)

We've done a whole lot of reorganization around how we're running Wasm engines, and I think for now we're going to proceed with support for wasmtime as the engine under wasmCloud. As soon as we get to rethinking pluggable / replaceable engines, I'd love to consider putting wasmedge as one of those engines


feat: react next upgrade

PR to handle the upgrade of React and NextJs. We are currently seeing prerender errors while building/running the next applications.
IMPORTANT: Do not merge as this is still a work in progress until the issues are resolved

It looks to have an issue with Nextjs 15:
https://github.com/webpack/webpack/discussions/19078


Update to igraph 0.9.0.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

This is an initial attempt, let's see how it builds.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [16, 17]

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@isuruf, I am trying to get the osx_arm64 operational, but I am facing some problems, could you help me out?
We had to jump through some hoops to get the CMake build system working, but that is (probably) functional at the moment. However, I now run into the problem that the dependencies that are installed on the osx_arm64 system are osx64 dependencies, not osx_arm64 dependencies. Hence, we cannot link against those dependencies:
ld: warning: ignoring file $BUILD_PREFIX/lib/libglpk.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file $BUILD_PREFIX/lib/libgmp.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file $BUILD_PREFIX/lib/libxml2.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file $BUILD_PREFIX/lib/libglpk.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file $BUILD_PREFIX/lib/libxml2.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file $BUILD_PREFIX/lib/libgmp.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

Could you perhaps point me in the right direction? If you have another feedstock that is linking against C libraries on osx-arm64 I could probably replicate the approach, but I could not find one immediately.

Thanks for the quick response @isuruf ! I will tweak it further from here...

Can you send a PR to add arpack and other missing dependencies to https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/osx_arm64.txt (for osx-arm64) and https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/arch_rebuild.txt (for linux-aarch64)?

Also, https://github.com/igraph/igraph/blob/4195a7075691ea4912c3f94021d84c02b6adc007/tests/CMakeLists.txt#L24 should be,
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-Wl,--disable-new-dtags")

Can you send a PR to add arpack and other missing dependencies to https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/osx_arm64.txt (for osx-arm64) and https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/arch_rebuild.txt (for linux-aarch64)?

Thanks, will do!

Also, https://github.com/igraph/igraph/blob/4195a7075691ea4912c3f94021d84c02b6adc007/tests/CMakeLists.txt#L24 should be,
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-Wl,--disable-new-dtags")

Great, thanks for the comment!

Let's use internal arpack for windows. I'll take a look when I get some time.


Develop

Codecov Report

Merging #11 (b835b01) into master (16bd0a2) will decrease coverage by 0.11%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
- Coverage   91.11%   91.00%   -0.12%
==========================================
  Files          25       25
  Lines         777      778       +1
==========================================
  Hits          708      708
- Misses         69       70       +1

Impacted Files
Coverage Δ

utils/plotter.py
68.49% <0.00%> (-0.96%)
:arrow_down:

Continue to review full report at Codecov.

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


Differing versions of google-auth-library

Differing versions of google-auth-library between googleapis (1.6.0) and googleapis-common (1.4.0) leads to TypeScript error.
Argument of type '{ auth: OAuth2Client; }' is not assignable to parameter of type 'GlobalOptions'.
  Types of property 'auth' are incompatible.
    Type 'OAuth2Client' is not assignable to type 'string | OAuth2Client'.
      Type 'import("/Users/sebastianedwards/Code/uprise/node_modules/google-auth-library/build/src/auth/oauth2client").OAuth2Client' is not assignable to type 'import("/Users/sebastianedwards/Code/uprise/node_modules/googleapis-common/node_modules/google-auth-library/build/src/auth/oauth2client").OAuth2Client'.
        Types have separate declarations of a private property 'redirectUri'.

Sorry, I should have clarified - this issue is the result of upgrading to<EMAIL_ADDRESS>While<EMAIL_ADDRESS>uses<EMAIL_ADDRESS>it now also depends on this library which in turn depends on<EMAIL_ADDRESS>The differences between these two versions causes the incompatibility error.

🤦♂

@SebastianEdwards I just cut a release with the fix - could you give this a try?

Thanks @JustinBeckwith - the new release has solved the problem 👍

Hi guys, looks like the issue came back
In my case:

googleapis: 34.0.0
google-auth-library: 1.6.1

TS2345: Argument of type 'import("C:/path/to/node_modules/googleapis/node_modules/google-auth-library/build/src/auth/oauth2client").OAuth2Client' is not assignable to parameter of type 'import("C:/path/to/node_modules/google-auth-library/build/src/auth/oauth2client").OAuth2Client'.
  Types have separate declarations of a private property 'redirectUri'.

Looks like the problem has surfaced again. And there is a major version diff -

google-auth-library --> ^3.0.0 (from `googleapis@39)
google-auth-library --> ^6.1.6 (latest google-auth-library)

Lowering the google-auth-library version to v3.0.0 solved the issue for now 👍🏽


Bundle with nuget

When I download git for Windows, then it has built-in support for 2FA for different providers like GitHub or VSTS.
Wouldn't it make sense to include this credential provider directly in the main nuget distribution? This would save projects from including installation instructions in their README files on how to get started with private Azure NuGet feeds. I consider this a problem, especially since this is only required when using the command line or VS Code. Opening a project in Visual Studio works out of the box as it has built-in integration with private Azure NuGet feeds and doesn't require any extra steps.

Because NuGet doesn't have a "distribution" in any sense other than "download this .exe file" from here, we decided with @anangaur and others from the NuGet team not to do any bundling here.
Separately, we are thinking about ways to build this into VS Code and into dotnet (which does have a distribution).

Note, as VS 2017 15.9 (or later) and VS Build SKU 2017 15.9 (or later) both install the credprovider, NuGet.exe 4.9 (or later) will be able to find that copy when run on that machine.


first commit to a github open source project

I did one minor italian translation edit to test the workflow while participating in hacktoberfest. I'm not a coder, so I'm still figuring it all out. More translations will be coming soon; hope I can be of help!

Hi, thanks for contributing.
I noticed from your GitHub profile you live in Arizona. Were you born in Italy and moved to Arizona or how do you know Italian?
I'm sorry if it feels overly personal for me to ask, Catima has had a lot of issues in the past with people translating languages they didn't speak that well so I want to ask so I can be sure the translations are of good quality :)

Hi there!
I was born in Germany, lived in Italy for most of my life and have moved to Arizona in April.
I have been working as a translator for over four years, and I actually translate English, German, Italian and French. Hope that provides some reassurance!
I understand where Catima is coming from, I have had to deal with/edit weird translations myself for my previous job and it can be a hassle.
This whole github/open-source thing is new for me, just wanted to give it a shot and see if I could be helpful.

Ah cool, thank you for confirming, that is really reassuring. I hope Arizona is treating you well :)
I see so far you only removed 1 incorrect line of text which, while definitely helpful, isn't really what I would consider a significant enough contribution. But if you translate a few more things I will definitely hit merge on this pull request to make your help count :)


[DisplayList] internal_nodes_canvas prevents full conversion of engine layers to a DisplayList interface

We've been slowly introducing optional code into the engine layers to render their output directly to a DisplayListBuilder so that we can maintain our current code base which is largely speaking to the SkCanvas API and also speak directly to the DisplayList interface in cases where calling through an SkCanvas call might lose information(*).
Unfortunately, we've started running into a common case where we use a saveLayer call on the internal_nodes_canvas object which broadcasts the saveLayer to a number of SkCanvas objects - typically one per embedded view in the PlatformView stack. In that case we must call saveLayer on the SkCanvas objects in order to broadcast the call as the optional leaf_nodes_builder object is only talking to the builder for the current embedding layer.
We either need to create an NWayBuilder type of object, or we need to completely switch over to DisplayListBuilder (or similar API) as our primary rendering API and have that speak to either Impeller or Skia in the back end.
(*) - mostly calls that involve an Sk...Filter object in the SkPaint object - many of those objects cannot be inspected well enough to store their parameters in a DisplayList that is being fed via an SkCanvas adapter.

The blockage for converting engine layers was solved by fixing https://github.com/flutter/flutter/issues/109579


Open file while preserving focus in the Explorer

When clicking a file in the Explorer using the mouse, the file is opened, but focus remains in the Explorer.
When navigating the Explorer using the arrow keys, files are not opened (and it seems this behavior is not wanted https://github.com/microsoft/vscode/issues/17682). Pressing Enter opens the selected file and moves focus to the editor. A way to open the selected file without moving focus from the Explorer would be really useful. This would make it easy to quickly navigate the Explorer and see what files look like. I propose that pressing Space in the Explorer opens the selected file while preserving focus in the Explorer.

Dup of https://github.com/microsoft/vscode/issues/28710


Adding a "Help" tab

It would be of benefit to have some sort of tab on the GUI for help, be it where to find help (the docs or the Discord) or for a potential feedback survey.

We need to really state all the stuff we want on this page. this is still too vague to be sent to mrjvs imo

It could be a glorified link page, with different buttons linking to articles on the Wiki. Or there could be small tips built into the app (like common fixes, like USB drivers, trying different ports/cables, see if the LED is blinking, etc) that don't require an internet connection.
What sounds best to you?

I think it would be good to have just a bunch of links for now, any specific help stuff could be displayed on the GUI wherever it's possible
I think it should be something like:
Docs Common Issues page
SlimeVR Discord
Maybe SlimeVR GitHub?

There is currently a link to docs as a question mark!


Build Guide: Errors at step "Building the .img"

Hey,
I was following your guide as a noob with help from a friend (your guide really is not that noob-friendly btw)
https://github.com/Start9Labs/embassy-os/blob/master/BuildGuide.md
and pretty much everything went well until to the point where I was building the image ( Step 7 ii ). It did start the process, but then somewhere in the process the error shown in the image appeared. No idea how to go on from here.

Thanks for the help in advance,

Oh and another maybe interesting part of the log:

Also emerging after the "make" command, somewhere in the middle. everything else looks good.

Nobody wants to help here? Anyone here who tried to build this software?

Sorry your build isn't working. We aren't going to have enough time troubleshoot this guide and update it between now and the release of 0.3.0 which will have an entirely new build process - also much simpler. My advice is to wait for that if you do not want to purchase an image.

When will be the estimated release of 0.3.0 ?

We're hoping in the next few weeks. Currently all of our development resources are working on the release of 0.3.0 which should reduce the complexity of the build process. It should be noted, however, that the build process itself is intended for experts and making it noob friendly has never been something we have put effort into. It isn't that we are opposed to making it noob friendly, it's just that we can't justify allocating resources to making it so, especially at this time when there are numerous people eagerly awaiting the 0.3.0 upgrade.
The original error you are running into seems very strongly like it is an error with your build environment and your node dependencies. Can you please specify what branch/commit you were building off of?

This is fixed by #381. If you are impatient and do not wish to wait for it to be merged you are free to try and build off of that commit directly. Otherwise you can wait for it to be merged and build off of master.


beautysh: patch "poetry" reference in pyproject.toml

Description of changes
Pull in https://github.com/lovesegfault/beautysh/pull/247, which I submitted upstream. The build-backend path was already correct, but the leftover reference to "poetry" instead of "poetry-core" fails the build when build is used.
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.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 248598 run on x86_64-linux 1

2 packages failed to build:

python311Packages.mdformat-beautysh
python311Packages.mdformat-beautysh.dist

4 packages built:

beautysh
beautysh.dist
python310Packages.mdformat-beautysh
python310Packages.mdformat-beautysh.dist

mdformat-beautysh failure will be fixed with #248677.


Fix ATF behavior during answerHeartbeatFromSDL = true

self.session.sessionId it is a table, so the expression self.session.sessionId == data.sessionId has always been false and ATF does not respond to HB from SDL
ATF does not respond to HB from SDL

@VVeremjova @LevchenkoS please review


Insufficient Documentation

Hello there! So the problem is that in the examples there are some things that work with the latest version but are not present in the docs such as graphic.LinearGradient().. I couldn't find documentation for it anywhere and I have no idea what the parameters stand for.. Could you provide me with some information or point me out to some v3 or v2 docs where I can check it out? Thanks in advance!

As I understand this API is from ZRender's LinearGradient. Is it right @Ovilia? And ZRender currently doesn't have English docs yet but Google Translate might offer help.

thanks a lot, seems to be it.. anyway, it would be good for it to be incorporated into the echarts docs since its part of its out of the box functionality

@bojidaryovchev Hi. Sorry for the misunderstanding.
We did not provide the doc for graphic.LinearGradient because it is suggest to use this instead, which can be found at #series-line.itemStyle.color:
color: {
    type: 'linear',
    x: 0,
    y: 0,
    x2: 0,
    y2: 1,
    colorStops: [{
        offset: 0, color: 'red' // color at 0% position
    }, {
        offset: 1, color: 'blue' // color at 100% position
    }],
    globalCoord: false // false by default
}


[Fix #10899] Fix an error for Lint/ShadowingOuterLocalVariable

Fixes #10899.
This PR fixes an error for Lint/ShadowingOuterLocalVariable when the same variable name as a block variable is used in return value assignment of if.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!