text:
I want to receive and send the Japanese hiragana and kanji（漢字やひらがなを送受信したい）

Do you may be exchanged in any way when you want to send and receive hiragana and kanji in Japanese?
I would like to receive and send the Japanese hiragana and kanji,
I will fail to UnPack.
Please tell me if there is a caveat when you want to send the hiragana and kanji.
You can use the HttpWebRequest method in the Unity of C # and is sending and receiving.
Open the MsgPack.Net35 under the src folder in MonoDevelop,
In General of Build of Project Options
A In Mono / .Net3.5 TargetFramework
How can you build, out an error in the following
Build did not complete.
INilImplicationHandlerOnUnpackedParameter.cs of
internal interface INilImplicationHandlerOnUnpackedParameter : INilImplicationHandlerParameter
Is because the compile error is gone Once in Mono / .Net4.0,
Following expression might not have been allowed in .Net3.5.

Please tell me.

日本語のひらがなや漢字を送信と受信したいのですが、
UnPackに失敗してしまいます。
ひらがなや漢字を送信する時の注意点があれば教えてください。
UnityのC#内でHttpWebRequestメソッドを使用して送信・受信しています。
また、srcフォルダの下のMsgPack.Net35をMonoDevelopで開き、
Project OptionsのBuildのGeneralで
TargetFrameworkを Mono/.Net3.5 にして
ビルドしたのですが、下記でエラーが出て
ビルドが完了しませんでした。
INilImplicationHandlerOnUnpackedParameter.csの
internal interface INilImplicationHandlerOnUnpackedParameter : INilImplicationHandlerParameter
Mono/.Net4.0にしたらコンパイルエラーがなくなったので、
下記表現は.Net3.5では許可されてないのかもしれません。

解決方法があれば教えてください。

Msgpack for CLI uses utf-8 by default, so any Japanese chars should be transferred. Would you show me the code which writes the msgpack stream with HttpWebClient?

Sorry, it seems that the .csproj file is staled. What branch did you cloned, and which .sln file did uou open?

I'm sorry in the long code
　Environment Unity4.6.2.  language C #

UseDLL is MsgPack.dll  in Unity3D Folder with MsgPack.Cli.0.5.11.zip
using UnityEngine;
using System;
using System.IO;
using System.Net;
using System.Collections;
using System.Collections.Generic;
using MsgPack.Serialization;
using MsgPack;
public void OnClickMsgPackDataClass()
{

    SendData senddata = new SendData();

    senddata.testdata = new TestData();

    senddata.status = 0;

    senddata.testdata.flgs = true;
    senddata.testdata.userId = 2147483647;
    senddata.testdata.os = 9223372036854775807;
    senddata.testdata.appVersion = 1.23456f;
    senddata.testdata.osVersion = 1.23456789012345d;

    DateTime nowtime = new DateTime();
    nowtime = DateTime.Now;
    senddata.testdata.requestTimestamp = nowtime.ToString("s");
    senddata.testdata.texthiragana = "あいうえおかきくけこさしすせそ";
    senddata.testdata.textkana = "タチツテトナニヌネノハヒフヘホ";
    senddata.testdata.textkanzi = "温故知新因果応報";
    senddata.testdata.textmulti = "あイ鵜えオ科きク家こ";
    senddata.testdata.sessionkey = "db5g2IkpaLY40Kme";
    senddata.testdata.language = "ja";
    senddata.testdata.device = "iPhone5";
    senddata.testdata.userUuid = "1a12za-6315-4598-124e-azsd521486d";
    senddata.testdata.signature = "1354azadfdfsdfsdfsd44464grtgrghtththtc15b0db2a02694c20505355f";

    // --- シリアライズ
    var stream = new MemoryStream();
    var serializer = SerializationContext.Default.GetSerializer<TestData>();
    // Pack obj to stream.
    serializer.Pack(stream, senddata.testdata);

    // デバッグ用バイト配列を取り出す
    byte[] bytes = stream.GetBuffer();

    // デバッグ用UTF-8 エンコード
    string text = System.Text.Encoding.UTF8.GetString(bytes);

    Debug.Log("text=" + text);

    HttpWebRequest req = (HttpWebRequest)WebRequest.Create(JSON URL String);
    req.ContentType = "application/x-msgpack; charset=UTF-8";
    req.Method = "POST";
    req.Accept = "application/x-msgpack";

    req.ContentLength = stream.Length;

    // データの設定
    System.IO.Stream s = req.GetRequestStream();
    s.Write(stream.ToArray(), 0, stream.ToArray().Length);
    s.Close();

    HttpWebResponse wres = (HttpWebResponse)req.GetResponse();
    //応答データを受信するためのStreamを取得
    Stream receiveStream = wres.GetResponseStream();
    StreamReader readStream = new StreamReader(receiveStream, System.Text.Encoding.UTF8);

    // --- デシリアライズ
    var unpacks = serializer.Unpack(receiveStream);

}

I've used the 0.5.11 of this URL.
　　　 https://github.com/msgpack/msgpack-cli/releases/
And I have to download the Zip file from this page.
Name is "Source code (zip)".
The procedure to open the "Mono develop Ver 4.0.1", was the build target to Mono / .Net3.5.
The opened project is "MsgPack.Net35.sln" under the "\src\MsgPack.Net35" folder.
When you build I get the following 4 errors:
\msgpack-cli-0.5.1_source\msgpack-cli-0.5.11\src\MsgPack\Serialization\INilImplicationHandlerOnUnpackedParameter.cs(63,63): Error CS1031: 型が必要です。 (CS1031) (MsgPack.Net35)
\msgpack-cli-0.5.1_source\msgpack-cli-0.5.11\src\MsgPack\Serialization\INilImplicationHandlerOnUnpackedParameter.cs(63,63): Error CS1519: 無効なトークン 'out' が クラス、構造体またはインターフェイスのメンバ宣言で使用されています。 (CS1519) (MsgPack.Net35)
\msgpack-cli-0.5.1_source\msgpack-cli-0.5.11\src\MsgPack\Serialization\INilImplicationHandlerOnUnpackedParameter.cs(74,74): Error CS1519: 無効なトークン '>' が クラス、構造体またはインターフェイスのメンバ宣言で使用されています。 (CS1519) (MsgPack.Net35)
\msgpack-cli-0.5.1_source\msgpack-cli-0.5.11\src\MsgPack\Serialization\INilImplicationHandlerOnUnpackedParameter.cs(2,2): Error CS1519: 無効なトークン '{' が クラス、構造体またはインターフェイスのメンバ宣言で使用されています。 (CS1519) (MsgPack.Net35)

Add'd like to hear your, but if the above Hiragana and Kanji em 11 characters, unpack will always fail.
Could you tell me How can reason I think that there is a kind of etiquette when using the full-width?

I have some questions about your code. It looks like that it send msgpack stream to JSON URL, and get response from the "JSON URL" site. I'm afraid that you sent msgpack stream to the server which expect JSON formatted request and it respond back JSON encoded error message -- msgpack serializer cannot recognize such (encoded JSON) stream.
I rewrote your code in 2 projects using HttpListener instead of WebRequest.GetResponse and test it, it worked fine in .NET 3.5 runtime. I will put the testing code in the end of this post for your information.

Sorry, you were right. Covariance (out' in generic argument) was supported from C# 4 compiler. I will fix it, but you can just remove outqualifier fromINilImplicationHandlerOnUnpackedParameter` source now.

Just use String :)

My test codes are below:
[Client code]
static void Main( string[] args )
{
	try
	{
		Console.WriteLine("CLIENT");
		Console.ReadLine();
		// ***Begin your original code except omitting outer SendData class.***
		var testdata = new TestData();

		//status = 0;

		testdata.flgs = true;
		testdata.userId = 2147483647;
		testdata.os = 9223372036854775807;
		testdata.appVersion = 1.23456f;
		testdata.osVersion = 1.23456789012345d;

		DateTime nowtime = new DateTime();
		nowtime = DateTime.Now;
		testdata.requestTimestamp = nowtime.ToString( "s" );
		testdata.texthiragana = "あいうえおかきくけこさしすせそ";
		testdata.textkana = "タチツテトナニヌネノハヒフヘホ";
		testdata.textkanzi = "温故知新因果応報";
		testdata.textmulti = "あイ鵜えオ科きク家こ";
		testdata.sessionkey = "db5g2IkpaLY40Kme";
		testdata.language = "ja";
		testdata.device = "iPhone5";
		testdata.userUuid = "1a12za-6315-4598-124e-azsd521486d";
		testdata.signature = "1354azadfdfsdfsdfsd44464grtgrghtththtc15b0db2a02694c20505355f";

		// --- シリアライズ
		var stream = new MemoryStream();
		var serializer = SerializationContext.Default.GetSerializer<TestData>();
		// Pack obj to stream.
		serializer.Pack( stream, testdata );

		HttpWebRequest req = ( HttpWebRequest )WebRequest.Create( "http://localhost/issue77" );
		req.ContentType = "application/x-msgpack; charset=UTF-8";
		req.Method = "POST";
		req.Accept = "application/x-msgpack";

		req.ContentLength = stream.Length;

		// データの設定
		var s = req.GetRequestStream();
		s.Write( stream.ToArray(), 0, stream.ToArray().Length );
		s.Close();
		// ***End your original code***
		Console.WriteLine("SENT");
		Console.ReadLine();
	}
	catch ( Exception ex )
	{
		Console.WriteLine( ex );
	}
}

[Server code]
static void Main( string[] args )
{
	try
	{
		var serializer = MessagePackSerializer.Get<TestData>();
		Console.WriteLine( "SERVER" );

		HttpListener listener = new HttpListener();
		listener.Prefixes.Add( "http://localhost/issue77/" );
		listener.Start();
		var context = listener.GetContext();
		var unpacked = serializer.Unpack( context.Request.InputStream );
		Console.WriteLine( "hiragana:{0}", unpacked.texthiragana );
		Console.WriteLine( "katakana:{0}", unpacked.textkana );
		Console.WriteLine( "kanji   :{0}", unpacked.textkanzi );
		Console.WriteLine( "multi   :{0}", unpacked.textmulti );
		listener.Abort();
	}
	catch ( Exception ex )
	{
		Console.WriteLine( ex );
	}
}

Note: If you run above code in Windows, you must run server as elevated privilege (you must run the cmd.exe as adminitrator).

I'm sorry to how to write misleading
JSON URL String  is actually is the URL of the API.
Security of relationship I have such writing.
And server side is written in code of java.

