text:
How to support SourceHanSans on UOS browser ?

I try to fix the problem that SourceHanSans font cannot display some Chinese characters on UOS Browser, I am confused about the version of pdfjs I am using, sorry for not being able to report more details about pdfjs.
I found the question, trying to run "npm run build" to convert the UniSourceHanSansCN-UTF32-H cmap file to the bcmap file.
I checked the file path and set PDFJS.cMapPacked to false or true, all failed. I don't get the expected bcmap file.
Actually, I don't know that converting this file will help me solve the problem.So, any help would be great for me, thanks a lot.

I am confused about the version of pdfjs I am using, sorry for not being able to report more details about pdfjs.

When opening an issue, please provide all of the information requested in https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md since the complete lack of details makes it impossible for anyone to assist you!

on UOS Browser

That's not browser that we support here, please see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support

I found the question, trying to run "npm run build" to convert the UniSourceHanSansCN-UTF32-H cmap file to the bcmap file.
I checked the file path and set PDFJS.cMapPacked to false or true, all failed. I don't get the expected bcmap file.

It's not even clear, given that you didn't actually including the PDF document in question (which is the first thing that the ISSUE_TEMPLATE asks for), if this step is necessary/relevant to do here...

Actually, I don't know that converting this file will help me solve the problem.

And neither does anyone else unfortunately; finally please see https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):

If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us in the Matrix room -- keep in mind that just code snippets won't help us troubleshoot the problem.

I am confused about the version of pdfjs I am using, sorry for not being able to report more details about pdfjs.

When opening an issue, please provide all of the information requested in https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md since the complete lack of details makes it impossible for anyone to assist you!

on UOS Browser

That's not a browser that we support here, please see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support

I found the question, trying to run "npm run build" to convert the UniSourceHanSansCN-UTF32-H cmap file to the bcmap file.
I checked the file path and set PDFJS.cMapPacked to false or true, all failed. I don't get the expected bcmap file.

It's not even clear, given that you didn't actually including the PDF document in question (which is the first thing that the ISSUE_TEMPLATE asks for), if this step is necessary/relevant to do here...

Actually, I don't know that converting this file will help me solve the problem.

And neither does anyone else unfortunately; finally please see https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):

If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us in the Matrix room -- keep in mind that just code snippets won't help us troubleshoot the problem.

First of all thanks for your reply. I'm sorry about couldn't upload any files and not used ISSUE_TEMPLATE.
Second, if anyone knows how to convert a cmap file to a bitmap file, it might help me to solve my problem, please reply.

Steps to convert UniSourceHanSansCN-UTF32-H to bcmap file
Download this repo to your local.
git clone git@github.com:mozilla/pdf.js.git
cd pdf.js
npm install -g gulp-cli
npm install

Then put your cmap file into the CMAP_INPUT folder.
mkdir -p external/cmaps
mv YOUR_CMAP_FILE external/cmaps
gulp cmaps

FAQ You may need:

no cmap files

### Building cmaps error
./external/cmaps has no cmap files, download them from:
  https://github.com/adobe-type-tools/cmap-resources
[10:24:23] 'cmaps' errored after 2.16 ms
[10:24:23] Error: cmap files were not found
    at ....../pdf.js/gulpfile.js:830:11
    at taskWrapper (....../pdf.js/node_modules/undertaker/lib/set-task.js:13:15)
    at bound (node:domain:433:15)
    at runBound (node:domain:444:12)
    at asyncRunner (....../pdf.js/node_modules/async-done/index.js:55:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)

You need to change gulpfile.js to set the filename /UniJIS-UCS2-H to your setup, or just delete it.

How to find the cmap file ?

In this case, just visit this github repo to download:

UniSourceHanSansCN-UTF32-H
UniSourceHanSansHK-UTF32-H
UniSourceHanSansHWCN-UTF32-H
UniSourceHanSansHWHK-UTF32-H
UniSourceHanSansHWJP-UTF32-H
UniSourceHanSansHWKR-UTF32-H
UniSourceHanSansHWTW-UTF32-H
UniSourceHanSansJP-UTF32-H
UniSourceHanSansKR-UTF32-H
UniSourceHanSansTW-UTF32-H

Or you can create your own. Cmap file created by adobe, if you need more information, click this link.

authors: Snuffleupagus baofeidyz


text:
Hyper link not working in PDFjs

I have a pdf in witch there is a link of website(Google). With PDFjs it now working. Please tell me the reason and solution.

It works for me. BTW, URLs usually start with "https://" and not with "www".

This works just fine with the latest viewer at https://mozilla.github.io/pdf.js/web/viewer.html. From the screenshot, it's a custom deployment (not even sure it's PDF.js). Most likely annotations have been disabled there. Closing since support for customized versions of PDF.js is out of scope.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119)

This patch is first big step for the new highlight feature.
Few patches will follow in order to conform to the specs UX/UI gave us.

/botio-linux preview

/botio test

source: gharchive/pull-request


text:
Sessions and more visit work.

@ncalexan!

Coverage increased (+1.5%) to 39.469% when pulling 4fbe0ca7083bf50873af817981b30c0687080882 on rnewman/sessions into 7e75d0b2a83fd50968c3e618a1ff6a8f6073080c on master.

authors: coveralls rnewman

repo: mozilla/tofino

license_source: bigquery


text:
[WIP] Rewrite content pages to use React

Fixes https://github.com/mozilla/tofino/issues/531 and https://github.com/mozilla/tofino/issues/493

Coverage increased (+0.5%) to 43.36% when pulling 4821738d67415ed25c552bd1abadee82bc490d1f on victorporof:react-content-pages into 9e572addf96a98c8723afbd77765fceb948783e9 on mozilla:master.

Coverage increased (+0.3%) to 43.097% when pulling cb663ec6bf5addff28692ca45b1efda6f3c81baf on victorporof:react-content-pages into 9e572addf96a98c8723afbd77765fceb948783e9 on mozilla:master.

Coverage increased (+0.3%) to 43.133% when pulling cb663ec6bf5addff28692ca45b1efda6f3c81baf on victorporof:react-content-pages into 9e572addf96a98c8723afbd77765fceb948783e9 on mozilla:master.

Coverage increased (+0.2%) to 43.081% when pulling cb663ec6bf5addff28692ca45b1efda6f3c81baf on victorporof:react-content-pages into 9e572addf96a98c8723afbd77765fceb948783e9 on mozilla:master.

Coverage increased (+0.3%) to 43.18% when pulling cc4b765589e5c5f073d13eb87282831d16a2898d on victorporof:react-content-pages into 15ead0436cd8d9911f49fd76045ace42a88e5ff7 on mozilla:master.

@bgrins

Coverage decreased (-0.09%) to 42.821% when pulling 1b7057b0d0885af5879baea6d8ef68eec547474d on victorporof:react-content-pages into 7bae9835c7a5525be176002ae0c1905d8abcfc2e on mozilla:master.

Looks good, thanks

authors: bgrins coveralls victorporof


text:
Fighshare API spec possible bug

It seems that the author resource representation returned by Figshares API may not be returning what is entirely expected. Figshare calls these representations presenters.
Example:
Article #1394809 should correspond to Figshare's Article Presenter Level 2, which at a glance it seems to do (Article Presenter L2 = L1 & L2 combined). Article Presenter L2 also contains an Author Presenter inside it.
If we take a closer look at the Author Presenter, it shows that ORCID is a field that you would expect to be returned, presumably if a specific author has an ORCID Figshare knows about. But Article #1394809 doesn't show an ORCID, even though the corresponding author, "Pedro Javier Villanueva Hernández" does have one on his figshare public profile. Seems like a bug.
Another example with a different article
TL;DR: There are multiple cases where Figshare's API isn't returning all the information I would expect. I think it probably means there's a bug in the API.
When this bug gets fixed (I'll make an issue on Fighshare's user_documentation repo), we should correct our author parsing for figshare to account for the change.

AH. API v1 doesn't specify ORCID. But V2 does. This isn't an issue, closing

license: mit


text:
Update Netty version to 4.1.9

closes #488

Coverage increased (+0.04%) to 92.044% when pulling 0153afb592bb3d8f75a7f2b52d759e690a4c3c15 on odiszapc:master into 68107988b0462efd7b9925a49679c6eab8ce0ec4 on mp911de:master.

Coverage increased (+0.04%) to 92.044% when pulling 0153afb592bb3d8f75a7f2b52d759e690a4c3c15 on odiszapc:master into 68107988b0462efd7b9925a49679c6eab8ce0ec4 on mp911de:master.

Thanks a lot. That's merged, polished and ported to the affected branches.

authors: coveralls mp911de odiszapc


text:
MountainCar fix tot_bin missing in some methods.

The variable amount of bins was missing in some methods for the MountainCar example.

Thank you for the contribution. Everything has been merged!

authors: Jan-Zeiseweis mpatacchiola


text:
Fix a compile error on AMD / ROCM 3.5.0 with hip-clang

A one-line fix to make neighbor compile

Thanks, good catch!

authors: jglaser mphoward

repo: mphowardlab/hipper


text:
Force download via AJAX

Hi,
I am wondering why the file won't download during an ajax call, in my component ;
public function onExportPDF(){
  return PDF::loadTemplate('renatio::invoice')->download();
}

The response is always returned as a string - Response headers ;
Cache-Control:no-cache
Connection:Keep-Alive
Content-Disposition:attachment; filename="document.pdf"
Content-Type:application/pdf
Date:Mon, 17 Jul 2017 02:54:26 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.4.25 (Win32) OpenSSL/1.0.2j PHP/7.1.4
Transfer-Encoding:chunked
X-Powered-By:PHP/7.1.4

