[FEATURE REQUEST] - Script usage for the average user

So @CJGarciaMusic messaged me about a very valid point with the Library and how it's currently set up.
And discussing potential solutions soon is a good idea so we won't need to refactor thousands of lines of code later on.
Essentially, it's hard for users to use any of the main scripts. They either need to:

Use git to clone the repo and update scripts
They couldn't necessarily download a single script (if it uses the Library)

They would also need to download the Library, make sure it's in a subdirectory, and update both files whenever there's an update.

@CJGarciaMusic, correct me if I'm mistaken about anything you were saying.
This is a valid point that dramatically diminishes the impact of these scripts as things stand because many people won't want to go through that process or don't know git to get started.
Now, I'd rather not completely get rid of the Library as it stands because it can be incredibly helpful with development. So here are possibilities I thought of to resolve this issue. Thoughts and ideas appreciated.

Have a "Dropbox Installer". Ok, for those who don't know how / don't want to use git, I can set up a Dropbox folder we can share with people. That folder can mainly just be the repo. Then I can set up a cron job with Keyboard Maestro on my computer to periodically git pull and update the Dropbox folder. Then people can get automatic updates. I've used this with several of my personal scripts with several people, and it's gone decently well. We'd need some proper documentation with the JW Lua plug-in installation. But people would need that anyways. The only challenge here would be notifying people of new scripts. Previously installed scripts will be updated automatically. This is by far the easiest option I've thought of and will only take ~30 minutes of work on my end.
We create a JW Lua Script as an installer/updater. Assuming JW Lua can connect to the internet or at least use curl, this should be possible. I have a rough outline of the code in my head. Then, people can set up a single JW Lua script, find new scripts, install the new scripts, and update them from a single script. I'm not sure if JW Lua can connect to the internet. With regular Lua, you need to import a module. Not sure if JW Lua includes that module. Of all the options I've thought of, this would likely be the hardest and most time-consuming. But probably the best user experience.
Create a website and pre-compile the scripts. Lately, I've been doing a surprising amount of web development, so this one is definitely doable. Essentially, you would be able to explore scripts on the site. When you download a script, the site will then look for all the imports and just replace the import statement with the contents of the library module. Crude, but it will work. Updates are going to be harder with this method, though. If we choose this route, I'd rather code the site. Which means there won't be a GUI to update it. So anyone updating the site would need to know HTML, CSS, and JS. The timeline would probably be ~3-4 weeks for the first version. Realistically, it would be only about 10 hours total, but don't want to overpromise a delivery date.
Perhaps @rpatters1 could create an installer plug-in? If JW Lua can't access the internet, I'm sure a plug-in written in C++ could. It would put most of the work on his shoulders since I don't know C++, but it's a potential option. @rpatters1, don't feel obligated to do this. Just throwing out ideas.
Alternatively, forget about good user experience. Kind of defeats the purpose of a public repo, but it's an option. I'd rather not choose this option, but it's an option.

I think, ideally, it would be great to have the best possible developer experience and user experience.
I don't think it's worth abandoning the idea of a Library where we can import functions at this point. If we can't find a suitable way for non-techie users to use the scripts, then that's probably time. I don't think we're there yet.
Thoughts? @CJGarciaMusic, @rpatters1

I share @CJGarciaMusic's concern.
Another option would be to use git. Perhaps we could package up the appropriate git commands to clone (if needed) and pull master in a simple shell script. Then all the potential user would have to do it execute the shell script.

To follow up: GitHub is almost there. If you click on the Clone->Zip file option, you get the master branch in a git-enabled folder that you can put anywhere you like.

Another idea: JW Lua may not be able to access the internet, but perhaps it can execute the shell script. Then the installer could be a lua scrupt.

After a little research I realize that, unlike Mac and Linux, git does not come preinstalled on Win. But this link works for anyone I believe:
https://github.com/Nick-Mazuk/jw-lua-scripts/archive/master.zip
So there could be a link on a web page that downloaded that link.

Looks like Lua can run shell commands. For instance, I just ran:
os.execute('cd /Users/nickmazuk/Desktop && mkdir lua_test && cd lua_test && curl https://google.com --output google.html')

and it successfully created a folder on my Desktop and saved the Google Hompage into that folder!
That's neat.
Given this, I'd say probably the best solution is to use Lua to create an installer and updater. Thoughts?

I like it. I think there is a PDK Framework command to open a dialog to get the target folder. I don't suppose there is some way for a script to add to the JW Lua menu in Finale.

Also, we'll need to test it on Win as well as Mac. I can do that easily. But for reference, I do that on my Mac using VMWare, in case y'all ever wanted to test on Win for yourselves.