In fact, although it was built and already remove the out,
Place the crafted DLL under the Unity of Assets folder
And auto compile runs I get an error such as the following.
So it is not possible to use to build the DLL,
I've used the DLL of Unity3D folder of MsgPack.Cli.0.5.11.zip.
Be .Net and cause .Net3.5 differs from the Visual Studio of Mono in Unity
Might.
Therefore, the correct answer of how to methods and build use correctly the DLL of MsgPack
It is in that situation that no longer know.
**************** Error Detail (Unity Console View)  ****************
Internal compiler error. See the console log for more information. output was:
Unhandled Exception: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
at System.Reflection.Assembly.GetTypes () [0x00000] in :0
at Mono.CSharp.RootNamespace.ComputeNamespaces (System.Reflection.Assembly assembly, System.Type extensionType) [0x00000] in :0
at Mono.CSharp.RootNamespace.ComputeNamespace (Mono.CSharp.CompilerContext ctx, System.Type extensionType) [0x00000] in :0
at Mono.CSharp.GlobalRootNamespace.ComputeNamespaces (Mono.CSharp.CompilerContext ctx) [0x00000] in :0
at Mono.CSharp.Driver.LoadReferences () [0x00000] in :0
at Mono.CSharp.Driver.Compile () [0x00000] in :0
at Mono.CSharp.Driver.Main (System.String[] args) [0x00000] in :0

Thank you for writing a sample code.
Because knowledge of the server-side is zero, you can try while examining the web.
Create as a console app in both VisualStudio,
And launch the server code exe, and if you want to do it on the run exe client code
What good?

Sorry for delayed response.

OK.
There are no special instruction you need to do. Would you show me the console log? Your pasted error message said that detailed information should be shown at "console log"...
Excuse me, did you ask me how to run sample program? To verify serialization, see server side console log and check whether sent Japanese characters are shown correctly.

遅くなりまして申し訳ありません。

承知しました。
特別なことをしなくても構いません。「console log」を見せてもらうことはできませんか？ 貼り付けていただいたエラーメッセージでは詳細は「console log」を見ろと書いてありますので。
すみません、サンプルプログラムの実行方法を聞いていますか？ 結果を確認するには、サーバ側プログラムのコンソールログを見て、送信した日本語文字が正しく表示されているかを確認していただければ。

@st0326s Has this problem solved?

Closed because 2 months gone.

repo: msgpack/msgpack-cli


text:
Added bin format family support.

https://github.com/msgpack/msgpack/blob/master/spec.md#bin-format-family

I'm using msgpack-javascript. It doesn't support new msgpack format. So I've added the bin format family support. I chose Uint8Array as the source type corresponding to bin.
I'm not sure that is the appropriate repository to send the pull request. I've also find the following implementation:
http://uupaa.hatenablog.com/entry/2012/11/19/030815
https://gist.github.com/uupaa/4106426

Is this project alive?

Hi there,
Actually, this project has been stagnant.
There is also a better modern code. https://github.com/uupaa/MessagePack.js
However, because it does not work in older browsers that do not use the TypedArray, it cannot entirely be replaced.

@redboltz  it's merged. thank you.

source: gharchive/pull-request

authors: jedie redboltz uupaa

repo: msgpack/msgpack-javascript

license: ISC

license_type: permissive

license_source: github-api


text:
Localmongo version 4.4.1

Update localmongo version to 4.4.1

Hi @gs-jha, thank you for the pull request. I have decided to implement this in a slightly different way... so developers can switch between versions based on their project needs. Please pull latest master branch.

authors: gs-jha msound

repo: msound/localmongo

license: MIT


text:
SAGE 2021 job script update

upload job scripts

Codecov Report

Merging #238 (15f767b) into master (a59fd6a) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #238      +/-   ##
==========================================
- Coverage   47.93%   47.92%   -0.01%
==========================================
  Files         118      118
  Lines       15353    15353
==========================================
- Hits         7359     7358       -1
- Misses       7994     7995       +1

Impacted Files
Coverage Δ

python/mspasspy/db/database.py
82.62% <0.00%> (-0.07%)
:arrow_down:

Continue to review full report at Codecov.

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

authors: codecov-commenter haruming

repo: mspass-team/mspass


text:
🛑 NYIAC is down