Hi,
check this topic: https://github.com/mplodowski/DynamicPDF/issues/29

I end up create an export page and component to make it work then in onRun method  added;
if( $this->export ){
   return PDF::loadTemplate('renatio::invoice')->download();
}

authors: mplodowski rajakhoury

repo: mplodowski/DynamicPDF


text:
Update magic.py

update offset for game version 1.1.0.0
test well for 3440*1440 in my pc

I can confirm it works for 2560*1080

mpm11011 is now dynamic search for hex address now.
I think my pr is useless now

I gotta get better about checking GitHub... completely missed this. Please let me know if the dynamic search works!

authors: bglebrun githoniel mpm11011

license: MIT


text:
does not work with 4G mobile data

Is it possible to do the transmission of audio and video through 4G data? It is that I am seeing that there is no possibility of putting the bitrate in a variable, or I cannot find the option.
I already have a vpn with ZeroTier set up and by cable it works perfectly, but for 4g data it doesn't work it uses too much bandwidth it seems to be.
Do you know how it can be done?
Thank you!

Hi,
It should be possible to stream through 4G, it is a network like another one. To limit bandidth you may look to v4l2 options support by your device, reduce resolution, ....
Best Regards,
Michel.

license: unlicense


text:
Remove date from the package documentation

https://github.com/mr-devs/top-FIBers/blob/f69d3f51ad12cb2f0463261d1c1f77598314f655/docs/code/top_fibers_pkg.md?plain=1#L10
As you can see in the most updated rendering of this page here — the date in the referenced line above is outdated.
Having the last updated date in two places is likely to lead to this issue. Use only the Last modified note from the YAML.

Completed.

repo: mr-devs/top-FIBers


text:
only ac load

Hi, Is it possible to insert only ac load, excluding pv?

https://github.com/mr-manuel/venus-os_dbus-mqtt-grid

authors: grydo mr-manuel


text:
🛑 Vintage Camera Box [vintagecamerabox.com] is down

In dd7a132, Vintage Camera Box [vintagecamerabox.com] (https://vintagecamerabox.com) was down:

HTTP code: 403
Response time: 308 ms

Resolved: Vintage Camera Box [vintagecamerabox.com] is back up in c9582d0.


text:
Error: ''NoneType' object has no attribute 'squeeze''

START OF TRACEBACK
Traceback (most recent call last):
File "/Applications/Data/Packages/stable-diffusion-webui/extensions/sd-webui-deforum/scripts/deforum_helpers/run_deforum.py", line 116, in run_deforum
render_animation(args, anim_args, video_args, parseq_args, loop_args, controlnet_args, root)
File "/Applications/Data/Packages/stable-diffusion-webui/extensions/sd-webui-deforum/scripts/deforum_helpers/render.py", line 415, in render_animation
prev_img, depth = anim_frame_warp(prev_img, args, anim_args, keys, frame_idx, depth_model, depth=None, device=root.device, half_precision=root.half_precision)
File "/Applications/Data/Packages/stable-diffusion-webui/extensions/sd-webui-deforum/scripts/deforum_helpers/animation.py", line 177, in anim_frame_warp
depth = depth_model.predict(prev_img_cv2, anim_args.midas_weight, half_precision)
File "/Applications/Data/Packages/stable-diffusion-webui/extensions/sd-webui-deforum/scripts/deforum_helpers/depth.py", line 104, in predict
depth_tensor = self.midas_depth.predict(prev_img_cv2, half_precision)
File "/Applications/Data/Packages/stable-diffusion-webui/extensions/sd-webui-deforum/scripts/deforum_helpers/depth_midas.py", line 82, in predict
).squeeze().cpu().numpy()
AttributeError: 'NoneType' object has no attribute 'squeeze'

Can you provide code ?

It typically means that, Your tensor is getting NoneType object because of that It can't be squeeze.
Possibly you explicitly provided some variable which is NoneType or created some function which returns NoneType object.

repo: mrdbourke/pytorch-deep-learning


text:
Where to put relevant meta data information e.g. for major instrument changes?

There is another detail to the taunus meta data, that I don't know how to handle it at the moment: the instrument that we refer to as "taunus-tof" within AGAGE had a major hardware change in 2022-09: We got rid of the TOF-ms and used a quadropole-ms instead. However, both taunus-tof and taunus-quad share the same GCWerks licence and hence pretend to be the same instrument.
Where should I put this information in order to get it through to the public nc meta data?

This should be something you can add in GCWerks and have feed through. For example, if you look at the GCWerks CGO Medusa files, there are multiple instruments mentioned in the attributes:
:instrument = "agilent_5975";
:instrument_date = "2012-08-01 00:00:00";
:instrument_comment = "upgraded MSD detector with generally improved precisions";
:instrument_1 = "agilent_5973";
:instrument_date_1 = "2004-01-01 00:00:00";
:instrument_comment_1 = "original MSD detector";
I'm afraid I don't know how you get this into GCWerks though. Also note that there seems to be an issue where some of these values are being overwritten, but I'll fix that (Issue #51 )

OK great thank you, I'll have a look and post the gcwerks file name here.

I just added the corresponding lines to
/agage/taunus-tof/config/gcnetcdf.conf:
#
# The most recent ms detector used
instrument 		agilent_5977B
instrument_date		2022-09-07 09:00
instrument_comment	Quadropole MSD with generally improved precisions, however less compounds than the TOF

# previous ms detector
instrument_1		tofwerk_EI-HTOF
instrument_date_1	2015-01-01 00:00
instrument_comment_1	original TOF MSD

and pushed the changes to hubibti. Let's wait a couple of days and see, if the changes make it to the .nc files.
Cheers, Thomas

Is this fixed now? Shall I close this issue?

Actually there is something weird going on here - it looks fine in the individual instruments file for the tof, but the instrument dates don't seem to be correct in the combined file:
 'instrument': 'GCMS-Medusa',
 'instrument_date': '2023-02-05',
 'instrument_comment': '',
 'instrument_1': 'agilent_5977B',
 'instrument_date_1': '2018-05-07',
 'instrument_comment_1': 'Quadropole MSD with generally improved precisions, however less compounds than the TOF',
 'instrument_2': 'tofwerk_EI-HTOF',
 'instrument_date_2': '2015-01-01 00:00',
 'instrument_comment_2': 'original TOF MSD',
 'instrument_type': 'GCMS-Medusa/GCTOFMS',
 'Conventions': 'CF-1.8',

authors: Amsoht TaunusObservatory joe-pitt mrghg

repo: mrghg/agage-archive


text:
Null Safety

Can you please upgrade the package to null safety?

@UsamaKarim You can try using story_maker

authors: NarekManukyan UsamaKarim


text:
Problems with .vue component files.

Hey I'm working with .vue files which are single-file components for VueJS.
These files have html-style syntax so I was surprised to be having problems with less-than-slash.
The issue is, in the
Wondering if anyone else has a similar problem? Thx.

I'm being an idiot, I forgot that  doesn't have a closing tag. My bad! Closing this.

repo: mrhanlon/less-than-slash


text:
fix:

Resolves: #323
How to Test

Which-key mappings like this should be picked up

require('legendary').setup({
  which_key = {
    mappings = {
      ['<space>f'] = {
        function()
          print('foo')
        end,
        'Print foo',
      },
    },
  },
})

Testing for Regressions
I have tested the following:

[x] Triggering keymaps from legendary.nvim in all modes (normal, insert, visual)
[x] Creating keymaps via legendary.nvim, then triggering via the keymap in all modes (normal, insert, visual)
[x] Triggering commands from legendary.nvim in all modes (normal, insert, visual)
[x] Creating commands via legendary.nvim, then running the command manually from the command line
[x] augroup/autocmds created through legendary.nvim work correctly

@gregorias can you confirm this fixes the issue for you? Seems to for me locally.


text:
Cannot control Access-Control-Allow-Credentials header

You added support for Access-Control-Allow-Origin header, but when I set that header to "*" I must also be able to control Access-Control-Allow-Credentials which I believe I can't.
also see:
http://stackoverflow.com/questions/23726690/access-control-allow-origin-with-socket-io-on-java-server
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Access-Control-Allow-Credentials is hardcoded in EncoderHandler.java. I think it should be configurable.

The best way to implement this would be to be able to access headers directly in an override. Often it is required to return individual origin dependent on apikey, for example.

Another option, which I saw in many servers, it that the server returns the original host. It would be very cool to get an event hook where I can look at the host, make changes, and return. That would be the perfect solution for managing origin IMHO.

Hi, you probably already found a workaround but in case someone else is wondering, the wildcard behavior can be achieved by providing null as origin (configuration.setOrigin(null)). You can check the original code here

authors: gdaniel oliverhausler

repo: mrniko/netty-socketio


text:
🐛 App does not build on iOS rc 3

What were you trying to do?
 ** ARCHIVE FAILED **
[RUN_FASTLANE] ▸ The following build commands failed:
[RUN_FASTLANE] ▸        CompileC /Users/1/Library/Developer/Xcode/DerivedData/bloggshouse-cmieuysyqglyaxazizdqisawmnsf/Build/Intermediates.noindex/ArchiveIntermediates/bloggshouse/IntermediateBuildFilesPath/Pods.build/Debug-iphoneos/VisionCamera.build/Objects-normal/arm64/TensorHelpers.o /var/folders/9h/k6llh0jd1_n75sqdsch6lzmr0000gn/T/eas-build-local-nodejs/f5288223-530e-4586-8518-9320ccb01ed3/build/frontend/apps/expo/node_modules/react-native-vision-camera/ios/Tensorflow\ Plugin/TensorHelpers.mm normal arm64 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'VisionCamera' from project 'Pods')

