Merge with VintageousPlus?

@gerardroche hey would you consider merging with https://github.com/trishume/VintageousPlus ?
I know you mentioned in https://github.com/guillermooo/Vintageous/issues/1096 that you don't want to deviate from stock vim. I'm willing to give up deviating from stock vim by default for the greater benefit of collaboration and there being one clearly maintained better fork.
If I add anything that deviates from stock vim I'll add it behind a setting that is off by default. In my fork I already have a simple mechanism for adding functionality that can be enabled/disabled by a setting.
If you're open to this I don't know if you have strong preferences as to which direction the merge should go. I would suggest you merge in to mine, I have a name and a repo that isn't set up as a fork (so PRs work correctly), but I'm open to alternatives. I could merge into yours or we could merge into an organization.
Random logistics notes:

I think the name should be clearly based off of "Vintageous" so that people know it is a fork that is strictly better and don't worry about which they should use.
The merge will probably be riddled with conflicts, I'm willing to do the work to resolve them, but in order to resolve them I do need to know the name to go with.
If you don't want to deal with other people committing to master I'm willing to do all my work as PRs

I was going to ask you if you wanted to combine efforts too. A setting disabled by default for plus functionality is good for me.
How did you setup your repository? Create a new one, clone Vintageous, and then push it to the new one? I've been looking for an easy way to merge the pull requests from the original repository into mine but there doesn't seem to be one. But I think it best to deal with any pr's and merges before doing any more big changes. I'll see what merge conflict I get if I try merge yours with mine, see if I can resolve it and then worry about renaming the package later because I still intend on moving all the root directory .py files into a subfolder, removing more dead code, and generally reorganise things to make it easier to refactor and get some idea of what can be done to improve things.
I think creating an organisation for the project would be best.
On the name. I'm not sure about VintageousPlus. I'd rather not get it confused with vim-plus. If others are like me they won't like the idea of non standard vim operations. The name alone could deter them. As far keeping the name Vintageous. I'm also not sure we need to keep it as part of the name either. For example, Guillermo didn't feel the need to be tied to the name. We can add a "vintageous" tag to the package in Package Control and mention it being a fork in the description. When people search for alternatives they will search for "vim".
As far as committing to master. I don't mind commits to master. I usually branch and merge back to master when ready but I've been hacking away on master because it was just me and I'm trying to get the main cleanup repository done. As long as the tests keep passing I'm happy.

@gerardroche Cool. An organization sounds good.
I was mainly wanting to attract the people who search for Vintageous in the Sublime Package Control install menu, which doesn't search descriptions or tags, but shows descriptions. They'd see both Vintageous and a new package with a description that clearly says that it is strictly better.
I'm not sure how much people search for "vim" vs. "Vintageous". Vim is what they want, but there's quite a number of references to Vintageous on the internet, and people who already know that is what they want. Something with Vim in the name would probably work pretty well too.
As for what I did to set up my repo and merge PRs: I created a new empty repo, cloned Vintageous, added the empty repo as a remote and pushed maser to it. Then I used hub to merge the PRs from Vintageous into my repo.
As for merge strategies I think the best approach might be to create a branch off of my repo, do a find+replace of VintageousPlus with Vintageous, then merge. Although I forget if Git merging detects conflicts when you change something conflicting and then change it back. Then after the merge rename everything to whatever new name we choose. It's unfortunate that all the imports in the package are done in an absolute way so that the code is tied to the package name.
Here's some name possibilities, using the Sublime package convention of UpperCamelCase:

NeoVintageous: like NeoVim, has the right connotations, NeoVim is also a stricty better fork that is cleaned up and maintained. This one's my favourite.
Advintageous: pun on Advantageous, shows up in Sublime search because of substring. Downside: not obviously a vim plugin
SublimeVim
VimEmulator
Vimic: yourvim_mimic but contracted
VimMimic
OpenVim: to contrast with Six, which may be better, but isn't open source
VimLime

I didn't think about search via the PC menu.
NeoVintageous or NeoVim :) I actually use neovim over vim. I love that it's so compatible with vim, I only had to make trivial changes to my vimrc and it was an improved anyways.
Is it fair to use the name neovim? It might not even be accepted to the package control channel. Plus the neovim organisation is taken. So I think yeah, NeoVintageous. It's good. I like it.
lowercase vs CamelCase
neovintageous vs NeoVintageous
neovim tends to use lowercase consistently. OS's are case insensitive, urls too.

Great. I know it's written neovim very often, but there's two reasons I chose the casing I did:

Looking at https://packagecontrol.io it seems that the convention is that package names are capitalized, either UpperCamel or Title Case. I don't like the idea of having the package name written differently in the code than the title, hence why I didn't include a space. It seems reasonable to not deviate from package naming convention without a clear reason.
I keep creating projects where the canonical name is lowercase (e.g syntect) and every time I regret it since it looks weird when I write it at the start of an english sentence and I constantly feel obliged to write it in backticks like syntect instead of just syntect.

here it is: https://github.com/NeoVintageous I even quickly made a logo since organizations have a profile picture.

:+1:
Issues and discussion can be moved to NeoVintageous.

Hi Guys,
Just wanted to say one HUGE THANK YOU!


Doesn't initialize when opening file from filemanager

The server does not start if the file is opened via the filemanager plugin. I'm not sure which plugin causes this issue, so I'm filing it here for now.

Hi @kra-mo - thanks for reporting this. I will take a look into this to see how this happens.

I implemented a fix for the issue. Can you check it out and see if this fixed it for you too?
Thanks!

It did! Thank you! :)


galleria rotates a picture to landscape when switching to fullscreen

There's something really odd with a picture I have. Some other pictures of mine don't have that problem, but for some reason, when I switch to fullscreen in galleria with this special picture, it gets flipped as landscape even though it was displayed, properly, in portrait mode, when in normal mode.
Worse: when I go back from fullscreen, the image is still squeeze to the side, like this:

It's as if something inside galleria was flipping the image. This happens only when I have keep_orig enabled, here's the (minimal) config to reproduce this:
theme = 'galleria'
autorotate_images = True
copy_exif_data = False
keep_orig = True

I do not have consent to publish the image, so I would prefer if I could send you a sample in private.
Other themes do not seem to have that problem. Setting keep_orig to False works around the issue as well. I can reproduce this in Firefox 57 and Chromium 63.0.3239.84.

interestingly, use_orig has no effect: when galleria flips to fullscreen, sigal tells it to load the original file, and that breaks the rotation immediately.

and obviously, i can't reproduce this now anymore. Not sure what was going on with that picture, but sorry for the noise. :/

okay well, this damn bug is back. and now i have public photos to show it, which might make things easier here...
https://photos.anarc.at/cities/montreal/#/3
Note that this photos is fine:
https://photos.anarc.at/cities/montreal/#/4
The difference? The latter was exported by Darktable, while the former is straight from the camera... Could this be why there is a problem here? That pillow wouldn't detect the proper exif tags from the camera?

I see both with the correct (vertical) orientation

even in full screen?

here's a screencast (zip file because github doesn't support video!) of the problem from my point of view, just to make sure we're on the same page. this is Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0.

Ok, I can also see this actually, but I need to wait long enough because my network is slow and the files are big and galleria shows the low res file while it downloads the high res! So maybe an issue with the fullscreen plugin ? It would be interesting to check in galleria's changelog or git repo is there is something. I think there is more recent versions than the one bundled in sigal, but last time I tried to update the design was broken.

yeah, i was wondering if this could be solved by a theme update as well... i can't imagine that galleria has such a huge bug and no one noticed (although I did look at their issue queue, iirc and couldn't find anything)...

yeah, i was wondering if this could be solved by a theme update as well... i can't imagine that galleria has such a huge bug and no one noticed (although I did look at their issue queue, iirc and couldn't find anything)... my strategy right now is to wait for theme updates in sigal and try again :)

You're lucky, I pushed a branch with the theme update yesterday, and I just merged it (#296) :)

nice, i guess i need to try this out now!

at first glance, this seems fixed in 1.4.0 - thanks!!!

Good news! :)