In cd3f0af, NYIAC (https://nyiac.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NYIAC is back up in 1322572 after 10 minutes.

source: gharchive/issue

repo: mswd-io/upptime


text:
[MTSRE-586] fix: use --build-with tag in dry-run mode

Signed-off-by: Priyanshu Raj prraj@redhat.com
py-mtcli
Description
fix for https://issues.redhat.com/browse/MTSRE-586
Next step:

Add --build-with tag in the check target here: https://gitlab.cee.redhat.com/service/managed-tenants-bundles/-/blob/main/Makefile#L29-35

/ok-to-test

repo: mt-sre/managed-tenants-cli


text:
documentation not up to date

A lot of the recent changes are not documented yet.

They’re in the queue for V4.1 docs. Just not public yet.

Yep, that was my assumption. Ticket can be considered a reminder.

4.1 was updated. Please let me know if anything appears missing.

The order of names for meld cards appears to be undocumented.

@fenhl Doc'd in changelog, but could prob be added to docs page

The changelog should not be considered documentation. If important things are mentioned there but left out from the docs page, users may have to scroll through the changelog (which will only get longer over time) to find what they're looking for.

Why is this closed? The missing documentation for meld card names has still not been addressed.

Thanks @ancestral: https://github.com/mtgjson/mtgjson4-website/commit/18fc36b8e8d6c7cc074c9dc68986f495240860ad

authors: ZeldaZach ancestral fenhl tooomm


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

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

HTTP code: 0
Response time: 0 ms

Resolved: https://treport.mtit.pna.ps is back up in 78b1b01.

repo: mtitservice/site


text:
🛑 https://ejrs.moj.pna.ps is down

In 5c42906, https://ejrs.moj.pna.ps (https://ejrs.moj.pna.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://ejrs.moj.pna.ps is back up in ffffd1c.


text:
Deck: Undertale not grabbing all files in manifest (only the first configuration file)

Ludusavi version
v0.15.2
Operating system
Linux (Steam Deck)
Installation method
Flatpak
Description
When trying to back up Undertale, even though the configuration contains undertale.ini (which is correct in PCGamingWiki and manifest), ludusavi for some reason doesn't retrieve the file. Ludusavi does grabs registry files which are not required for saving.
Another question is should Ludusavi throw an error if not all the files are found if PCGamingWiki provides file path instead of folder paths? PCGamingWiki doesn't mark files as optional so should it be assumed all files are mandatory?
I have attached logs, configuration, and the ls of the game files (all files have the same read/write permissions in the directory)
Logs
Log
INFO [ludusavi::cli] beginning backup with 1 steps
DEBUG [ludusavi::prelude] ranking installations for Steam: /home/deck/.local/share/Steam
DEBUG [ludusavi::prelude] [Undertale] selecting subdir with score 9223372036854775807: Undertale
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/drive_c/users/steamuser/AppData/Local/UNDERTALE/file9
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/drive_c/users/steamuser/AppData/Local/UNDERTALE/file9
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/drive_c/users/steamuser/AppData/Local/UNDERTALE/file0
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/drive_c/users/steamuser/AppData/Local/UNDERTALE/config.ini
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/system.reg
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/user.reg
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/userdef.reg
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/drive_c/users/steamuser/AppData/Local/UNDERTALE/file0
DEBUG [ludusavi::prelude] [Undertale] found: /home/deck/.local/share/Steam/steamapps/compatdata/391540/pfx/drive_c/users/steamuser/AppData/Local/UNDERTALE/config.ini
INFO [ludusavi::layout] [Undertale] no need for new backup
INFO [ludusavi::cli] completed backup

config
---
manifest:
  url: "https://raw.githubusercontent.com/mtkennerly/ludusavi-manifest/master/data/manifest.yaml"
  etag: ~
language: en-US
theme: light
roots:
  - path: /home/deck/.local/share/Steam
    store: steam
redirects: []
backup:
  path: /home/deck/ludusavi-backup
  ignoredGames: []
  merge: true
  filter:
    ignoredPaths: []
    ignoredRegistry: []
  toggledPaths: {}
  toggledRegistry: {}
  sort:
    key: name
    reversed: false
  retention:
    full: 1
    differential: 0
  format:
    chosen: simple
    zip:
      compression: deflate
    compression:
      deflate:
        level: 6
      bzip2:
        level: 6
      zstd:
        level: 10
restore:
  path: /home/deck/ludusavi-backup
  ignoredGames: []
  sort:
    key: name
    reversed: false
customGames:
  - name: Undertale
    files:
      - "<root>/userdata/<storeUserId>/391540/remote"
      - "<winLocalAppData>/UNDERTALE/file0"
      - "<home>/Library/Application Support/com.tobyfox.undertale"
      - "<home>/.config/UNDERTALE_linux"
      - "<winLocalAppData>/UNDERTALE/config.ini"
      - "<home>/.config/UNDERTALE_linux_steamver"
      - "<winLocalAppData>UNDERTALE/undertale.ini"
      - GOG
      - "<winLocalAppData>/UNDERTALE/file9"
    registry: []

directory

There might be a typo in your custom configuration - the line with the undertale.ini misses a / in front of UNDERTALE:
excerpt:
      - "<winLocalAppData>/UNDERTALE/config.ini"
      - "<winLocalAppData>UNDERTALE/undertale.ini"

HTH

This error originates from the data on pcgamingwiki:  https://www.pcgamingwiki.com/wiki/Undertale

Thanks @sluedecke for noticing the typo.  Apologies for being blind. I'll mark this ticket as closed and open an issue with PCGamingWiki

Curious @sluedecke to get your thoughts on my other comment, if it makes sense to throw an error throw an error if not all the provided files (file path not directory path) are found from PCGamingWiki? PCGamingWiki doesn't mark files as optional so should it be assumed all files are mandatory?

In the scenario when you have started the game once, but did not yet create a save game, some files might be rightfully missing.  I would go for a warning if some files or folders are not present.
But: ludusavi would then need to aware which 'system' you are using (no need to warn about missing macos files on a linux machine etc.) and I am not sure if it is at the moment.  The manifest includes such information, but prelude::scan_game_for_backup uses a list of paths generated in prelude::parse_paths and this list no longer has this information.  Maybe @mtkennerly has some more thoughts on that.

Giving it some more thought, I would even question having a warning, for example Dwarf Fortress: versions < 50.x store their saves in <path-to-game>/data/save, but the latest version 50.x and up store it in <path-to-game>/save.  There is no information on how to differentiate that, so even a warning would be potentially misleading here.

Yeah, it's really hard to do a warning like that without false positives, since it can vary by game and how complete/accurate the PCGW page is.
Thanks for helping catch the data error here :+1:

authors: JSin mtkennerly sluedecke

repo: mtkennerly/ludusavi


text:
Extension crashes when registering duplicate connection name

Describe the bug
The new option to save passwords on vscode's keystore is registering the connection using only it's name as a unique identifier.
So by creating two connections that uses the SQLTools Driver Credentials, and have the exact same name, database and driver, the extension won't work until one connection is manually erased from the config file

I think the extension should either prevent duplicate connection names, or add a unique identifier to the connection ID.

This problem existed before 0.27.0 and is unrelated to the new capability for drivers to store passwords in the keystore. See https://github.com/mtxr/vscode-sqltools/issues/668#issuecomment-991088634

authors: dyegoaurelio gjsjohnmurray

repo: mtxr/vscode-sqltools


text:
Allow to specify session file location relative to workspace root

Is your feature request related to a problem? Please describe.
I've set up a couple different connections in workspace-level settings of different projects. They are stored under .vscode in the project root. I want to be able to also store session files somewhere in the project directory tree.
Describe the solution you'd like
Allow to somehow set session file location relative to project root. Possible solutions:

relative paths are always treated as relative to workspace root
relative paths in workspace-level settings are treated as relative to workspace root
a separate flag in settings to treat the path as relative to workspace root
resolve $workspaceRoot (and possibly other variables?)

Describe alternatives you've considered
I have found no suitable alternative for this feature
Additional context
SQLTools v0.28.0

Love to have this.

authors: iliazeus vietstone-ng


text:
Tab design is not the same as chrome

The tab design is changed in the latest version. The side edges does not have the curve and fall straight. They also seem shorter in height . Firefox stable 88.0.1

I've switched the master branch to tackle Firefox 89 support which includes Mozilla's proton redesign by default. There's a release v88.0 you can use which should still work fine for pre-proton, or you can enable the proton redesign in Firefox 88 and keep using the latest master commits.

That worked. Also great to know work is already being put for the upcoming proton designs. Thank you for your work. Proton is way forward and makes Firefox better. But in a lot of ways still lags behind chrome, like even font treatment in the UI is horrible to say the least

This is fixed for the new firefox too!

authors: muckSponge neerajklite sheeepdev

repo: muckSponge/MaterialFox


text:
feat: tortoiseTTS

Is your feature request related to a problem? Please describe.
We support rhaspy, bark and now vall-e-x (#1007). Another popular project is https://github.com/neonbjb/tortoise-tts
Describe the solution you'd like
A backend for tortoise tts
Describe alternatives you've considered

Additional context
Having support for tortoiseTTS too would help not only for users already using it, but allows also LocalAI to be a good benchmarking platform for all the solutions out there.

Also relevant: https://twitter.com/reach_vb/status/1702369875820212608?t=C96cnC9AF5O59bHJ-kIdyw&s=19
Looks like coqui brings tortoiseTTS on par with vall-e-x voice cloning capabilities. Maybe worth putting effort directly into that one.

The recently released XTTS-v2 is even more exciting.

I have started work on tortoise.cpp, which might be of interest https://github.com/balisujohn/tortoise.cpp

https://github.com/mudler/LocalAI/pull/1489

authors: balisujohn djmaze mudler

repo: mudler/LocalAI


text:
Wrong editor time displayed in all time summary

Describe the bug
The editor time displayed on the main page of the summary (in my case for Android Studio) is oddly low. If you click on a project that mainly used this editor, the time is higher than on the main page. This is strange as it should contain all the data from the subprojects.
System information

Wakapi version 2.10.4
Operating system

If Linux: which distro? Ubuntu 22.04.3 LTS
If Docker: which image and tag? ghcr.io/muety/wakapi:2.10.4

Database Postgres

Global Editor chart (All Time):

Editor Chart of a project (All Time)

Can you please try to go to Settings -> Danger Zone, then Regenerate summaries and see if that helps?

I've tried that (and waited for about 20 Minutes). Now the charts are a complete mess. AndroidStudio has even less time and "idea" which I use far more often is basically not visible. My languages chart doesn't really look correct either.

Do you see any error or warning messages in the server's console? Also, are the stats more accurate if you add &recompute=true as a URL parameter on the summaries page?

I can't spot any errors in the log. There are multiple weird lines like:
[wakapi]   | 2024-01-30T20:34:33.141703737Z [INFO ] starting with postgres database
[wakapi]   | 2024-01-30T20:34:33.150874894Z [INFO ] potentially running migration '20201103-rename_language_mappings_table'
[wakapi]   | 2024-01-30T20:34:33.155044674Z [INFO ] potentially running migration '20201106-migration_cascade_constraints'
[wakapi]   | 2024-01-30T20:34:33.156473067Z [INFO ] no need to migrate '20201106-migration_cascade_constraints'
[wakapi]   | 2024-01-30T20:34:33.156479067Z [INFO ] potentially running migration '20210202-fix_cascade_for_alias_user_constraint'
[...]

And it goes on like that for ~40 lines. I don't know if this is the expected behaviour.
And this warning is logged:
2024-01-30T20:34:33.141680437Z [WARN ] failed to parse reverse proxy ip
&recompute=true makes the charts much more accurate. Thy seem fine now. But if I remove this argument the old charts are still being displayed.

Those log messages are fine. Something seems to be wrong with your summary calculation. Small discrepancies of a few minutes are common, but hours is too much. Would you be open to send me a dump of your database (with all sensitive information like passwords, etc. removed) as a private message? I'm aware that's a lot to ask for, but would probably be the easiest way to debug this.

In general, I would be willing to send a dump. However, since my instance has multiple users, I would need to limit the data to my user account and I would also like to anonymize the data a bit.
How would it be possible to get in touch with you? Do you have a Discord server?

Yes, you can remove all users and their data from the dump. Best contact me via e-mail (see my GH profile).

What data exactly do you need from the various tables? Which tables can I delete and which do I need to anonymize?

This also happens in my instance. And I can confirm 2.10.2 is fine and 2.10.3 is buggy.

git bisect shows that the first bad commit is 791f5cc5f72b99cda1318b6e2c9fc132954fb988

@ddadaal Any immediate ideas about that?

I can confirm this problem also exists in my MSSQL instance. Editor, Languages, OS and machine time are wrong, but the sum of numbers of all of these 4 items are identical, and the Projects and Labels seem to have correct numbers. It seems the same set of data is missing when these 4 items are calculated.
I checked my DB and found out all of the existing SummaryItem has type 0, which means SummaryProject in the code https://github.com/muety/wakapi/blob/master/models/duration.go#L72. On the other hand, it means the SummaryItems of all other types are missing in the db.
This commit https://github.com/muety/wakapi/commit/791f5cc5f72b99cda1318b6e2c9fc132954fb988 removes foreign constraints and adds gorm:"-" tag in exactly these 4 columns, which was meant to prevent gorm from creating extraneous foreign keys. The one constraint in Projects is not changed, and so the Project result is correct.
I assume it is because the SummaryItem of other types are not persisted in the db because it is explicitly ignored by gorm:"-" tag.  It also explains why recompute helps because when the recompute exists, all data are calculated live, not from db.
A quick fix would be to manually persist the other SummaryItem when persisting Summary. I've submitted a PR for it #603. I am pretty occupied recently and have not tested the fix yet, so please let me know if anyone has tested it.

I should have spotted that bug in the review of #592 :neutral_face:. Thanks a lot for reacting so quickly, @ddadaal! :raised_hands: Tested your hotfix locally and seems to be working fine. Will merge the PR, deploy it and let it run for a short while.

No! It's not fixed yet! It doesn't persist entities correctly. The result is correct because no summary or summaryitem is persisted and the data are always calculated live. I have a working fix that does persist data and and I will push it later.

Realized that just now. I'm getting errors like:
[ERROR] failed to save summary (n1try, 2024-02-01 00:00:00 +0100 CET, 2024-02-02 00:00:00 +0100 CET) - unsupported data type: [0xc001b80120]: Table not set, please set it like: db.Model(&user) or db.Table("users")

Will wait for your fix. Thanks a lot again!

The release note should remind users to clear and regenerate summaries.

yay it works again 🎉

authors: bestlinuxgamers ddadaal muety ouuan tippfehlr

repo: muety/wakapi


text:
Other links

Hey thanks for the project, looks very nice. There are other possibilities that are internal but would not be matched with the current Regex, like those:

I would suggest going the other route and instead checking if it's not external since it's normally easier:
// External links regexp, they start by one of those: 'http://', 'https://', '//'
const external = /^(https?:\/\/|\/\/)/i;

export const isInternalLink = (link: string) => !external.test(link);

Here are the tests for this Regex: https://regex101.com/r/k71umu/1

Woah, awesome insight. Do you want to make a PR for this? If you do, make a Contributor section in README.md . And put your username there 👍

This is my work account (personal) but sure, I'll do juts that. I found the repo through literally googling for npm is internal link :smiley:
I had some ideas (as shown above), but wanted to see if I was missing anything so decided to search for 3rd parties solutions. Checking for // as well came from SO.
BTW, would you be happy with this syntax instead? I find it a bit cleaner but that'd be up to you since it's your repo after all:
import isInternalLink from 'is-internal-link';

(or both syntaxes for importing it to avoid having to bump a major version it just for that)

Sure sure, Let's export both.

Hey, new version publihsed.
And can now import like this
import isInternalLink from 'is-internal-link';

authors: franciscop-invast muhajirframe

repo: muhajirframe/is-internal-link


text:
Eslint giving error for duplicate props

This is not a bug request, but rather, it's a discussion on the reasons why you named 2 prop types of TextField almost the same with one being upper case.
According to TextField API,
TextField exposes two prop types  with almost same names. InputProps and inputProps.
Currently, my Eslint gives me an error for having duplicate prop type.
Is there any reason to name 2 prop types almost the same?
Can't we rename 1 of them to something more clarifying?
This also gives headaches with linting tools.
Expected Behavior
Eslint or any other linting tool doesn't give me any duplicate error.(react/jsx-no-duplicate-props).
Current Behavior
Eslint throwing duplicate prop error.
Plugin is located here.
##Temporal solution
Yes, you can set ignoreCase to false in .eslintrc but isn't it better to name our props in a more definitive way?
Thank you.
Your Environment

Tech
Version

Material-UI
1.0.0-beta30

React
^16.0.0

eslint
^4.8.0

I have found the following solution to the problem: much cleaner:
<TextField
- inputProps={{
-   foo: true
- }}
  InputProps={{
    bar: true,
+   inputProps: {
+     foo: true,
+   },
  }}

Checkbox has inputProps which in the documentation should behave like InputProps on TextField
Screenshot of Checkbox documentation:

Screenshot of TextField documentation:

I see it this way: InputProps on TextField should be inputProps and InputProps should be inputAttributes as the documentation describes anyways.

@oliviertassinari can we deprecate InputProps and make it inputAttributes or anything other than a duplicate prop??

@matthewjwhitney What about htmlInputProps? cc @mui-org/core-contributors

doesn't matter to me as long as it's not a duplicate...

I quite like this suggestion: https://github.com/mui-org/material-ui/issues/10064#issuecomment-373190215 (as did more people than 👍 the original issue. So, perhaps we drop the prop?

I quite like this suggestion: #10064 (comment) (as did more people than  the original issue. So, perhaps we drop the prop?

The code change looks pretty trivial. Although in my experience moving a prop to the inherited component means for most API readers it doesn't exist.

I quite like this suggestion: #10064 (comment)

@mbrookes This solution requires more effort to be found without landing on this issue. It's non-obvious. A developer needs to look at the Input properties API. It's why we have added inputProps properties to the TextField component. @eps1lon How would you approach the problem?

@eps1lon How would you approach the problem?

It's important to understand that the text field is a simple abstraction on top of the following components:

We can't do much beyond that. If people skip the very first paragraph then recovering from that is hard.
change this in the api docs:
const inputProps = {
  step: 300,
};

-return <TextField id="time" type="time" inputProps={inputProps} />;
+return <TextField id="time" type="time" InputProps={{ inputProps }} />;

Add a link to the Input API for the InputProps entry. We do this for all the other components too and it doesn't seem to be an issue for those component props.
Aside:
We could add a functionality to the props table that would expand the immediate props to all available props via prop forwarding. TypeScript users already get this for free via IntelliSense (although without prop description (yet)). Would be nice to see everything in one window instead of opening 2 or 3 tabs to see every possible prop.

authors: bobslaede eps1lon matthewjwhitney mbrookes mehi-shokri oliviertassinari

repo: mui-org/material-ui


text:
[docs] Document the color helpers

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

Expected Behavior
I've done a comparison of various JS color utility libraries. I found that @material-ui/core/es/styles/colorManipulator.js offers the smallest bundle size of all options I could find. Here's a comparison to other libraries (all numbers are minified; second number is minified + gzipped):

colorManipulator.js // 3.02kb, 1.25 gzipped
kewler // 7.24kb, 2.7kb gzipped
spectra // 10.5kb, 3.38kb gzipped
tinycolor2 // 15.2kb, 5.28kb gzipped
color // 23.1kb, 7.83kb gzipped
chroma-js // 39.8, 15.9kb gzipped

Current Behavior
@oliviertassinari has stated that the color manipulator is a private API. He also openly asked if there were better open-source alternatives to the private implementation. In my view, there is no better alternative. colorManipulator.js offers basically identical functionality to all of the other libraries, and does it in the fewest amount of bytes.
Context
Color Manipulation is a very generic problem, this library has the best solution, but it is a private API. I think it could be easily publishable as a separate entity within the mono-repo structure. It's already fully unit tested, so there could be no disagreement that it would be in a good state to make publicly accessible.

We could move it to @material-ui/docs. I'd be reluctant to move it to @material-ui/lab, as there is no color-picker in the spec.

At work, we are often using these helpers by tapping into the private API. Keeping the module within a reasonable size is critical for Material-UI. In the long run, I think that moving the styles folder into a @material-ui/styles package can make sense (if we need different release lifecycle/dependencies).
Should we close the issue as a duplicate of #10789? Also, I have seen some people (few) using the docs search to find some info without success.
@mbrookes What about keeping it where it is now?

I would prefer to be able to use the color manipulator functions without having to download the entire core library. I think it would be sensible to create a @material-ui/styles package.

without having to download the entire core library.

We are working on improving that. But I can understand the motivation: https://packagephobia.now.sh/result?p=%40material-ui%2Fcore.

@oliviertassinari Besides what we've discussed here already (e.g., moving the styles directory into a separate module), is there anything else you'd like to see in a PR that could close this issue and #10789?

colorManipulator.js offers basically identical functionality to all of the other libraries, and does it in the fewest amount of bytes

Not strictly true - all offer varying degrees of additional functionality; somewhat proportional to their size. The exception is colorManipulator's emphasize, however this is the application of lighten and darken according the result getLuminance, so could be achieved with most libraries.
colorManipulator provides the minimal subset needed for Material-UI. Still, if that's good enough for others, we should still make it a public API, as this (and other) issues suggest.
I thought it would be helpful to benchmark the function (or method) names that are used for equivalents to colorManipulator's functions, particularly for fade, which I have always found awkwardly named (fade can make a color less faded!).
Note that some of these functions take a relative value, e.g. lighten(color, 0.5) -> color 50% lighter than it was. While others are absolute: fade(color, 0.5) -> color with alpha set to 50%.

Library
Lighten
Darken
Darken light / lighten dark
Opacity
Get luminance
Get contrast ratio

Material-UI
lighten
darken
emphasize
fade
getLuminance
getContrastRatio

Kewler
lightness (+%)
lightness (-%)
N/A
N/A
N/A
N/A

Spectra
lighten
darken
N/A
fadeIn fadeOut
luma
N/A

tinycolor2
lighten
darken
N/A
setAlpha
getLuminance
readability

color
lighten
darken
N/A
fade opaquer
luminosity
contrast

chroma
brighten
darken
N/A
alpha
luminance
contrast

My preference for fade is to follow tinycolor2's setAlpha, as it is descriptive, and mirrors the get' of getLuminanceandgetContrastRatio`.
I don't have a strong preference for an alternative name emphasize, however I don't think that the current name is accurate or descriptive. Suggestions welcome!

I would add polished to the list of libraries to benchmark against. I agree, setAlpha > fade. What do you think of rgba as a name suggestion?

polished added. Interesting that two other the libraries use fade in the function name, and that polished uses "fade" in the description fo rgba, so maybe it isn't currently so far off after all.
The only issue with rgba() is the potential for confusion with CSS rgba(), which has a different syntax.

I would add CSS, Post CSS, SASS and Less in the benchmark list. We handle the same problem https://alligator.io/css/color-function/.

Huh, interesting. So maybe alpha() then? Not as explicit as setAlpha(), but since it follows the future CSS naming...

👍 for alpha().

For "Darken light / lighten dark": contrast > emphasize, imo.

Darken light / lighten dark": contrast > emphasize, imo.

Sort of, but only if you were to apply a sufficiently large coefficient. The typical use case is to slightly lighten a dark color, or slightly darken a light color, rather than to create a contrasting color.

I was curious about the polished bundle size cost for us to use it. I couldn't get tree-shaking to work. With ES5 modules, the bundle size cost is +3 kB gzipped.

Going back to the original problem stated :) Now that these helpers are part of the @material-ui/system, we can go ahead and add a new page in the docs under System to document them.

for lazy ppl like me who end up at this page:
https://mui.com/system/basics/

authors: jorepstein mbrookes mnajdova oliviertassinari petermikitsh


text:
optimal-imports codemod not working with typescript

[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'm trying to run codemod on my typescript project. Tried to execute in bulk, no success:
#!/usr/bin/env bash

find src \( -name '*.ts' -o -name '*.tsx' \) -print | xargs jscodeshift --verbose=2 --parser=tsx --extensions=ts,tsx -t node_modules/@material-ui/codemod/lib/v4.0.0/optimal-imports.js

Then I tried to apply it to a single file, like this:
jscodeshift --verbose=2 \
            --dry-run \
            --parser=tsx \
            --extensions=ts,tsx \
             -t node_modules/@material-ui/codemod/lib/v4.0.0/optimal-imports.js \
              src/components/NotFound.tsx

Here are the file imports:
import { Typography } from '@material-ui/core';
import Box from '@material-ui/core/Box';
import React from 'react';

Codemod does not affect this file:
Processing 1 files...
Spawning 1 workers...
Sending 1 files to free worker...
 NOC src/components/NotFound.tsx
All done.
Results:
0 errors
1 unmodified
0 skipped
0 ok

Expected Behavior 🤔
I expect codemod to affect the file and transform the first import into
import Typography from '@material-ui/core/Typography';

Steps to Reproduce 🕹

Steps:
see above
Context 🔦

Your Environment 🌎

Tech
Version

Material-UI
v4.3.1

React
16.9.0-alpha.0

Browser

TypeScript
3.5.3

@material-ui/codemod
4.3.0

@doomsower The plugin won't perform the following diff:
-import { Typography } from '@material-ui/core';
+import Typography from '@material-ui/core/Typography';

It's meant to do:
-import Typography from '@material-ui/core/Typography/Typography';
+import Typography from '@material-ui/core/Typography';

@oliviertassinari @doomsower
I am working in a project that has this problem, the only way to solve this would be to do it manually?, is there a solution that can be applied in a massive way?
Current
import { Fade, IconButton, makeStyles, Modal, Paper, Grid } from '@material-ui/core'
Expected
import Fade from '@material-ui/core/Fade import Paper from '@material-ui/core/Paper
...

@11ume Same feedback: https://github.com/mui-org/material-ui/issues/16879#issuecomment-518008595. We have no codemod to do this transformation. You can keep the current imports, it's often good enough for performance in dev mode (no impact in prod).
If you are interested in contributing this codemod, it could be interesting.

authors: 11ume doomsower oliviertassinari


text:
Crossword Solver - Gold Sponsor Logo

Hi there! Crossword Solver is one of your Gold Sponsors.
Our logo is included on this page: https://opencollective.com/material-ui/contribute/gold-sponsors-2860 but can we get it added to the following pages?
https://material-ui.com/
https://material-ui.com/discover-more/backers/
Can we also please get the company name added under our logo on this page: http://taobao.mirrors.alibaba.ir/package/@clearcapital/material-ui-core
Thank you!!

This page as well :) Let me know, thank you for your help! https://opencollective.com/material-ui#section-contributors

@emraeshine3 Yeap, it's planed in the next batch of update, thanks for the reminding and the support :)

Awesome, thank you!


text:
[Container] props type missing in Theme

In createMuiTheme, the MuiContainer props is missing...
How to override default props of this component?

Version: @material-ui/core: 4.7.1

Docs: https://material-ui.com/api/container/#css
Theme config:

TSLint error:
Argument of type '{ palette: { primary: Color; secondary: Color; grey: Color; }; typography: { fontFamily: string; }; props: { MuiTextField: { variant: "outlined"; fullWidth: true; }; MuiButton: { variant: "contained"; color: "primary"; }; MuiLinearProgress: { ...; }; MuiTabs: { ...; }; MuiDialog: { ...; }; MuiContainer: { ...; }; }; }' is not assignable to parameter of type 'ThemeOptions'.
  Types of property 'props' are incompatible.
    Type '{ MuiTextField: { variant: "outlined"; fullWidth: true; }; MuiButton: { variant: "contained"; color: "primary"; }; MuiLinearProgress: { variant: "indeterminate"; color: "secondary"; }; MuiTabs: { ...; }; MuiDialog: { ...; }; MuiContainer: { ...; }; }' is not assignable to type 'ComponentsProps'.
      Object literal may only specify known properties, and 'MuiContainer' does not exist in type 'ComponentsProps'.ts(2345)

Thank you for reporting this issue. We're indeed missing an entry in https://github.com/mui-org/material-ui/blob/78a04243216dbb09b795d83e25fa4b35a6e2a08f/packages/material-ui/src/styles/props.d.ts#L124-L125

@max10rogerio Do you want to contribute the fix? :). It should be about adding the missing key.

@oliviertassinari Yes!


text:
Inconsistent or duplicit CSS styles in

I'm using the React-Admin library which internally uses Material UI and after upgrading to the new React-Admin (and bumping @material-ui/core) version I'm encountering a problem with inconsistently ordered CSS imports in <head>.

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

Current Behavior 😯

CSS classes are inserted into head in inconsistent order or even duplicated. Starts with MUI styles, then React Admin's styles, then MUI styles again (some new, some duplicated), then makeStyles. This leads usually to shadowing of CSS styles (e.g. overriding RaMenuItemLink component inserts the rule in head, but then MuiButtonBase is inserted in head again, overwriting text color)
I also think it's happening for components that are rendered conditionally, that "once they're needed", their styles can get re-inserted again.
Expected Behavior 🤔
Consistent order of CSS imports that allows me to use the React Admin's components, Material UI components and possibly overrides in theme too - maybe MUI > RA > makeStyles

Steps to Reproduce 🕹
Unfortunately I have no idea where this issue stems from and I haven't been able to reproduce the issue from React Admin's codesandbox, which admittedly doesn't help my chances to solve this issue.

Context 🔦
I asked the same question on React Admin's repository, which pointed me here, as they seem to only be using <ThemeProvider> in the core Layout component. I also further described the issue in this Stackoverflow question. It might be also some unexpected interactions with Next.js I'm using, but I have no idea where to even look.
The issues it causes is quite global, and while I think I can patch it with a lot of makeStyles  somewhat closer to the components, I don't think it solves the core problem.

Your Environment 🌎

`npx @material-ui/envinfo`
System:
    OS: Windows 10 10.0.19041
  Binaries:
    Node: 14.5.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 90.0.4430.93
    Edge: Spartan (44.19041.906.0), Chromium (90.0.818.51)
  npmPackages:
    @emotion/styled:  10.0.27
    @material-ui/core: ^4.11.1 => 4.11.4
    @material-ui/icons: ^4.9.1 => 4.9.1
    @material-ui/lab: ^4.0.0-alpha.57 => 4.0.0-alpha.57
    @material-ui/styles:  4.11.4
    @material-ui/system:  4.11.3
    @material-ui/types:  5.1.0
    @material-ui/utils:  4.11.2
    @types/react: ^16.9.38 => 16.9.56
    react: ^16.12.0 => 16.14.0
    react-dom: ^16.12.0 => 16.14.0
    typescript: ^4.1.3 => 4.1.3

Without a reproduction, nobody from the community will be able to really help. However, this is a common issue we have seen. You should be able to find duplicates in the repository or even on StackOverflow. The first thing you need to verify is that @material-ui/styles is not duplicated in your bundle. It's a singleton, it needs a single version.

https://material-ui.com/getting-started/faq/#i-have-several-instances-of-styles-on-the-page

Leaving this here in case anyone comes with similar issue - before trying anything else, try deleting node_modules folder and reinstall packages from scratch. For me, something went wrong during the process of updating the versions and all issues fixed themselves after reinstalling.

authors: oliviertassinari sMteX


text:
inconsistent Button-placement for multiple children

When adding multiple children to the button the placement is dependent of the order of the children.

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

Expected Behavior

Same placement, independent from the order.
Current Behavior

Placement differs slightly. There is a problem with the inheriting display of the label. We could not inherit the display-prop (behavior like the html5-button-component).
Steps to Reproduce (for bugs)
https://codesandbox.io/s/y0vv1243w9
Context

I stumbled over that when working with custom icons implemented like the examples. (used Fontawesome5-icons, like in this sandbox).
Your Environment

Tech
Version

Material-UI
1.0.0-beta.25

React
16.2.0

browser
chrome 63.0.3239.108

Seems this is caused by the default ButtonBase.js style from this line:
https://github.com/mui-org/material-ui/blob/cccf34cd72ac8f63d43476dd8d837134dc8fc0e4/src/ButtonBase/ButtonBase.js#L13
Though I'm not sure this is something we should update here, as we can always override the default styling if needed, see this example: https://codesandbox.io/s/pwnm1n11p0 (where class button's display property is set to inline-block in this case).

authors: Chopinsky PutziSan


text:
[docs] Add closing tag in the Popover snippet

the copied code doesn't work because missing the closing tag.

Closes #13025

@liesislukas Nice!

authors: liesislukas oliviertassinari


text:
[docs] Fix docs build regression

Try to solve https://github.com/mui-org/material-ui/pull/14911#issuecomment-473691146.

Something is very wrong with the build of the documentation after this change. It takes 11 minutes instead of 2 minutes.

I had to restart deploys that were timing out before the upgrade. I noticed very slow deploys a couple of times. Might just be netlify. Did you verify the slow build in a fresh clone?

@eps1lon The output difference:
next@8.0.3

10:58:39 AM: $ rimraf .next && cross-env NODE_ENV=production BABEL_ENV=docs-production next build
10:58:40 AM: Creating an optimized production build ...
10:58:42 AM: > Using external babel configuration
10:58:42 AM: > Location: "/opt/build/repo/babel.config.js"
11:11:47 AM: Compiled successfully.

next@8.0.0

7:23:05 PM: $ rimraf .next && cross-env NODE_ENV=production BABEL_ENV=docs-production next build
7:23:06 PM: webpackbar 18:23:06 ℹ Compiling Client
7:23:06 PM: webpackbar 18:23:06 ℹ Compiling Server
7:23:07 PM: > Using external babel configuration
7:23:07 PM: > Location: "/opt/build/repo/babel.config.js"
7:25:13 PM: webpackbar 18:25:13 ✔ Client: Compiled successfully in 2.12m
7:25:19 PM: webpackbar 18:25:19 ✔ Server: Compiled successfully in 2.21m

I'm believe it's Next.js related. a +10min build diff is pretty extream for Netlify infrastructure flakiness.

next@8.0.2 is KO.

canary solves the problem.

@oliviertassinari This has something to do with minification. Adding this to next.config.js also speeds up the build when using 8.0.3:
module.exports = {
  webpack: config => {
    config.optimization.minimize = false;

    // ... everything else

Related GitHub issue: https://github.com/zeit/next.js/issues/6316

@ellisio Thank you for the follow-up :)

authors: ellisio eps1lon oliviertassinari


text:
[docs] Fix typo, extra 'you'

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

@jedsmit It's a great first pull request on Material-UI 👌🏻. Thank you for working on it!

authors: jedsmit oliviertassinari


text:
The gitter link on README points to a 404

Due to the recent repo change name, the Gitter link on the README now points towards a 404.
So either keep the old name for the gitter OR change it and then this PR is useless :)
(but in the meantime it fixes the 404).

Ok, I went too fast :running_man:
I close this PR in favor of #9284 (which includes this fix and wayyyy more :+1: )


text:
[TextField] Improve the API documentation

Address api issue of #9326

@rosskevin Sorry, I should have done a new commit for reviewing, it was too late before I realized it.

no problem

authors: oliviertassinari rosskevin


text:
Turn deprecation warnings into logs

Deprecation warnings in the latest 3.x versions make my app look like it's broken, while it works perfectly. I know that these warnings only appear in development, however they bring a lot of noise and potentially hide real errors.
Is it possible to turn these warnings into console.log() messages instead of console.error()?

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

Expected Behavior 🤔
Use code from 3.0 with the latest 3.x without error (because of semver)
Current Behavior 😯
Using an old Typography variant (like <Typography variant="title" />), or a <TableCell numeric />, or a raised Button raises error in the console:

Context 🔦
I'm migrating react-admin from material-ui v1 to material-ui v3 (cf https://github.com/marmelab/react-admin/pull/3102). And I can't find a syntax that works for both versions :(

@fzaninotto This is a prop-type warning. I would encourage you to move the discussion to prop-types: https://github.com/facebook/prop-types/blob/e32c4900f5ab5fd3acea93e9d2f0d09e4a2f2ceb/checkPropTypes.js#L20.

There is no syntax that works with both versions. The simplest is probably to jump from v1 to v4.

By the way, if you want to comment on https://spectrum.chat/material-ui/general/what-do-you-guys-think-about-the-tables-and-how-they-are-handled-in-material-ui~27c0b5be-9cea-4e8f-88bc-faaf4103bf33. It would be appreciated.

Allow me me disagree.
If I made a mistake with a proptype, I find it normal that the console shows an error - it's my mistake.
If I wrote code with material ui v3 and it works without error, I find it normal that the console shows no error when I upgrade to a minor release.
The current behavior is really misleading: the console shows error while the code works perfectly and will continue to work fine in all 3.0 releases. That's a break of the semver semantics.

This is a prop-type warning. We try to follow the convention.

There is no standard for deprecation warnings that I know of. You chose to use PropTypes for these, but it's an implementation detail.

The simplest is probably to jump from v1 to v4.

No, because V1 and V3 are almost compatible (except for Firefox), while you're still busy adding instructions to the V4 upgrade guide.

There is no standard for deprecation warnings that I know of. You chose to use PropTypes for these, but it's an implementation detail.

@fzaninotto We hope we can use React.warn in v5 for this problem. React will introduce a new method that shows the stack trace when warning: https://github.com/facebook/react/pull/15170.

Maybe you can upgrade to a v3 version that doesn't has the deprecation warnings?

Is it possible to turn these warnings into console.log() messages instead of console.error()?

We might want to use console.warn. console.log is too weak.

The most important constraint we have considered when adding the deprecation warning was to show the component stack trace. The only option we had was the prop-types warning, that happens to use console.error. I think that console.warn would be better here. (We were using the same strategy in v0.x).

Maybe you can upgrade to a v3 version that doesn't have the deprecation warnings?

That's a good idea, but:

Which version is it?
It's not me who is going to upgrade to v3, it's the react-admin user base. I find it hard to explain them that react-admin supports v3.a but not v3.b because there are some breaking changes, while you say that you support semver...

I understand that you're deeply involved in v4 and that v3 might not be a priority for you, but I insist that this is a BC break.
Would it help if I submitted a PR to master?

@fzaninotto What about upgrading to v3, accepting v1 in the dependency range but fixing the deprecating warnings?

How can I fix the deprecations warnings? The code would stop working on V1.

I don't see the problem with react-admin introducing deprecation warnings to the users in a minor version bump.

I agree if these are warnings. But your deprecation warnings are actually console errors.

Correct. This stratategy can't work. It's not backward compatible. What you want is an option to disable the deprecation warnings. console.log would probably still be too noisy.

I don't mind a console.log.

And your users?

Is this a public API? Maybe we could feature detect the API?

Is this a public API? Maybe we could feature detect the API?

I don't understand your question. I gave an example code that triggers the error in the description: <TableCell numeric />. This is called by react-admin's <NumberField />, which is public API.

console.log for deprecation wrnings isn't a problem because:

it only appears in development
it doesn't make CI builds fail

Also you and I actually need a communication channel to warn about deprecations. react-admin uses console.warn() for that.

Import * from @material-ui/core/utils/reactHelpers.
See if setRef is defined.
defined => v3. not defined => v1

It's not perfect, setRef was introduced in v3.1.1.

react-admin uses console.warn() for that.

So why should Material-UI use console.log?

Oh, console.warn() is fine, too ;)

It's not perfect, it's a rough approximation. setRef was introduced in v3.1.1, the deprecation latter on.

I appreciate that you try to find a solution for react-admin, but again, I think this is a bug in material-ui. A minor version should not cause errors on code created for a lower version.

A minor version should not cause errors on code created for a lower minor version.

These are not actual errors. These are warnings that are logged via console.error.
We want to move things like deprecation warnings to use React.warn. Right now we don't have another choice than using warning and propTypes.

These are not actual errors. These are warnings that are logged via console.error.

For my CI, it makes no difference. I haven't released a react-admin version that supports material-ui v3, but I'm ready to bet that for the react-admin users, it won't make any difference, either.

Right now we don't have another choice than using warning and propTypes.

I don't understand why. If react-admin uses console.warn(), why can't you do it, too?
But it seems we don't agree so I won't bother you guys anymore. I'm just sorry you don't follow semver more carefully.

I'll just add one remark: the deprecation warnings are not all equal regarding noise. See this extract of my console:

If you insist on logging errors for deprecations, could you at least do it in the less-cumbersome way (first example) instead of the super noisy one (second example)?

It was designed on purpose to have the component stack trace, hence it's verbose.

If react-admin uses console.warn(), why can't you do it, too?

But it seems we don't agree so I won't bother you guys anymore. I'm just sorry you don't follow semver more carefully.

We can disagree but lets not make this conversation accusatory. If you want to fail on console.error then this is your choice. A react app won't crash by default if a console.error is logged. Hence adding those warnings is not a Semver breaking change. We only add deprecation warnings in minor releases which is exactly what SemVer defines.
Using console.warn won't help anybody because you will get the stack trace from react internals. They give you no clue where the warning originated.

If you insist on logging errors for deprecations, could you at least do it in the less-cumbersome way (first example) instead of the super noisy one (second example)?

The component stack isn't noise. It's information that helps you locate the issue. This is common in react. I don't understand why you consider it noise all of the sudden.
I understand that these can be frustrating. In a perfect world (php did this right) deprecation warnings would have their own log level. Maybe we can re-evaluate the message format so that you easily hide deprecation warnings by looking for a Material-UI Deprecation Warning in the message and hide those.
Once React.warn is available we can provide component stacks via console.warn instead of relying on propTypes validation. But if this lands we need to include our caching solution for these messages and make sure we support earlier react versions.

I didn't want to sound accusatory, sorry if I did. So let me rephrase:

I'm just sorry you don't follow semver more carefully.

as

I'm just sorry you don't follow semver the same way as I do, which is to guarantee that a minor upgrade will not break existing code, including by raising new errors.

As for using console.error instead of console.warn because it has a stack trace, I understand that you're doing the opposite trade-off in material-ui as I did in react-admin: improve the upgrade path for future versions while making the upgrade path to the current version harder.
These differences in interpretation prevent me from publishing a minor version of react admin that raises new errors, so they prevent react-admin from using material-ui v3.

If you want to blame Material-UI for react admin using v1 instead of v3, why not, It's fine with me. As long as the migration to v4 can be smooth, I'm happy :).

I am very confused about those console errors and it's not clear to me how to get rid of them. They are very noisy, I can't easily see the console errors I actually need to care about. I can't influence the deprecation warnings myself, because they're caused by a 3rd-party library (react-admin).
Maybe consider hiding them behind a config flag next time, or do it like Vue and provide a specific migration build/package.

Why couldn't we use console.warns? They have existed in the browser for quite a while.

authors: eps1lon fzaninotto mediafreakch oliviertassinari pkelly-rh

repo: mui/material-ui


text:
Unstyled Circle appears at bottom when searching

Duplicates

[X] I have searched the existing issues

Related page
https://mui.com/
Kind of an issue
Other
Issue description
While searching and when my internet is slow, the page scrolls me down to part as shown in the page:-

Context 🔦
What brought me to this page? Search

I have experienced this issue, from time to time. I agree that something is off with the way the style are loaded. Related to #16502.

authors: mynameisankit oliviertassinari


text:
[Button] Disabled Button still calling onClick

I'm seeing behavior in the next/Button widget where disabled buttons are still calling onClick. The buttons appear visually disabled. Occurs in the simplest case:
<Button onClick={() => console.log('just got clicked')} disabled>Click Me</Button>

Thanks for the report. I'm on it 👍 .

onTouchTap still invoke when disabled
<Button
  raised
  disabled={!this.state.email}
  color='primary'
  className={classes.button}
  onTouchTap={this.getCode}
>
  Get Verification Code
</Button>

@ng-hai onTouchTap is no longer supported.

Is it OK if I remove react-tap-event-plugin when using v1-alpha version?

@ng-hai Yes, you should.

What is the alternative of onClick and onTouchTap?
Because typescript throw error "'IntrinsicAttributes & ButtonProps & { children?: ReactNode; }'."

@oliviertassinari Is there a handler still fired even when the button is disabled? I want to add handling to highlight missing fields on a form.

Maybe this can help someone:
I thought I have the same issue (the onClick was fired even the button was disabled), but then I discovered that the parent row of that button had the same onClick handler :)

I am also facing same issue

authors: Hobbit44 aftab-onefc agustin107 jcheroske ng-hai oliviertassinari sergii-zhuravel


text:
[TextField] Duplicated MuiTextarea element

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

Expected Behavior

I think there should be only 1 MuiTextarea element
Current Behavior

There are 2 MuiTextarea elements
Steps to Reproduce (for bugs)

Add TextField to your application
View the rendered TextField in the DevTools

https://codesandbox.io/s/lxl8145nl7

Context

It doesn't affect me at all - but I just wanted to show you this because it doesn't look like it's intended and I don't have time right now to dig into Material-UI for pull request
Your Environment

Tech
Version

Material-UI
1.0.0-beta.13

React
15.6.1 & 16.0.0

browser
Version 61.0.3163.100 (Official Build) (64-bit)

etc
Windows 10

Both textarea are here for a purpose. The first one provides us the line-height and the second one the overall height. They are crucial for implementing the auto grow and max rows feature.
https://github.com/callemall/material-ui/blob/e6d8d7ab5b3eb2a9553d54bfd7ff67230a8b6f1b/src/Input/Textarea.js#L213-L231

I'm having this same issue. If it's crucial is to have it should not being shown.

@matheuseabra what's your issue?

Textarea is being rendered twice. If the two are essential, one of the should be hidden but as the screenshots shows it's rendering both textareas

It should be hidden. How do you reproduce the issue?

@oliviertassinari Honestly I just trying to render a basic textarea... don't know why this is hapenning

@matheuseabra I would love to know why it's happening :).

@oliviertassinari I'm also experiencing the same issue of duplicate rendering of mui textfields, are there any fix?

authors: DominikSerafin matheuseabra nateriver322 oliviertassinari


text:
[wip][poc] Add Pigment CSS screenshot test

This PR sets up CI steps for testing screenshots test using Pigment CSS. It uses the pigment-css-vite-app that is already set up in the project for testing Material UI with Pigment CSS.
The fixtures are located in src/pages/fixtures directory. Any component added there will be automatically added as a screenshot (e.g. check the apps/pigment-css-vite-app/src/pages/fixtures/PigmentCSSDifferentChildren.js file).
The logic is very similar to how the other regressions tests are set up.
For demos screenshots, in the end I decided to use the components we have under the /material-ui routes. There were some issues with importing components from the docs, I kept getting the error ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL when using https://vitejs.dev/guide/features.html#glob-import
TODO:

[ ] Remove the dummy fixtures after the review, they are there just to show-case that we can also add additional files.

Changes look good to me. There are some small issues in the images (like first character of placeholder showing for Select) but we'll have to verify that locally first.

There are some small issues in the images (like first character of placeholder showing for Select) but we'll have to verify that locally first.

It's the same locally, it's likely some bug/issue we need to look into. At least the screenshot test caught it ;)

I dint see anything missing. LGTM

@mnajdova may I ask you to add a fixture for the Select component? I don't see it in the added screenshots.

@mnajdova may I ask you to add a fixture for the Select component? I don't see it in the added screenshots.

Added the default demos and also one screenshot with an open select.

Added the default demos and also one screenshot with an open select.

Thanks!

authors: DiegoAndai brijeshb42 mnajdova


text:
Validate the name when creating code components

Proposing this as a solution for this dialog:

Closes https://github.com/mui/mui-toolpad/issues/790

looks like a good solution to me!

authors: Janpot apedroferreira

repo: mui/mui-toolpad


text:
Set cookie domain

Starting in 7.43.0 any-domain cookies will not be exported
cf https://curl.se/libcurl/c/cookie_interface.html
@ziyan (although I tested locally) could you confirm master does not work on debian bullseye?

@ziyan sorry it turned out that this patch breaks stretch environment.

stretch=7.52 buster=7.64 bullseye=7.74

according to https://github.com/curl/curl/issues/6723 and https://github.com/curl/curl/commit/b8d5036ec9b702d6392c97a6fc2e141d6c7cce1f, 7.60 had incompatible change. We need version-conditional :sob:

should be fixed now

repo: mujin/controllerclientcpp

license_source: bigquery


text:
fix: fitactivity combine should accumulate all the accumulable values

Previously, we only accumulate Record's distance, but in reality, messages may have fields requires accumulation as well, such as Record's accumulated_power. We should dynamically find and accumulates those values.

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

Project coverage is 100.00%. Comparing base (f83b3c9) to head (acfe055).

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #453   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           42        42
  Lines         3659      3659
=========================================
  Hits          3659      3659

: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:
Timing the Stimulation Code

I'm trying to send continuous stimulations on MEA 2100. For which I was running a timer to detect the execution time for each time it traverses through the code as shown below:
`
        watch.Start();
        cStgDevice.PrepareAndSendData(0, amplitude, duration, STG_DestinationEnumNet.channeldata_voltage);
        // connect all stimulation channels to the first trigger
        cStgDevice.SetupTrigger(0, new uint[] { 255 }, new uint[] { 255 }, new uint[] { 1 });

        // start the first trigger

        cStgDevice.SendStart(1);
        watch.Stop();`

My input duration are in the order of milli-seconds, hence I have to provide such N trains for my signal. But to my surprise the stopwatch returned that it is taking ~(10-15)milli-seconds to complete one such stimulation cycle. If this is the case it defeats the purpose of the signal. Am I calculating the timing from the wrong points or if not how should I go about this?

Hi, stopping the stimulator, sending the data, then restarting it is not ideal if you want to switch between stimulation patterns within milliseconds, because as you've seen it takes a bit of time to prepare the stimulation pattern in the McsUsbNet.dll and send it to the stimulator due to e.g. delays in the USB transfer. If you have timing-critical stimulation, there are several options to deal with this (see chapter 6.2s and 6.3 in the McsUsbNet documentation):

What kind of stimulation trains are you using? You can program quite complex patterns for the stimulator by using nested loops, so maybe it is an option for you to load one pattern on the stimulator that contains all trains. This would be the best option if you are simply repeating the same train with pauses in between, for example.
You can also divide the memory of the stimulator into multiple segments, load a waveform pattern into each segment and then only switch between memory segments when you want to start the next train. Switching between segments happens within milliseconds
You can assign different patterns to the available triggers (4, usually) and start them within microseconds
You could use the "Streaming Mode" of the stimulator, not the "Download Mode". However, this is much more complex to program, so we usually recommend using the Download Mode of the stimulator.

Please have a look at the documentation for the McsUsbNet where you will also find snippets with example code.

@armwal  Definitely, I'll look into those sections of the documentation. I'm attaching a sample Temporal Raster Plot  for your reference, please do let me know your thoughts. Here the y-axis represents the electrodes and the x-axis defines the timeline. How should we approach this.

If I understand your picture correctly, you want to achieve (at least) 5 stimulation trains running at the same time that switch basically independently from each other between on and off without any breaks in between? Sorry, but I don't see a good way to realize this with the builtin stimulator of the MEA2100 and exact timing. 3 stimulation trains would be doable by assigning each one to a different Stg. More stimulation trains could be achieved by having 1 Stg continuously active (assuming all stimulation trains have the same stimulation amplitudes) and only changing the active electrodes with the SetElectrodeEnable call by setting all electrodes to 1 that need to be active and the others to 0. You would need to call SetElectrodeEnable at every time point when any of the stimulation trains change from on to off. But because executing the SetElectrodeEnable call and communicating with the stimulator via USB takes a variable amount of time, you won't have precise timing of the stimulation anymore.
As I said, based on your plot of the stimulation pattern I don't see a way to achieve exactly this pattern. I've asked the developer of the stimulator API for his thoughts, maybe he has some more ideas.

@armwal: Any leads from the API developer?

It is as Armwal said in his last post: You can only specify 3 different stimulation pattern, that can run at the same time. However its is possible to switch the used electrodes during the stimulation from one selected pattern of electrodes to the next one. This feature is called list-mode.
For this there is the second argument listmodeIndex in the command SetEelectrodeEnable and SetElectrodeDacMux.
You need to define the sideband channel 1 as well and use bit 8 to indicate when the stimulation pattern should switch to the next electrode pattern. Listening to this bit of the sideband needs to be activated with the comand SetListmodeTriggerSource.
You need to define the range of different electrode pattern with the command SetListmodeIndexRange.
Finally the list-mode needs to be activated before you start the stimulation with ListModeSendStart.
For this kind of usage, it is recommended to run all three (or less) channels at the same time, because the electrode pattern change is one global change.
Segmented memory (which was mentioned in an earlier post) is not implemented for the MEA2100, but only on our standalone stimulators STG400x.

Can we replace the STG400x with a Master-9 to send 3 or more different stimulation patterns? or can we introduce a Di/o to bridge them like this.

As far as I am aware there is no (easy) way to connect an external stimulator to the MEA2100 in a way that the stimulus will be applied via the MEA channels and the blanking circuit of the MEA2100 works properly. However, it could be possible to apply the stimulation patterns from the external stimulator via external electrodes/wires to the bath in the MEA or by soldering the connection to the stimulator to the contact pads on the MEA, but I don't know how feasible this is in practice. Our technical support should hopefully be able to help you with this, so please write an email to support@multichannelsystems.com to discuss this further.

authors: JensMCS armwal satabios


text:
Add eslint and remove tslint

Closes #97
Add eslint configs and remove tslint configs. There may still be some remnants to clean out, but that will require some more investigation/help (@waxlamp)

Could you edit the description to explain what's different and/or better about using ESLint?

It's in the issue, but I'll quote it up top for ease of reviewing.

Also, you mentioned there are some remnants to clean up--what did you mean?

I didn't remove any of the plugins, and I was concerned that means that tslint is still in there as a dependency. I feel like that could be cleaned up a bit, but I'd need to explore what can be removed.

repo: multinet-app/view-adjmatrix


text:
version bump to 1.8.0

This resolves #8

@mumoshu Can you review and merge this? @james-woods did the valuable work!

LGTM. Thanks for your contribution @james-woods @yu-iskw 👍

authors: james-woods mumoshu yu-iskw

repo: mumoshu/kube-airflow


text:
Plex playback does not trigger webhooks

What version of Music Assistant has the issue?
2.1.0rc1
What version of the Home Assistant Integration have you got installed?
No response
Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

[X] Yes

The problem
When playing music using Plex, I see the play history get updated. However, Music Assistant does not create any webhook that can be used to trigger other services. For example, I am using webhooks in Plex to scrobble to Navidrome:

This works perfectly when playing music directly from Plex but does not work when playing music using Music Assistant. Music Assistant does not trigger any events in plex.
How to reproduce
We can check the logs
Music Providers
Plex
Player Providers
Sonos
Full log output
NA
Additional information
No response
What version of Home Assistant Core are your running
2024.7.2
What type of installation are you running?
Home Assistant Container
On what type of hardware are you running?
Alternative

Issues are for things that should work but don’t. Why do you think this should work. Has it ever worked? If not this is a feature request.

authors: OzGav arsaboo

repo: music-assistant/hass-music-assistant


text:
Correct error in attribute classes membership of incipText

From pd...@virginia.edu on September 26, 2011 17:05:18
Currently, inciptText is a member of att.link.external, an attribute class that no longer exists.  It should be a member of att.pointing instead.
Original issue: http://code.google.com/p/music-encoding/issues/detail?id=33

From pd...@virginia.edu on September 26, 2011 14:35:15
This issue was closed by revision r367 .
Status: Fixed

repo: music-encoding/music-encoding


text:
Irregular placement of accidentals on turns

Here is an example of a turn, where the lower-note accidental is placed above the turn:

For visual fidelity, this accidental must be placed in turn@accidupper, but for gestural fidelity it should be placed in turn@accidlower; otherwise, rendering of this turn (such as in a MIDI conversion) will be incorrect.
Extra attributes should be added to <turn> to allow this case.   I think I have seen this in printed editions as well: the most common note to alter would be the lower auxiliary note, converting it into a minor second leading tone.   In this case the scribe leaves it to the performer to figure that out.
Additional attributes to distinguish between visual and gestural accidental would be useful for other corner cases.  I propose adding @accidupper.ges and @accidlower.ges which would act in a similar manner to note@accid and note@accid.ges.
So the second turn in the above example would be encoded as:
<turn staff="1" accidupper="s" accidupper.ges="n" accidlower.ges="s" form="upper" />

Adding @accidupper.ges and @accidlower.ges would also localize the accidentals of the auxiliary notes which would simplify conversion to MIDI, since the accidental states of the auxiliary notes would not need to be inferred from the key signature and previous accidental states of notes in the measure.  This is a non-trivial process, similar to inferring note@accid.ges.
This is related to issue https://github.com/humdrum-tools/verovio-humdrum-viewer/issues/425.

Another approach would be to see this as a writing (or printing) error. We have actually very straightforward ways to encode cases like this (see "Apparent Errors" in the MEI Guidelines). The encoding would be much simpler and easier to understand and you would have all the possibilities of rendering alike.

If the scribe wrote the accidentals on the turns in an inconsistent manner, then I would call it a scribal error.  I have asked Jacek if there are other turns in the same music that have accidentals on them.
If there happens to be more turn accidentals notated in the same way, I would less like calling them errors rather than deviations from standard modern notation practice.  This could fit into sic/corr, but seems less suited since it would be intentional by the scribe rather than unintentional.  Or perhaps you were thinking of the <reg> method from the Regularization and Normalization section below the documentation for sic/corr, since that seems better for this sort of situation.
Here is the Apparent Errors section of the Guidelines.  You can add links to issues text using this Markdown construction:
[text for link](link)

Such as in this case:
 [Apparent Errors](https://music-encoding.org/guidelines/v4/content/scholarlyediting.html#edittransErrors)

Regardless, there will eventually be an issue related to the rendering of ornaments (trills, mordents, turns, etc), which verovio currently does not deal with.   So it would be wise to implement @accidupper.ges and similar for ornaments.   If there is no gestural information about the accidentals of auxiliary ornament notes, there will be similar difficulties as when converting <notes> into MIDI when @accid.ges is not encoded.  Note that your benefactor is obsessed with ornament realization, so you should either avoid doing it yourself, or get it right the first time...

Humdrum has a system analogous to <sic>/<corr> that could be used:
https://doc.verovio.humdrum.org/filter/sic
although I have not mapped it to the MEI system yet in the converter.  But for this particular case I created a parameter to switch the placement of the accidentals so that the lower accident would be displayed above the turn:

Yes, MIDI rendering is a more convincing reason for implementing accidupper.ges than individual scribal or regional conventions which however should be marked up as deviations from CMN

Here is the manuscript source:  http://bc.bdsandomierz.pl/dlibra/publication/1283/edition/1251/content
There are four cases of turns with accidentals, all of which have the same convention that the accidental which is shown above the turn is meant to be applied to the lower auxiliary note:

And the realization of each:

authors: craigsapp frakel


text:
updated kernel versions

Ran the kernel update script:
6.1.83-rt28 -> 6.1.90-rt30
6.6.23-rt28 -> 6.6.30-rt30
6.8.0-rt8 -> 6.8.2-rt11

Surprised that the script still works!
Thanks, much appreciated.

Yep, flawlessly!
Any time!

authors: bhechinger henrytill

repo: musnix/musnix


text:
If I only adaptation few-shot language, should I download the whole train dataset?

Thanks for your great work! As the title said, let's say I want to adapt on Greek language. is it ok for me to only download Greek language dataset, and then run the few-shot adaptation part? Looking forward to your reply.

Hi,
It is possible to only use the target language data, but other languages serve as a strong regularizer, so using only a small target dataset would lead to worse results or even training failure. If storage and computational resources are limited for using the full dataset for fine-tuning, I would suggest at least incorporate several major rich-resource languages.

authors: CindyTing mutiann

repo: mutiann/few-shot-transformer-tts


text:
[content] update information about Espressif RISC-V chips

Hi @asb 👋
Thanks a lot for mentioning Espressif chips and development boards in your blog post.
In this PR I have updated the entry about the ESP32-C6 and added the lower-cost ESP32-C2 (a.k.a. ESP8684).
I haven't yet added the ESP32-H2 yet, since the datasheet for the mass production version of the chip hasn't been published yet and the development boards are not yet available on Mouser. I'll try to remember to come back in a month or so and make another update.

Thank you so much for dropping by with these additions and clarifications - really appreciated!

authors: asb igrr

repo: muxup/muxup-site


text:
Animate fill in text

This PR is related to Issue #12

🍾 🎉 🌮

repo: mvdwg/telling-stories

license: mit


text:
[QT-Wallet] Logout failed with the error message.

OS Versions Tested: Windows
Build -https://ftp.mwc.mw/nightly_builds/05-26-2020/
Steps to reproduce:

Login into QT-Wallet
Goto Settings and change MQS Domain to  dev1.mwc.mw.
Click Logout button

Actual Result:
Logout is not happened and got the below error message.

From the work flow it can happen if wallet was recovered. I wasn't be able to reproduce for a normal usage. Fix cover wallet recovered case.
Will mark ticket as ready when start nightly.

Not able to reproduce the issue with the latest build, hence closing this ticket.

repo: mwcproject/mwc-qt-wallet


text:
Wallet configuration->Send mwc parameters

In Wallet Configuration, Send mwc parameters: What is Restore original supposed to do?
It’s only clickable once you start typing new parameters, and if you click it it takes you to the latest setting you just had, not to the original 20 confs 1 output.
That is, if you change it more than once, Restore original takes you back to the previous one, not to the original defaults
IMO it should take you back to original, since users may change it and then doubt wether thay may have made a mistake, so it’s best to go back to default.

Yes, currently it is a rollback to latest accepted settings.
Will hardcode the defaults ones.

Fixed

authors: MWCmax bayk


text:
workflows: update action deps and runners

update actions to latest
update to use latest LTS nodejs for the PR test
add macos-12.0 and windows-2022
remove deprecated runners, macos-10.15 and ubuntu-18.04

These are all non user-facing changes, so lgtm.

repo: mxschmitt/action-tmate


text:
Default example styling

Right now, the default example looks okay-ish, but it's not cross-browser tested at all and could be made nicer looking and working.

@mxstbr I could look into working on this this weekend if you don't mind me taking time from working on the website.

I think this is fine, I'd rather get the website and v3 finally out of the door. :+1:
Closing for now, but we'll definitely revisit this after the initial release!

Sounds good 🐐

authors: mxstbr webdesserts

repo: mxstbr/react-boilerplate


text:
fix can-be-merged - 111

[Auto generated]
Number: [#111]

github-gitlab-webhook-server: Closing issue for PR: fix can-be-merged.
PR was closed.

repo: myakove/github-gitlab-webhook-server


text:
Fix int8 training

be more compatible with low-end gpus

Thanks for this PR!
I'll merge it after test.

try --optim=adamw_bnb_8bit

authors: mymusise sandofree

repo: mymusise/ChatGLM-Tuning


text:
Consider deprecating ResultSet in favor of array(ResultRange)

The only real difference between ResultRange and ResultSet is that ResultRange is an input range, whereas ResultSet allocates space to store all the result rows, downloads them, and provides a random access range.
This suggests that ResultSet is completely redundant with phobos's array(Range) function, and is therefore an unnecessary duplication of ResultRange, violating DRY.
The functions which return ResultSet should simply forward to the ResultRange version, call array(), and return Row[].
Possibly, during the deprecation phase, ResultSet could be changed to simply be an alias of Row[].
If there's any worthwhile functionality ResultSet provides that isn't trivially achievable via array(ResultRange), it should be moved outside of ResultSet if possible, or otherwise ResultSet could be kept, but simply reduced to a trivial wrapper around Row[].

Fixed in 91da16a86d4351785cb9a0172be8d7ae7ae74fdb

repo: mysql-d/mysql-native


text:
Update index.js

successfully removed dot in comment XD

Thank you for your pull request however the dot is there to end the sentence in that piece of documentation.

authors: dougwilson geekykumaran

repo: mysqljs/mysql


text:
sh: run-s: not found

when I run - npm run build or npm run prebuild, It works perfectly and these scripts use run-s.
But When I am trying to build a docker image, I am getting this error
docker build . --build-arg APP_PORT=3000  -t test1
[+] Building 29.2s (16/16) FINISHED
 => [internal] load metadata for docker.io/library/node:17.2.0-alpine                                                                                3.6s
 => [internal] load build context                                                                                0.3s
 => => transferring context: 1.10MB                                                                                0.3s
 => [ 5/12] WORKDIR /usr/src/app                                                                                0.2s
 => [ 6/12] COPY --chown=node:node . /usr/src/app                                                                                0.3s
 => [ 7/12] COPY package*.json ./                                                                                0.1s
 => [ 8/12] RUN npm ci                                                                                23.0s
 => ERROR [12/12] RUN npm run build                                                                                1.0s
------
 > [12/12] RUN npm run build:
#16 0.940
#16 0.940 > builder-backend@0.0.1 prebuild
#16 0.940 > run-s cleanup prettier lint-check compile
#16 0.940
#16 0.956 sh: run-s: not found
------
executor failed running [/bin/sh -c npm run build]: exit code: 127

It fails on prebuild step.
this is the package.json file
cat package.json
{
  ...
  "scripts": {
    "prebuild": "run-s cleanup prettier lint-check compile",
    "build": "nest build",
  },
  "dependencies": {
    ...
  },
  "devDependencies": {
    "npm-run-all": "4.1.5",
  },
}

Problem fixed -
npm ci use NODE_ENV to check the environment and was not installing devDependencies.

repo: mysticatea/npm-run-all


text:
Encoding Error caused by react-native XMLHttpRequest.

My project request data with Chinese. But some times the data response from server would be a unreadable string.
After debug，we found that it is cause by the ‘XMLHttpRequest’ object support by RN.
It's a issues of react-native, but we found we just can't change the axios adapter to 'http'.
dispatchRequest.js
 var adapter;

  if (typeof config.adapter === 'function') {
    // For custom adapter support
    adapter = config.adapter;
  } else if (typeof XMLHttpRequest !== 'undefined') {
    // For browsers use XHR adapter
    adapter = require('../adapters/xhr');
  } else if (typeof process !== 'undefined') {
    // For node use HTTP adapter
    adapter = require('../adapters/http');
  }

Could you please teach me a way to change the adapter to 'http'?  I don't know if 'http' can work in react-native, or you can show me a adapter for 'fetch'?
For this project, would you like to change the default adapter to 'http' in react-native? or create a 'fetch' adapter?
Thanks

The http adapter uses node's http module under the hood. I don't believe the http module is available in React Native environment so the http adapter will not work there.
There are no plans to create a fetch adapter at the moment. Have you tried to use fetch directly to check if it doesn't have the same issue?

@nickuraltsev  Yes, I tried to use fetch, and It's OK. And I write a simple 'fetch' adapter for our RN project by my self, but I thought it didn't support enough config correctly, so I wish would you show a official example.
Thanks for reply

@wzl002 You can use the xhr adapter as an example. The code can be found here: https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js.

repo: mzabriskie/axios


text:
Import file warning or not cancel in MZMINE4

Is your feature request related to a problem? Please describe.
In MZMINE4, I noticed that when the mzXML files have some problems (because of raw file corruption), all the subsequent data import tasks were canceled. However, in MZMINE3, all other files were imported and the problematic files were not imported and showed warnings. This makes MZMINE3 work more smoothly in data import than MZMINE4 by ignoring the problematic files and just providing warnings.

Describe the solution you'd like
Make the MZMINE4 data importing ignore problematic files, list warnings, and import all the other normal files like MZMINE3.
Describe alternatives you've considered
If not possible, at least listing which file has the problem would be nice. Currently, all the subsequent file importing is messed up in MZMINE4 if any file has a problem in the middle.

Hi @jamesjiadazhan, thanks for the report. Can you please upload the problematic mzxml file so we can reproduce the issue?

Sure. Thanks for the help!
corrupted_mzXML.zip

Hi i finally had some time to look into it. I think the spectral data is not encoded correctly. I woud suggest to reconvert the raw data to mzML and not mzXML, e.g., using MSConvert

Hi i finally had some time to look into it. I think the spectral data is not encoded correctly. I woud suggest to reconvert the raw data to mzML and not mzXML, e.g., using MSConvert

Thank you! I will try that.

authors: SteffenHeu jamesjiadazhan

repo: mzmine/mzmine


text:
.xlsx export for massvoltammograms

Added the functionality to export the massvoltammograms data to a single .xlsx file.
Also implemented the Task interface into the MasvolltammogramExportTask class to check the exports progress. And changed the getFinishedPercentage method for the MassvoltammogramTask class, so the progress can be displayed properly.

nice, thanks

authors: SteffenHeu WesMark


text:
Can't handle error CasperError: Cannot upload nonexistent file

I'm trying to somehow handle errors in my casper.js script.
I've tried with
try { ... } catch(e) {}

as well with
casper.on('error', function() {...})

the script stops when having an error like
CasperError: Cannot upload nonexistent file
How to handle the errors on my own?

What is version of your phantomjs?

you can paste your script?

phantomjs version: 1.9.0
casper.on('error', function(e) {
    sendError(e)
})

casper.start(...)

casper.then(function() {
	try {
		casper.then(function() {
		  	this.fill('form.add', {
		        'file': 'tmp/'+product.id+'/'+image.order+'.'+image.url.split('.').pop(),
		    }, false)
		})
	} catch(e) {
		sendError(e)
	}
})

if there's no image, I get the CasperError: Cannot upload nonexistent file
any ideas to catch this error?

Have you looked at if PhantomJS had similar errors reported around the time of 1.9.0 ?

I meet the same problem which I post in http://stackoverflow.com/questions/29158204/how-to-make-casperjs-continue-instead-of-exit-on-exception .
Could you give me some help? Thanks.

As part of a cleanup effort:
Looks to be a stale help request. Assuming you've moved on to better and cooler things. Please feel free to re-open if this is still an active issue for you and we'll try our best to help out.

authors: 3x14159265 BIGjuevos paazmaya rdpanek zjiash


text:
fix cache invalidations when result contains empty values

🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of
the pull request.
Description
Please include a summary of the change and which issue is fixed. Please also include relevant
motivation and context. List any dependencies that are required for this change.
Fixes #1953 (issue)
Type of change
Please delete options that are not relevant.

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

How Has This Been Tested?
Issue #1953 contains most relevant information, also I added a new test purges cached empty query operation execution result via imperative cache.invalidate api using typename.
Test Environment:

OS: MacOS
@envelop/...:
NodeJS: 18.16.0

Checklist:

[x] I have followed the
CONTRIBUTING doc and the
style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented on my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Further comments
This might as well just be a draft. I'm not sure if I need to follow the CONTRIBUTING.md for drafts. Let me know if this is useful or not.

Thank you for sharing this with us !
Honestly, I'm pretty happy with your proposal. I think that it is a good improvement, the current behaviour of the cache invalidation for empty values is actually a bug we need to fix I think.
Your approach seems totally fine for me !
I will add some observations but I think this is totally something we want to merge :-)

Thanks for your quick feedback! I've just pushed some changes, pretty happy with how it's turned out.

Thank you for taking the time for this 😀
After some thoughts, I see a drawback with our approach here.
The idea here is to be able to invalidate by type when we add an entity to avoid having null or lists stale. But this comes at cost of loosing the cache for any response which contains at least one entity of this type, while it is probably not stale just because we added an item.

I've created an issue to discuss about my concern here : #1979
Let's merge this since it's not really related.
@marhaupe Can you add a changeset ? Just run pnpm changeset and follow instructions :-)

Done 👍 I also read through your proposal and I like it, I just left a comment with one thought I had though.

Thank you again for the time spent on this :-) very appreciated !

authors: EmrysMyrddin marhaupe