Reproduceable Code
No response
What happened instead?
error build
Relevant log output
No response
Device
m1
VisionCamera Version
rc 2
Additional information

[X] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Thanks for reporting, will fix!

authors: mrousavy nikitapilgrim

repo: mrousavy/react-native-vision-camera


text:
appdata: translate=no properties

It appears that the appstream project no longer supports translatable=no properties, and gettext extract the translatable=no marked strings as translatable.
I opened an issue to inform about the situation, but translatable=no properties are not accepted by developers. You can find the issue here: https://github.com/ximion/appstream/issues/623
Please test your script or string extraction process before merging this PR.

In MetaInfo files, each individual paragraph of a description
(or enumerated entry) is translated individually, however,
you can only exclude the complete block from being translated
by adding translate="no" to the description element.

Source: https://freedesktop.org/software/appstream/docs/sect-Quickstart-Translation.html

I renamed "translatable" to "translate" in all occurances in this file

authors: mrvladus yakushabb

repo: mrvladus/Errands


text:
Updated BusProviders-Arduino to use submodules

This pull request includes all the files required to have submodules used in the busprovider project instead of grabbing the ZIPs. The Readme.md file has been changed to reflect this.

@TGoodhew,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

authors: TGoodhew msftclas

repo: ms-iot/BusProviders


text:
Error: %1 is not a valid Win32 application.

D:\nodep\work>node server

module.js:356
  Module._extensions[extension](this, filename);
                               ^
Error: %1 is not a valid Win32 application.
D:\nodep\node_modules\cap\build\Release\cap.node
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (D:\nodep\node_modules\cap\lib\Cap.js:3:13)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

Hello,
module.js:356
Module._extensions[extension](this, filename);
^
Error: %1 is not a valid Win32 application.
D:\nodep\node_modules\cap\build\Release\cap.node
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (D:\nodep\node_modules\cap\lib\Cap.js:3:13)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
I am facing the same issue. I have installed node 64 bit version in windows 7 64-bit. When I tried to run the test case which has cap module, it is throwing the above error.
I need your support is resolving this error. Any log file you want, I can send that.

repo: mscdex/cap


text:
Cannot read property 'entities' of undefined

projects.toString() // from "state.projects", Map instance
and many other functions throw this error (eg ownProps.project.tasks.includes(taskId) there)
I saw you redefined many functions from immutable, maybe this is the source

Can you provide some more code for me to understand. And which version are you using?

Sorry, I move from normalizr-immutable to vanilla Immutable.fromJS for better handleability.
But there is commit of this issue
I think origin of this issue is that initialState of project reducer is Map({}) there
import { Map } from "immutable"
import * as types from "../projectConstants"

const initialState = Map({})

export default function projects(state = initialState, action = {}) {
  switch (action.type) {
  case types.LOAD_PROJECTS: {
    return state.merge(action.payload)
  }
  default:
    return state
  }
}

And then I marge it like this   dispatch(loadProjects(normalized.entities.projects))
And when I try use it state.projects.toString(), it throw Cannot read property 'entities' of undefined error

Ok, at a glance, it seems to me that you should merge entities and not entities.projects.
Also, "property 'entitities' of undefined" suggests that the projectsReducer is not available when that call is made. This could be related to not supplying the reducer reference correctly in the schema definition.