hmm... unfortunately, it seems I am still seeing this bug in 1.4.0, sorry for the false positive. :( it does not seem like Galleria 1.5.7 fixed the problem and i still see originals rotate all over the place...


Error: missing field detail_level for key general at line 25 column 1

Describe the bug
When I start gpg-tui I immediately get this message and it then exits
Error: missing field `detail_level` for key `general` at line 25 column 1

To Reproduce
Steps to reproduce the behavior:

Run gpg-tui
See error

Expected behavior
No error, GUI instead.
System Information

OS: macOS Ventura 13.2

Rust Version: 1.67.0

GPGME version: 1.18.0

GPGME engine version: 2.4.0

Project Version: 0.9.3

Hello, thanks for reporting this! 🐻
It's a regression in 849d90df3a51a33c0fb2b863988282d8f645c5b3 and should be fixed via 0cecc714be9d0a37c7885aebdf5d1c6c055ccf97.
I will be releasing a new version shortly.

v0.9.4 is out!

I've confirmed that 0.9.4 works for me.
Thank you!


Feature Request: Improved CSS

Maybe just adopt a standard tailwind css template to improve the aesthetic?

hey. i know the ui is not great but rather have the flexibility of not using a template. were there specific aspects that you think should be improved?

I just noticed the colour preferences, thanks for that!

The ability to slide and save the boundary lines would be great
Add a colour preference for background as well
Ability to change font from a pulldown

these are great suggestions thank you! I don't think I will implement the slide bc this introduces a lot of complexity in maintaining layouts for different screen sizes, but I will definitely put the other 2 on the todo list.

@improvethings background and font customization is now in astral.

Hi, can you please point where the customisation exists? I have been trying to change default font but it seems like all standard ways of changing default font in Quasar are somehow being overriden.

hey there, font customization lives in astral's settings page. is that setting not working for you?


ignore Properties/launchSettings.json even if Properties is a subfolder

Reasons for making this change:
to support the situation that the Properties folder is a subfolder

@chucklu good point, thanks!


EXO V3 Module and Client Access Rules

We have client access rules (CARs) setup to block Exchange Remote PowerShell.  When the EXO V3 Exchange module is installed, our account is not recognized as having permission to run Exchange PowerShell commands.  We can downgrade to the 2.0.5 version of EXO V2 module and it works again.

@jlawso40, I asked that very questions about CARs when v3.0.0 of the module was released.
I'm sure that if you used the UseRPSSession switch in the connection command, then your CARs would work fine, as that switch makes the connection behave exactly like v2.0.5. It was the REST API connection (connecting without using the UseRPSSession switch) method that had me concerned.
Fortunately, I'm told that CAR support for REST API connections using the v3.0.0 module have been added, and are currently rolling out. Worldwide saturation is expected by mid-November.

Thank you.  I saw that switch and thought it might allow it.  I just have not had a chance to test it by upgrading the module again.  I have also heard that CARs will be going away by next September.  Supposed to be replaced by Continuous Access Evaluation.
https://techcommunity.microsoft.com/t5/exchange-team-blog/deprecation-of-client-access-rules-in-exchange-online/ba-p/3638563

@jlawso40 Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Update to 3.0.0-preview9 compatible version of Razor.

This shouldn't be merged until a preview8 release has been completed.

aspnet/AspNetCore#12701

does this need Roslyn update in omnisharp-roslyn too?

does this need Roslyn update in omnisharp-roslyn too?

It depends on 3.3.0 beta builds of Roslyn. So as long as omnisharp-roslyn is on 3.30 it should "just work" (tested everything out locally). That being said if Roslyn did some breaking changes between beta builds it's possible it falls over; at which point we can spend more time to align versions.


The available server factories are: [ GRPC_SERVER ] error, while passing grpc+verbs protocol!

Issue type
Support
Have you reproduced the bug with TensorFlow Nightly?
No
Source
source
TensorFlow version
2.15
Custom code
Yes
OS platform and distribution
Linux Ubntu 22.04
Mobile device
N/A
Python version
3.10
Bazel version
6.1.0
GCC/compiler version
clang-16
CUDA/cuDNN version
N/A
GPU model and memory
N/A
Current behavior?
I am trying to run a distributed training code using multi-worker mirrored strategy and I want the code to use grpc+verbs on a RoCE-capable network card. I have built the tensorflow from the source and since the "verbs" option is not there anymore, I've added the following lines in the .bazelrc file in tensorflow root direcory:
build:verbs --define=with_verbs_support=true
And passed --config=verbs and It's compiled successfully. Now when I want to use the grpc+verbs api in the code like the following (based on [https://github.com/tensorflow/tensorflow/issues/37622]) :
worker_index = 0  # For instance
os.environ['TF_CONFIG'] = json.dumps({
'cluster': {
'worker': ["<IP_ADDRESS>:12345", "<IP_ADDRESS>:12345", "<IP_ADDRESS>:123>
},
'task': {'type': 'worker', 'index': worker_index},
'rpc_layer':'grpc+verbs'
})
it gives me error:
tensorflow.python.framework.errors_impl.NotFoundError: No server factory registered for the given ServerDef
(The available server factories are: [ GRPC_SERVER ])
Could you please help me figure out how to run distributed training using multi-worker mirrored strategy on tensorflow using the verbs api ?
Standalone code to reproduce the issue
import tensorflow as tf
import keras
import os
import json

def get_compiled_model():
    # Make a simple 2-layer densely-connected neural network.
    inputs = keras.Input(shape=(784,))
    x = keras.layers.Dense(256, activation="relu")(inputs)
    x = keras.layers.Dense(256, activation="relu")(x)
    outputs = keras.layers.Dense(10)(x)
    model = keras.Model(inputs, outputs)
    model.compile(
        optimizer=keras.optimizers.Adam(),
        loss=keras.losses.SparseCategoricalCrossentropy(from_logits=True),
        metrics=[keras.metrics.SparseCategoricalAccuracy()],
    )
    return model

def get_dataset():
    batch_size = 32
    num_val_samples = 10000

    # Return the MNIST dataset in the form of a `tf.data.Dataset`.
    (x_train, y_train), (x_test, y_test) = keras.datasets.mnist.load_data()

    # Preprocess the data (these are Numpy arrays)
    x_train = x_train.reshape(-1, 784).astype("float32") / 255
    x_test = x_test.reshape(-1, 784).astype("float32") / 255
    y_train = y_train.astype("float32")
    y_test = y_test.astype("float32")

    # Reserve num_val_samples samples for validation
    x_val = x_train[-num_val_samples:]
    y_val = y_train[-num_val_samples:]
    x_train = x_train[:-num_val_samples]
    y_train = y_train[:-num_val_samples]
    return (
        tf.data.Dataset.from_tensor_slices((x_train, y_train)).batch(batch_size),
        tf.data.Dataset.from_tensor_slices((x_val, y_val)).batch(batch_size),
        tf.data.Dataset.from_tensor_slices((x_test, y_test)).batch(batch_size),
    )

# Set TF_CONFIG
worker_index = 0  # For instance
os.environ['TF_CONFIG'] = json.dumps({
    'cluster': {
        'worker': ["<IP_ADDRESS>:12345", "<IP_ADDRESS>:12345", "<IP_ADDRESS>:12345"]
    },
    'task': {'type': 'worker', 'index': worker_index},
    'rpc_layer':'grpc+verbs'
})

# Create a MirroredStrategy.
strategy = tf.distribute.experimental.MultiWorkerMirroredStrategy()
print("Number of devices: {}".format(strategy.num_replicas_in_sync))

# Open a strategy scope.
with strategy.scope():
    # Everything that creates variables should be under the strategy scope.
    # In general this is only model construction & `compile()`.
    model = get_compiled_model()

# Train the model on all available devices.
train_dataset, val_dataset, test_dataset = get_dataset()
model.fit(train_dataset, epochs=2, validation_data=val_dataset)

# Test the model on all available devices.
model.evaluate(test_dataset)

Relevant log output
2024-01-08 15:35:36.165997: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: SSE3 SSE4.1 SSE4.2 AVX AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
WARNING:tensorflow:From /users/maziyar/dnn.py:57: _CollectiveAllReduceStrategyExperimental.__init__ (from tensorflow.python.distribute.collective_all_reduce_strategy) is deprecated and will be removed in a future version.
Instructions for updating:
use distribute.MultiWorkerMirroredStrategy instead
2024-01-08 15:35:37.225240: E tensorflow/core/common_runtime/eager/context_distributed_manager.cc:783] No server factory registered for the given ServerDef: cluster {
  job {
    name: "worker"
    tasks {
      key: 0
      value: "<IP_ADDRESS>:12345"
    }
    tasks {
      key: 1
      value: "<IP_ADDRESS>:12345"
    }
    tasks {
      key: 2
      value: "<IP_ADDRESS>:12345"
    }
  }
}
job_name: "worker"
default_session_config {
  device_count {
    key: "CPU"
    value: 1
  }
  device_count {
    key: "GPU"
    value: 0
  }
  device_filters: "/job:worker/task:0"
  gpu_options {
    experimental {
    }
  }
  allow_soft_placement: true
  graph_options {
    rewrite_options {
      scoped_allocator_optimization: ON
      scoped_allocator_opts {
        enable_op: "CollectiveReduce"
      }
    }
  }
  experimental {
    collective_group_leader: "/job:worker/replica:0/task:0"
    coordination_config {
      service_type: "standalone"
      service_leader: "/job:worker/replica:0/task:0"
      enable_health_check: true
      coordinated_job_list {
        name: "worker"
        num_tasks: 3
      }
    }
  }
}
protocol: "grpc+verbs"

The available server factories are: [ GRPC_SERVER ]
Traceback (most recent call last):
  File "/users/maziyar/dnn.py", line 57, in <module>
    strategy = tf.distribute.experimental.MultiWorkerMirroredStrategy()
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/util/deprecation.py", line 383, in new_func
    return func(*args, **kwargs)
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/distribute/collective_all_reduce_strategy.py", line 255, in __init__
    self).__init__(cluster_resolver, communication_options)
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/distribute/collective_all_reduce_strategy.py", line 186, in __init__
    CollectiveAllReduceExtended(
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/distribute/collective_all_reduce_strategy.py", line 339, in __init__
    self._initialize_strategy(self._cluster_resolver, devices=devices)
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/distribute/collective_all_reduce_strategy.py", line 358, in _initialize_strategy
    self._initialize_multi_worker(cluster_resolver)
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/distribute/collective_all_reduce_strategy.py", line 530, in _initialize_multi_worker
    context.context().ensure_initialized()
  File "/users/maziyar/.local/lib/python3.10/site-packages/tensorflow/python/eager/context.py", line 619, in ensure_initialized
    pywrap_tfe.TFE_EnableCollectiveOps(context_handle, server_def_str)
tensorflow.python.framework.errors_impl.NotFoundError: No server factory registered for the given ServerDef: cluster {
  job {
    name: "worker"
    tasks {
      key: 0
      value: "<IP_ADDRESS>:12345"
    }
    tasks {
      key: 1
      value: "<IP_ADDRESS>:12345"
    }
    tasks {
      key: 2
      value: "<IP_ADDRESS>:12345"
    }
  }
}
job_name: "worker"
default_session_config {
  device_count {
    key: "CPU"
    value: 1
  }
  device_count {
    key: "GPU"
    value: 0
  }
  device_filters: "/job:worker/task:0"
  gpu_options {
    experimental {
    }
  }
  allow_soft_placement: true
  graph_options {
    rewrite_options {
      scoped_allocator_optimization: ON
      scoped_allocator_opts {
        enable_op: "CollectiveReduce"
      }
    }
  }
  experimental {
    collective_group_leader: "/job:worker/replica:0/task:0"
    coordination_config {
      service_type: "standalone"
      service_leader: "/job:worker/replica:0/task:0"
      enable_health_check: true
      coordinated_job_list {
        name: "worker"
        num_tasks: 3
      }
    }
  }
}
protocol: "grpc+verbs"

The available server factories are: [ GRPC_SERVER ]

Hi @Maziyar-Na ,
I was able to reproduce the issue on Colab using TF v2.15. Please find the gist for your reference.
Thank you!

Thanks @Venkat6871 !
Is there any solution? I want to run TF 2.15 using verbs api.

Hi @Maziyar-Na ,
IMO, verbs support not available in 2.x versions. There are few issues attached here for more details.


fixed the extra white space below carousel

Related Issuse or bug

bug: extra space below carousel in homepage.

Fixes: #103
Describe the changes you've made
I've changed the dimensions of margin of footer from the carousel. This removes the extra white space caused due to 'auto' margin.
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Describe if there is any unusual behaviour of your code(Write NA if there isn't)
NA

@swapnilsparsh Shall I limit the web pg height ? Or increase the footer length?

@swapnilsparsh Shall I limit the web pg height ? Or increase the footer length?

Don't increase the footer length, you can try by doing some changes in carousel.

Hey @saaiswetha,
Any updates? Are you able to do the changes?

Hey @saaiswetha,
Any updates? Are you able to do the changes?

I tried to modify the carousel length but its overfitting the pg. But I checked mobile preview also, there are no extra white spaces below carousel.

Fix this

Because of the changes you made, there are no extra white spaces below the carousel. But there is extra white space below the footer. Please have a look.

Fix this

Because of the changes you made, there are no extra white spaces below the carousel. But there is extra white space below the footer. Please have a look.

Yeah I got it. I've fixed that now, could you check it out.

@sakshikhachane Yeah got it. I've fixed that now, could you check it out.

The font size is enlarged with respect to different previews , if I try to keep the size fixed a space below footer is coming.
Not able to do both i.e keep the font size fixed and avoid the space below footer.  (the font size can be kept fixed using
initial scale tag but this causes space below footer).

You can try scrolling down, gif is not going inside navbar.

Hey @saaiswetha,
I have checked it again, the gif is going inside the navbar. Please fix it.


Could you write simple guide?

Could you write a simple guide about how to use it?

Yeah i could write one later on my pc

Bump.
I dont understand what to do with all those jars lol

https://github.com/mkotb/MineCloud/wiki/Installation


Question about the pseudo-parallel data in the DualRL training stage

Thanks for your great work!
I have a question for the pseudo-parallel data used in the annealing pseudo teacher-forcing stage: From your paper, I notice the pseudo-parallel data is generated on-the-fly using the latest model. However, I find the codes for this in the dual_training.py, as shown below,
https://github.com/luofuli/DualRL/blob/7983ec08900395ea1fe22861dd944b426b9c6064/dual_training.py#L84-L86
https://github.com/luofuli/DualRL/blob/7983ec08900395ea1fe22861dd944b426b9c6064/dual_training.py#L308-L317
just load paired data from args.tsf_train_data which stores the pseudo-parallel data generated by the template-based approach for pretraining, instead of generating with the latest model.
Did I understand this correctly? Have I missed anything?
Thank you.

Uh oh! I made a mistake here when I cleaned the code. I have deleted the code which uses the pseudo-data generated on-the-fly but preserved the code which uses the original pseudo-parallel data.

Wait for a minute, I will update the code! Thanks!

Thank you very much for your reply @luofuli .
But It seems there is still a problem. The mid_ids_in_bs is the transferred output from source style A to the target style B. Shouldn't this be used as the input_ids together with src[''ids''] as targets to train nmts_train[B] instead of nmts_train[A], since the generated text should be put in the source side?

Yes, you are right! I did not show you the whole code! The section of previous_b is right with you! I just do several ablation studies to validate which one can work!

Got it! Thanks a lot! @luofuli

I have updated the code! If you don't have any questions, you can close the issue! Thanks for your feedback!


Consideration / Tutorial update for modules we may not want to be made public on GitHub

Hello,
The current tutorial for creating a generic IOC starts with pushing the chosen module to GitHub.  This makes sense, but I think we need to be careful of the (admittedly small) number of support modules which may contain proprietary code that we shouldn't be publishing.
Some suggested steps for this:

Draw up a list of the modules which this applies to and make the list known within the group
Add a notice to these modules to warn any developer not to publish it publicly
Add a tutorial to these pages to describe what approach should be taken when creating a generic IOC for these types of modules

Thanks,
James

Thanks James.
Please could you note here any modules that you are aware of that fit this criteria.

A survey on Slack returned:

ADHamamatsu
Potentially ADOdin as it may contain detector modules which fall under this
xspress-detector but this is being actively looked at

An update regarding the xspress detector:
There are 3 repos to do with xspress:

xspress-detector - currently being worked on to make it publishable
xspress3 - not publishable and will probably remain as such
da-xspress3 - same situation as xspress3

I believe @GDYendell is looking into publishing xpress with correct attention to licensing.


Bump XMLCoder dependency to 0.8.0

Looks like 404 checks reported by pod lib lint are triggered by social_media_url in the podspec, this is now removed to make the checks pass.

@hodovani thank you 🙏


Maven dependency for yaml module has a misstype

Hi, I was trying to add a maven dependency for the yaml module, but maven didn't want to resolve the dependency for some reason.
After some investigation, I noticed, that the actual dependency artifactId is called annotationconfg-yaml instead of annotationconfig-yaml (missing 'i' in "config")
Would be nice to fix :D

wow that typo exists since the library was created.. jeez
anyways, i will find time to fix it. thanks for spotting it tho


Sgdemux

Hello,
I have added minimal test data to be merged into the branch demultiplex. These files are necessary for testing a new nf-core module sgdemux.
Sincerely,
Samantha White

Wait, I take that back 😆
There should be a samplesheet with paths to samplesheet/out.sample_meta.csv and the fastq and the sample id. So something like
id, samplesheet, fastq
test,samplesheet/out.sample_meta.csv,testdata/sim-data/fastq.tar.gz

Or are you going to add that directly to demultiplex?

@Emiller88 If I have understood you correctly the changes in https://github.com/nf-core/test-datasets/pull/736/commits/49ff75284263017e91f718acfecf6330db866b08 should address your previous comment. Thanks!


JSONDecodeError: Expecting value

In func: load_static_map_image(center,api_key)
data = response.json() occurs error
Optional arguments that json.loads takes, raises requests.exceptions JSONDecodeError .
If the response body does not contain valid json.

Error occurs when we try to parse something that is not valid JSON as if it were.
To solve the error, make sure the response or the file is not empty, or conditionally check for the content type before parsing.
Common causes of the error:

Trying to parse invalid JSON values (e.g. single-quoted or with a trailing comma).
(not this) Getting an empty response from a remote server (e.g. 204 or 404) and trying to parse it as if it were JSON.
(not this) Trying to parse a response with a different Content-Type (e.g. text/html) as if it were JSON.
Trying to read a JSON file incorrectly or trying to parse the contents of an empty JSON file.

The response.json() method is used to extract and parse the JSON data from the response body. It internally calls the json.loads() function to deserialize the JSON data and convert it into a corresponding Python object.


conflate supported optional and unsupported optional into optional

This idea was floated by philip and aaron but neither had the chance to enter so I offered. I like it because it is simpler. now is the time to do it.
lets look at whaat the actions of software aree in different cases:

hw exists, supported optional
hw exists unsupported optional
hw doesn't exist supported optional
hw doesn't exist unsupported optional

for case 1 we'd like the sw to support it (e.g. context switch registers for vector) but it is still up to sw. if it can't handle it yet then it should check the ELF flag and Discovery (likley DT by that time) and not execute the binary. if it can handle it then it should do the right things.
for case 2, it behaves a lot like case 1 except a lot smaller group of implementations will likely support.
for cases 3&4 we'd like the sw not to execute binaries using the feature as opposed to running into an illegal instruction using the same method as described for case 1.
So in practicality I don't see an effective difference other than guidance which could be added in non-normative text.
It seems like a lot of complexity with very much actual impact.
am I missing something?

There's the aspects of what we want SW to do, but there's also a messaging and understandability component for any consumer of the Profiles spec proper. A single optional category is easier to explain without a lot of prose. And, I assert, that what we'll see in practice is that people will support the popular optional extensions in the SW as the original intent of the 'supported optional' category.

seems like that is a weak reason for manifesting 2 categories. It is hard
to explain to the world and again will not be treated any differently by
software. this could be handled with non-normative text. In my opinion the
names are not consistent with your intent. So a name like high priority
optional and low priority optional or strongly suggested optional and
optional (i don't like these names but you get the idea).
On Wed, Jul 13, 2022 at 2:08 PM Krste Asanovic @.***>
wrote:

Merging the two categories would substantially weaken one goal of profiles
which is to remove optionality and reduce fragmentation.
E.g., if P had been ratified in 2021, would you want P and V to be seen as
equal in RVA22?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-profiles/issues/61#issuecomment-1183679633,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP2OFRCDBAIJTHAQTMFCPQDVT4V3RANCNFSM5257VUWA
.
You are receiving this because you authored the thread.Message ID:
@.***>

RVA software will treat P and V differently.   I don't understand how putting everything in a single category and then having sub-categories with effectively the same meaning as the two original categories is preferred.  We're trying to remove optionality and give direction as to what hardware and software should coalesce the ecosystem around.

I continue to support the current categorization.
The lone "optional" category fails to connote intent.  We are trying to reduce the load on software developers, and we'd rather guide them towards focusing on things we actually expect will be relevant.
"Optional with low priority" is not much of an improvement over the lone "optional" category.  It still lends the impression that work should be done on the low-priority things at some point.  In fact, it would be better that no time be spent on the "unsupported optional" category, because doing so adds extra software complexity and distracts from other software efforts.

Proposal is to drop unsupported optional and incompatible from profiles spec, which would make this issue moot.

Done with https://github.com/riscv/riscv-profiles/commit/8525de8e97911398a6750cc9489a2c295f91b6df


[Eco news] The 'Read more' button does not redirect to the Single view of the particular news from the Home page, only after visiting the 'Eco news' page

Environment: all.
Reproducible: always.
Build found: 26.07.22
Preconditions

The Green City: https://www.testgreencity.ga/GreenCityClient/#/ is opened

Steps to reproduce

Scroll down to the 'Еко новини' informational section
Click on the 'Read more' button

Actual result
The user is not redirected to a single view of the news. The page is empty
read more .webm
Only after visiting the 'Eco news' page, the user is redirected to the single view of the particular news using the 'Read more' button
Expected result
The user is redirected to a single view of the particular news
User story and test case links
E.g.: "User story #351
Test case"

Duplicate #4638


Distributed KafkaChannel Sarama Client Refactor

This PR is a comprehensive refactoring of the Sarama clients (admin / producer / consumer) used in the distributed KafkaChannel implementation.  The reason for the refactor is to move closer towards an implementation that could be used by both Channel implementations.  The work of further refining the implementation, moving to pkg/common and using from the consolidated channel is left for the future as it is not a trivial exercise.
In general the creation of Sarama clients is not a complicated process so you might ask why would we need/want a common set of code for doing so.  There are two main reasons...

The distributed implementation provides support for Azure EventHubs as well as a "custom" sidecar proxy for the Sarama AdminClient's ability to Create/Delete Kafka Topics.  If this logic were common then the consolidated implementation would instantly gain this capability as well.
The Sarama library does not provide fakes or mocks for testing and is not coded against interfaces.  Therefore the distributed implementation provides an Interface for the AdminClient usage as well as testing utilities (mocks/stubs) for all the Sarama clients.

OK fine, but that doesn't explain why we need to refactor the current distributed implementation?  The answer is that for historical reasons the implementation was dynamically loading Secrets containing Kafka Authentication and adding them to the Sarama.Config provided.  This was done to support the "pooling" of Azure EventHub Authentication credentials in order to work around the Azure limitation of 10 EventHubs (Kafka Topics) per EventHub Namespace.  This refactor removes this pooling capability in favor of a simple approach whereby the Sarama.Config struct is expected to be complete and no Kubernetes resources are loaded.  This also allows the distributed implementation to align with recent changes around common configuration/authentication handling.
Great, but why doesn't this PR go further and actually make the new implementation a reusable component in pkg/common?  That was was the original intent of this work, but... recent changes to the consolidated have made the complicated.   New code was added to List the ConsumerGroups and cache them in order to maintain KafkaChannel Status.  The distributed channel has a different architecture and is able to do this tracking inline.  This means that the consolidated implementation is now using the ListConsumerGroups() from the Sarama.AdminClient which is cannot be supported by the Azure EventHubs (and likely the custom-sidecar) use cases.  Therefore, it makes sense to tackle that problem (if desired) as a separate effort that might consider one of the following approaches...

Refactor the listing/caching of ConsumerGroups in the consolidated implementation to eliminate this incompatability.
Add the ListConsumerGroups() functionality to the distributed implementations AdminClientInterface and find a way to support it for EventHubs/Custom-Sidecar usage.
etc..

Proposed Changes

Remove the dynamic lookup of K8S Secrets and the modification of the provided Sarama.Config from the AdminClient, SyncProducer, and Consumer clients and instead expect to be provided a complete Sarama.Config with all necessary Authentication already included.
Remove the EventHub Namespace Pooling thus limiting usage to 10 EventHubs (Kafka Topics)
Enhance the ability to "stub" the creation of these client to make unit testing easier
Enhanced unit tests a bit
Miscellaneous cleanup/enhancements

Release Note
Removed support for pooling Azure EventHub Namespaces and now only support a single Namespace/Authentication which limits Azure EventHub usage to their constrained number of EventHubs (Kafka Topics).

@travis-minke-sap I couldn't check every change but overall the changes look good. I would like to get this merged before I start working on https://github.com/knative-sandbox/eventing-kafka/issues/298
Could you fix the linting issue please?

@travis-minke-sap I couldn't check every change but overall the changes look good. I would like to get this merged before I start working on https://github.com/knative-sandbox/eventing-kafka/issues/298
Could you fix the linting issue please?

Thanks @aliok - appreciate you taking a look.  @eric-sap did a really thorough review so it should be good to merge once all the builds pass.  I just pushed the last linter issue - not sure how I missed that (blaming it on Friday Afternoon Syndrome ; )

Thanks @aliok - appreciate you taking a look.  @eric-sap did a really thorough review so it should be good to merge once all the builds pass.  I just pushed the last linter issue - not sure how I missed that (blaming it on Friday Afternoon Syndrome ; )

/assign

/assign


[DOCFIX] Add newline to readme file

Adds newline at the end of a README file.

alluxio-bot, merge this please


Deploy lambda function via s3

Closes #248
How did I implemented it?

Try to get the s3 bucket associated with the stack. If s3 bucket doesn't exist, create a stack with a template that adds a s3 resource and set its name to config. Here I am not setting a bucket name so AWS generates a random name for us.
If there is a s3 bucket associated with this stack, set its name to config.
Create/update the lambda function. In both cases I'm using ~s3.putObject~ s3manager.upload to upload the zip code and then deploying the function using bucket/key parameters.
If lambda function was created (not updated) then update the stack with lambda function parameters.
When deleting the stack we need to empty bucket first because cloud formation fails to remove non empty buckets.

wooottt thanks man! I'm pushing v0.2.0 soon, so I'll review this for v0.3.0

awesome PR!
Probably conflicts because v2.x conflicts is on master right now.
🙏

Hi @tj
I've resolved the conflicts.
Any progress on this?

I'm a little hesitant to add s3 manually for now, since Lambda uses S3 behind the scenes, I wouldn't be surprised if they just increase the size limit. The concurrent multipart-upload stuff would still be super cool though if we got that working

got it @tj
I'll try to replace the s3.S3.PutObject implementation by s3manager.Uploader.Upload (which uses multipart upload) when I have some free time.
Apparently it looks simple to do that.

awesome! I'll try and do some testing when I'm back home, I'm curious if the concurrent uploads would really improve the upload time since upload speeds are usually ISP-bound anyway, but I suppose for CI-based deploys it could be a nice win!

FWIW, we are deploying from CI and would appreciate this.

@agurtovoy why do you need this feature for CI? I deploy like:
sudo: required
language: go
go:
- tip
before_install:
- curl -sfL https://raw.githubusercontent.com/apex/up/master/install.sh | sudo sh
install:
- go get github.com/golang/dep/cmd/dep
- dep ensure -v
- dep status
script:
- cd $TRAVIS_BUILD_DIR
- go test -v ./...
after_success:
- test "$TRAVIS_BRANCH" = master && up deploy production
- up url production

@kaihendry We'd appreciate faster deployment times and higher size limit (not pushing it yet, but likely to be soon enough).

Laptop (35mb file):

regular: ~10s
multipart: ~11s

Laptop (512mb file):

regular: ~3m
multipart: ~1.5m

EC2 (512mb file):

regular: ~30s
multipart: ~15s

Seems worth it, especially in the cloud with a good connection. Plus that s3manager is a drop-in replacement for s3.New() which is nice.
For what I'd consider a "normal" sized app it seems negligible, none of my Go apps are larger than 30mb, but Node stuff gets pretty huge so it should help quite a bit there

Ha, looks like I jinxed myself. Just ran into the 50Mb deployment limit, looking forward to this.

Hi @tj
As we've discussed I've updated the PR with a simpler implementation for s3 bucket.
Could you please review?

Hi @tj
Any news?

hey sorry! been focusing on some other stuff before adding new features. Should be done this stuff in a day or two

ok @tj
Just let me know when you are ready to review this PR so I can resolve the conflicting files.

Sounds good thanks man! I think we should be ok to revisit this now. I wanted to see if reInvent would mention increased limits, but nope! So S3 is the way to go I guess.

@tj
Conflicts were resolved.

we also need to account for existing projects which may not have the bucket, but with Fargate maybe it's not even worth trying to hack this stuff into Lambda, I think I'd rather prioritize Fargate, we need S3 cleanup as well

Hi @tj
I've made the changes you mentioned:

Rollback deploy() code to the old semantics.
Account for existing projects which may not have the bucket

Could you review again?

awesome thanks man! looks great. It's at least ~35% faster for a 28mb app, curious how it'll impact even larger apps.
the only thing we need to figure out now is the S3 bucket name, up-deploy-NAME will clash with others since S3 buckets are globally scoped at the region level.
The only thing I can think of is fetching the account ID, or we could use a random name and save it to up.json so it can be referenced later but that feels more hacky.

Curious, what if all up deploys went into up-deploy/ and each "deploy" followed the naming convention of appName/region/version? then at the end of it all you'd never clash with names and you'd have all deploys in one s3 bucket
example path: up-deploys/gh-polls/us-east-1/xxx

ah can grab the account id from the role we prime, so that'll be ok.
@hhsnopek yea one bucket might not be bad, but complete isolation might prevent some accidental deletions

Sorry if this is a stupid question, I'm sure it is, but is S3 a valuable target once Fargate is available? Is there anyway we can save a lot of this hard work for Fargate compat?

@lukeed yes and no I guess. It's definitely less important with Fargate as an option, but S3's multi-part deploys speed things up for the Lambda case.
Lifting the size restriction isn't a huge win IMO, since an app that huge is doing something wrong in my opinion haha, but faster uploads is nice.

:v:


removing tests for data downloader dependent on third party website, change in test dataset for test_time_series_neighbors

Two testing improvements:

Remove test for data downloads that is dependent on a third party website #1257

Change test dataset in test_time_series_neighbors to use UnitTest instead of ItalyPowerDemand.  #1235

Oh look, it's this again https://github.com/alan-turing-institute/sktime/issues/1194
@aiwalter, @RNKuhns

Sporadic, so I'll rerun the whole lot!

ran again and it goes away


Using pylance with pytest.raises

I'm looking for a way to use pylance with pytest.raises without getting undesirable error diagnostics.
Here is a minimal example of the two error diagnostics I don't want to see.
class FooBar:
    def __init__(self, name: str):
        if not isinstance(name, str):
            raise ValueError('FooBar names must be strs')

        self.name: str = name

def test_foobar():
    with pytest.raises(ValueError): # issue 1
        a = FooBar(1) # issue 2

Issue 1
It appears that pytest.raises is inferred to return RaisesContext | ExceptionInfo and since ExceptionInfo is not a valid context manager pylance will tell me that this is bad.

Object of type "ExceptionInfo" cannot be used with "with" because it does not implement enter

Issue 2
In this case pylance is completely correct, but also completely unhelpful.
I am deliberately checking that doing this the wrong way does what I intend.

Argument of type "Literal[1]" cannot be assigned to parameter "name" of type "str" in function "init"

Which version of the pytest package are you using? With the latest version, I'm not able to repro the first issue. I suspect it has been fixed in the pytest code.
For the second case, that is expected behavior. The type checker is telling you that you are passing a value that does not match the declared type. There are a few options here:

If FooBar is a mocked type, you can define its constructor signature to take an object rather than str, since you're testing that it behaves correctly when sending in values other than str.
If FooBar is the real type you're testing, then you can suppress the errors that the type checker finds in your tests by using # type: ignore comments. Or you can suppress classes of errors in the file using a # pyright: reportGeneralTypeIssues=false comment at the top of the file.

I was able to solve issue 1 by updating pytest (to 6.2.2) as you suggested.
For issue 2, I am in the second case and the file-level suppression is a sufficient solution.
Thanks!

Given pytest 8.3.2 and pyright 1.1.377 I have "Issue 1" pyright errors today:
Object of type "ExceptionInfo" cannot be used with "with" because it does not implement enter

Given pytest 8.3.2 and pyright 1.1.377 I have "Issue 1" pyright errors today: Object of type "ExceptionInfo" cannot be used with "with" because it does not implement enter

@eklunko, I recommend entering a new issue on Pyright. I can't reproduce your problem with pytest 8.3.2 and this code here:
class FooBar:
    def __init__(self, name: str):
        if not isinstance(name, str):
            raise ValueError('FooBar names must be strs')

        self.name: str = name

def test_foobar():
    with pytest.raises(ValueError): # works fine
        a = FooBar("1")

@eklunko, I recommend entering a new issue on Pyright. I can't reproduce your problem with pytest 8.3.2 and this code here:

There might be a difference in how pyright and pylance process this code.
You're right, I should open a new issue. Thank you!


DDC throws type error instead of noSuchMethod when number of arguments is wrong

See the test corelib_2/null_nosuchmethod_test/01
This invocation of noSuchMethod has the wrong number of arguments (2, should be 1) and so should call the noSuchMethod method on the function (the function happens to be the standard noSuchMethod function).  Instead if throws a type error because the first argument is a string, where it should be an invocation.

@jmesserly
We should cleanup the treatment of these dcall errors & improve the error messages and stack traces.  All these are supposed to be NSM (could be different implementations of that type I suppose):

Wrong # of arguments
Wrong parameter type (we throw a type error, but don't tell you the function and param slot that failed)
Method doesn't exist

Wrong parameter type is tricky. I think the following would then be an infinite loop:
class MyInvocation extends Invocation {}
class A { noSuchMethod(covariant MyInvocation) => print("Arrived!"); }

main() => (new A() as dynamic).foo();

Wrong parameter type is tricky. I think the following would then be an infinite loop:

slight correction to the program (needs parameter name i, otherwise MyInvocation is the param name instead of the type)
abstract class MyInvocation extends Invocation {}
class A { noSuchMethod(covariant MyInvocation i) => print("Arrived!"); }

main() => (new A() as dynamic).foo();

... but yeah we need to keep that as a TypeError. We could certainly add more information to TypeErrors however, and we can fix this bug (wrong number of arguments is handled before type checking, and calls nSM)

.. slight correction to the program

Right, thanks!

As @matanlurey mentioned in https://github.com/dart-lang/sdk/issues/32564#issuecomment-376664813, we should make similar improvements to DDC's TypeError message.

https://github.com/dart-lang/sdk/issues/32653 is possibly a dupe of this

https://dart-review.googlesource.com/c/sdk/+/48940


Update "verbatim" latin phrase to "exactly as is"

SIG Docs recommends avoiding Latin phrases. "verbatim" is a latin phrase.
I've updated verbatim to exactly as is, which retains the "verbatim" latin phrase meaning.

/assign @bradtopol

Agreed! Closing PR. Thanks @sftim !


release followup: update examples

Besides that the examples needs some more work to get them working because of the breaking changes between 0.14.0 and 0.15.0 (and maybe other oversights).
I assume you would like to release 0.13.0 plugins asap. Maybe keep them unmodified (0.12.1/0.14.0) but working for now and fix them as followup once 0.13.0 is availble at npm.
Originally posted by @Flarna in https://github.com/open-telemetry/opentelemetry-js-contrib/pull/316#discussion_r562836815

Maybe we could include the samples somehow in the lerna project to avoid this release update ping-pong?
Clearly each of them would require some smoke test.

Maybe we could include the samples somehow in the lerna project to avoid this release update ping-pong?
Clearly each of them would require some smoke test.

They used to be included in the lerna project, but there were issues with the plugin system not properly patching modules due to lerna's linking.

They used to be included in the lerna project, but there were issues with the plugin system not properly patching modules due to lerna's linking.

They used to be included in the lerna project, but there were issues with the plugin system not properly patching modules due to lerna's linking.

Just opened https://github.com/open-telemetry/opentelemetry-js-contrib/issues/422, but I guess you've already tried this, @dyladan, am I right? Do you have any details on the problems you had?


Create login signup

Closes #1
Login Page

Route: "/login", Do we want the login page to be the home page? Or possibly make this a component that the homepage can use
Redirects to "/dashboard" on success for now, not sure where to redirect and how we want to store user sessions
Responsive Email input fields
Option to view password plaintext (eye button)
Popup Error messages
Placeholder session post request using "fetch" (we default to use fetch? or we want to import axios?)

Note: Forgot Password (Recovery) page not completed
Sign up Page

Route: "/sign-up"
Redirects to "/dashboard" on success for now, not sure where to redirect and how we want to store user sessions
Responsive Email, Password, Password Confirmation fields
Option to view password plaintext (eye button)
Popup Error messages
Placeholder user post request using "fetch" (we default to use fetch? or we want to import axios?)

Style

Colors used are nextUI named defaults ("primary", "danger") that can be changed with a config file
Components used are all nextUI components as well
I am not good at design so no proposed logo and page banner from me...

Testing
Not included in this branch & pull request

We can consider using Jest and the testing-library/react to test our pages and components.
I have tried it out on a different branch and it also can create a coverage report

Is there something else I should do before I try to run this, I keep getting the following error when I try to sign up ...

Sorry, I forgot to mention that the pages only has placeholder calls to our backend (not yet integrated) so all the login and sign-up requests will fail (404 NotFound error) and produce this error message.
If you change the placeholders in the sign-up/page.tsx and login/page.tsx to https://jsonplaceholder.typicode.com/users in sign-up and login, it will process the request. However, since they are placeholders, they will work no matter if the account exists or not.
Once the success occurs, the user is redirected to a placeholder page that doesn't exists yet so a 404 NotFound error will display instead.


Saheel dev

I just get the new file after kavindiya changed and push it to main , correct some conflict also


pull request for e2e test at 12/25/2016 17:45:10

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Deploy all the examples to now.sh

The links to the deployments can be added to the README.
Alternatively, only add a "Deploy with Now" button to all the READMEs.

I like the second option 👌🏻

Is there a "Deploy with Now" button? I remember seeing one someplace but can't find it now.
// @leo

https://deploy.now.sh/

I see you already found it 😄

You can now deploy subdirectories with deploy.now.sh!
Each README would get a button like:
Code would be:
[![Deploy to now](https://deploy.now.sh/static/button.svg)](https://deploy.now.sh/?repo=https://github.com/zeit/next.js/tree/master/examples/basic-css)


Version 1.0 Roadmap

This pull request adds the version 1.0 roadmap to the repository,
outlining our intentions for the first version of this project.
Signed-off-by: Rian Quinn<EMAIL_ADDRESS>

the overall goal is exciting, but the tasking / schedule seem extremely aggressive. Also, some interim milestones would be useful for general tracking purposes.


Certain database rows cause prisma client to crash

Bug description
When running the Prisma.model.findMany command one of my rows in sql causes Prisma to crash and output this error. Im not entirely sure if there's a malformed value in my database. Im also not 100% sure what this error is trying to tell me or what column is causing this error.
thread 'tokio-runtime-worker' panicked at 'Given exponent overflowing the maximum accepted scale (255).: TryFromIntError(())', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/tiberius-0.9.3/src/tds/numeric.rs:287:47
stack backtrace:
   0:        0x114188924 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h188b7ef1c7993e78
   1:        0x1141a8020 - core::fmt::write::he84a3004e7af3f34
   2:        0x114182bf4 - std::io::Write::write_fmt::h9370b50affaab0be
   3:        0x11418a070 - std::panicking::default_hook::{{closure}}::hc074f8023cce83ca
   4:        0x114189dd8 - std::panicking::default_hook::hef854b51b9b79ff2
   5:        0x11418a508 - std::panicking::rust_panic_with_hook::h1e59e224d558a492
   6:        0x11418a43c - std::panicking::begin_panic_handler::{{closure}}::he1a9d6ab32bfd8c6
   7:        0x114188e00 - std::sys_common::backtrace::__rust_end_short_backtrace::he9b94791b02f48cd
   8:        0x11418a194 - _rust_begin_unwind
   9:        0x11420f964 - core::panicking::panic_fmt::h9fec86f6a9c4146e
  10:        0x11420fa08 - core::result::unwrap_failed::h04f08301b97a771c
  11:        0x113dc9690 - tiberius::tds::numeric::bigdecimal_::<impl tiberius::to_sql::ToSql for core::option::Option<bigdecimal::BigDecimal>>::to_sql::he5f2c3bc35de62b0
  12:        0x113a3e4f4 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h1bb2b6a9432cac5a
  13:        0x113b4b484 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h2c448aba16cbe0dd
  14:        0x113a45154 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h2d24b4e1de521fc1
  15:        0x113a67c5c - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hd131c838039a4de9
  16:        0x113a426a0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h29d081eee69d4353
  17:        0x1135e9cb0 - <tracing_futures::Instrumented<T> as core::future::future::Future>::poll::h6a0e88c60196da0f
  18:        0x1135c61b8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h23c0ec236bd0df8d
  19:        0x1135bfabc - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h18a32ffe68cbd829
  20:        0x1135d38c8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h9e8ceff94408aad4
  21:        0x1132b68f4 - query_core::interpreter::query_interpreters::read::read_related::{{closure}}::h14363e55dbc2eaee
  22:        0x1132a8d10 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h378feeca0e4e39a2
  23:        0x1132ab050 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h8100932631ec4597
  24:        0x1132a3ba4 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h07f4ac0fa08d642e
  25:        0x1132aa3a8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7db6055ee109787b
  26:        0x1132ab080 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h8100932631ec4597
  27:        0x11326c824 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h355e260569f4cfa6
  28:        0x1132a3568 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h07796cc1a1e899eb
  29:        0x1132a92d0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7106db4746c0e007
  30:        0x1130c38e0 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::hf1dd5c4c78895573
  31:        0x113072cc0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hb5050e51c5321afd
  32:        0x11306f674 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h997271f988289b2d
  33:        0x11307e024 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hd10e9bfc8e75506a
  34:        0x113064358 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h361ae0ceb45fab66
  35:        0x11306a390 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h73b5b997c96f0f75
  36:        0x11306c71c - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7d8bfc95225ffe44
  37:        0x1130c35e0 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h9106f7b9f1dc9491
  38:        0x113078594 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hbdf923899c928647
  39:        0x113081c60 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hde71dadbf14e540e
  40:        0x1130670cc - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h5b7ac248ee7f63fd
  41:        0x1131306f0 - tokio::runtime::task::core::CoreStage<T>::poll::hffd92748427be685
  42:        0x11300929c - tokio::runtime::task::harness::poll_future::h0b21672fa4bef1c1
  43:        0x11300d85c - tokio::runtime::task::harness::Harness<T,S>::poll::h21d125b77f2c8822
  44:        0x113dec290 - std::thread::local::LocalKey<T>::with::h9edccece6c2f3963
  45:        0x113e027cc - tokio::runtime::thread_pool::worker::Context::run_task::h3f0afe5218ac3f54
  46:        0x113e01b18 - tokio::runtime::thread_pool::worker::Context::run::h0aab08c900c3bd18
  47:        0x113defbac - tokio::macros::scoped_tls::ScopedKey<T>::set::h28c8de06c0a15374
  48:        0x113e015e0 - tokio::runtime::thread_pool::worker::run::hf7b13b0164905c27
  49:        0x113df8c00 - <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll::hc3991b35707512ae
  50:        0x113df9f08 - tokio::runtime::task::harness::Harness<T,S>::poll::h0e33bd385a4898d3
  51:        0x113de4cf8 - tokio::runtime::blocking::pool::Inner::run::h55cea32f5020a611
  52:        0x113debf54 - std::sys_common::backtrace::__rust_begin_short_backtrace::h756ca1dda46c8a00
  53:        0x113decb68 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h96e9be7d1b666a9d
  54:        0x11418e828 - std::sys::unix::thread::Thread::new::thread_start::h7b2f9b83fb320a20
  55:        0x19ff8026c - __pthread_deallocate

/Users/collinsmallegan/Projects/Materials Resources/Prophet21Connector/node_modules/@prisma/client/runtime/index.js:29917
      throw new PrismaClientRustPanicError(message, this.client._clientVersion);
            ^
Error:
Invalid `this.prisma.inventory_receipts_hdr.findUnique()` invocation in
/Users/collinsmallegan/Projects/Materials Resources/Prophet21Connector/src/orders/orders.service.ts:10:47

   7 constructor(private prisma: PrismaService) {}
   8
   9 async readPickTicket(request: readPickTicketRequest) {
→ 10   return this.prisma.inventory_receipts_hdr.findUnique(
Given exponent overflowing the maximum accepted scale (255).: TryFromIntError(())

This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.

How to reproduce

Expected behavior
Prism a shouldn't crash when running a query.
Prisma information

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlserver"
  url      = env("DATABASE_URL")
}

model invoice_hdr {
  invoice_no   String  @id(map: "pk_invoice_hdr", clustered: false) @db.VarChar(10)
  ship2_state  String
  total_amount Decimal @default(0, map: "df_invoice_hdr_total_amount") @db.Decimal(19, 4)
}

model oe_pick_ticket {
  pick_ticket_no Decimal @id(map: "pk_oe_pick_ticket") @db.Decimal(19, 0)
}

model oe_hdr {
  order_no              String  @id(map: "pk_oe_hdr") @db.VarChar(8)
  delivery_instructions String?  @db.VarChar(255)
  oe_hdr_uid            Int     @unique(map: "ak_oe_hdr_uid")
  ship2_add1            String? @db.VarChar(50)
  ship2_add2            String? @db.VarChar(50)
  ship2_country         String? @db.VarChar(50)
  ship2_city            String? @db.VarChar(50)
  ship2_state           String? @db.VarChar(50)
  ship2_zip             String? @db.VarChar(10)
}

model inventory_receipts_hdr {
  receipt_number Decimal @id(map: "pk_inventory_receipts_hdr") @db.Decimal(19, 0)
  inventory_receipts_line inventory_receipts_line[]
}

model inventory_receipts_line {
  receipt_number Decimal @db.Decimal(19, 0)
  line_number    Int

  inv_mast_uid    Int
  qty_received    Decimal @db.Decimal(19, 9)
  unit_of_measure String  @db.VarChar(8)

  //inv_mast                       inv_mast                         @relation(fields: [inv_mast_uid], references: [inv_mast_uid], onUpdate: NoAction, map: "FK50ofotx2q7fdwomayg9kvuss2")
  inventory_receipts_hdr inventory_receipts_hdr @relation(fields: [receipt_number], references: [receipt_number], onUpdate: NoAction)

  @@id([receipt_number, line_number], map: "pk_inventory_receipts_line", clustered: false)
}
```ts
return await this.prisma.inventory_receipts_hdr.findUnique({
      where: {
        receipt_number: receiptId,
      },
      include: {
        inventory_receipts_line: true,
      },
    });
  }

Environment & setup

OS: MacOS
Database: Microsoft SQL Server
Node.js version: v18.6.0

Prisma Version
Environment variables loaded from .env
prisma                  : 4.3.1
@prisma/client          : 4.3.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine c875e43600dfe042452e0b868f7a48b817b9640b (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.3.0-32.c875e43600dfe042452e0b868f7a48b817b9640b
Default Engines Hash    : c875e43600dfe042452e0b868f7a48b817b9640b
Studio                  : 0.473.0

I would guess it is getting some numeric value from the database that it can not put into the expected data structure.
Can you shared this query?
Invalid `this.prisma.inventory_receipts_hdr.findUnique()` invocation in
/Users/collinsmallegan/Projects/Materials Resources/Prophet21Connector/src/orders/orders.service.ts:10:47

From looking at the model:
model inventory_receipts_hdr {
  receipt_number Decimal @id(map: "pk_inventory_receipts_hdr") @db.Decimal(19, 0)
  inventory_receipts_line inventory_receipts_line[]
}

It could be that the recpeipt_number has some invalid values maybe that are not really Decimal(19,0)?

It only crashes when I use the include statement. Without using it and running a query for inventory_receipts_line all of my queries run
Prisma inventory_receipts_line.findUnique returns the following without issue. My issue is trying to run
return this.prisma.inventory_receipts_hdr.findUnique({
      include: {
        inventory_receipts_line: true,
      },
      where: {
        receipt_number: request.pickNo,
      },
    });

This query works without issue
async readPickTicket(request: readPickTicketRequest) {
    return this.prisma.inventory_receipts_line.findMany({
      where: {
        receipt_number: request.pickNo,
      },
    });

[
  {
    receipt_number: 5000010,
    line_number: 1,
    inv_mast_uid: 19098,
    qty_received: 50,
    unit_of_measure: 'EA'
  }
]
[
  {
    receipt_number: 5000009,
    line_number: 1,
    inv_mast_uid: 19965,
    qty_received: 24,
    unit_of_measure: 'EA'
  }
]
[
  {
    receipt_number: 5000010,
    line_number: 1,
    inv_mast_uid: 19098,
    qty_received: 50,
    unit_of_measure: 'EA'
  }
]
[
  {
    receipt_number: 5000011,
    line_number: 1,
    inv_mast_uid: 24917,
    qty_received: 1000,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 2,
    inv_mast_uid: 24783,
    qty_received: 6000,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 3,
    inv_mast_uid: 24918,
    qty_received: 30000,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 4,
    inv_mast_uid: 38062,
    qty_received: 2000,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 5,
    inv_mast_uid: 24874,
    qty_received: 120,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 6,
    inv_mast_uid: 24921,
    qty_received: 100,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 7,
    inv_mast_uid: 24885,
    qty_received: 6,
    unit_of_measure: 'EA'
  },
  {
    receipt_number: 5000011,
    line_number: 8,
    inv_mast_uid: 24934,
    qty_received: 100,
    unit_of_measure: 'EA'
  }
]

Is it possible that Prisma is trying to process data that isn't listed in the schema? As there is more columns in the table that are not utilized by Prisma?

Yes, that is why I asked for the full query - but I now saw that you had provided it, and it just got lost via the code formatting in GitHub. Back oot the query: An include indeed pulls in another model, in your case inventory_receipts_line:
model inventory_receipts_line {
  receipt_number Decimal @db.Decimal(19, 0)
  line_number    Int

  inv_mast_uid    Int
  qty_received    Decimal @db.Decimal(19, 9)
  unit_of_measure String  @db.VarChar(8)

  inventory_receipts_hdr inventory_receipts_hdr @relation(fields: [receipt_number], references: [receipt_number], onUpdate: NoAction)

  @@id([receipt_number, line_number], map: "pk_inventory_receipts_line", clustered: false)
}

I think the last Json object you provided above is that data already? Can you confirm that?
Do I understand that the only line item for 5000010 is this one:
[
  {
    receipt_number: 5000010,
    line_number: 1,
    inv_mast_uid: 19098,
    qty_received: 50,
    unit_of_measure: 'EA'
  }
]

And still requesting with where = receipt_number: 5000010 it crashes?

I'm using Prisma onto of a erp system hence why I only implemented the columns I needed and not everything. Here is a JSON object for receipt_number 5000009 - 5000011.  Yet Prisma crashes with receipt_number=5000010.
[
  {
    "receipt_number": 5000009,
    "line_number": 1,
    "qty_received": 24.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 24.000000000,
    "date_created": "2005-10-31 12:20:59.000",
    "date_last_modified": "2005-11-02 15:54:09.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 24.000000000,
    "po_line_number": 1,
    "unit_cost": 3.250000000,
    "extended_cost": 78.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 78.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 3.250000000,
    "extended_cost_display": 78.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 19965,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 81387,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000010,
    "line_number": 1,
    "qty_received": 50.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 50.000000000,
    "date_created": "2005-10-31 12:23:23.000",
    "date_last_modified": "2005-11-09 11:35:00.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 50.000000000,
    "po_line_number": 1,
    "unit_cost": 17.000000000,
    "extended_cost": 850.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 850.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 17.000000000,
    "extended_cost_display": 850.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 19098,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 77975,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 1,
    "qty_received": 1000.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 1000.000000000,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 1000.000000000,
    "po_line_number": 1,
    "unit_cost": 0.310000000,
    "extended_cost": 310.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 310.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 0.310000000,
    "extended_cost_display": 310.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24917,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 121760,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 2,
    "qty_received": 6000.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 6000.000000000,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 6000.000000000,
    "po_line_number": 2,
    "unit_cost": 0.292000000,
    "extended_cost": 1752.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 1752.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 0.292000000,
    "extended_cost_display": 1752.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24783,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 119041,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 3,
    "qty_received": 30000.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 30000.000000000,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 30000.000000000,
    "po_line_number": 3,
    "unit_cost": 0.290000000,
    "extended_cost": 8700.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 8700.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 0.290000000,
    "extended_cost_display": 8700.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24918,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 121782,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 4,
    "qty_received": 2000.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 2000.000000000,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 2000.000000000,
    "po_line_number": 4,
    "unit_cost": 0.250000000,
    "extended_cost": 500.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 500.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 0.250000000,
    "extended_cost_display": 500.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 38062,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 169877,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 5,
    "qty_received":<PHONE_NUMBER>00,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity":<PHONE_NUMBER>00,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched":<PHONE_NUMBER>00,
    "po_line_number": 5,
    "unit_cost": 0.393000000,
    "extended_cost": 47.1600,
    "freight_amount": 0.0000,
    "amount_vouched": 47.1600,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 0.393000000,
    "extended_cost_display": 47.1600,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24874,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 120751,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 6,
    "qty_received":<PHONE_NUMBER>00,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity":<PHONE_NUMBER>00,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched":<PHONE_NUMBER>00,
    "po_line_number": 6,
    "unit_cost": 0.520000000,
    "extended_cost": 52.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 52.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 0.520000000,
    "extended_cost_display": 52.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24921,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 121846,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 7,
    "qty_received": 6.000000000,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity": 6.000000000,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched": 6.000000000,
    "po_line_number": 8,
    "unit_cost": 11.950000000,
    "extended_cost": 71.7000,
    "freight_amount": 0.0000,
    "amount_vouched": 71.7000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 11.950000000,
    "extended_cost_display": 71.7000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24885,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 121387,
    "receipt_removed_by": null
  },
  {
    "receipt_number": 5000011,
    "line_number": 8,
    "qty_received":<PHONE_NUMBER>00,
    "unit_of_measure": "EA",
    "unit_size": 1.0000,
    "unit_quantity":<PHONE_NUMBER>00,
    "date_created": "2005-10-31 12:29:40.000",
    "date_last_modified": "2005-11-03 14:12:30.000",
    "last_maintained_by": "LST",
    "vouch_complete": "Y",
    "qty_vouched":<PHONE_NUMBER>00,
    "po_line_number": 11,
    "unit_cost": 1.400000000,
    "extended_cost": 140.0000,
    "freight_amount": 0.0000,
    "amount_vouched": 140.0000,
    "freight_amount_vouched": 0.0000,
    "unit_cost_display": 1.400000000,
    "extended_cost_display": 140.0000,
    "freight_amount_display": 0.0000,
    "inv_mast_uid": 24934,
    "qty_disassembled": 0.000000000,
    "qty_lost": null,
    "msp_landed_cost": 0.000000000,
    "substitute_item": "N",
    "original_inv_mast_uid": null,
    "pricing_unit": "EA",
    "pricing_unit_size": 1.0000,
    "substitute_line_number": null,
    "date_receipt_removed": null,
    "retrieved_by_wms": null,
    "transfer_flag": null,
    "country_of_origin": null,
    "vessel_landed_cost_posted_amt": null,
    "wrong_part_no_flag": "N",
    "pallet_id": null,
    "created_by": "MRS\\Administrator",
    "label_qty": null,
    "inventory_receipts_line_uid": 122105,
    "receipt_removed_by": null
  }
]

This is the DDL in SqlServer
-- auto-generated definition
create table inventory_receipts_line
(
    receipt_number                decimal(19)                                  not null
        constraint fk_inv_rcpt_line_inv_rcpt_hdr
            references inventory_receipts_hdr,
    line_number                   int                                          not null,
    qty_received                  decimal(19, 9)                               not null,
    unit_of_measure               varchar(8)                                   not null,
    unit_size                     decimal(19, 4)                               not null,
    unit_quantity                 decimal(19, 9)                               not null,
    date_created                  datetime                                     not null,
    date_last_modified            datetime                                     not null,
    last_maintained_by            varchar(30)                                  not null,
    vouch_complete                char                                         not null,
    qty_vouched                   decimal(19, 9)                               not null,
    po_line_number                int                                          not null,
    unit_cost                     decimal(19, 9),
    extended_cost                 decimal(19, 4),
    freight_amount                decimal(19, 4),
    amount_vouched                decimal(19, 4),
    freight_amount_vouched        decimal(19, 4),
    unit_cost_display             decimal(19, 9),
    extended_cost_display         decimal(19, 4),
    freight_amount_display        decimal(19, 4),
    inv_mast_uid                  int                                          not null,
    qty_disassembled              decimal(19, 9) default 0                     not null,
    qty_lost                      decimal(19, 9),
    msp_landed_cost               decimal(19, 9),
    substitute_item               char           default 'N'                   not null,
    original_inv_mast_uid         int,
    pricing_unit                  varchar(8)                                   not null,
    pricing_unit_size             decimal(19, 4)                               not null,
    substitute_line_number        int,
    date_receipt_removed          datetime,
    retrieved_by_wms              char
        constraint df_inventory_receipts_line_retrieved_by_wms default 'N',
    transfer_flag                 char,
    country_of_origin             varchar(255),
    vessel_landed_cost_posted_amt decimal(19, 4),
    wrong_part_no_flag            char
        constraint df_inventory_receipts_line_wrong_part_no_flag default 'N'   not null,
    pallet_id                     varchar(30),
    created_by                    varchar(255)
        constraint df_inventory_receipts_line_created_by default suser_sname() not null,
    label_qty                     int,
    inventory_receipts_line_uid   int identity,
    receipt_removed_by            varchar(255),
    constraint pk_inventory_receipts_line
        primary key nonclustered (receipt_number, line_number)
            with (fillfactor = 80)
)
go

create clustered index idx_inv_recpts_line_covered
    on inventory_receipts_line (inv_mast_uid, receipt_number, line_number, date_created)
    with (fillfactor = 80)
go

create index idx_inv_recpt_line_wms
    on inventory_receipts_line (retrieved_by_wms)
    with (fillfactor = 80)
go

create index idx_inventory_receipts_line_vendor_scorecard
    on inventory_receipts_line (date_created, receipt_number, po_line_number, qty_received)
    with (fillfactor = 80)
go

grant delete, insert, references, select, update on inventory_receipts_line to PxxiUser
go

grant delete, insert, references, select, update on inventory_receipts_line to p21_application_role
go

Befrore we spend more time on this: This could already be fixed in dev versions of 4.4.0, see https://github.com/prisma/prisma/issues/15079 and https://github.com/prisma/prisma/issues/14703. Can you try installing prisma@dev and @prisma/client@dev in your project and see if this fixes the query in question? Then this fix would be included in the release next Tuesday.

That seemed to fix it I also added a map key.
inventory_receipts_hdr inventory_receipts_hdr @relation(fields: [receipt_number], references: [receipt_number], onUpdate: NoAction, map: "fk_inv_rcpt_line_inv_rcpt_hdr")


unread_msgs: Fix all unreads in muted stream being treated as muted.

CZO Discussion

Screenshots and screen captures:
Before

After

The count is still not correct as we don't use unread_msgs.count directly;  PR to show count correctly: #26849
Updated Docs
Count

Streams

mentions

Self-review checklist

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

Communicate decisions, questions, and potential concerns.

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

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

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

Completed manual review and testing of the following:

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

Updates in the recent push:

Addressed the review comments
In apply_unread_message_event(), we had:

if ( stream_id not in state["muted_stream_ids"] and
     not topic_has_visibility_policy(user_profile, stream_id, topic, UserTopic.VisibilityPolicy.MUTED)
   ):
       state["unmuted_stream_msgs"].add(message_id)

Fixed it to consider a stream message as unmuted if it belongs to:

a not muted topic in a normal stream
an unmuted or followed topic in a muted stream

Posted a couple small comments on the details, otherwise lgtm!

Updates in the recent push:

Addressed the review comments.
Updated the docs as discussed on CZO. -- updated images in the PR description.

Applied these changes to document as a normal API change, and marked to merge once CI passes:
diff --git a/api_docs/changelog.md b/api_docs/changelog.md
index c8b0555df1..1edfeed023 100644
--- a/api_docs/changelog.md
+++ b/api_docs/changelog.md
@@ -20,6 +20,12 @@ format used by the Zulip server that they are interacting with.

 ## Changes in Zulip 8.0

+**Feature level 213**
+
+* [`POST /register`](/api/register-queue): Fixed incorrect handling of
+  unmuted and followed topics in calculating the `mentions` and
+  `count` fields of the `unread_msgs` object.
+
 **Feature level 212**

 * [`GET /events`](/api/get-events), [`POST /register`](/api/register-queue),
diff --git a/version.py b/version.py
index 4ebbf00ba8..5bfed5f098 100644
--- a/version.py
+++ b/version.py
@@ -33,7 +33,7 @@ DESKTOP_WARNING_VERSION = "5.9.3"
 # Changes should be accompanied by documentation explaining what the
 # new level means in api_docs/changelog.md, as well as "**Changes**"
 # entries in the endpoint's documentation in `zulip.yaml`.
-API_FEATURE_LEVEL = 212
+API_FEATURE_LEVEL = 213

 # Bump the minor PROVISION_VERSION to indicate that folks should provision
 # only when going from an old version of the code to a newer version. Bump
diff --git a/zerver/openapi/zulip.yaml b/zerver/openapi/zulip.yaml
index 48c6376040..757d880cdd 100644
--- a/zerver/openapi/zulip.yaml
+++ b/zerver/openapi/zulip.yaml
@@ -11854,8 +11854,8 @@ paths:
                               The total number of unread messages to display. This includes one-on-one and group
                               direct messages, as well as stream messages that are not [muted](/help/mute-a-topic).

-                              Zulip 8.0 fixed a bug where the "unmute topic" feature wasn't considered.
-                              ([#26848](https://github.com/zulip/zulip/pull/26848))
+                              **Changes**: Before Zulip 8.0 (feature level 213), the unmute and follow
+                              topic features were not handled correctly in calculating this field.
                           pms:
                             type: array
                             description: |
@@ -11954,8 +11954,8 @@ paths:
                               mentioned directly, and unread [non-muted](/help/mute-a-topic) messages
                               in which the user was mentioned through a wildcard.

-                              Zulip 8.0 fixed a bug where the "unmute topic" feature wasn't considered.
-                              ([#26848](https://github.com/zulip/zulip/pull/26848))
+                              **Changes**: Before Zulip 8.0 (feature level 213), the unmute and follow
+                              topic features were not handled correctly in calculating this field.
                             items:
                               type: integer
                           old_unreads_missing:


Add PyRadio template repository

This looks like the main pyradio repo, not a Base16 template repo.

@joshgoebel gah, how silly of me! I copied the wrong link it seems, thank you for double checking. I fixed it now.

What does the temp dir during build do for you?  It looks like you're just linking to the existing templates directory... so I'm not sure how a symlink helps?  Just curious.

Hi @joshgoebel,
Good question :sweat_smile:
It was some way I did this to get around needing to actually put the working files in the base16 directory structure required by the builder, by linking the template to base16/templates/base16-pyradio and then moving out the generated themes. Quite cumbersome.
I also realize there is still some artifacts left in the makefile from previously using base16-builder-python that I got an issue with just today due to #39. :/
Suggestions?

I'm not sure how you're doing things... personally I'd just checkout the template INTO the base16 folder and then manage it from there, as hinted at in the node builder instructions.  So them the build assets are exactly where you want them, git add, git commit, done.

Right, so the root of the repo would then contain the base16/ directory with its subdirectories containing templates and themes if I understand things correctly? I just wanted to avoid that extra click of going into the base16 directory for downloading/viewing the themes and templates.
Sorry for being so obtuse, but I don't frequently work with these types of files.

base16

base16/schemes (a checkout of the main schemes repo)
base16/templates/your_template (a checkout of your template)

To build (from inside your you_template):
cd ../../..
base16 build
cd base16/templates/your_template

Of course if you wrap this in a tiny script you don't need to cd back as when the script dies you'll be returned automagicaly.
Every once in a while you need to jump into schemes to pull down changes, etc...

We've also got the Go builder available as a Github action. I have an example in the base16-emacs repo:
https://github.com/base16-project/base16-emacs/blob/main/.github/workflows/update.yml

Ah right I understand now, thank you for taking the time to explain.
I saw the example in the builder README but I was still a bit confused as you understand. I will consider making some changes to simplify things.
Good evening/morning :)

We've also got the Go builder available as a Github action. I have an example in the base16-emacs repo:
https://github.com/base16-project/base16-emacs/blob/main/.github/workflows/update.yml

That's cool! Thanks for the example :)
I'm using the node builder in an action currently: https://github.com/edunfelt/base16-pyradio/blob/main/.github/workflows/update.yml


add supriya

@sippiammu  please create a new branch and add your profile data to it so that all tests will pass. If you attempt to make changes to the main branch and send a pull request, the system checks will naturally fail because you are not allowed to make any changes to the main branch.

Hey can you do the commit again, there are some issues with the commit.