I've tried using a VM to use Windows before. It was very buggy with JW Lua specifically, though. That may just be my experience, though.
There is a JW Lua command to have the user select a folder to upload files into (FCFileSaveAsDialog). I've used it before. I've also saved config options to a TXT file. So perhaps we could use that to save the file path (that way users don't need to mess around with preferences).
Alternatively, we could set the default save path to be their Plug-ins/JW Lua/a folder name we decide on/. There's a JW Lua function to find their plugin folder (FCString():SetPluginsFolderPath()).
I don't know how to add a script to the JW Lua menu through a JW Lua script. That would be incredibly useful! I know the perfect layout plugin packages a copy of JW Lua with the Perfect Layout plugin already in the menu bar. So perhaps there's a way to modify the .bundle file to add the JW Lua script?
Also, in case Windows need a different shells script than macOS, we can use FCUI:IsOnMac() and FCUI:IsOnWindows() to distinguish between the two.

I haven't used JW Lua on Windows enough to have an opinion about how buggy
it is. (Honestly, I would be surprised if it's any more buggy than on
native Win. But it is definitely slower.) I was able to test the library
loading without any problems.
I mean, ultimately if this project is really going to take off, we have to
get Jari on board, at least to the extent of allowing me to work on his
code if he is not able to. We could address a tremendous amount of
headaches with some simple changes to JW Lua. We could eliminate rafts of
lua code with simple enhancements to the PDK Framework. And if we are
unable to build JW Lua soon with the latest PDK, Finale will gradually
begin to leave it behind.
All by way of saying, all of us need to keep an eagle eye out on Facebook
for Jari. If he posts, try to get his attention. I saw a post from him a
few weeks ago in the Scripts group I believe. I posted a greeting, but
unfortunately he did not reply.
On Mon, Jun 15, 2020 at 1:09 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

I've tried using a VM to use Windows before. It was very buggy with JW Lua
specifically, though. That may just be my experience, though.
There is a JW Lua command to have the user select a folder to upload files
into (FCFileSaveAsDialog). I've used it before. I've also saved config
options to a TXT file. So perhaps we could use that to save the file path
(that way users don't need to mess around with preferences).
Alternatively, we could set the default save path to be their Plug-ins/JW
Lua/a folder name we decide on/. There's a JW Lua function to find their
plugin folder (FCString():SetPluginsFolderPath()).
I don't know how to add a script to the JW Lua menu through a JW Lua
script. That would be incredibly useful! I know the perfect layout plugin
packages a copy of JW Lua with the Perfect Layout plugin already in the
menu bar. So perhaps there's a way to modify the .bundle file to add the
JW Lua script?
Also, in case Windows need a different shells script than macOS, we can
use FCUI:IsOnMac() and FCUI:IsOnWindows() to distinguish between the two.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-644287348,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X2YAOXKBXNN6427B3DRWZPT5ANCNFSM4N5V6T3A
.

I agree and that sounds like a plan.
So here are some ideas for next steps:

Get other JW Lua creators on board, that way we can really build up a library of scripts and get more opinions from other developers

I'll email Jan, Harold, and the French coder (don't know his name) later today and post in the JW Lua email group

Figure out the exact functions for the installer

Are we going to download the entire repo?
Download scripts individually?
etc.

Create a JW Lua script for what users are going to see. Essentially, figure out the UI. That way we know what data we need to get using a curl command or similar.
Figure out a good backend to fetch the info needed for the installer/updater. Potentially it could simply be downloading the repo and we won't need to do anything special. But it depends on the exact functionality we decide on.
Hook everything up and test it!

Thoughts?

To address your specific points, I don't think we should put lua scripts in
the plugins folder. On Mac, at least, plugins are in a privileged location
that is already restricted in Catalina so that you have to use root to copy
files there. (For some users.) My guess is that future macOS versions could
make it even harder to add ad hoc files to the plugins folder.
JW Lua is putting its data somewhere. I don't think it is inside the
bundle, but so far I'm not finding it. Will keep looking.
On Mon, Jun 15, 2020 at 1:09 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

I've tried using a VM to use Windows before. It was very buggy with JW Lua
specifically, though. That may just be my experience, though.
There is a JW Lua command to have the user select a folder to upload files
into (FCFileSaveAsDialog). I've used it before. I've also saved config
options to a TXT file. So perhaps we could use that to save the file path
(that way users don't need to mess around with preferences).
Alternatively, we could set the default save path to be their Plug-ins/JW
Lua/a folder name we decide on/. There's a JW Lua function to find their
plugin folder (FCString():SetPluginsFolderPath()).
I don't know how to add a script to the JW Lua menu through a JW Lua
script. That would be incredibly useful! I know the perfect layout plugin
packages a copy of JW Lua with the Perfect Layout plugin already in the
menu bar. So perhaps there's a way to modify the .bundle file to add the
JW Lua script?
Also, in case Windows need a different shells script than macOS, we can
use FCUI:IsOnMac() and FCUI:IsOnWindows() to distinguish between the two.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-644287348,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X2YAOXKBXNN6427B3DRWZPT5ANCNFSM4N5V6T3A
.

Here's a little proof of concept you might all enjoy... All it does is list and open the link. Downloading and installing shouldn't be too difficult...
`function plugindef()
finaleplugin.RequireSelection = false
finaleplugin.Author = "CJ Garcia"
finaleplugin.Copyright = "© 2020 CJ Garcia Music"
finaleplugin.Version = "0.1"
finaleplugin.Date = "6/15/2020"
finaleplugin.CategoryTags = "Note"
return "Lua Repository", "Lua Repository", "A list of all current public Lua scripts."
end
local tmp_dir = "/tmp/"
if os.execute("cd "..tmp_dir.."lua_test.html") == true then
os.execute("cd "..tmp_dir.."lua_test && curl https://github.com/Nick-Mazuk/jw-lua-scripts --output lua_list.html")
else
os.execute("cd "..tmp_dir.." && curl https://github.com/Nick-Mazuk/jw-lua-scripts --output lua_list.html")
end
function titlecase(str)
local buf = {}
local in_word = false
for i = 1, #str do
local c = string.sub(str, i, i)
if in_word then
table.insert(buf, string.lower(c))
if (string.find(c, '%s')) or (string.find(c, '%.')) then
in_word = false
end
else
table.insert(buf, string.upper(c))
if (string.find(c, '%('))  then
in_word = false
else
in_word = true
end
end
end
return table.concat(buf)
end
local current_scripts = {}
local download_links = {}
local current_file = tmp_dir.."/lua_list.html"
for line in io.lines (current_file) do
if string.find(line, "title=".%.lua"") and (string.find(line, ".lua" id=""))then
local first_index = string.find(line, "title=".%.lua"")
local last_index = string.find(line, ".lua" id="")
local file_name = (string.sub(line, first_index + 7, last_index - 1))
local display_name = titlecase(string.gsub(file_name, "_", " "))
local download_link = "https://github.com/Nick-Mazuk/jw-lua-scripts/blob/master/"..file_name..".lua"
table.insert(current_scripts, display_name)
table.insert(download_links, download_link)
end
end
local str = finale.FCString()
str.LuaString = "Download Lua Script"
local dialog = finale.FCCustomWindow()
dialog:SetTitle(str)
local script_list = dialog:CreateListBox(0, 0)
script_list:SetWidth(244)
for key, value in pairs(current_scripts) do
str.LuaString = value
script_list:AddString(str)
end
dialog:CreateOkButton()
dialog:CreateCancelButton()
if dialog:ExecuteModal(nil) == 1 then
local link_index = script_list:GetSelectedItem() + 1
os.execute("open "..download_links[link_index])
end`

I found the location where JW Lua stores the menu items on Mac. It's
probably a parallel location on Windows.
~/Library/Application Support/Makemusic/Finale 26/jwpluginstorage.xml
So in theory you could add to that file programmatically. I'm not sure how
JW Lua would react to it while running, though.
On Mon, Jun 15, 2020 at 1:39 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

I agree and that sounds like a plan.
So here are some ideas for next steps:

Get other JW Lua creators on board, that way we can really build up
a library of scripts and get more opinions from other developers

I'll email Jan, Harold, and the French coder (don't know his
name) later today and post in the JW Lua email group

Figure out the exact functions for the installer

Are we going to download the entire repo?
Download scripts individually?
etc.

Create a JW Lua script for what users are going to see.
Essentially, figure out the UI. That way we know what data we need to get
using a curl command or similar.
Figure out a good backend to fetch the info needed for the
installer/updater. Potentially it could simply be downloading the repo and
we won't need to do anything special. But it depends on the exact
functionality we decide on.
Hook everything up and test it!

Thoughts?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-644308253,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X5KNJ7I7M5WDJJ6TG3RWZTBRANCNFSM4N5V6T3A
.

Wow, you two are great!
I'll definitely have to try out @CJGarciaMusic's script.
I can confirm that on my machine, the JW Lua scripts are also stored in that location.

Another thought I had is that it's too bad we can't create subfolders that
reflect into submenus in the Finale plugin menu. But without access to JW
Lua source I don't see how it will be possible.
On Mon, Jun 15, 2020 at 4:07 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

Wow, you two are great!
I'll definitely have to try out @CJGarciaMusic
https://github.com/CJGarciaMusic's script.
I can confirm that on my machine, the JW Lua scripts are also stored in
that location.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-644390194,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X37ILOWWMRT7A5ALSLRW2EPTANCNFSM4N5V6T3A
.

Yeah, it would be great if we could get submenus.

Anyways, I figured out something useful with the library. In the jwpluginstorage.xml file, there's this element:
<UserPreferences SelectedPage="1" RunMultiSelectionMode="0" ExpCleanConsole="1" DevCleanConsole="1" Windowshade="0" EditorTabWidth="4" EditorFontName="Verdana" EditorFontSize="12" EditorTheme="1"></UserPreferences>

It's right after the <PluginNodes> element.
Inside, we can put required paths. In other words, we can add in the path to our library! So for instance, on my machine, it would be:
<UserPreferences SelectedPage="1" RunMultiSelectionMode="0" ExpCleanConsole="1" DevCleanConsole="1" Windowshade="0" EditorTabWidth="4" EditorFontName="Verdana" EditorFontSize="12" EditorTheme="1">
    <RequireFolders CollectionIdx="1" FCString="/Users/nickmazuk/Documents/Github/jw-lua-scripts/library"/>
</UserPreferences>

Note: If there are multiple required folders, they must have unique CollectionIdx values.
Then, instead of writing out this to import a library:
local path = finale.FCString()
path:SetRunningLuaFolderPath()
package.path = package.path .. ";" .. path.LuaString .. "/library/?.lua"
local articulation = require("articulation")

…we can simply do
local articulation = require("articulation")

So in short, when we ask for a folder to save the JW Lua files, we can also add the library path to this preference file.

So one of the simple changes I would like to see in JW Lua is that it
automatically adds the scripts folder to the list of running folders. As
long as we don't have access to changing the code, this seems like a
reasonable substitute. Therefore I would advocate adding our main folder to
the xml file and leaving the "library/" qualifications in the scripts. Not
only does this set us up for a hoped-for revision in JW Lua, it makes clear
that they are library scripts in the library folder.
On Mon, Jun 15, 2020 at 5:27 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

Yeah, it would be great if we could get submenus.
Anyways, I figured out something useful with the library. In the
jwpluginstorage.xml file, there's this element:

It's right after the  element.
Inside, we can put required paths. In other words, we can add in the path
to our library! So for instance, on my machine, it would be:

<RequireFolders CollectionIdx="1" FCString="/Users/nickmazuk/Documents/Github/jw-lua-scripts/library"/>

Note: If there are multiple required folders, they must have unique
CollectionIdx values.
Then, instead of writing out this to import a library:
local path = finale.FCString()
path:SetRunningLuaFolderPath()
package.path = package.path .. ";" .. path.LuaString .. "/library/?.lua"
local articulation = require("articulation")
…we can simply do
local articulation = require("articulation")
So in short, when we ask for a folder to save the JW Lua files, we can
also add the library path to this preference file.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-644421836,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X2G3LWIPEOMX2S6OTLRW2N33ANCNFSM4N5V6T3A
.

So here is my proposal for how to add the libraries. We could refactor the library loads like this:
local path = finale.FCString()
path:SetRunningLuaFolderPath()
package.path = package.path .. ";" .. path.LuaString .. "?.lua"
local library = require("library.general_library")

This makes it clear that the libraries are in the library subfolder.  Then once we have a mechanism in place to add our local folder of jw-lua-script/?.lua to the jwpluginstorage.xml we can remove the first 3 lines leaving only
local library = require("library.general_library")
The beauty of this is that ultimately I would like for JW Lua itself to run scripts in an environment where the running script folder (plus ?.lua) is part of the runtime environment by default. Then we will not even need to modify jwpluginstorage.xml.

I just did a proof of concept of my idea. That was an amazing find in jwpluginstorage.xml btw. I would never have figured it out from mine, because my UserPreferences branch contained no sub-branches. Anyway, I added it as you did:
<UserPreferences SelectedPage="2" RunMultiSelectionMode="0" ExpCleanConsole="1" DevCleanConsole="1" Windowshade="0" EditorTabWidth="4" EditorFontName="Verdana" EditorFontSize="12" EditorTheme="1">
       <RequireFolders CollectionIdx="1" FCString="<my-folder-location>/Lua Scripts"/>
</UserPreferences>

Now I can add the library with one line of code:
local library = require("library.general_library")
It seems lua treats "." as a path delimiter. This also works:
local library = require("library/general_library")
BTW, how do you get your code snippets to be color-labeled?

Great!
I think that's going to be the way to go. It's simple, and I do like how adding require("library.general_library" signals that the file is in the library folder (as opposed to some random Lua library). We just have to figure out how to add that code to the UserPreferences.

For the color-labeling, you just need to add the name of the language after ``` in the multiline code snippet.
For instance, this …
``` lua
-- this is lua
print('hello world')
```

… becomes …
-- this is lua
print('hello world')

See Syntax Highlighting in the markdown cheatsheet: https://guides.github.com/features/mastering-markdown/

So the Windows location is exactly where I expected to find it. The analogous place on Windows (which I found by looking in Finale Preferences->Folders):
C:\Users\Robert Patterson\AppData\Roaming\MakeMusic\Finale 26\jwpluginstorage.xml

I then edited this file as we have done for the Mac. Everything worked as expected. I think this approach is the right one.

Something like this might allow us to edit the jwpluginstorage.xml either as a shell-out or directly in JW Lua:
xml2lua

I have an idea on how to add the file path to jwpluginstorage.xml without using a 3rd-party library. Will code it up later today.
Also, just a thought. If we were to create an installer for JW Lua itself (which would also install the JW Lua script installer), would you @rpatters1 be willing and able to sign it for macOS? I think you have an Apple Developer ID to sign your plugins (let me know if I'm wrong).
If that's possible, it would be extremely helpful. Then we can create a package using this software or similar, bypassing all the confusing steps of installing a 3rd-party plugin and a JW Lua script. Such a package could:

Detect if JW Lua is already installed
If not, install the correct version
Install the installer Lua script and add the library path to the jwpluginstorage.xml file
Prompt users to restart Finale

Basically making the entire process one step for users.
Plus, if it was possible to sign it, we might also be able to bypass the "unverified developer" warning with JW Lua.
Thoughts?

I am extremely reluctant to sign with my personal apple id. I think it may
go against their terms of use. And anyway, JW Lua ultimately needs to be
signed by Jari if he wants it to continue having a life.

On Tue, Jun 16, 2020 at 11:26 AM Nick Mazuk<EMAIL_ADDRESS>wrote:

I have an idea on how to add the file path to jwpluginstorage.xml without
using a 3rd-party library. Will code it up later today.
Also, just a thought. If we were to create an installer for JW Lua itself
(which would also install the JW Lua script installer), would you
@rpatters1 https://github.com/rpatters1 be willing and able to sign it
for macOS? I think you have an Apple Developer ID to sign your plugins (let
me know if I'm wrong).
If that's possible, it would be extremely helpful. Then we can create a
package using this software or similar
https://www.macupdate.com/app/mac/34613/packages, bypassing all the
confusing steps of installing a 3rd-party plugin and a JW Lua script.
Such a package could:

Detect if JW Lua is already installed
If not, install the correct version
Install the installer Lua script and add the library path to the
jwpluginstorage.xml file
Prompt users to restart Finale

Basically making the entire process one step for users.
Plus, if it was possible to sign it, we might also be able to bypass the
"unverified developer" warning with JW Lua.
Thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-644870015,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X7GKH5K5562A32NCKDRW6MHTANCNFSM4N5V6T3A
.

That's perfectly ok. And yeah, Jari does need to eventually sign JW Lua anyways.

Ok, I believe I finally got the file this file to have a list of all the Lua scripts in the repo. It should also update every time we merge into the master branch.
https://raw.githubusercontent.com/Nick-Mazuk/jw-lua-scripts/gh-pages/scripts.txt
Here's a sample of the file:
FILE=UI_switch_to_selected_part.lua
AUTHOR=CJ Garcia
VERSION=1.2
DATE=June 12, 2020
CATEGORYTAGS=UI
NAME=Switch To Selected Part
DESCRIPTION=Switches to the first part of the top staff in a selected region in a score. Switches back to the score if viewing a part.

FILE=beam_selected_region.lua
AUTHOR=Robert Patterson
VERSION=1.0.1
DATE=June 12, 2020
CATEGORYTAGS=Note
NAME=Beam Selected Region
DESCRIPTION=Beam Selected Region

FILE=beam_unbeam_selected_region.lua
AUTHOR=Robert Patterson
VERSION=1.0.1
DATE=June 12, 2020
CATEGORYTAGS=Note
NAME=Unbeam Selected Region
DESCRIPTION=Unbeam Selected Region

This way, we can quickly search for new scripts, check for updates, or anything else. The metadata is taken straight from the plugin def, so anytime we update that, this file will change.
P.S. If you've gotten notifications about any builds failing, that was me testing Github actions to make sure this always works.

I was just thinking we should probably require descriptions so people know
why anyone took the trouble to write them.
On Tue, Jun 16, 2020 at 4:50 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

Ok, I believe I finally got the file this file to have a list of all the
Lua scripts in the repo. It should also update every time we merge into the
master branch.
https://raw.githubusercontent.com/Nick-Mazuk/jw-lua-scripts/gh-pages/scripts.txt
Here's a sample of the file:
FILE=UI_switch_to_selected_part.lua
AUTHOR=CJ Garcia
VERSION=1.2
DATE=June 12, 2020
CATEGORYTAGS=UI
NAME=Switch To Selected Part
DESCRIPTION=Switches to the first part of the top staff in a selected region in a score. Switches back to the score if viewing a part.
FILE=beam_selected_region.lua
AUTHOR=Robert Patterson
VERSION=1.0.1
DATE=June 12, 2020
CATEGORYTAGS=Note
NAME=Beam Selected Region
DESCRIPTION=Beam Selected Region
FILE=beam_unbeam_selected_region.lua
AUTHOR=Robert Patterson
VERSION=1.0.1
DATE=June 12, 2020
CATEGORYTAGS=Note
NAME=Unbeam Selected Region
DESCRIPTION=Unbeam Selected Region
This way, we can quickly search for new scripts, check for updates, or
anything else. The metadata is taken straight from the plugin def, so
anytime we update that, this file will change.
P.S. If you've gotten notifications about any builds failing, that was me
testing Github actions to make sure this always works.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-645029676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X33J4FW4QQFJSEHQKTRW7SG5ANCNFSM4N5V6T3A
.

P.S. Unfortunately, JW Lua truncates the descriptions at something like 64
characters when it displays them in Finale. That's an ancient limitation
from PDK of ~2003.
On Tue, Jun 16, 2020 at 5:06 PM Robert Patterson <
<EMAIL_ADDRESS>wrote:

I was just thinking we should probably require descriptions so people know
why anyone took the trouble to write them.
On Tue, Jun 16, 2020 at 4:50 PM Nick Mazuk<EMAIL_ADDRESS>wrote:

Ok, I believe I finally got the file this file to have a list of all the
Lua scripts in the repo. It should also update every time we merge into the
master branch.
https://raw.githubusercontent.com/Nick-Mazuk/jw-lua-scripts/gh-pages/scripts.txt
Here's a sample of the file:
FILE=UI_switch_to_selected_part.lua
AUTHOR=CJ Garcia
VERSION=1.2
DATE=June 12, 2020
CATEGORYTAGS=UI
NAME=Switch To Selected Part
DESCRIPTION=Switches to the first part of the top staff in a selected region in a score. Switches back to the score if viewing a part.
FILE=beam_selected_region.lua
AUTHOR=Robert Patterson
VERSION=1.0.1
DATE=June 12, 2020
CATEGORYTAGS=Note
NAME=Beam Selected Region
DESCRIPTION=Beam Selected Region
FILE=beam_unbeam_selected_region.lua
AUTHOR=Robert Patterson
VERSION=1.0.1
DATE=June 12, 2020
CATEGORYTAGS=Note
NAME=Unbeam Selected Region
DESCRIPTION=Unbeam Selected Region
This way, we can quickly search for new scripts, check for updates, or
anything else. The metadata is taken straight from the plugin def, so
anytime we update that, this file will change.
P.S. If you've gotten notifications about any builds failing, that was
me testing Github actions to make sure this always works.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-645029676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X33J4FW4QQFJSEHQKTRW7SG5ANCNFSM4N5V6T3A
.

Created a pull request that updates the README to require descriptions.
Also, tonight I'll go ahead and update all the library import statements to match what we agreed on above.

Now that the scripts are bundled to include the applicable functions from the library and users can easily download scripts from the website, shall I close this issue?
Though, a dedicated installer would be nice, I think the current solution is probably good enough. Any thoughts?

I'm cool with closing it. But maybe CJ should comment as well.
On Thu, Jul 29, 2021 at 12:15 PM Nick Mazuk @.***>
wrote:

Now that the scripts are bundled to include the applicable functions from
the library and users can easily download scripts from the website, shall I
close this issue?
Though, a dedicated installer would be nice, I think the current solution
is probably good enough. Any thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Nick-Mazuk/jw-lua-scripts/issues/17#issuecomment-889320065,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYB6X4FJFUHQQZESSRVGZ3T2GEATANCNFSM4N5V6T3A
.

Just a note (off topic but this is the best thread):
The plugindef can include an option called notes. This field accepts a multiline string and is correctly parsed and displayed on the website. Might be a good idea to start using this field to document how to use each script. There's only so much you can write in the description of the return statement, and often that's not enough to communicate the full usage of a script.

Closing since @CJGarciaMusic hasn't commented on this in a year.
CJ, feel free to reopen.


[wip] D3 v4

TODO

[x] Figure out what to do about d3.rebind deprecation
[x] Initial map loading is in the wrong place
[x] Data only loads in the way top left corner of the map
[ ] Fix tests

[x] Fix testing of lib (now included under iD.lib)
[ ] Fix events in tests

Notes:

Resource for changes: https://github.com/d3/d3/blob/master/CHANGES.md
d3-zoom is very changed https://github.com/d3/d3-zoom and rather difficult to upgrade
this now avoids all "throwing stuff onto the d3 object" patterns and instead exports independent functions and objects from add-ons.

Common changes:

style no longer takes an object. change to styles and import d3-selection-multi.
transition no longer does .each('on', function, instead do .on('end'
selections are immutable; reassign if you want to reference selections after enter() calls
rebind was removed and I added a backport. I'm not 100% it works yet.

@bhousel any chance you'll get time to check out this branch? I know you're slammed with other work, but this branch is really the final push of the refactor: it totally eliminates non-modular dependencies and vastly simplifies the build step. Once this is in, we can move much faster with iD.

@tmcw, @kepta
It's September now and I've had it with this refactor.
Why do the source maps in the Chrome Dev tools not match up with actual code in the repository.

I can't fix issues with the D3 upgrade if I can't edit the code and rebuild iD in a reliable way.
If we can't get a basic development environment working in this branch in the next week, let's scrap this summer's work and return to the 1.9.7 branch.   I'm not willing to waste any more time fighting with tools.
If you think it that what we have works, kindly spell out for me the steps that you are following to build everything and run tests..  Update the README too if you feel like making things easy for me.
Sorry for the angry tone of this but it's getting late and I really hate feeling like I'm wasting my time.

So the answer to why the source maps weren't getting updated.. A syntax error elsewhere caused the build to just fail silently, so the source map and the iD.js bundle were old.
The server did say "Rebuilding" but never followed up with a "Rebuilt" message.
The local server should do something on errors, not silently ignore them.

I've fixed the sourcemap issue. How much time can you dedicate to this PR next week? Over the past 20 days, I've done much of the work on this branch, and related efforts - building the development environment, doing d3 upgrades en masse, painstakingly refactoring the build system. I had hoped that looping you in would help resolve the map-loading problem - maybe with the build process clearer, you can finish those changes?

I've fixed the sourcemap issue. How much time can you dedicate to this PR next week? Over the past 20 days, I've done much of the work on this branch, and related efforts - building the development environment, doing d3 upgrades en masse, painstakingly refactoring the build system.

I just tried it.
As a test, I introduced a syntax error, and the server printed
{ [SyntaxError: 'return' outside of function (594:4) in /Users/bryan/Projects/iD/modules/renderer/map.js]
  pos: 17582,
  loc: Position { line: 594, column: 4 },
  raisedAt: 17588,
  code: 'PARSE_ERROR',
  file: '/Users/bryan/Projects/iD/modules/renderer/map.js' }

This is good!
Then I fixed the error and nothing happened.. no message, no rebuild.   Is this expected?   This seems wrong to me.

So the previous way of doing things was:
... edit code...
make
npm run test
python -m SimpleHTTPServer

and presumably the new way is:
... edit code...
npm run build
npm run test
npm start

If I am wrong about that, or if parts of the edit-compile-test loop are still not all the way done, (for example reliable source map generation), all I'm saying is lets take a pause and figure those things out first.

Okay, fixed that in 	f402e6b - that was also a one-line change. The development_server.js is a 50-line utility that I wrote according to what I know of the rollup API, and we need to treat it as a mungible thing that we can all contribute to - neither of these issues should have been a blocker, one was 'ignoring the second callback of a promise', and the second was fixing a mutex. Both were one-line fixes.

Okay, fixed that in f402e6b - that was also a one-line change.

Thank you, I'll see what I can do with this today...

🎉  woot, nice work with the zoom refactoring!

Making significant progress:
fixed:

area drawing
dragging points
raw tag editor
map size
line display
multi attributes

Making significant progress:

Nice, thanks!!  Yeah, when I read the v4 release notes I thought we would probably need to put those merge calls just about everywhere.  That's a pretty big change to the general update pattern, but immutable selections will be so much easier to reason about.

Fixed point adding. Line + way adding is still broken. Point adding took a long time to figure out but was not much of a code change.
Fixed circularize tests. Other tests are failing, mostly because of the behavior of triggerEvent. Some parts of the codebase expect real events, with targets.. maybe we should use happen more and trigger less?

Taking a break to read, so if anyone else wants to take a shot at the remaining queue, go for it.

I've been spending the past day trying to understand why the iD global is undefined when run through mocha-phantomjs (even though it works fine in a real browser).
d3 is bundled as a umd module, but they are able to attach to the global window root, so I'm not sure why our bundle won't do it (even with an explicit window.iD = iD).  I guess we switched it to iife because of #3356?
    <script>
    console.log('d3 = ' + window.d3);
    console.log('iD = ' + window.iD);
    </script>

d3 = [object Object]
iD = undefined
ReferenceError: Can't find variable: iD
   in global code at file:///Users/bryan/Projects/iD/test/spec/spec_helpers.js:3

Anyway I would be really happy if I could find a way to get npm run test (and consequently travis) working again.

Fiddled for a bit and I think 9834f66 will do it. The iD bundle has 'use strict' on it, and phantomjs's interpretation of strict in combination with its pretty quirky semi-browser is all bad news bears. https://travis-ci.org/openstreetmap/iD/builds/157471249 has tests running again.

Fiddled for a bit and I think 9834f66 will do it. The iD bundle has 'use strict' on it, and phantomjs's interpretation of strict in combination with its pretty quirky semi-browser is all bad news bears. https://travis-ci.org/openstreetmap/iD/builds/157471249 has tests running again.

Thanks!!  👍

Area & line drawing fixed! More small issues with the event dispatching refactor.

Almost there! Most of the rest of the test-thwacking is dealing with d3.customEvent, dispatch, and so on - help appreciated as always.

Okay, @kepta @bhousel all tests pass. Only took many hours and a can-do attitude.
Shall we do some UI testing before merging this PR?

Shall we do some UI testing before merging this PR?

Unfortunately we've never had automated test coverage of anything under the old iD.ui namespace, so yes we'll need to do a lot of manual testing before we put up the "mission accomplished" banner.
For example, I notice that all the areas are being filled with black:

Hopefully this won't be too bad. Most of the stuff we uncover will be because of the changes in D3 general update pattern.

Just a quick update:  This branch is actually getting pretty close to merging!   It is useable for editing and saving.  A few things that seem off:

[ ] certain field elements (like combobox placeholders) aren't showing up on hover the first time (probably because of changes to D3 general update pattern and enter selection no longer flows into update)
[ ] help screen missing some graphics
[ ] walkthrough doesn't advance to next chapter

I think this is small stuff and I'll hopefully fix and merge to master within the next few days. 😄

Merged!  🏁 🎉
Thanks @tmcw for tolerating my crankiness and for keeping this moving!
The D3 upgrade was a massive amount of work, but this is a great step forward for iD and I'm glad we were able to pull it off!


[UnitTests] Temporarily disable IndexSubset testcases while investigating

rdar://problem/56338898

CC @rxwei @bgogul

@swift-ci Please smoke test

So sorry for the delay in investigations!

No worries. Force merging to unblock the CI.


[FAQ] convert a list of lists to a single list

General Question
How do I convert [[1, 2], [3, 4]] to [1, 2, 3,4] in kcl?

Hey @Peefy ,added the PR #325

Closed by #325


Document cluster configuration, architecture, and failover

closed in favor of https://github.com/influxdb/influxdb.com/issues/263


Can't access form.values

Describe the bug
Using
const form = useForm({ subscribe: 'form' });

Based on Steppers example, form.values is undefined, is that expected behavior? Shouldn't it be accessible for validations as password confirmation?
Maybe it's all about me and another JS issue because I'm quite bad at it :D.

@KannarFr Yes subscribing to the "form" only will not give you access to the "fields" values.
This is for performance optimisation. But you can access the values later in the tree.
This is to prevent the root component to rerender on every field change.
Example:

const MyFormPart = () => {
  const form = useForm(); // same as useForm({ subscribe: true })
  // Have access to form.values
  return <pre>{JSON.stringify(form?.values, null, 2)}</pre>;
};

const MyForm = () => {
  const form = useForm({ subscribe: 'form' });
  // Don't have access to form.values
  return (
    <Formiz connect={form}>
      <form noValidate onSubmit={form.submit}>
        <MyFormPart />
      </form>
    </Formiz>
  );
};

@ivan-dalmet Oh ok, thanks!


Top and Bottom Pagination

Top and Bottom Pagination, defaults to only the bottom pager being shown.
Included a React Story for an example
bumped react-story:  "react-story": "^0.0.10"

Ready for review now

@tannerlinsley any update for this PR? Thank you

there is an issue with react-story that I created, react-router-dom@next doesn't exist anymore

@tannerlinsley updated the PR based on the feedback

@aaronschwartz I'm good on this.  Are you?

@tannerlinsley would you be able to merge it soon? Thanks a lot!


T4

rejected:T4
reason: significantly less than 150 encrypted transactions made (only 36 found on-chain)

rejected:T4
reason: significantly less than 150 encrypted transactions made (only 36 found on-chain)


a800s not open after update FW_DR2800_50MBIT

i have a800s at 1.0.19ww official fw and then i try your fw to FW_DR2800_1.0.14ww and FORCEUPD.txt on this folder it update success and work just fine check the version is 1.0.14 and then i try update to FW_DR2800_50MBIT at first use FORCEUPD.txt on your root project that not work update fail and dsahcam restart same version at 1.0.14ww so next i use FW_DR2800 on FW_DR2800_50MBIT and use FORCEUPD.txt file on "FW_DR2800_1.0.14ww" folder and this update working and it boot on to record and menu work fine and then after 3mins on recording it shut it self up and nothing happen even i try plug it again with or without memory card or different cable input ac it just gone no LED i do try press power button for 5 or 10 sec or 60 sec there is nothing boot up
can you help or figure this out please i don't hear any sound of explosive or smell like burnt capacitor... nothing

i got it fixed by throw FW_DR2800_1.0.14ww and FORCEUPD.txt in sd card on FAT32 formated and reinstalling FW_DR2800_50MBIT and i check my sd card have file debug.txt in that file we have "1609459633 check_for_mmc.sh detected" text i don't know what that mean it work now i'm testing on car

i got it fixed by throw FW_DR2800_1.0.14ww and FORCEUPD.txt in sd card on FAT32 formated and reinstalling FW_DR2800_50MBIT and i check my sd card have file debug.txt in that file we have "1609459633 check_for_mmc.sh detected" text i don't know what that mean it work now i'm testing on car


WIP: Validation

Add support for validation using the Visitor pattern.
Rules implemented:

[x] ExecutableDefinitions
[x] FieldOnCorrectType
[x] FragmentsOnCompositeTypes
[x] KnownArgumentNames
[x] KnownDirectives
[x] KnownFragmentNames
[x] KnownTypeNames
[x] LoneAnonymousOperation
[x] NoFragmentCycles
[x] NoUndefinedVariables
[x] NoUnusedFragments
[x] NoUnusedVariables
[ ] OverlappingFieldsCanBeMerged
[ ] PossibleFragmentSpreads
[ ] ProvidedNonNullArguments
[ ] ScalarLeafs
[ ] SingleFieldSubscriptions
[ ] UniqueArgumentNames
[ ] UniqueDirectivesPerLocation
[ ] UniqueFragmentNames
[ ] UniqueInputFieldNames
[ ] UniqueOperationNames
[ ] UniqueVariableNames
[ ] ValuesOfCorrectType
[ ] VariablesAreInputTypes
[ ] VariablesDefaultValueAllowed
[ ] VariablesInAllowedPosition

Pull Request Test Coverage Report for Build 300

3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 83.47%

Totals

Change from base Build 296:
0.006%

Covered Lines:
2232

Relevant Lines:
2674

💛  - Coveralls

Pull Request Test Coverage Report for Build 300

3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 83.47%

Totals

Change from base Build 296:
0.006%

Covered Lines:
2232

Relevant Lines:
2674

💛  - Coveralls

Closing this PR and breaking the changes into separate PRs.


Need to make MLST display like users are anticipating

For example, "MLST.Escherichia_coli_1.457" should display like "ST-457", as users are used to seeing, instead of the long concatenated string.
https://www.patricbrc.org/portal/portal/patric/Genome?cType=genome&cId=562.10576

Our naming scheme is slight deviation from the simple naming, i.e. ST-XXXX, but it is necessary as it helps us address the following issues without having the need to have multiple fields to capture all MLST related information, which would be even more confusing for the users.
All of the MLST databases used in PATRIC come from PubMLST. There are multiple MLST databases / typing schemes for some of the pathogens, each using different set of genes for typing as shown below. The database names we use come straight PubMLST, which includes pathogen name + typing scheme number. The prefix MLST was added intentionally to make it easier to search for genomes with MLST assignments.
Acinetobacter_baumannii_1
Acinetobacter_baumannii_2
Escherichia_coli_1
Escherichia_coli_2
Leptospira_spp
Leptospira_spp_2
Leptospira_spp_3
Pasteurella_multocida_1
Pasteurella_multocida_2
Streptococcus_thermophilus
Streptococcus_thermophilus_2
Vibrio_cholerae
Vibrio_cholerae_2


feat: add support for nullable objects.

@fulopkovacs you're a maintainer :) Approve and merge as you see fit!


[Bug] Reading Webtoons/Webcomics shows Black Screen on BlueStacks

Device information

Tachiyomi version: <IP_ADDRESS>
Android phone & version: BlueStacks v<IP_ADDRESS>9, 32-bit Android

Steps to reproduce

Download BlueStacks, 32-bit Android version
Install Neko, and open a Webcomics / Webtoons which has long vertical images.
Read a chapter. Upon opening it, you'll only a black screen and the images aren't loading even if you download the chapter.

Note: Manga which has a Left to Right reading settings doesn't have any issue.
Expected behavior
Read the webcomics / webtoons
Actual behavior
Black Screen
Other details

I want to reduce my addiction on reading thus I wanted to reduce the devices I can use to read (e.g. Smartphone / Tablet) and limit Neko to my PC through BlueStacks, an Android App Player. While I could read directly from MD's website. I find the bookmark functionality lacking versus Neko's bookmark feature.
Screenshots

Is this still an issue?

I'm not sure if I can test right now while MD is down. I'll publish an update once there's a source to read on Neko.

Wait nevermind. I could test it right now, The issue seems resolved now with the latest updates on both Neko and Bluestacks

Love issues that fix themselves :smile:


global_route does not support its documented arguments

OpenROAD 719c6dc617d4b8d6896500bb41cdf057864f9e09

Issue:

global_route does not support its documented arguments, opting to show this error:
$ echo "global_route -verbose 3" | openroad -exit
OpenROAD v2.0-2364-g719c6dc61
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.
[ERROR STA-0406] global_route positional arguments not supported.
STA-0406

Probable Cause: https://github.com/The-OpenROAD-Project/OpenROAD/commit/110c23c2565b07e460c4f4ab7d3cd4e68ddfd5f7

Reproducible:

echo "global_route -verbose 3" | openroad -exit

Critical for OpenLane, btw

@donn I've updated the -verbose option to be a flag. We don't have the levels now, that's why you have the failure. I've created a PR updating the -verbose documentation.

Thanks. I've updated the invocation


chore(docs): Fix link in the Data Types page

Description
Problem*
Existing link in the Data Types page to the generics page opens https://noir-lang.org/assets/files/generics-ff7aa43d69e6cca523a1f2e74064a062.md in a separate tab, instead of the page in the docs.
1. Click:

2. Opens:

Summary*
Fix link to relatively redirects to the generics page.
Documentation*
Check one:

[x] No documentation needed.
[ ] Documentation included in this PR.
[ ] [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

[ ] I have tested the changes locally.
[ ] I have formatted the changes with Prettier and/or cargo fmt on default settings.


Discussion: interesting task-queue usage

So I was reviewing Aurelia code for #12 and this piece of code, found in repeat.js got me thinking:
handleInnerCollectionMutated(collection, changes) {
  // guard against source expressions that have observable side-effects that could
  // cause an infinite loop- eg a value converter that mutates the source array.
   if (this.ignoreMutation) {
    return;
  }
  this.ignoreMutation = true;
  let newItems = this.sourceExpression.evaluate(this.scope, this.lookupFunctions);
  this.observerLocator.taskQueue.queueMicroTask(() => this.ignoreMutation = false);
   // call itemsChanged...
  if (newItems === this.items) {
    // call itemsChanged directly.
    this.itemsChanged();
  } else {
    // call itemsChanged indirectly by assigning the new collection value to
    // the items property, which will trigger the self-subscriber to call itemsChanged.
    this.items = newItems;
  }
}

I understand the objective here but it doesn't feel right to me.
First it doesn't protect against all circular changes. Because if a computed property is in the cycle this won't work, as the computed property itself will be queued after the ignoreMutation reset.
Second, the problem at hand is not unique to this binding. In fact any code might trigger an evaluation that may have side effects that may create a cycle. Cycles in the dependencies are coding errors but they are sometimes unintended and it's good to have some protection against them. But I feel like the code above is too narrow and specific enough. To quote the comment: any binding can have a value converter.
Random thought: what about limiting the number of iterations in the micro-task loop?

I agree- a value converter that produces side-effects is a coding error.
The block of code you referenced is to protect against a common mistake where the value converter implementation looks like:
toView(array) {
  return array.sort(...);
}

I think limiting the number of iterations in the loop is a good idea, in the sense that it will make the system "fail fast" rather than hang the browser. It would not be a recovery mechanism due to the perf and bug-masking issues it would cause. Failing to fully flush the task-queue is a fatal error imho.
@EisenbergEffect thoughts?
@jods4 if you have some ideas on how the flush iteration cap might be implemented a PR is always appreciated

@jdanyow I certainly want to help developers avoid errors and fail fast is a good characteristic. Do you have some ideas on what you would change?

I don't- was just saying to @jods4 that I liked the idea of having a cap because it would be a "fail fast" instead of "hang".  Either way it's a fatal error.
@jods4 can this be closed or are you working on a change for this?

When I have some time I might tackle the task queue issues in #12. I think that would be the right place to implement an iteration limit.
Not sure if you want to keep this issue open/linked or close it.
If we add an iteration limit to the task queue it would be good to remove code such as this one, although it would be difficult to find its occurrences.

@jods4 any updates on this- should we keep it open?

@jdanyow as I wrote in #12, I got caught in work and was too busy to work on this :disappointed:
I am traveling for 1 month so don't expect any PR from me any time soon.
This ticket is not critical so feel free to keep it open or close it as you see fit. As I wrote above it would probably be a good idea to implement such an iteration cap into the task queue itself, which could be done at the same time as the work suggested in #12.

Closing for now since it's not critical. If issues arise in the future, we can revisit.


openocd/digilent-arty: use existing digilent-hs1.cfg as programmer

The programmer definition was a copy of the digilent-hs1 programmer, so replace
this with sourcing the programmer definition file.

this should be equivalent, but still better test this before merging

Happy to merge if someone can confirm it still works....

It seems that openocd also tries to match the product names which are slightly different. So this patch will likely break the openocd support for the arty.


Light sync state needs a proper format

The sync_state_genSyncSpec RPC call can be used in order to dump the current finalized state of the chain. This state is commonly called a "checkpoint". This is currently used by smoldot in order to have a starting point for syncing, so that it doesn't have to sync from scratch.
Unfortunately, this was sloppily implemented.
Code can be found here: https://github.com/paritytech/substrate/blob/b9927cdca03830d07bc1cdd8b8d80a3d32f64bd1/client/sync-state-rpc/src/lib.rs#L132-L178
We literally just copy some SCALE-encoded blob into the chain spec. The SCALE-encoded blob use internal data structures of Substrate, such as EpochChanges.
This means that any modification to the EpochChanges struct or its children structs modifies the format of the checkpoints and requires an update on the smoldot side (or any other piece of code that would want to decode checkpoints).
This happened for example in https://github.com/paritytech/substrate/pull/9284, which modifies this struct. Since it's not hinted anywhere that modifying this struct will break things, it is easy to accidentally do it.
An additional problem is that this blob contains a lot of data that is completely unnecessary. Checkpoints should only contain the minimum amount of information necessary to sync from the current finalized block, whereas right now it also contains all the upcoming epoch changes in all non-finalized forks.
Instead, we should properly define what information is found in these checkpoints, and simplify them.

we should properly define what information is found in these checkpoints

To give an idea, these are the data structures that smoldot uses for a checkpoint:
https://github.com/paritytech/smoldot/blob/4da02f21a6278f100153d2878756a19bdfb216f2/src/chain/chain_information.rs#L121-L333

Sounds very interesting definition to me, in the sense that it would be nice that we have a single encoding output and a way to associate a unique hash to such state.
Then of course being able to provide merkle proof for the different elements would be nice (I don't know serialization that support this, but sounds quite interesting thing to do, attaching merkle proof to scale surely would be fun, but being realistic just something similar to a chain block (hash of hash a few bigger content) would work).
The smoldot checkpoint looks good (three content: block production, block finalization and state).
Also I think this could be interesting for full client too, so maybe something a bit generic (array of extension/subsystems), which make me think a binary serialization with schema would be good, but having a versioning of the different components should be enough.
IIRC implementing this in substrate may be a bit of work (I remember previously that a bit of grandpa history was needed due to implementation, may have be lifted by recent changes), but probably worth doing anyway.

a binary serialization with schema would be good

This is a bit nit-picky, but JSON makes sense to me. Performance for parsing this doesn't matter, and our chain specs are already in JSON. There's no need to make it more complicated to read than it already is.

My not JSON is not so much about perf (even if I enjoy compactness), more about having unique hash for the same set of info.
Certainly a good formatting rules can work here, or using another format from the json to achieve this goal.
I like this idea of unique hash to be able to build some trust around the snapshot (a bit like srtool for binary).
Also it might actually be a bit optimistic from my part to consider that for a finalized block the snapshot content can be restricted to a unique information set.

Note that if we instead provide runtime entry points that allow retrieving the consensus-related information, we could also only provide a finalized block header or even just a finalized block hash.

I can not really follow what you are talking here about @cheme. I mean you can just hash the file and get a unique hash? Or what kind of unique hash do you want to have?

I can not really follow what you are talking here about @cheme. I mean you can just hash the file and get a unique hash? Or what kind of unique hash do you want to have?

I was targeting a unique snapshot hash for a state, (not unique hash for a encoded snapshot): having a single valid snapshot hash for a given block. So unique set of info at a state (may not be achievable), and unique encoding for this set of infos (so encoding would not allow different ordering of infos, not allow additional spaces...).
But in fact it may be something better abstracted from file format (for state there is already header -> state root that does the job).

What would be the purpose of that hash?
Slightly unrelated: a maybe controversial question is whether to include information about Babe in the checkpoint.
Strictly speaking, you could retrieve GrandPa and Babe information from the chain and the checkpoint would just be a finalized block header (or even hash). The problem with doing that is that you need to find a node that hasn't pruned the storage of that finalized block, otherwise you can't retrieve them.
If you use warp syncing, then you need the GrandPa info of the starting point in order to verify the warp sync proof, but you don't need the Babe information because the warp sync will bring you to a block that hasn't been pruned and you can retrieve this Babe info from the chain.

What would be the purpose of that hash?

Only use case I got in mind is trusted users signing the hash (of course you can sign if there is multiple hash, but it creates possible issues or less convergence if multiple signing are done on different hash: generally with a single snapshot builder everyone can ends up on same hash, but it sounds less good).
Probably a way to skip on usual proof check (but one idea could be to have the warp sync proof attached to snap and check babe content on import), out of the efficiency reason, some may have more confidence in trusted peers than past history of validators signing for more or less rational reason.
In other word if you got two snapshot providers (trusted through https), you know both snaps are containing the same content without having to look inside.
The babe question sounds tricky, I would attach it.
It would not make sense to me to first download a trusted snapshot and then having to download additional content atop of it.
Still a use case could be to download a snapshot in order to warpsync from it afterward. Then no need for it.
I would certainly propose to make an optional snapshot subcomponent (either attached or just its hash (if hash of all subcomponents is snapshot hash) or just not here), but I already did and conclude it may be a wrong direction :)
Probably the size of babe state is not worth skipping.

This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/community-bootnodes-and-snapshot-providers/630/1


Different class names when rendering on client vs server

I'm trying to add SSR to a project based on Create React App. On my backend I got it to render the correct CSS by using this babel plugin and adding ssr: true to my .babelrc file, but now the class names are not the same as when they're client rendered.
I'm using the newest version 2.0.0 on both the client and server, but since I haven't ejected CRA, I can't add a babel loader to it and I'd prefer not to eject.
The client class names has a sc- prefix and looks like sc-bdVaJa jfEfSr, while the server rendered ones do not and also have different hashes.
Is this possible to fix? And should it be? I'm thinking now that having two different ways of transpiling my code on the client and server will lead to trouble in other places eventually. But I'm also curious as to why the hashes are different, I'm guessing this plugin handles it differently than the main styled-components does?

You need to apply the same transformation to client and server files, assuming the files are not universal :) otherwise the client is not going to have the same data attached to it to render with the same className


Add android export error on invalid package name

Fix for https://github.com/godotengine/godot/issues/7877
These changes provide package name validation. Shows an error on unacceptable package name that causes a package parsing problem. The validation pattern base on https://developer.android.com/studio/build/application-id
Some example screenshots:

Perhaps the error message could be a little more descriptive? It'd be nice if the user had some indication of what to fix about the package name. Even if that involved just linking them to https://developer.android.com/studio/build/application-id (but I don't think that's a good idea)

That also fixes part of #23172, we should probably list all other properties that need to be validated.

@LikeLakers2 Ok, I've added more informative error messages, Android Studio users should be familiar with those errors.

@akien-mga Yeah, it'd be nice to see a robust export form for each platform, thanks for linking the related issue.

@lethiandev Looking through the changes, those error messages seem fairly reasonable. I approve. :) That should make it a lot easier to know what's wrong with the package name.
That said, I noticed you used $genname in the gif, and the error about the $ disappeared. Does $genname get replaced with something else?

@LikeLakers2 Yes, $genname is replaced by the get_package_name function, it's just stripped version of the Name's field under the Unique Name one. If the field is empty, it's "noname" instead.
I copied messages direct from the Android Studio IDE, someone familiar with AS can feel like at home.

Thanks!

Now that Godot 3.1 has been released, we don't plan to cherry-pick new features and enhancements to the 3.0 branch, unless there is very strong support in favor of it. Removing cherrypick label for 3.0.


Add files via upload

Added association-move-arrow.png to help with the explanation of https://github.com/mendix/docs/edit/development/content/refguide/associations.md

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


chore: decouple optional and required properties for a container

This simple PR decouples the optional properties of a container from the required ones.
Rationale:
We use this library in combination with CDK's capabilities to handle compiling, bundling and uploading images to ECR. In which case we expect our users to provide all other properties of a container but the image property which is abstracted away.

@iliapolo any eta for a review?

Hi @iliapolo,
ContainerOpts can be used by a downstream library to provide high-level constructs that handle the lifecycle of a docker image, therefore the end-user will not need to pass image as a property but might still be configuring other aspects of the container (eg, resource allocations, env vars, etc)
Take this example taken from one of our internal libraries.
The construct handles all the complexity of producing an asset directory with a Dockerfile, and then uses CDK's capabilities of uploading the asset to an ECR registry.
A user of our library still might want to configure other properties of the container.
As you can see it'd be confusing to require a ContainerProps since the user will be forced to pass something for image
/**
 * Properties for DotnetDeploymentApplication
 */
export interface DotnetDeploymentApplicationProps {
  readonly containerOpts?: ContainerOpts;
}

/**
 * Creates a single-deployment dotnet application
 */
export class DotnetDeploymentApplication extends Construct {
  /**
   * The image asset location used by the deployment's main container
   */
  public readonly imageAssetLocation: DockerImageAssetLocation;

  constructor(scope: Construct, id: string, props: DotnetDeploymentApplicationProps) {

    const chart = new Chart(new App(), 'App Chart');

    // This pseudo-function compile and bundles some code, and creates a CDK image asset
    // returning a `DockerImageAssetLocation` class
    // CDK will then handle the creation of the docker image and uploading to ECR.
    // The image location will then be known at deploy-time
    const image = DotnetBundling.getImageLocation(this, ...props);

    // Provision a deployment
    const deployment = new kplus.Deployment(chart, 'Deployment');

    // Use provides all properties of the main container except for the image property
    deployment.addContainer({
      image: image.imageUri,
      ...props.containerOpts,
    })
  }
}

💚 All backports created successfully

Status
Branch
Result

✅
k8s-24/main

✅
k8s-25/main

Questions ?
Please refer to the Backport tool documentation


Don't propose updates to a more precise version of the same docker tag

This change allows us to avoid unwanted PRs like the one reported at #6746.
I took the chance to clean things up a bit and extract a Dependabot::Docker::Tag class that holds information about a Docker tag and how it maps to numeric versions.
Fixes #6746.

You're right. I think it's best to ship the fix ourselves now to not depend on upstream plans/fixes/improvements, but we can leave a TODO for a future logic removal, once we verify that this particular registry API implementation is finally providing proper digests that we can use?

Another consideration is that last time I looked at Registry API v2 docs, providing content digests was optional, so maybe we can keep the logic regardless to satisfy registries that choose to not implement it.

Maybe just add a NOTE pointing to this discussion and to the Redhat announcment so that future devs have the relevant context if they're working on a bugfix of some kind in that section of code that they're aware they may be able to delete it altogether, and then call it good for now?


Remove provided optional configs

This PR removes usages of the PropDeps plugin from Gradle. As a result, provided and optional configurations have been removed. All previously referenced dependencies in these configurations have been updated to be listed under either api, implementation, or compileOnly.

The conversion of 'provided' dependencies to 'api' is based on (my understanding of) what Gradle expects an 'api' dependency to be. In this case, I understood it as "If you want to compile code that is going to use the public API for this, you will need this library as well since it is exposed through the API."
For MR, this means you need to have Hadoop on the compile classpath because you'll be interacting with input and output format classes that extend, expect, and return Hadoop classes.
For Spark, this includes the Spark frameworks since interacting with ES-Hadoop will require you to pass your Spark Contexts/RDDs/Dataframes to the library.
Hive and Pig is where these things get fuzzy. You don't write Java for Hive or Pig. Instead you are writing a parsed query language. For this reason, I took the approach of "If you were to build a library for those integrations that depended on ES-Hadoop, which things would need to be API dependencies?"
For that, I landed at the Hive and Pig dependencies that we use as inputs and outputs from what might be reasonably considered the API of the project (the input and output formats), though even that may be considered somewhat dodgy. I'm open to feedback on it for sure.

I understood it as "If you want to compile code that is going to use the public API for this, you will need this library as well since it is exposed through the API."

This is a correct understanding. The difference between api and provided is how the consumers runtime classpath is affected. An api dependency is effectively <scope>compile</scope> which means it will be on the compile and runtime classpath of the downstream consumer. Using provided the dependency is only on the compile classpath, and it's expected that the runtime environment will have this available already somehow.

For that, I landed at the Hive and Pig dependencies that we use as inputs and outputs from what might be reasonably considered the API of the project (the input and output formats), though even that may be considered somewhat dodgy.

If I'm not writing Java code that uses an API then this isn't an API dependency. These dependencies are "inputs" but they are runtime. That is, if the dependency changes, I don't need to recompile anything, but runtime behavior might change. At least that's how I understand how you're describing it. In any case, the implementation vs provided distinction remains. Using provided means we aren't telling consumers to put this on their runtime classpath. Now we are. Maybe that's ok?

I've made some changes to this - converted the specifications for most of the dependencies to implementation instead of api. The remaining api dependencies are for the Hadoop client in the mr project, the core Spark library in the spark projects, and the Storm API in the storm project. For the uberjar/uberpom we release, these have all been converted to implementation instead of api, which translates them to runtime in the pom that is created. This should keep the dependencies pulled into downstream projects for compilation to a minimum, mostly dependencies that downstream projects will already be depending on for compilation.

All previously referenced dependencies in these configurations have been
updated to be listed under either api, implementation, or compileOnly.

Relates #1423

i dont understand anything about gradle scopes, so i might be a little ignorant about what is happening here... but i know the standard is to have spark dependencies be provided in poms and i would expect such. e.g if you build a project that runs on spark you build an assembly jar (or equivalent) that should not include spark itself (it can be a real nasty source of bugs if you do include spark).
so the poms that result from this change simply seem incorrect to me and i will work around it using exclusion rules and such.

@koertkuipers This change was made with the expectation that most Spark deployments use spark submit arguments to provide the jars for execution of a job rather than repackaging all dependencies into a single distributable. We went down this path with the thought that if users were creating a single distributable, they'd be taking a more direct approach to their build process and thus shouldn't have too much a problem excluding spark as a runtime dependency from the ES-Spark library. Happy to discuss the issue further though if this is causing usability concerns for you.

hi @jbaiera
it is not clear to me how using spark submit arguments to provide the jars for execution would make it ok for spark itself to be a compile/runtime dependency?
i do not use this method of adding jars, but i can think of 2 possible scenarios:

when adding jars with spark-submit (transitive) dependencies are also included. in this case it is not a good idea to pull in spark itself as a (transitive) dependency. spark jars are added to class-path by spark-submit already.
when adding jars with spark-submit (transitive) dependencies are not included. in this case having spark itself as a dependency doesn't do any good either.

what is the scenario where having spark as a compile-time/runtime dependency is useful?

what is the scenario where having spark as a compile-time/runtime dependency is useful?

Going off what I remember from April, the driving force for this change was 2-fold: ES-Hadoop was being updated to better comply with Gradle's project modeling and the plugin that provided this functionality is a third party plugin that we have little to no control over. A lot of changes were happening in order to support cross compilation of Scala/Spark artifacts, and getting the community plugin that added provided and optional scopes to work with the changes we were making was becoming a maintenance nightmare.
At the time it seemed logical that a project depending on ES-Hadoop/Spark would already have defined Spark as a provided dependency, and thus having Spark as a compile time dependency of the library (which would end up transitive) would be relatively innocuous to the end-user project development environment.
As for the topic of deployments, my expectation at the time was that most deployments make use of the spark submit jar arguments to specify their dependencies. This was informed mostly from my experiences with the community over the years: Using the spark submit jar argument was the more common approach. Users who bundled their application and libraries together would just need to exclude Spark from that artifact. A small extra step.
With this line of thinking, we removed the plugin, set the scopes to what would be the most reasonable scopes Gradle could support out of the box, and moved on with our refactoring. Several months after this change though, I'm a bit more skeptical that the spark submit jar model of deployment is as ubiquitous as previously thought.
I'll open an issue for returning the dependencies to provided. I'm not sure how reasonable it would be to return the previously optional dependencies, which at the time was the Spark SQL libraries, as well as every integration library in the uberjar. Those would most likely make a return as provided if we went forward with that change.

@koertkuipers I've opened an issue for this https://github.com/elastic/elasticsearch-hadoop/issues/1541

@jbaiera thank you for that!
you are right that it is just a few extra excludes. i just did this yesterday. i started with making elaticsearch-spark simply an intransitive dependency in sbt, but then realized that such an approach cannot be expressed correctly in the POM file my project generates. so i ended listing all the elaticsearch-spark dependencies explicitly for exclusion. no big deal but a little fragile.
i prefer to keep spark and hadoop out of the compile/runtime scope completely at all times, since they are a bit of transitive kitchen sinks, which makes it to understand what the actual dependencies are that will be end up in the assembly/fat jar.


add object initializers

Currently there are 2 ways to enforce implementing an interface over an object:

creating a object literal in an interface type context
constructing an instance of a class that implements the said interface

In both cases we deal with a newly created object, however there are also situations when an already created object needs to be extended to comply to some more elaborate interface.
A good example are mixins and scenarios alike:
interface DoThis {
   x: any;
   y: any;
}
interface DoThat {
   z: any
}
interface DoBoth implements DoThis, DoThat {
}

function extend(doThis: DoThis): DoBoth {
    // need to make sure that all properties of DoThat are set
    // wish could do just
    //       doThis.z = undefined;
    //       return doThis;
    // have to do
    return {
        x: doThis.x,
        y: doThis.y
        z: undefined
    };
}

let doThis : DoThis = { x: undefined, y: undefined };
let doBoth = extend(doThis);

I am not aware how to make the extend function type safe, other than copying each field from doThis to the resulting object. Which might or might not be a solution (functions are harder to extend this way). If only TypeScript had a way to enforce an interface on the given object it would be very helpful.

type assertion?
function extend(doThis: DoThis): DoBoth {
    return doThis as DoBoth;
}

no, quite opposite
first off it will break if you do as you say
secondly, type assertion is taking responsibility for checking code off the compiler, whereas I am looking for opposite

the only thing i can think of other than type assertion would be to spread in the other object.
function extend(doThis: DoThis): DoBoth {
    return {
        z: undefined,
        ...doThis
    };
}

nice but what about primitives and functions in the doThis position?

Spread should be sugar for object.assign, so no non-enumrable and only own properties. Not sure if this is what you had in mind.

now as i read closer it looks like a solution

Object spread and rest is tracked by https://github.com/Microsoft/TypeScript/issues/2103

gonna need to reopen it
one more useful scenario
function initializeAsDoThis<T>(obj: T => DoThis) { // <-- possible syntax for object that needs to be initialized?
    obj.x = undefined;
    obj.y = undefined;
}
interface Foo {
}
class C implements DoThis  {
    constructor() {
        initializeAsDoThis(this);
    }
}

Spread should be sugar for object.assign, so no non-enumrable and only own properties. Not sure if this is what you had in mind.

spread operator is only useful at creating new objects, but for the cases where we deal with an existing object we can't use it

problem:
say we have 20 interfaces each with 10 properties
it's easy to manifest that a our class is going to implement all 20 of them

it's much harder to come up with a list of 20x10=200 declared/initialized properties of this class that currently need to be spelled inside the class (there is no way to take property declaration/initilization outside the class)
we cannot utilize inheritance for this because it's very unlikely that our class hierarchy has 20 ancestors classes that each implement one of those 20 interfaces
we cannot delegate property initialization to a sub routine (just like we can do in vanila JavaScript)

workaround: none, we have to declare and initialize 200 properties by hand
solution: with initilizers we could have 20 functions which we would call from the constructor, each initilizer would add 10 initialized properties of a corresponding interface, we need a way for TypeScript to acknowledge that these properties are there and the class should be considered fully initialized
use case:
i wish i could to do declaration and initialization of properties of a class outside of a class
i am proposing so
in a , because can you implement an interface on a class without explicitly declaring all properties?

definition:
object initializer - is a function/method with a parameter that has 2 types: in and out, at the call site the function expects a value of the in-type to be used as an arugument, after the function is called argument passed should be considered being of the out-type

so is this a different proposal for https://github.com/Microsoft/TypeScript/issues/8353?

I think it is different. Main difference is that rather than trying to
track all possible execution branches that might reassign a variable (which
makes it a very hard task) I am proposing a simpler task of enforcing a
type change within the immediate scope of a dedicated function without
accounting for anything might happen in a subroutine.
On May 12, 2016 7:47 PM, "Mohamed Hegazy"<EMAIL_ADDRESS>wrote:

so is this a different proposal for #8353
https://github.com/Microsoft/TypeScript/issues/8353?
—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/8545#issuecomment-218917157

we have talked about something similar proposals before; the main reason for aversion is complexity. once you mix in generics, these declarations become harder to read and understand.

You can achive something similar with Mapped Types and Partials, according to this StackOverflow answer.

@afnpires SO question is about different matters

@aleksey-bykov can you clarify which aspects (if any) can't be accomplished today?

yes please

you have an object a of type A
a gets passed to a foo function
after function is called the value a must be of type B

example:
type A = {}
const a: A = {};
type B { x: number; y: number };
function foo(a: {}): void { // <-- need syntax to express the effect
   a.x = 0;
   a.y = 0;
}
const b: B = a; // <-- works because `a` is of type `B` now after `foo` is called on it

the only way to accomplish it today is to use so-called "mixins" via classes (which is as ugly as my life) or hacking a to b using casting, whereas in vanila javascript code this pattern is natural and very popular (which is one of your goals - support idiomatic javascript), so here i am

Looking at that example I see either #10421 or #22865

i looked at them the second one is what i am taking about but i dont like the syntax, and besides this issue is 12000 issues ahead of that one

@lilezek yes please:
function initializeXY<T extends {}>(obj: T => T & {x: number; y: number;}): void {
   obj.x = 0;
   obj.y = 0;
}

@aleksey-bykov That's good for extending, but I think it can't be used for reducing an object:
const obj = {x: 15, y: 13};
delete obj.x; // Or a function that does the delete for you.

After the delete sentence you couldn't represent the type of the obj without a cast.

did you try this:
function initializeXY<T extends { y: unknown }>(obj: T => T & { y: never; }): void {
   delete obj.y;
}

Sorry, as I wrote in the edit in my comment: isn't that the actual syntax for functions?

functions require a list of parameters which has to be enclosed into parenthesis (value: number) => number or () => number whereas here we have T => T (observe no parameter list)

Yes, that's correct, but these are so similar I think that it would be easy to be confused between them. Anyway, if you want I can put your suggestion in my issue description as an additional option.

please do

Before I do I need first some description about how it would work with that syntax. For instance, if you want to convert something from string to be a number:
function normalizePhoneNumber<T extends {phone: string}>(obj: T => T & { phone: number }): void {
   obj.phone = parseInt(obj.phone, 10);
}

What type is obj inside the function? If it is {phone: string} & { phone: number } then that line will not pass TypeScript checks.

i agree, it might be easier to achieve by using 2 different identifiers, question of the balance of the price tag of this feature vs. happiness of the developers who tend to like typing less

on the second thought it might be more confusing to have a virtual identifier that has no meaning in the real code
unless typescript does code rewriting by replacing x2 by x which to my knowledge goes against its goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals
5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

also it can be a burden for developers to pick a name for that extra identifier, in my experience picking a meaningful name is 20% of my day job

I think your suggestion and mine are not comparable in size. While you use generics and that adds < T extends >, T => T &, and two types (the type before and the type after), mine adds then and two identifiers (with their types). So basically any of them can be bigger or smaller depending on the size of the types and identifiers.
On the other hand, I agree that having a second, virtual identifier, can be confusing and it might be even against TypeScript goals. I'll try to think about another suggestion without a virtual identifier, but I wouldn't go either to use generics + a syntax that is pretty similar to arrow functions, plus having a flow analyser which could be hard to implement and that I that is still undefined how it should work.
About choosing a name, you can choose an arbitrary style for the name of the second virtual identifier, such as x then xAfter or such.

generics are necessary because it's the way to generalize and express uncertainties and about your types, i can't see how you can go without them, you would have to reinvent them at some point or greately limit the scope of applicability of this feature
flow analysis is already implemented, we just need to make use of it
arrow syntax is already familiar to anyone who used callbacks

since the syntax concerns the types (not the JS expressions) it can be literally anything: =>,  ->, ::, >>, <!> etc

While I agree with everything you said, I don't see the uncertainty of types to need the use of generics. For instance, using the syntax I proposed (I use this one because I don't have yet a better option), the types here are exact and not uncertain:
interface Before {
  address: string;
}

interface After {
  addr: string;
}

function map(userb: Before then usera: After) {
   usera.addr = userb.address;
   delete userb.address;
}

You know exactly what must be the type and you know exactly what will it be after. And this could be mixed with generics if any of these types (the type before and the type after) are unkown:
function inlineMap<T,U>(arrayB: T[] then arrayA: U[], mappingFunc: (T) => U) {
  for (let i = 0; i < arrayB.length; i++) {
    arrayA[i] = mappingFunc(arrayB[i]);
  }
}

problem is that in my use cases i don't know much if anything at all about what objects will be passed into my initializer function
think of the mixin pattern, i want to turn my very own object into something that has x and y properties and able to be manipulated by changing them
Before and After in your example are cute but what if i need the same addr / address behavior applied to something else?
my point is that Before should be rather a generic, because you have no idea upfront what it will really be

your last example is not going to work without generics because T and U as declared (bare generics) have nothing to do with having { addr: } or any other props

besides say you have
interface Circle { x: number; y: number; r: number; }
interface Line { x1: number; x2: number, y1: number, y2: number; }
interface Box { ... }
interface Triangle { ... }
interface Star { ... }
interface NGon { ... }

now i want to add color to all/any of them, according to you i need to a special function for each single type of object
now i want to add label to all/any of them, again i need a special function for each single type of object
it's just silly

You don't need 10 callbacks. I think I'm using the generics as they are being used in the definitions of TypeScript for arrays:
interface Array<T> {
  map<U>(callbackfn: (value: T, index: number, array: T[]) => U, thisArg?: any): U[];
}

And with the proposed syntax example, if you want to add colour to all of them you could just do:
function addColour<T extends {}>(primitive: T then primitiveWithColour: T & {colour: string}, colour: string) {
  primitiveWithColour.colour = colour;
}

this feature has to be build around generics, generics are the main use case, the main use case calls for prime time support from the language, using non-generics would be a special case
10 callbacks are necessary if you don't want to deal with extends, i can give you an example but too lazy to write it, if extends is not a problem then 10 callbacks are not required

Why it has to be built around generics? They can be used, but I don't see the need for mandatory usage of generics if you know exactly the type before and the type after the change.

i didn't say generics are mandatory, all i said that generics is the main use case while specific types is a special case, and the reason i brought it up is that syntax is should rather be favoring the main case, not the specific case

This doesn't come up often enough to justify the investment necessary to create this behavior


Move some image related methods & struct to smaller files

daemon package is huge and some files in there are quite big. I've started to split some of them in smaller piece but the changeset went quite big really fast, so I'm doing smaller PR to make the review quicker (and thus provoke the less conflict case for other PRs) 🐙.
This one just moves around some methods and struct related to images to smaller files. This is just moving things around (no modification in code), but I feel with more small files and focused files, reviewing, changing will be easier on daemon package.
/cc @runcom @thaJeztah @calavera @LK4D4
🐸

:heart: love it!

LGTM

LGTM ping @LK4D4

LGTM


build(lockfile): add lockfile=3 gate

Copied from coveo/cli, migrated to ESM, workflow adapted to fit in ui-kit existing workflow.
https://coveord.atlassian.net/browse/KIT-2502

@louis-bompart How about (as a followup even) prevent any local updates to pkg lock file (with lint-staged) and only update it in CI. That will ensure that the correct version is used and also the lock file hasn't been inadvertently deleted and regenerated leading to issues?

@louis-bompart How about preventing any local updates to pkg lock file (with lint-staged) and only update it in CI. That will ensure that the correct version is used and also the lock file hasn't been inadvertently deleted and regenerated leading to issues?

Mh, I'm really not found of that, it reverse on its head the meaning of a lockfile (they are mostly meant to ensure a ci install the exact same deps as the user machine), and adding dependencies would become a real pain.


Add category filter for export CLI command

Based on the following blog post:
https://forum.shopware.com/discussion/36424/advanced-import-export-artikelexport-ueber-konsole-nur-bestimmte-kategorie

Hi @balux
thanks for your contribution! I created a ticket for your PR, so we could test it within our workflows:
https://issues.shopware.com/#/issues/PT-6365

Hi @balux
your PR ist merged with 58c87d2e655818a2c5ba2abc80d607beeba4aa6f
Thanks!


Fixes fatal error on campaign collections signup flow.

What's this PR do?

Fixes fatal error on campaign collections signup flow.

Where should the reviewer start?
Read #5433
How should this be manually tested?

Open http://dev.dosomething.org:8888/volunteer/grandparents-gone-wired
Signup for it
Make sure this error doesn't appear:

Any background context you want to provide?
Context: dosomething_signup_get_mbp_params() works both for translatable campaigns and not translatable campaign collections. The changes in #5153 (this line) assumed that normal node title is always replaced by translatable field_title, which is just not the case for campaign collections.
So access to unknown title_field in wrapper caused this:

EntityMetadataWrapperException: Unknown data property title_field. in EntityStructureWrapper->getPropertyInfo() (line 335 of /var/www/dev.dosomething.org/html/profiles/dosomething/modules/contrib/entity/includes/entity.wrapper.inc).

and
exception 'EntityMetadataWrapperException' with message 'Unknown data property title_field.' in /var/www/dev.dosomething.org/html/profiles/dosomething/modules/contrib/entity/includes/entity.wrapper.inc:335

What are the relevant tickets?
Fixes #5433.

cc @blisteringherb @DeeZone

:+1:  nice find
is this something we will want to abstract into a helper function eventually?

@angaither Not sure. I think eventually we will have all content types translatable. I'll create an issue to think about it though.


Remove the use of SubscriberPtr and SubscriptionPtr

The smart pointers were protecting us from sending 2 terminating signals, mostly. We don't have that requirement now so we can remove them.
Please verify:

circular dependencies are taken care of
lifetime of instances while executing the methods is taken care of.

Once done, remove the smart pointers from the ReactiveStreams library.

done.


Configure repositories etc. via a config file

Looks great to me, thank you @jwodder !  I will merge and give it a try later on (after moving config out etc).


能设置宽屏页面么?

Is your feature request related to a problem?
左右空白较多，能添加宽屏按钮么？

Describe the solution you'd like
左右空白较多，能添加宽屏按钮么？

Additional context
No response

I hope to make the middl

e bar a little wider, but now the screens are relatively large, looking a little smaller.

It would be awesome if we could get a wider memos on wide screens

The latest demo site(https://demo.usememos.com) has been updated with relevant layout to work better on wide screens. You guys can try it out and give some feedback! @star2k @jifeiyun @salvoza

The latest demo site(https://demo.usememos.com) has been updated with relevant layout to work better on wide screens.  最新演示网站( https://demo.usememos.com) 已更新相关布局，以便在宽屏上更好地运行。你们可以试一试并提供一些反馈意见！@star2k @jifeiyun @salvoza

The latest demo site(https://demo.usememos.com) has been updated with relevant layout to work better on wide screens.  最新演示网站( https://demo.usememos.com) 已更新相关布局，以便在宽屏上更好地运行。你们可以试一试并提供一些反馈意见！@star2k @jifeiyun @salvoza

How to achieve your effect?

@star2k It will be updated in the next release.


fix: Try to convert a static list into a set in rust

Which issue does this PR close?
Closes #183
Rationale for this change
Leverage InSet optimization and improve performance.
What changes are included in this PR?

use datafusion's in_list function to create an InListExpr
optimize use group to make all the datafusion::physical_expr's items into a same group

How are these changes tested?
Existing tests.

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

Project coverage is 33.28%. Comparing base (488c523) to head (20c67df).

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #184      +/-   ##
============================================
- Coverage     33.29%   33.28%   -0.01%
  Complexity      766      766
============================================
  Files           107      107
  Lines         35385    35385
  Branches       7658     7658
============================================
- Hits          11781    11779       -2
- Misses        21157    21158       +1
- Partials       2447     2448       +1

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

Merged, thanks


Uninitialized variable fix for ISNUMERIC function with varchar and nvarchar arguments

Description
This change addresses a bug about the incorrect behavior of the ISNUMERIC function in Babelfish when handling string variables (NVARCHAR and VARCHAR).
Currently, production Babelfish instances (specifically PostgreSQL 16.2 on aarch64-unknown-linux-gnu (Babelfish 4.1.1)) incorrectly handle the ISNUMERIC function for string variables (NVARCHAR and VARCHAR), returning 0 (false) for valid numeric string representations. With this change, ISNUMERIC will correctly return 1 (true) for valid numeric strings, aligning its behavior with SQL Server.
The issue stemmed from an uninitialized variable typmod containing garbage values, which impacted the behavior of the numeric_in function, invoked by the varchar2numeric function.
In the production instances, the typmod variable, happens to point to an incorrect positive garbage values, bypassing the is_valid_numeric_typmod check, trickling down into an error. The change adds two arguments to the numeric_in call made in varchar2numeric, namely OID (Elem Type) and TYPMOD, which are then used to initialize the variables in numeric_in to default values, ensuring that no garbage values are used. It was also observed that numeric_in is invoked similarly with three arguments in other functions such as cstring_to_numeric, fixeddecimal_numeric etc, except this particular function.
Test cases test ISNUMERIC with varchar/nvarchar variables, invoking varchar2numeric. Existing test cases babel_isnumeric, babel_isnumeric-vu-verify already cover various other data types and scenarios: numeric data types and string literals.
Issues Resolved
BABEL-5129
Test Scenarios Covered

Use case based -

-- Test varchar
SELECT ISNUMERIC(varchar_type)
FROM babel_5129
GO
~~START~~
int
1
~~END~~

-- Test varchar variable
DECLARE @v varchar(20);
SELECT @v = '12.3420000000';
SELECT ISNUMERIC(@v), LEN(@v), DATALENGTH(@v)
GO
~~START~~
int#!#int#!#int
1#!#13#!#13
~~END~~

-- Test nvarchar
SELECT ISNUMERIC(nvarchar_type)
FROM babel_5129
GO
~~START~~
int
1
~~END~~

-- Test nvarchar variable
DECLARE @nv nvarchar(10);
SELECT @nv = '12.3420000000';
SELECT ISNUMERIC(@nv), LEN(@nv), DATALENGTH(@nv)
GO
~~START~~
int#!#int#!#int
1#!#10#!#10
~~END~~

Boundary conditions -

-- Test empty varchar variable
DECLARE @v varchar(20);
SELECT @v = '';
SELECT ISNUMERIC(@v), LEN(@v), DATALENGTH(@v)
GO
~~START~~
int#!#int#!#int
0#!#0#!#0
~~END~~

-- Test empty nvarchar variable
DECLARE @nv nvarchar(10);
SELECT @nv = '';
SELECT ISNUMERIC(@nv), LEN(@nv), DATALENGTH(@nv)
GO
~~START~~
int#!#int#!#int
0#!#0#!#0
~~END~~

Negative test cases -

-- Test varchar variable with invalid numeric
DECLARE @v varchar(20);
SELECT @v = '12.34.20000000';
SELECT ISNUMERIC(@v), LEN(@v), DATALENGTH(@v)
GO
~~START~~
int#!#int#!#int
0#!#14#!#14
~~END~~

-- Test nvarchar variable with invalid numeric
DECLARE @nv nvarchar(10);
SELECT @nv = '12.34.20000000';
SELECT ISNUMERIC(@nv), LEN(@nv), DATALENGTH(@nv)
GO
~~START~~
int#!#int#!#int
0#!#10#!#10
~~END~~

Minor version upgrade tests -

Major version upgrade tests -

Performance tests -

Tooling impact -

Client tests -

Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.416%

Totals

Change from base Build<PHONE_NUMBER>5:
0.0%

Covered Lines:
44885

Relevant Lines:
60316

💛  - Coveralls