Yes, or I had to use NormalizedRecord as initialState, I just surprised that entities created by "normalizr-immutable" is not compatible with vanilla immutable entities at first glance, I will close the issue, thanks you for your time
P.S. I thought that Record doesn`t have Iterable methods, I was misguided by official documentation :smile:

The entities created by normalizr-immutable are simple immutable Records, fully compatible. If you start using the Proxy facilities, you have to take a little more care in how you use things. But for me, the pains are worth it.
One more thing: I recommed using the latest 0.0.4 beta of normalize-immutable. Depending on configuration the 0.0.3 branch uses a Record for the entities structure which was a misguided choice on my part.

Ok, currently I just teaching react, it seems I will return to normalizr-immutable once)

authors: BjornMelgaard mschipperheyn

repo: mschipperheyn/normalizr-immutable


text:
🛑 Do53 Roost IPv6 TCP is down

In d2654b9, Do53 Roost IPv6 TCP (http://107.189.10.142:9205) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv6 TCP is back up in 30c26a0 after 30 minutes.

repo: mschirrmeister/upptime-loopx


text:
🛑 Do53 Roost IPv6 TCP is down

In f42b1c3, Do53 Roost IPv6 TCP (http://107.189.10.142:9205) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv6 TCP is back up in d871d10 after 11 minutes.


text:
🛑 Do53 Roost IPv6 UDP is down

In ca0250e, Do53 Roost IPv6 UDP (http://107.189.10.142:9204) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv6 UDP is back up in 84c029c after 37 minutes.


text:
🛑 Do53 Roost IPv4 TCP is down

In 0cedf14, Do53 Roost IPv4 TCP (http://107.189.10.142:9203) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv4 TCP is back up in e2709d9 after 11 minutes.


text:
add new scalability consideration

IoTHubQuotaExceed

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/iot/data-ingestion.md
:white_check_mark:Succeeded
View

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.

authors: VSC-Service-Account ferantivero

repo: mspnp/architecture-center


text:
Hanz/reorg repo structure

connect to #147
created folder structure as:
•build
•docs
•setup
•src
◦AdhocExploration
◦LongTermStorage
◦Shared
◦Simulator

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

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.azure.com.

TTYL, AZPRBOT;

Are we getting rid of the root solution file? That makes it hard to build everything.

Mike, we are getting rid of the root solution file.

Other than the typo, looks good to me.  Though I have a couple of questions/comments

We're using new terms for the top-level folder names that don't match the solution/project/namespace.  IMHO these should all be aligned:

LongTermStorage vs ColdStorage
AdHocExploration vs WarmStorage
Simulator vs ScenarioSimulator

I find it confusing that the config files aren't all at the same depth within their corresponding folders.

The cold storage config file in the root, next to the sln file.
The warm storage and simulator config files are one level deeper, with the console host .csproj files.  They should be brought up one level.

I'm not sure why the config file names need to be prefixed so verbosely.  Example, WarmStorage.EventProcessor.ConsoleHost.Template.config could probably just be settings.template.config (with the real file being settings.config).

It might be cleaner if the shared packages folder was built at /src/Shared/packages instead of /src/packages.

Also, just FYI - after pulling down these changes, one needs to do a git clean -fd with VS closed to clean up the old structure.

good catches Matt.
On the LongTermStorage VS Coldstorage points.  I thought the high level was capturing the scenario story and then we drilled down into technology implementation.  So I thought this was OK.
Be interested in what others think on this item.
On the naming for configuration.  Totally agree with Matt.  Simple simple simple naming convention. Let the location provide the configuration context.  More I think about it, I'm all for a single configuration file.  This is an Reference Implementation and should be easy to change the configuration. Hunting around to change various settings that really repeated in other files is a pain.
Move packages out of Share.   Share should be for the files we produce - not 3rd party packages.
On the Simulator, understand your point.  But we have no backlog to move the simulator to other technologies at the  moment. Where we do on the other scenario's.  My thought is to leave it as it is, until we specifically get direction to consider simulation with other technologies.
mantra - stay simple.

authors: MikeWasson azurecla hanzzhang lbrader mj1856

repo: mspnp/iot-journey


text:
Interceptor presets are no longer accessible for import

See this comment: https://github.com/mswjs/interceptors/pull/313#issuecomment-1436419369
It seems that when we added bundling for ESM/CJS, we didn't consider some of the imports that are documented in the project's documentation that say that presets should be imported like so:
import browserInterceptors from '@mswjs/interceptors/lib/presets/browser'

Hi, @cdimitroulas. This makes sense, I think we forgot the "/presets" exports. Is this only the documentation problem though?

I haven't reviewed the documentation to see if other things are invalid, I was just opening this issue based on the comment I linked so that it doesn't get lost since the comment was on a closed PR.

Yeah thank you @cdimitroulas I was about to create a tracking issue as well. Subscribed!

@blaenk, thanks for discovering this. Please, would you be interested in opening a pull request? This should be a matter of adding that path to those presets in "exports" in package.json. I can help you with the code review and getting this fix released.

Released: v0.22.5 🎉
This has been released in v0.22.5!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.

Hey, @blaenk, no worries! I think presents should be correctly exported now. Thanks for keeping an eye on these changes. I feel really good about the exports we've got now!

Hey there, it's been a while and I just recently upgraded this package from the version I pinned from before this issue, and I noticed that unfortunately there is still an issue with the exports.
Running tsc directly also leads to this issue:
error TS2307: Cannot find module '@mswjs/interceptors/presets/browser' or its corresponding type declarations.

2 import browserInterceptors from "@mswjs/interceptors/presets/browser";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've spent a few hours fiddling with the thing, reading up on typescript documentation on moduleResolution, module, etc., and my vague hunch is increasingly that it's something to do with the conditional exports. I've run tsc --traceResolution to log out what exactly tsc is doing, and have tried this with all manner of combinations of configuration values, both in tsconfig.ts and while editing @mswjs/interceptors' own package.json.
I can't figure out exactly what is going wrong, but I have a vague feeling that there are two contributing factors:

It seems like the types that get applied up are the node ones, so then if I somehow force it to pick up the browser presets (e.g. by hand-editing this package's package.json to remove the browser conditional, which seems to be getting skipped otherwise), I get type errors seemingly because the types that the node types expect, while named the same, are not the same ones as those used in the 'browser' section of the library

For some reason, the browser condition in the exports is not triggering. I can't figure out how to get tsc to look inside it. I did see this potentially relevant part of the node documentation:

When using environment branches, always include a "default" condition where possible. Providing a "default" condition ensures that any unknown JS environments are able to use this universal implementation, which helps avoid these JS environments from having to pretend to be existing environments in order to support packages with conditional exports. For this reason, using "node" and "default" condition branches is usually preferable to using "node" and "browser" condition branches.

I actually tried various combinations of this, and wasn't able to get it to work.

I think maybe the exports and use of conditionals there is too clever for the JS' ecosystem of tooling (even putting aside the dimensionality of ESM/CJS/etc.). I'm not sure what the solution is as I'm pretty new to this aspect of things and have spent many hours already trying to understand the problem.
I think it would be worth beginning by adding a sub-project to this repo which simply consists of the browser preset example, and hooking that up to github actions so we can ensure going forward that it keeps working.

@blaenk, I believe that's rather a documentation issue on the Node's side. I find the exports of Interceptors to be correct intention-wise. Certain presets mustn't be imported in certain environments. Restricting that on the imports level seems like a good idea.
What ends up happening is people importing browser-specific presents in a Node.js module. Or, at least, in a module that TypeScript treats as as Node.js module. I believe this is also what's happening in your case. You should configure TypeScript to treat that module, and import resolution in it, as a browser module (if it's indeed intended for the browser, of course). If you share more information about what you're trying to do, I may help with more specific advice.

I think maybe the exports and use of conditionals there is too clever for the JS' ecosystem of tooling

I don't think so. The problem is that JavaScript developers aren't accustomed to differentiating between different environments while writing TypeScript. They should be, and I'd rather put my effort into explaining how to do that.
I've adopted the new version of Interceptors across multiple frameworks and encountered no issues. Take a look at the examples to see if there are any extra steps necessary to make it work.

@blaenk, I believe that's rather a documentation issue on the Node's side. I find the exports of Interceptors to be correct intention-wise. Certain presets mustn't be imported in certain environments. Restricting that on the imports level seems like a good idea.

I completely empathize and agree. The intent seems correct. I understand the reason for wanting to use conditionals here.

What ends up happening is people importing browser-specific presents in a Node.js module. Or, at least, in a module that TypeScript treats as as Node.js module. I believe this is also what's happening in your case.

I agree, that's the impression I was getting because the --traceResolution was indeed showing node paths.

You should configure TypeScript to treat that module, and import resolution in it, as a browser module (if it's indeed intended for the browser, of course).

That's what I was getting at, or trying to at least. It is not clear to me what TypeScript configuration (tsconfig.ts) would have it looking under the browser condition within package.json's exports. It doesn't help that it's a very tricky thing to search for, since any information, search results, documentation---is clobbered by the export keyword in ESM. That's not your problem of course, nor am I complaining, just sharing that I have put in the effort, traced log output, searched around, etc., and it's still not quite clear to me. The closest I've arrived at is moduleResolution: bundler, but that still didn't seem to help.
You are correct that I am targeting the browser. My situation is that I'm using webpack to bundle things, however, to be very clear, I quickly ruled out webpack when I ran into the same situation with tsc --build. I wonder if browser would only get looked at by a bundler like webpack, but then since it runs tsc, that part is what is failing because it would appear tsc is unaware of the browser condition

The problem is that JavaScript developers aren't accustomed to differentiating between different environments while writing TypeScript. They should be, and I'd rather put my effort into explaining how to do that.

Agreed. I'd love to hear anything you're willing to share. I didn't come here lightly at the slightest sign of trouble, but only after really investing time to figure it out. By the way, when I mention the time I have spent trying to figure this out, I don't mean that at all to complain or to imply that it is the fault of this library, I'm grateful for the library. I mean it as a matter of fact, as I've been trying to get steeped in the whole ESM/CJS dichotomy and exports fields and dimensionality of tsc vs node vs bundlers, etc.

I've adopted the new version of Interceptors across multiple frameworks and encountered no issues. Take a look at the examples to see if there are any extra steps necessary to make it work.

I've adopted the new version of Interceptors across multiple frameworks and encountered no issues. Take a look at the examples to see if there are any extra steps necessary to make it work.

Thank you so much I was not aware of that.
However, I did a quick search and saw that you are not using the browser presets? In other words there is no import like:
import browserInterceptors from '@mswjs/interceptors/presets/browser'

I should've been clearer: the problem I'm encountering appears to be most apparent when importing the browser presets.
I can 'circumvent' the problem (with a major caveat) by simply foregoing the browser preset (which is just an array) and importing the separate packages and constructing the array myself:
import { BatchInterceptor } from "@mswjs/interceptors";
import { XMLHttpRequestInterceptor } from "@mswjs/interceptors/XMLHttpRequest";
import { FetchInterceptor } from "@mswjs/interceptors/fetch";

const interceptor = new BatchInterceptor({
  name: "interceptor",
  interceptors: [new FetchInterceptor(), new XMLHttpRequestInterceptor()],
});

My suspicion though is that that is indeed doing what you suspect as well: that it is actually picking up the node types/packages. That said, it happens to actually work out seemingly fine in the browser, but of course I'd prefer to fix that.
So to put it plainly: I'd love to know if you'd be so kind to share what TypeScript configuration would be necessary so that when my project is built, it correctly looks into the browser conditions on the exports.
I have:

"type": "module", in my package.json

in my tsconfig.ts compilerOptions I have:
"moduleResolution": "bundler",
"module": "ES2020",
"target": "ES2020",
"esModuleInterop": true

Along with these, which I'm not sure how relevant they are:
"allowSyntheticDefaultImports": true,
"alwaysStrict": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"noFallthroughCasesInSwitch": true,
"noImplicitAny": true,
"noImplicitReturns": true,
"noImplicitThis": true,
"noUnusedLocals": false,
"noUnusedParameters": false,
"skipLibCheck": true,
"sourceMap": true,
"strict": true,
"strictNullChecks": true,
"strictPropertyInitialization": false,

Thanks for a great discussion around this!
My plan is to release the next version of MSW and invest some resources into educating people around treating different environments (browser/node) while authoring tests, since that's the main area where such import issues happen.

It is not clear to me what TypeScript configuration (tsconfig.ts) would have it looking under the browser condition within package.json's exports.

Your confusion is valid. This setup often spreads outside of TS as well, since certain tools like Jest or Vitest may use code transformers and have their own module resolution on top of what you have in tsconfig.json.
It doesn't help that some tools have unintuitive defaults that make you go in circles before you realize what's going on. For example, JSDOM forces browser imports despite you writing a Node-oriented code. I'm opting-out of this behavior by using the testEnvironmentOptions.customExportConditions option in jest.config.js:
https://github.com/mswjs/msw/blob/faa71c42430176b8fb4aa073e2260a783437f3e2/test/jest.config.js#L13-L21
I'd have to research this topic better to have a write-up of the steps needed to solve it. I don't have all the info right now, unfortunately.

@blaenk, I think you're right. Those examples are using MSW in the browser, and in that environment, it doesn't rely on Interceptors at all, and uses a Service Worker instead 👍 Perhaps that's the reason why the error you're experiencing never surfaced in those examples.
We can take the first action here in introducing a module compatibility test suite. I wrote one for MSW and it has already prevented a number of broken releases in regards to ESM compatibility. We need to write this test suite for Interceptors as well to prevent module-related issues.
You can take a stab at this if it sounds interesting to you! I will always support with code review along the way.

Thanks for the call out about Jest. That's exactly the kind of thing I mean with respect to the various layers. I'm at least aware of the complexity there even if I don't fully grasp every corner of it, I am aware enough of the complexity to respect it.
This is why in my case, I'm not even at the point of involving Jest, jsdom, ts-jest, etc.---I'm purely running tsc --build alone, without any TypeScript compiler plugins or anything like that. It's as "vanilla" as it can get. I'm not going through a bundler like webpack/rollup/vite, etc.

It's perplexing to me that tsc would make any exports-related decisions, to be honest. Conditional exports are meant to be resolved by the environment, not the transpiler. A transpiler has no clue where this code will run. This is twice as confusing since TS doesn't have any designated module resolution options in terms of "hey, I want this subset of modules to use browser exports". moduleResolution is a different thing altogether.

Thanks for that insight. That's the impression I was getting as well, that TypeScript wasn't really paying attention to those things nor had a way to express which to look at.
So if we consider what you just said, and then we look at the effective, distributed package.json for this package:
  "main": "./lib/node/index.js",
  "module": "./lib/node/index.mjs",
  "types": "./lib/node/index.d.ts",
  "exports": {
    ".": {
      "types": "./lib/node/index.d.ts",
      "require": "./lib/node/index.js",
      "import": "./lib/node/index.mjs",
      "default": "./lib/node/index.js"
    },
    "./ClientRequest": {
      "browser": null,
      "types": "./lib/node/interceptors/ClientRequest/index.d.ts",
      "require": "./lib/node/interceptors/ClientRequest/index.js",
      "import": "./lib/node/interceptors/ClientRequest/index.mjs",
      "default": "./lib/node/interceptors/ClientRequest/index.js"
    },
    "./XMLHttpRequest": {
      "browser": {
        "types": "./lib/browser/interceptors/XMLHttpRequest/index.d.ts",
        "require": "./lib/browser/interceptors/XMLHttpRequest/index.js",
        "import": "./lib/browser/interceptors/XMLHttpRequest/index.mjs",
        "default": "./lib/browser/interceptors/XMLHttpRequest/index.js"
      },
      "types": "./lib/node/interceptors/XMLHttpRequest/index.d.ts",
      "require": "./lib/node/interceptors/XMLHttpRequest/index.js",
      "import": "./lib/node/interceptors/XMLHttpRequest/index.mjs",
      "default": "./lib/node/interceptors/XMLHttpRequest/index.js"
    },
    "./fetch": {
      "browser": {
        "types": "./lib/browser/interceptors/fetch/index.d.ts",
        "require": "./lib/browser/interceptors/fetch/index.js",
        "import": "./lib/browser/interceptors/fetch/index.mjs",
        "default": "./lib/browser/interceptors/fetch/index.js"
      },
      "types": "./lib/node/interceptors/fetch/index.d.ts",
      "require": "./lib/node/interceptors/fetch/index.js",
      "import": "./lib/node/interceptors/fetch/index.mjs",
      "default": "./lib/node/interceptors/fetch/index.js"
    },
    "./RemoteHttpInterceptor": {
      "browser": null,
      "types": "./lib/node/RemoteHttpInterceptor.d.ts",
      "require": "./lib/node/RemoteHttpInterceptor.js",
      "import": "./lib/node/RemoteHttpInterceptor.mjs",
      "default": "./lib/node/RemoteHttpInterceptor.js"
    },
    "./presets/node": {
      "browser": null,
      "types": "./lib/node/presets/node.d.ts",
      "require": "./lib/node/presets/node.js",
      "import": "./lib/node/presets/node.mjs",
      "default": "./lib/node/presets/node.js"
    },
    "./presets/browser": {
      "browser": {
        "types": "./lib/browser/presets/browser.d.ts",
        "require": "./lib/browser/presets/browser.js",
        "import": "./lib/browser/presets/browser.mjs",
        "default": "./lib/browser/presets/browser.js"
      }
    }
  },

Would it not therefore pick up one of the top-level module/main (I believe depending on whether my package is type: module) along with types? If that's the case, then doesn't it stand to reason that TypeScript would therefore try to use the node types for everything? Zoom in on those three fields:
  "main": "./lib/node/index.js",
  "module": "./lib/node/index.mjs",
  "types": "./lib/node/index.d.ts",

They are all node. So TypeScript would (I'm guessing) take these as the 'entry point' into things, and by then it's game over for any browser types being accessible, is my understanding.
So is the solution to this something like, don't compile with TypeScript alone, but instead with the bundler. However, the bundler will also just call out to TypeScript (ts-loader in my case with WebPack) which will attempt to type-check/etc. and so the situation would break down in the same manner (I'm only guessing. I can confirm though that bundling also fails).

For what it's worth: I just manually edited the package's package.json (as in, within node_modules) to this, and building works now:
Basically, I removed any node-only export, and in cases where there were browser and node, i made browser the default (though not via default). Everything appears to work perfectly. tsc --build passes, and bundling does too.
I don't presume to understand the intricacies, but thought it might be a revealing data point for you, since you appear to be more understanding of these things. My uninformed hunch is that tsc is being led astray somehow or is simply oblivious to browser (if that even matters, I have no clue).
  "main": "./lib/browser/index.js",
  "module": "./lib/browser/index.mjs",
  "types": "./lib/browser/index.d.ts",
  "exports": {
    ".": {
      "types": "./lib/browser/index.d.ts",
      "require": "./lib/browser/index.js",
      "import": "./lib/browser/index.mjs",
      "default": "./lib/browser/index.js"
    },
    "./XMLHttpRequest": {
      "types": "./lib/browser/interceptors/XMLHttpRequest/index.d.ts",
      "require": "./lib/browser/interceptors/XMLHttpRequest/index.js",
      "import": "./lib/browser/interceptors/XMLHttpRequest/index.mjs",
      "default": "./lib/browser/interceptors/XMLHttpRequest/index.js"
    },
    "./fetch": {
      "types": "./lib/browser/interceptors/fetch/index.d.ts",
      "require": "./lib/browser/interceptors/fetch/index.js",
      "import": "./lib/browser/interceptors/fetch/index.mjs",
      "default": "./lib/browser/interceptors/fetch/index.js"
    },
    "./presets/browser": {
      "types": "./lib/browser/presets/browser.d.ts",
      "require": "./lib/browser/presets/browser.js",
      "import": "./lib/browser/presets/browser.mjs",
      "default": "./lib/browser/presets/browser.js"
    }
  },

TypeScript always assumes Node module resolution, afaik. There's moduleResolution: bundler, which is recommended in some cases, but I don't know much about it to know what exactly it does.
In general, modern bundlers will pick up the exports fields. tsc is a transpiler, so I have no idea why it'd even look into exports. Chances are, it doesn't. It just assumes Node and picks up main.

For what it's worth: I just manually edited the package's package.json (as in, within node_modules) to this, and building works now:

It works for your use case but it breaks imports in Node.js. Interceptors is a Node-focused library, so its main entry must always point to a Node.js build.

It works for your use case but it breaks imports in Node.js. Interceptors is a Node-focused library, so its main entry must always point to a Node.js build.

Oh I didn't mean to imply that this should be the solution at all. I understand that great care and effort has been invested into making this library cater to both environments, and I am grateful for it considering I am a consumer of the secondary use case, according to you.
I only presented that as a data point in case it might be revealing to you as to what may be going on in my case, if not specifically, then broadly.
In other words, I thought that by seeing that, it might immediately reveal to you what may be going on, given you seem more knowledgeable about these things.
What you're saying tracks along another hunch I had. That the exports are looked at by webpack, so does that mean that a project using the browser part of this library cannot build with tsc alone? By that I mean, for example, running it even if only for type-checking (of course would ultimately want a bundler in the end for actual use in a browser).

If anyone's curious: I was playing around with it a bit and found that I can also resolve the issue by explicitly setting tsconfig's paths. I'm not sure if this is standard practice for doing this kind of thing (as in, not a hack), and whether it should be expected of users to know to do that (I genuinely don't know):
    "baseUrl": ".",
    "paths": {
      "@mswjs/interceptors": ["node_modules/@mswjs/interceptors/lib/browser"],
      "@mswjs/interceptors/*": ["node_modules/@mswjs/interceptors/lib/browser/*"]
    }

Just extra info for anyone else that runs into this: I was paranoid that webpack was actually still including the node files. I confirmed this by setting:
    stats: {
      logging: 'verbose',
      modules: true,
    },

Then running a build with --json=stats.json and finding occurrences to the interceptors node paths.
So I realized that I needed to inform webpack of the tsconfig paths I configured to specifically look at the browser files, so that webpack can automatically creates aliases for them, and I did so using the package tsconfig-paths-webpack-plugin with this configuration:
      plugins: [
        new TsconfigPathsPlugin({
          logLevel: "INFO",
          mainFields: ["browser", "module"],
          extensions: [".js", ".ts", ".tsx"]
        })
      ]

I would be surprised if every user knows to do this for arbitrarily-deep transitive package dependencies that require it. I feel like there probably is or should be some automatic way that I can configure my package to be targeting 'web' and for it to automatically use the browser files, both in tsc and in webpack.
It seems to me that since it's tsc which errors out primarily, the issue is probably with the fact that the top-level types refers to the node ones.
Some quick/light searching led me to https://github.com/Microsoft/TypeScript/issues/29128 which appears to be requesting a way to express certain types for a node package and other types for a browser package, e.g. with nested conditions like exports has or via a types-browser field or something like that.
The issue appears to have been closed by this comment https://github.com/Microsoft/TypeScript/issues/29128#issuecomment-449798551 which I will quote here:

If your package has different types in node vs the browser.... have you considered that you really have two separate packages? We assume that a single package has a single API.

This gets back to my comment above where I wondered if this would all be simplified (both from a package maintainer perspective and from a user perspective) if two packages were published.
I humbly put that idea forward for @kettanaito and others to consider. I'll create a separate issue to track that.

Sorry if this is considered spammy, but figured it may be interesting for anyone interested.
I learned about the customConditions setting in tsconfig. With it I can specify that it should consider browser true when looking at exports conditionals. This actually half worked in that I can correctly import the @mswjs/interceptors/presets/browser file now, but it overall fails because typescript is still using the node version of index.d.ts, so the type of BatchInterceptor is that of the lib\node version.
"customConditions": ["browser"]

Like that typescript maintainer comment says, I wonder if it might be possible to unify the types somehow (so browserInterceptors might be named commonInterceptors or something) or indeed have separate packages. See again https://github.com/Microsoft/TypeScript/issues/29128

Okay. adding that above condition to my tsconfig.ts (which I think is perfectly fine and probably preferable) + modifying this package's package.json to conditionally expose the browser types/files makes everything work! I'm curious what you think @kettanaito:
    ".": {
      "browser": {
        "types": "./lib/browser/index.d.ts",
        "require": "./lib/browser/index.js",
        "import": "./lib/browser/index.mjs",
        "default": "./lib/browser/index.js"
      },
      "types": "./lib/node/index.d.ts",
      "require": "./lib/node/index.js",
      "import": "./lib/node/index.mjs",
      "default": "./lib/node/index.js"
    },

I will file a PR for discussion.

See https://github.com/mswjs/interceptors/pull/421

authors: blaenk cdimitroulas kettanaito

repo: mswjs/interceptors


text:
Add test coverage

Description
To prevent regression, we need to add unit/e2e test coverage for all crucial functions.

TODO:

[ ] Enable Upgrade notice sub-command test cases
[ ] Enable windows support
[ ] (stretch) Enable color testing - we already have images, we can reuse them

All crucial functions are no tested, see linked pull-request for more information and https://szostok.io/projects/version/community/testing/

repo: mszostok/version


text:
templateSrv.replace returns string

this.templateSrv.replace returns string, which in case of multivalue Variable returns "{obj1,obj2,...}"
I'll pull a request with a workaround hack for logStreamNames

Sorry, datasource doesn't support multiple log stream names.
I fix UI...
https://github.com/mtanda/grafana-aws-cloudwatch-logs-datasource/commit/5774586f9a426a34cc8cc01af1610a72e88692ce


text:
🛑 https://detulkarm.edu.ps is down

In 8c5385a, https://detulkarm.edu.ps (https://detulkarm.edu.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://detulkarm.edu.ps is back up in 5b4d09d.

repo: mtitservice/site


text:
🛑 https://minfo.ps is down

In 5f560fd, https://minfo.ps (https://minfo.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://minfo.ps is back up in 711faa8.


text:
🛑 https://palpost.ps is down

In 1037a67, https://palpost.ps (https://palpost.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://palpost.ps is back up in 2357ea6.


text:
🛑 https://detulkarm.edu.ps is down

In eb1569f, https://detulkarm.edu.ps (https://detulkarm.edu.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://detulkarm.edu.ps is back up in e725ff7.


text:
🛑 https://mtit.pna.ps is down

In d77d3fe, https://mtit.pna.ps (https://mtit.pna.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://mtit.pna.ps is back up in 48f7a35.


text:
🛑 https://palcp.ps is down

In 3fff74c, https://palcp.ps (https://palcp.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://palcp.ps is back up in f0e94a9.


text:
🛑 https://minfo.ps is down

In 25be428, https://minfo.ps (https://minfo.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://minfo.ps is back up in 6380d8e.


text:
🛑 https://mtit.pna.ps is down

In 88f3eb4, https://mtit.pna.ps (https://mtit.pna.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://mtit.pna.ps is back up in 1bc273b.


text:
Screenshare

Under certain circumstances screenshare fails to connect. I tested it on different machines between different networks and can't seem to figure out the root cause. No console errors appear. In the cases where it fails (it's always this pc as broadcasting screen) anyone who is supposed to be viewing only sees constant loading. Again, testing on mulitple machines multiple networks. The machines that fail always fail and they only fail as broadcaster. Could it be an issue with these machines processors? GPUs? Network cards?

which library do you use to capture and attach screens? attach streams after Video is loaded ie Video.onplay = function (e){sharestream(e);}

Hello
First of all, Thanks for good your product...
I am using your WebRtc in my site. It is totally good.
But I have one trouble now.
When I try to share my screen with 3 or 5 participants in one session, then my cpu performance is getting 95%+.
Also in each participant side, each one is getting high cpu usage, too.
I want 10+ participants in my session, so this issue is critical from me.
I believe you can tell me  its solution.
I hope will be got your advice soon.
Thank you.

authors: Wemperer smithhan viro24

repo: muaz-khan/RTCMultiConnection


text:
Adding vetur support

Vetur can provide autocomplete support for custom components through tag and attributes definition files and by linking to them under a "vetur" key in the package.json. See this page for more details.

Excellent work! Thank you, will publish new version soon.

@all-contributors please add @shadskii for code,doc

@all-contributors please add @shadskii for code and doc

authors: mubaidr shadskii

repo: mubaidr/vue-swimlane


text:
Add installation intructions about macOS Mojave Dark Mode

I guess the light theme is more accurate to Chrome so I just added this sentence to the README for macOS Mojave and Firefox <64 users.
For #41

Oops, didn't mean to close this (on a smartphone atm).

I created MaterialFox Helper which is able to force Chrome's light or dark theme. It is experimental so I didn't include it in readme but you're welcome to give it a try and see if it improves the situation. I've tested it on Mojave and it is able to force the light theme. It's relatively stable so might be worth adding it to readme.

I agree, the light theme still faces the same issues as described in #39, so using the Helper is better overall.

Hmm, so Light (Material) would be the most accurate one I guess?
Obviously this makes this PR obsolete so feel free to close it.

Yes, Light (Material) should be about as close as possible to Chrome, though technically the default theme can always be closer due to full CSS control. Unfortunately the Mojave dark theme is a lightweight theme forced on by Firefox so in order to maintain lightweight theme compatibility we need to override it with another lightweight theme. In practice, Light (Material) and the default Mojave theme should be just about identical.
I'll need to modify the readme to link to MaterialFox Helper, or you can feel free to do so.

Feel free to do that, I think you have a better understanding whats the best in each situation.
Ping me when you did the change and I'll close the linked issue.

Done!

authors: Madis0 heubergen muckSponge

repo: muckSponge/MaterialFox


text:
Doesn't work with configurable Enter Play Mode settings

The code heavily expects statics to be cleared between runs, which breaks when you use the faster Play Mode in newer versions of Unity. I have tried to fix this myself but none of my attempts worked (hence the issue instead of a PR, sorry).
I was testing with both Domain and Scene reload disabled.
Reference: https://docs.unity3d.com/Manual/ConfigurableEnterPlayMode.html

If it helps anyone, the problem seems to be in ContinuationProcessorGroup.Add():
var p = ContinuationProcessor<T>.instance;

if(p == null)
{
	p = ContinuationProcessor<T>.instance = new ContinuationProcessor<T>(InitialCapacity);
	processors.Add(ContinuationProcessor<T>.instance);
}

The static variable ContinuationProcessor<T>.instance isn't reset to null when domain reload is disabled, and therefore isn't added to the new processors list. One solution might be to add a variable to ContinuationProcessor that you could check to see if it's from a previous play session.

Thanks for investigating this. Looks like we need to hook into [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)] and reset all static fields to resolve this. I'm not on the right computer to push any code but for future reference, adding something like...
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)]
static void Initialize()
{
	ContinuationProcessor<T>.instance = null;
}

..might help to resolve the issues. I'll work on it when I have access to my dev machine.

authors: lcsondes mikehofm muckSponge

repo: muckSponge/UnityAsync


text:
Add a newsletter section

Nowadays, newsletters are a common section in every website. I would like to make a newsletter reusable news letter section using React.

Can you please assign this issue to me?

can you guys share some ideas about the newsletter page how are you thinking to create this?

Newsletter section generally subscribes the users taking their emails to send regular updates. This has become quite popular these days.
I feel a working newsletter section fully working and independent can benefit a lot of websites and can be so useful.

can you guys share some ideas about the newsletter page how are you thinking to create this?

Something like this removing the menu, replacing the illustrations with others and adjusting the styles to the ones they are currently using.

@ch3ber can you work on the home page and let @saimaheshtaduri work on the newsletter?

Sounds good to me. Assign the issue to me. @muhammad-ahmed02

No problem @muhammad-ahmed02

assign the home page issue to me

@saimaheshtaduri make sure take a pull of updated code when you create a PR

Sure. @muhammad-ahmed02

@saimaheshtaduri are you working on this or should I close the issue?


text:
Date Picker shows wrong date value in version 18.2

The date picker will show the date minus 1-day value for a given date value in the date picker.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
The date value assigned from the state object should populate the date picker date value as it is.
Current Behavior
The date picker will show date - 1 value in the date pciker for a given date value populated through the state object.

Steps to Reproduce (for bugs)
This can be easily reproduced and can be seen here - http://www.material-ui.com/v0.18.2/#/components/date-picker

export default class DatePickerExampleToggle extends React.Component {
  constructor(props) {
    super(props);

    const date = new Date();
    this.state = {
      date: date
    };
 }
 render() {
    return (
      <div>
        <DatePicker
          floatingLabelText="Ranged Date Picker"
          value={this.state.date}
        />
    }
  }
}

Tech
Version

Material-UI
18.2

React
15.6.2

browser
Chrome (64.X)

The date picker is a challenging component to implement. The complexity comes from different sources: date manipulation and correctness, internationalization, keyboard/touch/mouse interactions, customization capabilities. We haven't been porting it to the v1-beta branch yet, nor it's a priority. But we are documenting alternatives. Here are some components that are promising:

material-ui-pickers
material-ui-time-picker

I'm closing for #4787.

I got the exactly same problem in my Material-table. The date picker will show date - 1 value in the date picker when it is editing.

authors: bansalrachita haohaiD oliviertassinari

repo: mui-org/material-ui


text:
[TextField] enhance css api

The TextField has a very limited CSS Api. I had a look into all the used components and can understand why you would not want to expose all of their CSS Apis. But the current situation is probably even worse.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡
My special use case: I have two nested themes that set overrides. Writing my own TextField component is not an option because we use e.g. react-jsonschema-form with rjsf-material-ui.
Examples 🌈
To style something in the outer theme and apply it in both I have to use selectors like
'& [class*="MuiInputLabel-outlined"]': {},
'& [class*="MuiInputLabel-root"] ~ [class*="MuiInputBase-root"] input': {},
'& [class*="MuiInputLabel-outlined"][class*="MuiInputLabel-shrink"]': {}

Motivation 🔦
Exposing (some of) the CSS Api of the underlying components of TextField would make this less prone to errors. It is hard to read and the keys are not checked by typescript.

This looks good to me. Notice

If you don't use theme nesting, you don't need the class name patch prefix, you can match exactly. This would be my preferred approach.
you can target each element with the xProps props, e.g. InputLabelProps or InputProps.

authors: oliviertassinari zepatrik


text:
Form inputs with secondary color don't get error color on focus

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
When focusing a form input, it usually gets highlighted with red if the input has an error. This is true when the color of the input is set to "primary", but not when it is set to "secondary", whereupon the secondary color is used upon focus instead. I don't see why this would be intentional. I guess the problem is related to the css specificity.
Expected Behavior 🤔
Inputs with errors should always be red by default, both when un-focused and when focused.
Steps to Reproduce 🕹
https://codesandbox.io/s/empty-violet-c37om

@fast-reflexes Your codesandbox does not contain any code using inputs. Did you forget to save or accidentally copied a different URL?

@fast-reflexes Your codesandbox does not contain any code using inputs. Did you forget to save or accidentally copied a different URL?

Woops.. forgot to save :( :) It's there now!

Woops.. forgot to save :( :) It's there now!

Thanks for the report. Very easy to follow what the problem is and how to reproduce it :+1:
I would definitely consider this a bug. I agree that the behavior for the primary color should also be implented when using the secondary color.

Thanks for the report. Very easy to follow what the problem is and how to reproduce it :+1:
I would definitely consider this a bug. I agree that the behavior for the primary color should also be implented when using the secondary color.

@fast-reflexes What do you think about this fix? Do you want to work on a pull request?
diff --git a/packages/material-ui/src/FormLabel/FormLabel.js b/packages/material-ui/src/FormLabel/FormLabel.js
index 61f4ad81a8..e3edede3d2 100644
--- a/packages/material-ui/src/FormLabel/FormLabel.js
+++ b/packages/material-ui/src/FormLabel/FormLabel.js
@@ -28,6 +28,10 @@ export const styles = (theme) => ({
     '&$focused': {
       color: theme.palette.secondary.main,
     },
+    '&$error': {
+      // To remove once we migrate to emotion
+      color: theme.palette.error.main,
+    },
   },
   /* Pseudo-class applied to the root element if `focused={true}`. */
   focused: {},
diff --git a/packages/material-ui/src/OutlinedInput/OutlinedInput.js b/packages/material-ui/src/OutlinedInput/OutlinedInput.js
index 589fae5e87..5798ed85e0 100644
--- a/packages/material-ui/src/OutlinedInput/OutlinedInput.js
+++ b/packages/material-ui/src/OutlinedInput/OutlinedInput.js
@@ -40,6 +40,10 @@ export const styles = (theme) => {
       '&$focused $notchedOutline': {
         borderColor: theme.palette.secondary.main,
       },
+      '&$error $notchedOutline': {
+        // To remove once we migrate to emotion
+        borderColor: theme.palette.error.main,
+      },
     },
     /* Styles applied to the root element if the component is focused. */
     focused: {},

I have left a comment on the new lines as we should, in theory, no longer need them once we move the component to emotion. We don't need to add a test for it.

@fast-reflexes What do you think about this fix? Do you want to work on a pull request?
diff --git a/packages/material-ui/src/FormLabel/FormLabel.js b/packages/material-ui/src/FormLabel/FormLabel.js
index 61f4ad81a8..e3edede3d2 100644
--- a/packages/material-ui/src/FormLabel/FormLabel.js
+++ b/packages/material-ui/src/FormLabel/FormLabel.js
@@ -28,6 +28,10 @@ export const styles = (theme) => ({
     '&$focused': {
       color: theme.palette.secondary.main,
     },
+    '&$error': {
+      // To remove once we migrate to emotion
+      color: theme.palette.error.main,
+    },
   },
   /* Pseudo-class applied to the root element if `focused={true}`. */
   focused: {},
diff --git a/packages/material-ui/src/OutlinedInput/OutlinedInput.js b/packages/material-ui/src/OutlinedInput/OutlinedInput.js
index 589fae5e87..5798ed85e0 100644
--- a/packages/material-ui/src/OutlinedInput/OutlinedInput.js
+++ b/packages/material-ui/src/OutlinedInput/OutlinedInput.js
@@ -40,6 +40,10 @@ export const styles = (theme) => {
       '&$focused $notchedOutline': {
         borderColor: theme.palette.secondary.main,
       },
+      '&$error $notchedOutline': {
+        // To remove once we migrate to emotion
+        borderColor: theme.palette.error.main,
+      },
     },
     /* Styles applied to the root element if the component is focused. */
     focused: {},

I have left a comment on the new lines as we should, in theory, no longer need them once we move the component to emotion. We don't need to add a test for it.

I would love too.. I haven't made a contribution to MaterialUI earlier though so I have to read up on the contribution guide and so on and I have a lot on my table right now.. but I'll see what I can do in the course of the coming week :)

I would love too.. I haven't made a contribution to MaterialUI earlier though so I have to read up on the contribution guide and so on and I have a lot on my table right now.. but I'll see what I can do in the course of the coming week :)

authors: eps1lon fast-reflexes oliviertassinari


text:
Theme's typography margin affects CSSBaseline body Margin

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
I added a default margin to my Body1 typography:
const theme = createTheme({
  typography: {
    body1: {
      margin: "1em 0",
    },
  },
});

I also use the CssBaseline component to reset my body margin. When I loaded my app, I found that my body had a margin: 1em 0;
Expected Behavior 🤔
body tag margin should be unaffected by the theme's Typography margin.
Steps to Reproduce 🕹

Steps:

Added the relevant code bits above. The situation should be fairly straightforward, but happy to create a cloneable repo if it's not.

Context 🔦
Use CssBaseline to reset my body margin while also giving my Body1 typography a default margin.
I believe the issue was introduced by https://github.com/mui-org/material-ui/commit/bd4724672e28bd0dc4be29fe3baa1d0e4cb14571#diff-1436704df74905287cc5fb6f20b61e236f60e395b38c45ec51dcbe841afa7ecaR25.
If I'm understanding the context of the change correctly, it seems like it's intending to only copy over the font size. I'd like to propose the following change:
...(theme.typography.body1 && theme.typography.body1.fontSize ? {fontSize: theme.typography.body1.fontSize} : {})
so that only the fontSize is copied over.
Your Environment 🌎

`npx @mui/envinfo`
  System:
    OS: Windows 10 10.0.19043
  Binaries:
    Node: 14.17.6 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.15 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 94.0.4606.81
    Edge: Spartan (44.19041.1266.0), Chromium (95.0.1020.30)
  npmPackages:
    @emotion/react:  11.5.0
    @emotion/styled:  11.3.0
    @mui/core:  5.0.0-alpha.51
    @mui/icons-material:  5.0.4
    @mui/material:  5.0.4
    @mui/private-theming:  5.0.1
    @mui/styled-engine:  5.0.1
    @mui/system:  5.0.4
    @mui/types:  7.0.0
    @mui/utils:  5.0.1
    @types/react: ^17.0.30 => 17.0.30
    react:  17.0.2
    react-dom:  17.0.2
    typescript: ^4.4.4 => 4.4.4

However it introduces crud just to avoid a breaking change, the removal of which would itself be a breaking change.
Let's park this one unless it gets sufficient momentum.


text:
[TextField] Fix classes forward to InputBase

[x] I have followed (at least) the PR section of the contributing guide.

Closes #26157

@eps1lon The ambition of the fix was demoted. It's now only fixing the regression (v4 -> v5) on the forward of the classes object, from the wrapper to the InputBase component. Regarding extending the classes to support more keys, we have #20706. Is seems that we can remove the "on hold" label as the types are no longer impacted. Do you confirm?

Regarding extending the classes types to support more keys, we have #20706. Is seems that we can remove the "on hold" label as the types are no longer impacted.

Yep looks ok now after review. In the future, don't blame everything on somebody else on reflex. Thinks usually fail for a reason, not just to block you.

@arpitBhalla Thanks

@oliviertassinari Thanks tou you too Sir

authors: arpitBhalla eps1lon oliviertassinari


text:
[examples] Update create-react-app examples with styled-components to use package aliases

Follow up on https://github.com/mui-org/material-ui/pull/27583
This PR updates the create-react-app examples that use styled-components to use package aliases.

Will we handle the styled interoperability section and the style engine docs section in a different PR?

Yes, will update the docs and the guides in a follow up PR


text:
Custom props don't exist in ownerState

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Link to live example: https://codesandbox.io/s/fast-forest-9roq93?file=/src/App.tsx
Browser Used: Chrome
Steps:

(If using Typescript) Add the custom prop definition to the Select component's props:

declare module "@mui/material/Select" {
    interface SelectProps {
        customStyle?: "red" | "blue";
    }
}

Add the styleOverride for MuiSelect to the theme:

components: {
    MuiSelect: {
        styleOverrides: {
            select: ({ ownerState }) => {
                if (!ownerState) return {};

                return {
                    backgroundColor: ownerState.customStyle === "red" ? "red" : "blue"
                };
            }
        }
    }
}

Use the Select component with the custom prop:

<Select
     customStyle="red"
     value={value}
     onChange={(event) => setValue(event.target.value)}
>
    ....
</Select>

I've noticed that if I inspect element on the select that the custom prop gets passed to the element, which makes sense. Normally I would use styled to create a variation and forward the custom prop but I didn't see if that's possible in the documentation.
The documentation I've followed is: https://mui.com/material-ui/customization/theme-components/#overrides-based-on-props
Current behavior 😯
The background of the Select will always be "blue" even if customStyle="red"
Expected behavior 🤔
When customStyle="red", the background color should change to red and vice-versa.
Context 🔦
Based on custom props from the design system I would like to change the style of the select globally.
Your environment 🌎

npx @mui/envinfo
  System:
    OS: macOS 13.1
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 3.1.1 - ~/.yarn/bin/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 109.0.5414.87
    Edge: Not Found
    Firefox: 98.0.1
    Safari: 16.2
  npmPackages:
    @emotion/react:  11.9.0
    @emotion/styled:  11.8.1
    @mui/base:  5.0.0-alpha.82
    @mui/envinfo:  2.0.8
    @mui/icons-material:  5.8.0
    @mui/lab:  5.0.0-alpha.78
    @mui/material:  5.8.1
    @mui/private-theming:  5.8.0
    @mui/styled-engine:  5.8.0
    @mui/styles:  5.8.0
    @mui/system:  5.10.4
    @mui/types:  7.1.3
    @mui/utils:  5.8.0
    @types/react:  16.14.21
    react:  17.0.2
    react-dom:  17.0.2
    styled-components:  5.3.3
    typescript: ^4.3.5 => 4.5.4

At this moment we don't support adding new props to the existing components. I don't believe this is documented as supported anywhere. The style overrides are intended for adding custom overrides based on the existing props of the components. For scenarios like this, you should be able to create a new styled component, use the shouldForwardProp if this shouldn't be spread on the inner component, and style it accordingly to your design spec. You can use this issue's comment as an inspiration: https://github.com/mui/material-ui/issues/25925#issuecomment-1190831411

Makes sense, I thought it might be the case but I saw that the Typescript definition was SelectProps<unknown> & Record<string, unknown> so I thought the Record<string, unknown> might have been for custom props.
Thank you for the help.

authors: mnajdova robertcorponoi

repo: mui/material-ui


text:
Autocomplete not working with NextJS app directory

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Link to live example: don't have
Steps:

follow official example using Chips

Current behavior 😯
I'm having the same problem this guy is having https://stackoverflow.com/questions/75818761/material-ui-autocomplete-warning-a-props-object-containing-a-key-prop-is-be
Expected behavior 🤔
It should work the same way it was working using pages directory
Context 🔦
It's not working
Your environment 🌎

npx @mui/envinfo
  System:
    OS: Windows 10 10.0.19044
  Binaries:
    Node: 18.12.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Spartan (44.19041.1266.0), Chromium (115.0.1901.188)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.8
    @mui/core-downloads-tracker:  5.14.2
    @mui/icons-material: ^5.14.1 => 5.14.1
    @mui/material: ^5.14.2 => 5.14.2
    @mui/private-theming:  5.13.7
    @mui/styled-engine:  5.13.2
    @mui/styled-engine-sc: ^5.12.0 => 5.12.0
    @mui/system:  5.14.1
    @mui/types:  7.2.4
    @mui/utils:  5.14.1
    @mui/x-data-grid: ^6.10.2 => 6.10.2
    @types/react: 18.2.17 => 18.2.17
    react: 18.2.0 => 18.2.0
    react-dom: 18.2.0 => 18.2.0
    styled-components: ^5.3.11 => 5.3.11
    typescript: 5.1.6 => 5.1.6

I changed my file extentions from js to jsx and it worked. Not using TS though


text:
Stepper lacks accessibility

Summary
When navigating the Stepper component with voice assistant and keyboard-only navigation, it doesn't read out which step you're currently in when you go to the next step. It also doesn't hint the user how many steps there are in total.
Examples
No response
Motivation
No response
Search keywords: Stepper lacks accessibility

Thanks for reporting the issues. This is one of the thing to improve for sure, ref https://ishadeed.com/article/stepper-component-html-css/.

Thanks for reporting the issues. This is one of the thing to improve for sure, ref https://ishadeed.com/article/stepper-component-html-css/.

Seems like this example website is also inaccessible, it achieves the Stepper as a UI but voice assistant + keyboard navigation is still not there. The current Stepper in MUI in production is even better than this one imo. Here are a few specs I feel could make the Stepper more accessible for voice-overs:
when focusing on the whole stepper: tell the user they are in a stepper, tell them how many steps there are
when focusing on a step: tell the user which step they're in and in what order (e.g you are in 2nd step)
when finishing the steps: tell them they've finished all steps

Thanks for reporting, @jacklaurencegaray. We'll most probably migrate components to Base UI in Material UI v7. Until then, we'll accept community contributions for improvements in the Stepper component (as long as they don't introduce breaking changes).


text:
[docs][pigment-css] Fix README typos

[x] I have followed (at least) the PR section of the contributing guide.

@ZeeshanTamboli, just opened a new PR https://github.com/mui/pigment-css/pull/5


text:
fix(decoder): n bytes counter

Fix n bytes counter mismatch on decode header
Make ErrCRCChecksumMismatch more verbose in CheckIntegrity
Simplified readbuffer's ReadN

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (456a9fd) to head (7f09f86).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #223   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           42        42
  Lines         3607      3606    -1
=========================================
- Hits          3607      3606    -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter muktihari

repo: muktihari/fit


text:
DOCS-8198-CONN-scripting-reference-kt

scripting-reference.adoc v 2.0.0

Closing new https://github.com/mulesoft/docs-connectors/pull/812

repo: mulesoft/docs-connectors


text:
Add user and group to NatRule

This change is

Closing because user and group don't seem to matter for NAT rules.

repo: mullvad/pfctl-rs


text:
Display appropriate-sized matrix on-load

This is meant to prevent overly large or badly structured full adjacency matrices from appearing.
For instance, a 1000x1000 adjacency matrix simply won't be legible if plotted naively.
Even a small, bipartite network can waste a lot of space: the Paul Revere network has two bipartite classes: 7 clubs and ~150-some-odd people. The naive rendering results in a large swath of non-connected nodes (in the club-to-club and people-to-people regions), with a thin, 7x~150 patch encoding the interesting information reflected across the diagonal. Better would be to express the two classes in the rows and columns, and make better use of the full screen real estate.

Alex suggested having 2-3 default views:

detailed view: shows label
overview: doesn't show labels

@jtomeck, feel free to use this issue as a place to discuss design issues, etc., around this feature.

authors: gotdairyya waxlamp

repo: multinet-app/view-adjmatrix


text:
Implemented generator

Implemented CSV generator
Generated CSV file, lol

Perfect!

repo: multipleton/dcs-whiskey


text:
Fix not running tests

Some tests are not running because there are GRASS GIS data used which are not included in the test docker. The ECAD location have to be changed to the NC-modis_lst mapset in the tests.
Additionally, the other tests have to be checked.

Note: the currently used test dataset offers:

https://grass.osgeo.org/sampledata/north_carolina/nc_spm_08_micro.zip

raster: lsat7_2002_10, landuse96_28m, aspect, basin_50K, slope, elevation

https://grass.osgeo.org/sampledata/north_carolina/nc_spm_mapset_modis2015_2016_lst.zip

vector:

point maps: elev_lid792_bepts, elev_lid792_randpts, elev_lidrural_mrpts, elev_lidrural_mrptsft, firestations, hospitals, poi_names_wake
line maps: boundary_county, elev_lid792_cont1m
polygon maps: geology, nc_state

Some tests are fixed in https://github.com/mundialis/actinia_statistic_plugin/pull/20
The rest of the tests will be fixed in an second PR by @linakrisztian and @VeronicaKoess

authors: anikaweinmann neteler


text:
Quotes in .env.example file causes exception

I copied the contents of the .env.example file for use with the instance I am setting up in docker. I am using the sqlite db, and received the following Fatal error:
Fatal error: Uncaught Exception: Unknown driver: "sqlite" in /var/munkireport/app/config/db.php:35 Stack trace: #0 /var/munkireport/app/helpers/config_helper.php(82): require() #1 /var/munkireport/bootstrap/app.php(38): configAppendFile('/var/munkirepor...', 'connection') #2 /var/munkireport/public/index.php(7): require_once('/var/munkirepor...') #3 {main} thrown in /var/munkireport/app/config/db.php on line 35
Changing the line in the .env file from CONNECTION_DRIVER="sqlite" to CONNECTION_DRIVER=sqlite fixed this issue.
I also found in slack where @flammable was having the same issue with the mysql driver: https://macadmins.slack.com/archives/C066NK3K5/p1548005965938100
I would suggest changing the .env.example file to remove those quotes, however, I'm not sure how far beyond the issues with the quote @flammable and I noticed one would need to go to remove this problem.

I'm seeing this same issue on other variables as well as I continue through the setup. Is this an issue related to my environment potentially?

@hfike It might be related to Docker. I have no problem with those quotes in my non-docker setup.

https://github.com/docker/compose/issues/3702
Sent from my iPhone

On 20 Jul 2019, at 19:18, Kevin M. Cox notifications@github.com wrote:
@hfike It might be related to Docker. I have no problem with those quotes in my non-docker setup.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sorry @hfike, I should really update my blog post to cover MunkiReport v4 in Docker (or frankly, the wiki). I had to eliminate all quotes from my env file, since they just don't work with Docker Compose.

I plan on making some notes on the wiki, however, if quote are removed, does this break non-docker usage?

Leaving out quotes caused some preferences not being parsed correctly. We would need to test if that’s still the case.
Sent from my iPhone

On 22 Jul 2019, at 07:15, Harry Fike notifications@github.com wrote:
I plan on making some notes on the wiki, however, if quote are removed, does this break non-docker usage?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: bochoven flammable hfike kevinmcox

repo: munkireport/munkireport-php


text:
Show the average amount of each type of resource by survivor

Should display a list containing the averages of resources by type (e.g. 10 Water per survivor).

SQL Query:
SELECT it.name, AVG(res.quantity)
FROM survivors AS surv
INNER JOIN inventories AS inv ON inv.owner_id = surv.id
INNER JOIN resources AS res ON res.inventory_id = inv.id
INNER JOIN items AS it ON it.id = res.item_id
GROUP BY it.name
ORDER BY it.name;

repo: murilocosta/agartha