Add CI Integration section + MegaLinter in README :)

All is in the title :)
Checklist
Not all of these might apply to your change but the more you are able to check
the easier it will be to get your contribution merged.

[x] CI passes
[x] Description of proposed change
[x] Documentation (README, docs/, man pages) is updated
[ ] Existing issue is referenced if there is one
[ ] Unit tests for the proposed change

I guess you might interested to support this project more than others. If that's correct, then I bet you want to be aware of  https://github.com/mrtazz/checkmake/issues/44

@abitrolly I'm already drowning with MegaLinter maintenance :)
But if MegaLinter users report issues or improvement ideas about CheckMake, i'll make sure to redirect them here :)

Ox Security is a startup and is already founding..... MegaLinter (so me !) , so open-source support is already in their expenses :D ( MegaLinter was an independent project before ^^ )

Right. This is what I am saying. Your investors want to be sure that your dependencies will not fall apart once you are out in the market.

thanks for the contribution!


Feat/rlp fsm

Description
This PR is meant to implement a new RLP circuit which make it easier to support new tx type.
The design doc is located at here
Issue Link
[link issue here]
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Contents

[x] rlp circuit constraints
[x] rlp circuit witness gen

Rationale
[design decisions and extended information]
How Has This Been Tested?

This PR cannot be merged before we make the final decision on how we impl the rlpEncode(tx) function. For more details, please refer to https://github.com/scroll-tech/zkevm-circuits/issues/515#issuecomment-1566513645.

@noel2004 Can you update the tx_l1_fee gadgets according to the change of rlpEncode?

Yeah, I agree with that. I have turned off the tx_l1_fee unit tests in evm circuit (as they are failing after I modify how we calculated the tx_data_gas_cost)

@lispc This PR is ready for merge.

disabling tx circuit in super circuit seems not good.  I would prefer other solutions
(1) wait for tx circuit, then merge this new rlp and tx in one single PR
(2) adjust this PR so it contains only new rlp implementation but will not remove old codes. Super circuit remain unchanged, namely new rlp circuit is only added but not "enabled".

Ok. I will push the updates to tx_circuit in this PR later and re-enable the tx_circuit.


Tags twitch around inside tooltip.

https://user-images.githubusercontent.com/3865976/103418285-a191fc80-4b53-11eb-8a2f-b6cdc1274fca.mp4
This also occurs with simple things, like vanilla wheat, with the same collection of mods. Minecolonies seems to be the primary source of most of the tags in question, so if you want an easy way of testing, I'd suggest grabbing that mod.
# Configure the options below to one of the following: disabled, enabled, onShift, onDebug or onShiftAndDebug
[tooltip_options]
	# Configure tooltip for burn time.
	burnTimeTooltipMode = "disabled"
	# Configure tooltip for registry name. E.g. minecraft:stone
	registryNameTooltipMode = "enabled"
	# Configure tooltip for NBT data.
	nbtTooltipMode = "enabled"
	# Configure tooltip for translation key. E.g. block.minecraft.stone
	translationKeyTooltipMode = "disabled"
	# Configure tooltip for max stack size.
	maxStackSizeTooltipMode = "disabled"
	# Configure tooltip for tags. E.g. forge:ingot, minecraft:planks
	tagsTooltipMode = "enabled"
	# Configure tooltip for durability.
	durabilityTooltipMode = "disabled"
	# Configure tooltip for hunger and saturation.
	foodTooltipMode = "disabled"

-- System Details --
Details:
	Minecraft Version: 1.16.4
	Minecraft Version ID: 1.16.4
	Operating System: Windows 10 (amd64) version 10.0
	Java Version: 14.0.2, AdoptOpenJDK
	Java VM Version: OpenJDK 64-Bit Server VM (mixed mode, sharing), AdoptOpenJDK
	Memory:<PHONE_NUMBER> bytes (3473 MB) /<PHONE_NUMBER> bytes (8192 MB) up to<PHONE_NUMBER> bytes (8192 MB)
	CPUs: 8
	JVM Flags: 10 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx8192m -Xms8192m -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M
	ModLauncher: 8.0.6+85+master.325de55
	ModLauncher launch target: fmlclient
	ModLauncher naming: srg
	ModLauncher services:
		/mixin-0.8.2.jar mixin PLUGINSERVICE
		/eventbus-3.0.5-service.jar eventbus PLUGINSERVICE
		/forge-1.16.4-35.1.28.jar object_holder_definalize PLUGINSERVICE
		/forge-1.16.4-35.1.28.jar runtime_enum_extender PLUGINSERVICE
		/forge-1.16.4-35.1.28.jar capability_inject_definalize PLUGINSERVICE
		/accesstransformers-2.2.0-shadowed.jar accesstransformer PLUGINSERVICE
		/forge-1.16.4-35.1.28.jar runtimedistcleaner PLUGINSERVICE
		/mixin-0.8.2.jar mixin TRANSFORMATIONSERVICE
		/forge-1.16.4-35.1.28.jar fml TRANSFORMATIONSERVICE
	FML: 35.1
	Forge: net.minecraftforge:35.1.28
	FML Language Providers:
<EMAIL_ADDRESS>		minecraft@1
	Mod List:
		CraftPresence-Forge-1.16.3-Release-1.7.5.jar      |CraftPresence                 |craftpresence                 |1.7.5               |DONE      |a8:61:b7:97:9b:6f:d3:ba:38:d8:ce:45:6c:4b:8d:fd:ea:84:dd:d1:09:46:5d:5a:4f:c5:03:91:b5:c0:bc:de
		astralsorcery-1.16.4-1.13.8.jar                   |Astral Sorcery                |astralsorcery                 |1.16.4-1.13.8       |DONE      |NOSIGNATURE
		TrashSlot_1.16.3-12.2.1.jar                       |TrashSlot                     |trashslot                     |12.2.1              |DONE      |NOSIGNATURE
		pamhc2trees-1.16.3-1.0.0.jar                      |Pam's HarvestCraft 2 Fruit Tre|pamhc2trees                   |1.0.0               |DONE      |NOSIGNATURE
		restrictedportals-1.16.4-1.1.6.jar                |Restricted Portals            |restrictedportals             |1.16.4-1.1.6        |DONE      |NOSIGNATURE
		DeathCounter-1.16.3-1.2.1.jar                     |Death Counter                 |deathcounter                  |1.2.1               |DONE      |NOSIGNATURE
		jei-1.16.4-<IP_ADDRESS>.jar                           |Just Enough Items             |jei                           |<IP_ADDRESS>            |DONE      |NOSIGNATURE
		FallingTree-Forge-1.16.4-2.8.1.jar                |Falling Tree                  |falling_tree                  |2.8.1               |DONE      |NOSIGNATURE
		mcw-windows-1.0.2-mc1.16.4.jar                    |Macaw's Windows               |mcwwindows                    |1.0.2               |DONE      |NOSIGNATURE
		windowlogging-mc1.16.3_v0.0.2.jar                 |Windowlogging                 |windowlogging                 |0.0.2               |DONE      |NOSIGNATURE
		findme-1.16.3-<IP_ADDRESS>.jar                         |Find Me                       |findme                        |NONE                |DONE      |NOSIGNATURE
		Neat+1.7-24.jar                                   |Neat                          |neat                          |1.7-24              |DONE      |NOSIGNATURE
		create-mc1.16.3_v0.3b.jar                         |Create                        |create                        |mc1.16.3_v0.3b      |DONE      |NOSIGNATURE
		Clumps-<IP_ADDRESS>.jar                               |Clumps                        |clumps                        |<IP_ADDRESS>            |DONE      |NOSIGNATURE
		XaerosWorldMap_1.11.6_Forge_1.16.4.jar            |Xaero's World Map             |xaeroworldmap                 |1.11.6              |DONE      |NOSIGNATURE
		shutupexperimentalsettings-1.0.1.jar              |Shutup Experimental Settings! |shutupexperimentalsettings    |1.0.1               |DONE      |NOSIGNATURE
		CTM-MC1.16.1-<IP_ADDRESS>.jar                          |ConnectedTexturesMod          |ctm                           |MC1.16.1-<IP_ADDRESS>    |DONE      |NOSIGNATURE
		CookingForBlockheads_1.16.3-9.2.2.jar             |Cooking for Blockheads        |cookingforblockheads          |9.2.2               |DONE      |NOSIGNATURE
		Controlling-<IP_ADDRESS>.jar                          |Controlling                   |controlling                   |<IP_ADDRESS>            |DONE      |NOSIGNATURE
		Placebo-1.16.3-4.3.3.jar                          |Placebo                       |placebo                       |4.3.3               |DONE      |NOSIGNATURE
		comforts-forge-1.16.4-<IP_ADDRESS>.jar                 |Comforts                      |comforts                      |1.16.4-<IP_ADDRESS>      |DONE      |NOSIGNATURE
		appliedenergistics2-8.2.0-beta.1.jar              |Applied Energistics 2         |appliedenergistics2           |8.2.0-beta.1        |DONE      |95:58:cc:83:9d:a8:fa:4f:e9:f3:54:90:66:61:c8:ae:9c:08:88:11:52:52:df:2d:28:5f:05:d8:28:57:0f:98
		NaturesCompass-1.16.4-1.8.6.jar                   |Nature's Compass              |naturescompass                |1.16.4-1.8.6        |DONE      |NOSIGNATURE
		SereneSeasons-1.16.4-<IP_ADDRESS>-universal.jar       |Serene Seasons                |sereneseasons                 |1.16.4-<IP_ADDRESS>     |DONE      |NOSIGNATURE
		ftb-gui-library-16<IP_ADDRESS>.jar                   |FTB GUI Library               |ftbguilibrary                 |16<IP_ADDRESS>         |DONE      |NOSIGNATURE
		upstream-1.0.jar                                  |Upstream                      |upstream                      |1.0                 |DONE      |NOSIGNATURE
		DefaultSettings-1.16.x-2.2.0.jar                  |DefaultSettings               |defaultsettings               |2.2.0               |DONE      |ed:1c:55:41:73:fd:14:1b:28:fe:ea:30:c5:11:3b:4d:3f:82:86:57:bb:5b:8a:b2:d7:f3:04:52:52:92:cf:e7
		FarmingForBlockheads_1.16.3-7.2.1.jar             |Farming for Blockheads        |farmingforblockheads          |7.2.1               |DONE      |NOSIGNATURE
		Bookshelf-1.16.4-9.3.18.jar                       |Bookshelf                     |bookshelf                     |9.3.18              |DONE      |ea:45:b3:82:b6:9d:50:16:95:e7:2e:34:e1:92:d5:b4:9b:69:90:d3:4f:2e:71:99:b0:be:40:80:27:1f:3e:b0
		pneumaticcraft-repressurized-1.16.4-2.8.2-101.jar |PneumaticCraft: Repressurized |pneumaticcraft                |1.16.4-2.8.2-101    |DONE      |NOSIGNATURE
		snowundertrees-1.16.4-v1.1.3.jar                  |Snow Under Trees              |snowundertrees                |v1.1.3              |DONE      |NOSIGNATURE
		mcw-doors-1.0.1fix-mc1.16.4.jar                   |Macaw's Doors                 |mcwdoors                      |1.0.1               |DONE      |NOSIGNATURE
		DataFixerSlayer 1.0-2.jar                         |DataFixerSlayer               |datafixerslayer               |1.0-2               |DONE      |NOSIGNATURE
		Hwyla-forge-1.10.11-B78_1.16.2.jar                |Waila                         |waila                         |1.10.11-B78_1.16.2  |DONE      |NOSIGNATURE
		WAWLA-1.16.4-7.0.2.jar                            |WAWLA                         |wawla                         |7.0.2               |DONE      |ea:45:b3:82:b6:9d:50:16:95:e7:2e:34:e1:92:d5:b4:9b:69:90:d3:4f:2e:71:99:b0:be:40:80:27:1f:3e:b0
		Toast-Control-1.16.3-4.3.0.jar                    |Toast Control                 |toastcontrol                  |4.3.0               |DONE      |NOSIGNATURE
		SnowRealMagic-1.16.3-2.2.2.jar                    |Snow! Real Magic!             |snowrealmagic                 |2.2.2               |DONE      |NOSIGNATURE
		Kiwi-1.16.3-3.4.1.jar                             |Kiwi                          |kiwi                          |3.4.1               |DONE      |NOSIGNATURE
		JustEnoughResources-1.16.4-<IP_ADDRESS>.jar         |Just Enough Resources         |jeresources                   |<IP_ADDRESS>          |DONE      |NOSIGNATURE
		immersive-portals-0.11-mc1.16.4-forge.jar         |Immersive Portals             |immersive_portals             |0.7                 |DONE      |NOSIGNATURE
		horsestandstill-1.16.3-1.0.1.jar                  |Stupid Horse Stand Still      |horsestandstill               |1.16.3-1.0.1        |DONE      |1f:47:ac:b1:61:82:96:b8:47:19:16:d2:61:81:11:60:3a:06:4b:61:31:56:7d:44:31:1e:0c:6f:22:5b:4c:ed
		ImmersivePetroleum-1.16.4-3.1.0-2.jar             |Immersive Petroleum           |immersivepetroleum            |3.1.0-2             |DONE      |NOSIGNATURE
		ftb-teams-16<IP_ADDRESS>.jar                         |FTB Teams                     |ftbteams                      |16<IP_ADDRESS>         |DONE      |NOSIGNATURE
		forge-1.16.4-35.1.28-universal.jar                |Forge                         |forge                         |35.1.28             |DONE      |22:af:21:d8:19:82:7f:93:94:fe:2b:ac:b7:e4:41:57:68:39:87:b1:a7:5c:c6:44:f9:25:74:21:14:f5:0d:90
		shetiphiancore-1.16-3.8.4.jar                     |ShetiPhian-Core               |shetiphiancore                |3.8.4               |DONE      |NOSIGNATURE
		blame-1.7.5.jar                                   |Blame!                        |blame                         |1.7.5               |DONE      |NOSIGNATURE
		supplementaries-0.9.16.jar                        |Supplementaries               |supplementaries               |0.9.16              |DONE      |NOSIGNATURE
		DynamicSurroundings-1.16.4-<IP_ADDRESS>.jar            |§3Dynamic Surroundings        |dsurround                     |1.16.4-<IP_ADDRESS>      |DONE      |b4:98:14:b9:76:55:25:4f:e5:5f:4d:71:90:87:43:5b:f9:d5:3a:02:60:42:5e:da:1f:15:9c:ff:be:a9:7c:77
		forge-1.16.4-35.1.28-client.jar                   |Minecraft                     |minecraft                     |1.16.4              |DONE      |NOSIGNATURE
		mcw-bridges-1.0.4-mc1.16.4.jar                    |Macaw's Bridges               |mcwbridges                    |1.0.4               |DONE      |NOSIGNATURE
		EnchantmentDescriptions-1.16.4-6.0.2.jar          |EnchantmentDescriptions       |enchdesc                      |6.0.2               |DONE      |ea:45:b3:82:b6:9d:50:16:95:e7:2e:34:e1:92:d5:b4:9b:69:90:d3:4f:2e:71:99:b0:be:40:80:27:1f:3e:b0
		AmbientSounds_v3.1.4_mc1.16.4.jar                 |Ambient Sounds                |ambientsounds                 |3.0.3               |DONE      |NOSIGNATURE
		MouseTweaks-2.13-mc1.16.2.jar                     |Mouse Tweaks                  |mousetweaks                   |2.13                |DONE      |NOSIGNATURE
		Psi 1.16-88.jar                                   |Psi                           |psi                           |1.16-88             |DONE      |NOSIGNATURE
		ImmersiveEngineering-1.16.4-4.1.2-129.jar         |Immersive Engineering         |immersiveengineering          |1.16.4-4.1.2-129    |DONE      |44:39:94:cf:1d:8c:be:3c:7f:a9:ee:f4:1e:63:a5:ac:61:f9:c2:87:d5:5b:d9:d6:8c:b5:3e:96:5d:8e:3f:b7
		durability101-1.16-0.0.3.jar                      |Durability101                 |durability101                 |0.0.3               |DONE      |NOSIGNATURE
		ftb-ranks-16<IP_ADDRESS>.jar                          |FTB Ranks                     |ftbranks                      |16<IP_ADDRESS>          |DONE      |NOSIGNATURE
		pamhc2crops-1.16.3-1.0.1.jar                      |Pam's HarvestCraft 2 Crops    |pamhc2crops                   |version             |DONE      |NOSIGNATURE
		CreativeCore_v2.0.10_mc1.16.4.jar                 |CreativeCore                  |creativecore                  |2.0.0               |DONE      |NOSIGNATURE
		mcw-trapdors-1.0.0-mc1.16.4.jar                   |Macaw's Trapdoors             |mcwtrpdoors                   |1.0.0               |DONE      |NOSIGNATURE
		Autofish-0.9.1-forge-mc1.16.4.jar                 |Autofish                      |autofish                      |0.9.1               |DONE      |NOSIGNATURE
		spark-forge.jar                                   |spark                         |spark                         |1.4.3               |DONE      |NOSIGNATURE
		pamhc2foodextended-1.16.3-1.0.0.jar               |Pam's HarvestCraft 2 Food Exte|pamhc2foodextended            |version             |DONE      |NOSIGNATURE
		jeiintegration_1.16.4-<IP_ADDRESS>.jar                |JEI Integration               |jeiintegration                |<IP_ADDRESS>            |DONE      |NOSIGNATURE
		curios-forge-1.16.4-<IP_ADDRESS>.jar                   |Curios API                    |curios                        |1.16.4-<IP_ADDRESS>      |DONE      |NOSIGNATURE
		eidolon-0.2.4.jar                                 |Eidolon                       |eidolon                       |0.2.4               |DONE      |NOSIGNATURE
		Patchouli-1.16.4-48.jar                           |Patchouli                     |patchouli                     |1.16.4-48           |DONE      |NOSIGNATURE
		overworld_two-1.0-Forge-1.16.4.jar                |Overworld 2                   |overworld_two                 |1.0                 |DONE      |NOSIGNATURE
		Xaeros_Minimap_20.30.1_Forge_1.16.4.jar           |Xaero's Minimap               |xaerominimap                  |20.30.1             |DONE      |NOSIGNATURE
		pamhc2foodcore-1.16.3-1.0.0.jar                   |Pam's HarvestCraft 2 Food Core|pamhc2foodcore                |version             |DONE      |NOSIGNATURE
		gravestone-1.16.4-1.0.8.jar                       |Gravestone Mod                |gravestone                    |1.16.4-1.0.8        |DONE      |NOSIGNATURE
		ftb-backups-<IP_ADDRESS>.jar                           |FTB Backups                   |ftbbackups                    |<IP_ADDRESS>             |DONE      |NOSIGNATURE
		polymorph-forge-1.16.4-0.21.jar                   |Polymorph                     |polymorph                     |1.16.4-0.21         |DONE      |NOSIGNATURE
		AutoRegLib-1.6-47.jar                             |AutoRegLib                    |autoreglib                    |1.6-47              |DONE      |NOSIGNATURE
		Quark-r2.4-283.jar                                |Quark                         |quark                         |r2.4-283            |DONE      |NOSIGNATURE
		enderchests-1.16-1.7.5.jar                        |EnderChests                   |enderchests                   |1.7.5               |DONE      |NOSIGNATURE
		structurize-0.13.104-ALPHA-universal.jar          |Structurize                   |structurize                   |0.13.104-ALPHA      |DONE      |NOSIGNATURE
		AmbientEnvironment-<IP_ADDRESS>.jar                    |Ambient Environment           |ambientenvironment            |<IP_ADDRESS>             |DONE      |NOSIGNATURE
		travelers_index-1.16.4-1.0.2.jar                  |Traveler's Index              |travelers_index               |1.16.4-1.0.2        |DONE      |NOSIGNATURE
		minecolonies-0.13.547-ALPHA-universal.jar         |Minecolonies                  |minecolonies                  |0.13.547-ALPHA      |DONE      |NOSIGNATURE
		mcws-roofs-2.0.0-mc1.16.4.jar                     |Macaw's Roofs                 |mcwroofs                      |2.0.0               |DONE      |NOSIGNATURE
		World Stripper-1.16.4-2.0.1.jar                   |World Stripper                |worldstripper                 |2.0.1               |DONE      |NOSIGNATURE
		AppleSkin-mc1.16.2-forge-1.0.14.jar               |AppleSkin                     |appleskin                     |1.0.14              |DONE      |NOSIGNATURE
		ferritecore-1.0.jar                               |Ferrite Core                  |ferritecore                   |1.0                 |DONE      |41:ce:50:66:d1:a0:05:ce:a1:0e:02:85:9b:46:64:e0:bf:2e:cf:60:30:9a:fe:0c:27:e0:63:66:9a:84:ce:8a
		engineersdecor-1.16.4-1.1.6-b1.jar                |Engineer's Decor              |engineersdecor                |1.1.6-b1            |DONE      |bf:30:76:97:e4:58:41:61:2a:f4:30:d3:8f:4c:e3:71:1d:14:c4:a1:4e:85:36:e3:1d:aa:2f:cb:22:b0:04:9b
		observerlib-1.16.4-1.4.4.jar                      |ObserverLib                   |observerlib                   |1.16.4-1.4.4        |DONE      |NOSIGNATURE
		moreoverlays-1.18.11-mc1.16.4.jar                 |More Overlays Updated         |moreoverlays                  |1.18.11-mc1.16.4    |DONE      |NOSIGNATURE
		moredragoneggs-1.4.jar                            |More Dragon Eggs              |moredragoneggs                |1.4                 |DONE      |NOSIGNATURE
		durabilityviewer-1.16.4-forge35.0.7-1.10.jar      |Giselbaers Durability Viewer  |durabilityviewer              |1.16.4-forge35.0.7-1|DONE      |NOSIGNATURE
		cloth-config-forge-4.1.2.jar                      |Cloth Config v4 API           |cloth-config                  |4.0                 |DONE      |NOSIGNATURE
		byg-1.1.5.jar                                     |Oh The Biomes You'll Go       |byg                           |1.1.5               |DONE      |NOSIGNATURE
		FastLeafDecay-v25.jar                             |FastLeafDecay                 |fastleafdecay                 |v25                 |DONE      |NOSIGNATURE
		CosmeticArmorReworked-1.16.4-v1.jar               |CosmeticArmorReworked         |cosmeticarmorreworked         |1.16.4-v1           |DONE      |5e:ed:25:99:e4:44:14:c0:dd:89:c1:a9:4c:10:b5:0d:e4:b1:52:50:45:82:13:d8:d0:32:89:67:56:57:01:53
		BetterMineshafts-Forge-1.16.3-1.1.1.jar           |YUNG's Better Mineshafts      |bettermineshafts              |1.16.3-1.1.1        |DONE      |NOSIGNATURE
		EnderMail-1.16.4-1.2.0.jar                        |Ender Mail                    |endermail                     |1.16.4-1.2.0        |DONE      |NOSIGNATURE
		BetterAdvancements-1.16.4-<IP_ADDRESS>.jar           |Better Advancements           |betteradvancements            |<IP_ADDRESS>           |DONE      |NOSIGNATURE
	Crash Report UUID: 38b25d82-3bc8-4aa9-a003-d74f2ada04b9

Let me know if the issue is still reproducable on 1.18.2 and I'll look into it further. I have no intention to support older versions of Minecraft anymore. 🙂

I also see this on 1.18.2 using TerraFirmaCraft which adds a lot of tags. I assume the issue comes from using a HashSet to store the lines

It makes no guarantees as to the iteration order of the set; in particular, it does not guarantee that the order will remain constant over time.

It could be that it just happens that small sets do result in the same order, only once you reach some threshold does it randomize.
Switching to a TreeSet or sorting before display should fix it.

any fix for this issue or mod alternative?


Create data collector for sharing force, impulse and actuation data

This PR allows to include cost functions that depend on the force, impulse or actuation data (#295 and #615). To do so, I created an abstraction for data collection with throw exception in case of users mistakes
Given an action data, we create a tailored data collection that is shared through any cost function. Different cost functions requires different kind of data collectors. And, in each cost function, we check that it has been passed a right data collector. This test is possible due to a proper design hierarchy of data collection abstractions.
This method doesn't affect the run-time performance due to casting. All needed castings are done inside the creation of a specific cost data. All code has Python bindings
Additionally, there are other minor tasks in this PR:

removed claim about virtualization against CRTP
fixed throw exception logic in cost-sum

@wxmerkt this tolerance value comes from a long discussion about NumDiff unittest (during Python development). The values depends on the disturbance used in the NumDiff routine, which it depends on the epsilon machine. For a 64bits machine, it's around 1e-4.

The reason of the fails in the CI is due to a change in Pinocchio version, as reported #645
I will proceed with this PR as it is.

@wxmerkt this tolerance value comes from a long discussion about NumDiff unittest (during Python development). The value depends on the disturbance used in the NumDiff routine, which it depends on the epsilon machine. For a 64bits machine, it's around 1e-4.

We should add this comment in the code. If there are discussions which arent captured on issues or in comments, it's not easy to follow

This PR didn't just fail on Xenial but also on Bionic

This PR didn't just fail on Xenial but also on Bionic

I am fixing now. But there is still the problem with Pinocchio, I will pointing you out  to this issue in my next PR


seiso should not raise error if configuration has already been deleted

Hello,
Some times, seiso raises this error when running with Gitlab CI and docker image appuio/oc:v3.11:
$ seiso configmaps -l app="${APPLICATION_NAME}" --older-than "${SEISO_OLDER_THAN}" --keep "${SEISO_KEEP_AT_MOST}" --delete
level=info msg="Seiso 0.7.0, commit a728ac2c7ea214bf9af854d4440d45528c13a5f6, date 2020-09-23T07:25:49Z"
Error: could not delete ConfigMaps for 'xxxx': configmaps "xxx-yyy-9dkg8m2bgh" not found

I think seiso could raise a Warning in this case but not an error, as the goal is to delete a config and it seems it's already deleted.

Hi.
That's interesting, because we are getting the list of candidates directly from the cluster. It seems like at the time where we are querying the cluster and deleting it after filtering, the candidate has been already deleted.... This looks like a race condition.
The fix should be easy, but how exactly do you use Seiso? what is the value of SEISO_OLDER_THAN and SEISO_KEEP_AT_MOST? Do you call seiso immediately after doing a deployment?

Depending on which environment is targeted, we've 3 different pair of values.
When I had this error, it was with the "development" environment configured with:
SEISO_KEEP_AT_MOST: 2
SEISO_OLDER_THAN: "3d"

seiso is run before any new deployment is run, but indeed, we can have some race condition with our integration and/or production environment launch the "seiso + deploy" job.
Maybe we should only run seiso for the development environment ?
Our gitlab-ci was inspired by the one provided by the appuio's example.

Hm strange, if it runs before the new deployment, I cannot image another reason why there's a race condition without having a closer look into your environment.
In any case, if you are able to wait a bit, the linked PR should ignore not-found-errors (but it will still be printed/logged as "Deleted"). That should remove the need to adapt your pipeline :tm:

Cool, many thanks for the PR :-)

We have released 0.7.1 now, please check if that works for you


Add a link to a players lichess opening book under players profile link

On a 4545 profile, https://www.lichess4545.com/team4545/season/32/player/tbest/ , there is a link to a players lichess profile.
I suggest also having a link directly to the players opening book. : https://lichess.org/analysis#explorer/TBest
Motivation is to save 1 click, as checking someone's opening book is common in 4545.

maybe instead the existing link on the pairing page for downloading a pgn should be replaced? not sure anyone still uses these.

Went with adding the Opening book to the pairings rather than removing the download games button. (https://github.com/Lichess4545/heltour/pull/503)
Would be more than happy to alter this if you think the two icons are too busy/cramped. If you all like it, then I am happy with the result.

This change is too opening-centric.  Games are objective and full truth about how a player plays, but the opening book is opening-centric.  Clicking on 4545 name we get to see the Lichess profile link and can go from there anyway

this can be closed, right? i will just do it.


Includes DENT Installation Guide

This commit includes the documentation for the DENT installation guide. Reference: https://github.com/dentproject/dentOS/wiki/Installation
Images file locations were changed to permit separation in directories "DENT Installation" and "GNS3 Installation"

Is there a specific use case for the .idea folder here? I believe it's IDE-based.
You may have accidentally pushed those files, and they are not necessary in this context.
Could you please confirm? @KorelU

Needs spell checking. For example "The dentOS build system generates an ONIE-compatible ..."

Needs spell checking.

Should now be addressed along with addition file issue

Will address spelling changes and additional files then create new pull request.


[GitHub] I only see my own repos, not external ones to which I was invited

Extension
https://www.raycast.com/raycast/github
Description

Steps To Reproduce

add your github account
you need acces to a repo from another user
try to create a new issue for this repo

Current Behaviour
I can't select this repo
Expected Behaviour
No response

Have you granted access to other repos?

@thomaslombart yes
Maybe a difference is, that it's repos from another user not an organization. But I have access to this repos, so it should also work.

When you say, "I have access" do you mean that you are a collaborator in these repositories?


Default schema name no longer quoted in SEARCH_PATH

Environment
Liquibase Version:4.14.0
Liquibase Integration & Version: maven
Database Vendor & Version:postgres
Description
The behaviour of DatabaseUtils in setting SEARCH_PATH changed in 4.14.0. It used to quote the default schema name and not the current search path. From 4.14.0 though. it quotes the current search path but not the default schema name. Since there are no tests for DatabaseUtils, I'm not sure whether this was intentional, but I noticed it since it started causing sql syntax errors for schema names containing a hyphen. I guess the intent was to quote both of them so I created a test for this.
Steps To Reproduce
Run test: https://github.com/flowertwig/liquibase/blob/searchpath-escaping/liquibase-core/src/test/java/liquibase/database/core/DatabaseUtilsTest.java
Test results for recent versions:
4.13.0
Expected :SET SEARCH_PATH TO "defaultSchema", "currentPath"
Actual   :SET SEARCH_PATH TO "defaultSchema", currentPath
4.14.0
Expected :SET SEARCH_PATH TO "defaultSchema", "currentPath"
Actual   :SET SEARCH_PATH TO defaultSchema, "currentPath"
4.15.0
Expected :SET SEARCH_PATH TO "defaultSchema", "currentPath"
Actual   :SET SEARCH_PATH TO defaultSchema, "currentPath"

Thanks for submitting this issue! We will look into it.

Issue does not exists in 4.10.0 but started from 4.11.0+

Is there any new on this?
I still have this issue with 4.17.2

I guess is there a work around or something for this?

Yes, I found a workaround for this issue. You can set the property: liquibase.preserveSchemaCase to true.
In case you use Spring Boot, you can add:
       System.setProperty(GlobalConfiguration.PRESERVE_SCHEMA_CASE.getKey(), "true");

As workaround (for Spring) I just quoted value for property spring.liquibase.default-schema="${application.datasource.schema}" and left unqouted for spring.liquibase.liquibase-schema=${application.datasource.schema}. As raw liquibase properties I guess it be default-schema-name and liquibase-schema-name respectively.

Just additional 50 cents from my case probably it will be useful.
If name of app the same of schema it works good without spring.liquibase.default-schema property. I have few services working fine with that config (with spring.liquibase.liquibase-schema only) but they were started like this initially.
But why I'm here? I have service with name "orders" connected to schema "order" and after liquibase 4.13.0 app does't start because topic issue. After schema has renamed to "orders" and added spring.liquibase.default-schema property - it's working good with last version. But don't start without spring.liquibase.default-schema

I'm also running into this issue with Liquibase Version 4.22.0
I'm using spring boot, and have not managed to get any of the workarounds to work correctly.
Firstly, Spring Boot does not support all liquibase parameters out the box, so I implemented a Component for it instead, no dice...
import jakarta.annotation.PostConstruct;
import liquibase.GlobalConfiguration;
import org.springframework.stereotype.Component;
@Component
public class LiquibaseConfig {
    @PostConstruct
    public void setProperty() {
        System.setProperty(GlobalConfiguration.PRESERVE_SCHEMA_CASE.getKey(), "true");
    }
}

@psavva You need to set that property before the Spring stuff comes into play. Worked just fine in our Spring Boot 2.7 and SB 3 apps.

I also encountered this issue during the migration to Spring Boot 3.
Any updates on it?

@dimon1165 Obviously not, but there is a workaround which will give you the old behavior back. As that workaround exists, I would not assume they would prioritize this very highly. I would expect this is the new behavior.

@FBurguer This is so annoying that I thought I might have a stab at this. Is there some obvious really-hard-to-fix reason why you guys haven't touched this that I should be aware of, or is this easy pickings?

FYI:
 System.setProperty(GlobalConfiguration.PRESERVE_SCHEMA_CASE.getKey(), "true");

didn't totally fix it for me, I was using
<sql>UPDATE ${database.defaultSchemaName}.customer...</sql>

In some migration scripts and since I didn't quote them here they failed.
Also try to use the previous checksum in the changeSet with:
<validCheckSum>8:66de2e69d671eac9cbed08f7a33debf5</validCheckSum>

didn't work great two as postgres and h2 have different checksums for sql statements, so I decide to just start blocking hyphens...


make services queryable by id provided by the service broker

We need to fetch the service from the CC api, using the identifier provided in the service catalog, so adding unique_id to be a query-able parameter.
Thoughts?

Hi @tinygrasshopper,
You can currently query based on label and provider which are guaranteed to be unique.  Is there a specific reason why that won't work for you and unique_id is better?
Thanks,
@adowns01, CAPI Team Member

Hi @adowns01
We are looking at the CC API from the perspective of the service broker author. The service author publishes a unique identifier to the cloud controller via the service catalog. The cloud controller then assigns its own unique identifier to the service, which is used as a 'primary' key in the CC API. As a service broker author I don't have ability to every query on the unique id that I provided to the cloud controller.
Currently our workaround for this is to fetch all the services(and navigating through all the pages) and detecting the service that we want by matching the unique id. With this change we will need to make fewer calls to the CC API.
We would also like to make a similar change to the service_plans api.
Best,
@craigfurman and @tinygrasshopper
Services Enablement Team, London

Thanks for the longer explanation @craigfurman and @tinygrasshopper. 👍


Add GetRecommendedInstanceType function and pick-instance-type CLI tool

This PR adds:

A new GetRecommendedInstanceType function to help us solve the issue where t2.micro and t3.micro instances are each available in some AZs, but not available in others. This module takes in a list of instance types to pick from and returns the recommended one to use, which is one that's available in all AZs in the current region.

A new pick-instance-type CLI that can be used to execute the same function from the CLI and get a recommended instance type printed to stdout. This can be used to figure out the instance type to use outside of an automated testing context: e.g., as part of Gruntwork Reference Architecture deployments.

Test failures are unrelated to this change. E.g., Getting intermittent issue from GCP:
compute_test.go:200: Error launching new Compute Instance: googleapi: Error 503: The service is currently unavailable., backendError

Update: This PR now also includes a new pick-instance-type CLI tool that can be used to execute the same function from the CLI and get a recommended instance type printed to stdout. This can be used to figure out the instance type to use outside of an automated testing context: e.g., as part of Gruntwork Reference Architecture deployments.

Thanks for the review! There are some test failures unrelated to this PR... I'll see if I can get them passing before merging, as I need a green build for the binaries to work.

And now tests passed... shrug. Merging now. Let's see what happens, I guess.

https://github.com/gruntwork-io/terratest/releases/tag/v0.28.11


Display stable API docs on /docs/all page

https://electronjs.org/docs/all#modules-for-the-main-process is currently referring to the inAppPurchase API which exists in electron@beta but not electron@latest.
This page should be updated to display stable docs, not beta. And in the beautiful future, users should be able to choose a specific version. Follow https://github.com/electron/i18n/issues/288 for updates on that effort.

https://www.electronjs.org/docs/all, which was in my opinion the single best thing about the docs, got deleted entirely.
Can it be restored? It's much more difficult to explore the docs without an "all" page.

I agree that was a very useful page. I'm not active on this project any more, so I don't have context on why this page was removed. My guess would be that its massive size caused performance issues, but again I don't know.
cc @electron/wg-ecosystem


How can i pass json string data from database to function?

I tried converting string to object and passing that object but no luck

As long as the json is from v3 it should work. If you have an String you should do JSON.parse(profile) where profile is the string


Http Requests and adding a Web Server + Database

I'm submitting a ...

[x] feature request

Http Requests and adding a Web Server + Database

Resolved in https://github.com/RommelTJ/rn-shop-app/pull/9


Add some basic tutorials for Chronos usage

Similar to https://mesosphere.github.io/marathon/docs/application-basics.html.

See also: https://mesosphere.com/blog/2015/03/26/integration-testing-with-mesos-chronos-docker/


[WFLY-14375] Upgrade Apache DS to version AM26

Issue: https://issues.redhat.com/browse/WFLY-14375
The upgrade needs the following:

The dependency now is apacheds-test-framework and apacheds-interceptor-kerberos is also required for the tests that need the kerberos interceptor.
Two new opens are added for jdk-17.
Some changes in test classes to accommodate to the new API (eh-cache is not used anymore for example).
I think that the modifications in Policy.java just fix a mistake, a eh-cache class was included for javadoc instead of the elytron one.

@fjuma This is the upgrade for apache-ds. Take a look when you have time.

I have just tried running this after merging to big-bang locally but I am seeing test failures with NoClassDefFound errors.
I am just syncing main to big-bang - once my changes are merged would it be possible for you to rebase this on big-bang and submit a PR against that branch instead?
https://github.com/wildfly/wildfly/pull/15724

Yes, no problem @darranl, I'll check it when the other PR is merged.

@darranl Doing more tests now but I don't see any NoClassDefFound in the PR. Nevertheless I detected that there are leftovers that reference apache-ds classes since WFLY-15001 (https://github.com/wildfly/wildfly/pull/14584) in the manualmode folder (for example these files). In that PR the tests OutboundLdapConnectionTestCase and OutboundLdapConnectionClientCertTestCase were removed but related files remain with no use at all. I'm going to delete them in this PR if you don't say something different.

@rmartinc I can have another look, there were some other issues popped up yesterday I needed to resolve so maybe not an issue after all.

I need to check some more in case it is my environment but I am seeing the following error when I test after merging to big bang:
Caused by: javax.naming.CommunicationException: <IP_ADDRESS>:10389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]
at java.naming/com.sun.jndi.ldap.Connection.(Connection.java:252)
at java.naming/com.sun.jndi.ldap.LdapClient.(LdapClient.java:137)
at java.naming/com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1616)

I have just checked the same test when this PR is merged to main and don't get a failure, if you would not mind looking at these tests once merged to big-bang as otherwise this will prevent us syncing main to big-bang.

@darranl Probably the error is because big-bang branch has this lines in basic with apache-ds again (this is not in main branch). The artifact should be changed to apacheds-test-framework. But don't worry. This can wait.

I am just adding a hold label for now so we can coordinate with big-bang - alternatively if you were able to submit directly to big bang we could merge there instead of to main.

@darranl I have submitted the same for big-bang in #15738. So you can close this and continue with the big-bang PR if you want. But not urgent, so I can wait too. Thanks!

Merged to big-bang under https://github.com/wildfly/wildfly/pull/15738 - big-bang will later be merged back to main so I will close this PR.


-1 doesn't work when use fzf+pipe+--bind

Category

[x ] fzf binary
[ ] fzf-tmux script
[ ] Key bindings
[ ] Completion
[ ] Vim
[ ] Neovim
[ ] Etc.

OS

[x ] Linux
[ ] Mac OS X
[ ] Windows
[ ] Windows Subsystem for Linux
[ ] Etc.

Shell

[ ] bash
[ ] zsh
[x ] fish

 When I use find+fzf+--bind to find a file and open with fzf, and then open with vim like this:
find Dir -iname Pattern | fzf --bind 'enter:execute vim {} < /dev/tty'

it works fine when there are multiple matches in the result of find, but when there is only one match, it will print the only match instead of open the file with vim
I already set set -gx FZF_DEFAULT_OPTS '-1 -0 --reverse' in my fish shell config file.
If I'm not using FZF_DEFAULT_OPTS right.
find Dir -iname Pattern | fzf -1 -0 --bind 'enter:execute vim {} < /dev/tty'

doesn't work for single match either.
So is it a bug?

when there is only one match, it will print the only match

You have -1 in your FZF_DEFAULT_OPTS  and that's what the option is supposed to do; finish fzf immediately. It is unrelated to bind option which is only triggered when you manually hit the key.
You can use shell script to catch the output and open it with the editor.


Testing Jupyter / Colab Notebooks

From last SIG Addons community meeting I picked up this task.
We want to discuss and implement a way to test jupyter / colab notebooks.
All discussions and ideas should go to this issue.
Furthermore the protocol sais that:

TF team is looking at ways to test doc strings (not sure if this should go to an other issue)
May be able to inline doc string test cases (not sure if this should go to an other issue)
First pass can we just test to make sure the notebook executes
Be sure to tag @karmel

I am not even sure which jupyter / colab notebooks should be tested. I guess these here:
https://github.com/tensorflow/addons/tree/master/examples
Is that right?

Should I open a separate issue about docstring testing?

Since these are norml jupyter notebooks we can smoke test them by just running them. This is possible with: nbconvert --ExecutePreprocessor.timeout=None --to notebook --execute <noteboo_name>.ipynb
Also see here: https://nbconvert.readthedocs.io/en/latest/execute_api.html#executing-notebooks-from-the-command-line
If this fails because some exception is raised the smoke test does not pass. But I am not sure how to integrate this into travis...
What do you think?

Since these are norml jupyter notebooks we can smoke test them by just running them. This is possible with: nbconvert --ExecutePreprocessor.timeout=None --to notebook --execute <noteboo_name>.ipynb
Also see here: https://nbconvert.readthedocs.io/en/latest/execute_api.html#executing-notebooks-from-the-command-line
If this fails because some exception is raised the smoke test does not pass.
Here is are links where they do exactly that:

example: https://github.com/ghego/travis_anaconda_jupyter
notebook testing lib: https://github.com/pyviz-dev/nbsmoke
notebook testing lib: https://github.com/opengeophysics/testipynb

My suggestion is to test the libs (link 2 and 3) and see if they fit our needs and decide which to use. The ppl. from link 2 (nbsmoke) say they are still "still undergoing heavy development". Lib 3. (testipynb) seems to be more mature to me.
What do you think?

Thanks for taking this on @PhilipMay. First impression is that either of the two libs looks like it could work for our first pass.

CC @tomerk and @yashk2810 , who worked on this on the TF side.

I tried running jupyter notebook cells in a docker container a while back, but as far as I remember I failed 😄 . In case something like this is of interested I am happy to help.

I which folder should the test be placed? I see 2 possibilities:

tensorflow_addons <- where the other tests are also located
examples <- where the examples are located

@MarkDaoust @lamberta

CC'ing @MarkDaoust who worked on this as well for tensorflow_docs. We test the tensorflow tutorials using a custom bazel test rule that combines nbconvert calls w/ small regex rewrites of the notebook code to make it execute less work.
(e.g. we replace the number of epochs to run w/ 1, and swap real dataset downloads with mock data).
We can explore open sourcing this rule if you think it would be useful. Otherwise if the libraries you linked above work fine for you they're worth considering.

Re: location
Noted in this comment, for notebooks that are intended as doc pages on tensorflow.org, they should go in the docs/tutorials/ directory to be consistent with the rest of the site. (We use "examples" to mean demo apps and other non-narrative samples.)

I have a first prototype solution here:
NBDIR = '../../examples'

class JupyterNotebooksTest(absltest.TestCase):

    def test_jupyter_notebooks(self):
        tnb = testipynb.TestNotebooks(directory=NBDIR, timeout=2100)
        self.assertTrue(len(tnb._nbpaths) > 0)
        self.assertTrue(tnb.run_tests())

if __name__ == '__main__':
    absltest.main()

The problem is that the path (NBDIR) is hard wired.
Any idears how to improve this?
Where should we place this script? In examples directory or tensorflow_addons/utils ?

I think it would be best to keep this away from the examples folder since this folder might get more "normal user clicks" than other module directories. Maybe you can put it to the other tools. @seanpmorgan maybe here https://github.com/tensorflow/addons/tree/master/tools/ci_testing ?

@PhilipMay could you open a PR with your changes?

@Smokrow PR with first version is here: #540

The testing by tf-docs team will be evaluated in #768


Update version: MongoDB.Shell version 2.2.11

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Programs\mongosh\mongosh.exe returned exit code: 1

(Automated response - build 886.)


need example of "async_request"

Can you let us know the example of "async_request" model?

There is one in the code already. Because all requests are performed asynchronously in the fastcgi protocol. Look at the code below:
public function request(array $params, $stdin)
{
    $id = $this->async_request($params, $stdin);
    return $this->wait_for_response($id);
}

With the current state of this project you could start multiple requests
    $id1 = $this->async_request($params1, $stdin1);
    $id2 = $this->async_request($params2, $stdin2);

And ready the results later:
$result1 = $this->wait_for_response($id1);
$result2 = $this->wait_for_response($id2);

If the $id2 request finishes before the $id1 request, the results are retrieved and returned on the wait_for_response($id2) call.
Sadly there currently is no way to execute code (like a callback or something) as soon a request is ready. Nothing is stopping you to fork, implement and contribute of course.
If you are looking for a non-blocking implementation, follow https://github.com/adoy/PHP-FastCGI-Client/issues/12 to see if that is going to happen. The non-blocking socket model requires a very different type of code and as a result will always support in a callback-like model


Multiple client instances connect to different Redis clusters

Feature Request
Describe the solution you'd like
We have 2 Redis clusters - one is in our China data center and the other is in our Singapore data center. Can we build up 2 lettuce client instances in a server environment?

Yes you can. I suggest that you share ClientResources to keep the number of I/O threads small.


Clean up needed! Help me remove items that are not related to a house theme

Please help me to remove items that are not related to the house theme.
Thank you!

Remember to close this issue once you are done
by tagging this issue https://github.com/ytbryan/house/issues/73


e2e tests are broken

Seems to be a Synpress issue, as far as I can tell. See details in this Synpress issue: https://github.com/Synthetixio/synpress/issues/795

Resolved, cf. https://github.com/Synthetixio/synpress/issues/795#issuecomment-1637126153


optional store exporting data (export.match)

Current Prometheus engine implementation exports data matched to the GSD. Data not matching the export.match specification is stored locally. It would be great if there will be an option to store all data (including data exported).
Please point me to the docs if this option already exists but I've missed it.

Hi @prudnitskiy,
All data should already be stored in the local Prometheus server for its configured --storage.tsdb.retention.time.
For managed-collection, we limit this to 30m to constrain memory usage, so if you're checking after that, you wouldn't see the data there.
If you're interested in retaining the data for longer, feel free to customize the install manifests your self to retain all data for longer (either for self-deployed or managed-collection).

Closing. If there are any other questions or discrepancies, please re-open and reach out.


LIME vs feature importance

Hi,
I have a question regarding the feature importance vs LIME.
For the adult data set, we can see the feature importance of my model -

However, when I set plotting various lime plots, I will post a few:

I ran around 20 plots and mostly we can see for example the variable marital status to be used in the decision. However, for the feature importance, it is slightly low. Is there a reason for this?
feature importance let us know that the more important features are on the higher nodes for splitting. For the LIME, it is ordered by values. Is it correct to understand that more important features does not necessarily means that it will result in larger gain/loss in the LIME?

Total 'gain' for capital gain = 0.10
total 'gain' for capital for class >50k  =  0.5
total 'gain' for capital for class <50k  =  0.5
0.5 + 0.5 = 0.10
The first plot is the total.
The next 2 plots are showing the total for each class which added is would show the first plot.

@bbennett36  are you saying that for the feature importance ( which is the first plot) is  the average of all the gains from the LIME plots? Because the 3 lime plots are only 3 random points of a test set..

No. I just noticed your plots are showing feature importance only for 'Class > 50k' (Which I'm summing is a classification problem). I'm going to guess that if you look at the gain for 'Class < 50k', and add up the gain for both classes, it will equal to the totals that you're seeing in the first plot.
Does that make sense? It looks like your only looking at the gain for 1 class and wondering why it's not equal to the total. You need to plot the other class and see if they add up.

@bbennett36
The first plot is the overall plot of feature importance from the model itself.
The subsequent plots are the LIME plot based off random points of a test set. As such, i do not understand how the logic of adding the plots from the lime to explain the feature importance plot. Also, this is indeed a classification problem for identifying if class > 50.
What i am not making sense is that why does the feature importance seems to contradict the lime plots. If age is of higher importance, does this mean that for the local interpretation by lime, each prediction should use AGE as a higher weightage or does this not hold true?

@germayneng
Have you checked how well is LIME explaining your model ? What's the approximation error ?

@m212 what is the function to obtain the approximation error for LIME?

@germayneng
lime.explanation.Explanation class has the attribute score
for example :
explainer = lime.lime_tabular.LimeTabularExplainer(train)
exp = explainer.explain_instance(sample)
exp.score

Adding LIME explanations up should not result in the feature importance weights - @bbennett36 is interpreting the feature importance graph incorrectly.
@germayneng You are correct: more important features according to feature importance in random forests are not necessarily going to show up with higher weights with LIME. Some features may have a lot of impact on individual predictions, but may be fragmented across the tree and thus get low feature importance. One quick thing you can do to check explanations is to test them - for these points you got explanations for, try perturbing capital gain , education and age and see the impact that those changes have.

@m212 i have the exp.score of 0.38905211797144262. how do i interpret this?
@marcotcr Thank you for your reply! Ok i understood. Basically from another example here I can see that higher features (higher feature importance) does not always result in highest / lowest gain / loss when it comes to predicting the target. What the higher importance feature does is to do the splitting on the top most nodes.
Also when you mean perturbing, is it as per your tutorial examples where you run through all the various values for a particular variable to identify the impact on the target variable while keeping other variable constant?

Yes, but you can also do it with multiple variables at a time. Basically that is how LIME is coming up with these weights in the first place.

@marcotcr can i say that the concept of marcotcr is similar to partial dependence plot except it is being localized ?

@germayneng The score you see is the sklearn.Ridge score for the perturbed data and the labels predicted by your model. It is an R² score
@marcotcr  is there a score limit after which we can no longer consider that LIME is approximating the model well locally ?

@m212  that make sense since LIME uses ridge regression under the hood. But isnt R2 not a good gauge since we can add more variables and it will increase

@germayneng I don't think it is similar to PDP - you don't see how the output changes as a function of the input for numerical features, you don't look at a feature at a time, etc.
For perturbing: if the data is categorical or discretized, we sample from a multinomial with probabilities given by the distribution in the training data. For continuous (non discretized) data we sample from a normal with mu and sigma estimated from the trianing data.
@mizukasai I think that threshold is application dependent, I don't think I can come up with a threshold for everyone : )


Install django-etuovi and django-oikotie from PyPI

Codecov Report

Merging #372 (cc8c1a8) into main (9592d39) will not change coverage.
Report is 4 commits behind head on main.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #372   +/-   ##
=======================================
  Coverage   90.38%   90.38%
=======================================
  Files         336      336
  Lines       11932    11932
  Branches      847      847
=======================================
  Hits        10785    10785
  Misses       1013     1013
  Partials      134      134

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Create separate contexts for analyzer and server

Part of #1830

Remove package_context.py and create separate contexts for analyzer and server.

There are some import errors, please check the tests.


I added a section called registryPrepopulate with two container waiteRegistry and pause. I'm not sure about the naming nor the form...


KOGITO-7471: Auto-layout for SWF

This is the first version of the autolayout for SWF.
More improvements can and will be made in the future, especially in terms of usability when we had the layout information saved. So we can compare what was changed and don't perform a full layout in every refresh of the canvas.

Hey @danielzhe, amazing work!! From the screen shots I can tell this is going very well :)
Quick question.. is the ELK-based mechanism for auto-layout going to be removed as part of this PR as well?

Thanks @danielzhe !
Can you please rebase this branch, it is actually in conflicts.
Also notice delegating to @handreyrc the engineering review, as I'll be off during next weeks.
NOTE: IMO this should be only merging when NO RISKS are found, we should properly test this and ensure we don't break any example, etc. This way I understand we still have time for the properly verification and fixes, if necessay, and try to include this for DP2. Otherwise, if reaching deadlines but having still open issues here, I would not vote for merging. I'll be off so letting to you this decision during following weeks!
@handreyrc @tiagobento @ederign @LuboTerifaj ^^
Thanks!

@danielzhe @handreyrc please remember to drop ELK from the bundle (JStypes, js files, etc)

@handreyrc please as part of the review for this PR, can you please obtain some performance metrics for the autolayout?
Notice we already have the metrics for the autolayout based on ELK [1], I expect this implementation faster, also as dropping the ELK bundle, there is no need for the 300ms the bundle takes to be parsed & evaluated by the browser. So I really expect better performance for this feature... let's see :)
[1] https://issues.redhat.com/browse/KOGITO-7041?focusedCommentId=20572270&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-20572270

Rebase and ELK removed!

Hey @danielzhe,
I tested this PR and I have some improvement points to suggest:
1- Transitions are being connected always to the center magnet and it causes trasitions to overlap some states when the workflow is too wide. It may look better if connections were made to top/bottom magnets of the states only. A setting could be implemented for that purpose.
2- The layout is Bottom-up. In this approach it is more likely that most of the states are concentrated in the bottom of the diagram also it makes the layer hierarchy unclear and a bit harder to follow. For example, the states "Compensate", "HandleError1" and "HandleError2" could be in the same layer as "Wait for Events" state. See below:

3- If a node is diconnected it is moved to the bottom of the diagram and the transitions may overlap other states and crosspath with other trasitions. Maybe changing the aproach to top-down and force disconected nodes to the right of the diagram may look better from the user point of view. It is how it works with the current ELK implementation. See below:

WDYT?
Performance
The performance in comparison to ELK is better. Actualy We have a great improvement here. It is fast!

By the way excelent job!
Thanks

Thank you for your review, @handreyrc ! I gonna do some changes based on your suggestions and ping you back when it is done!

Hi, @handreyrc
I did some changes as you requested. I think the result is much better now. Some points to consider:

The layout gives a false impression that it is bottom-up but it is not. This happens because of the way algorithm (Longest Path algorithm) that we are using to position nodes inside each layer. Consider the diagram that we are using. The algorithm works by calculating the cost to go from Start node to each one of the nodes. So, for example, the cost to go from Start to  "Handle Error 3" it is 6 (6 nodes that we have to cross to get there). And that's why the "Handle Error 3" node it is in layer 6. Probably the ELK is using another more complex approach to do the layering. I tried another algorithm but the result was worst than we have now.

I tried to force the disconnected nodes to go to the right but the result wasn't good, causing edges crossing:

The "End" node is always alone, so I think the UX is better now.

Let me know what you think.

Hey @LuboTerifaj, I have been facing this issue every once in a while but I don't think this is related to our extension.
Something that helps me is to completely close VS Code when this issue happens (ref https://stackoverflow.com/a/69316961).

Hello @caponetto , @danielzhe , the extension still doesn't work. If I open any serverless workflow file, the diagram cannot be opened. There is the error in console log: Error opening 'fileName.sw.json'. in NotificationsAlerts.ts:42.

Hello @caponetto , @danielzhe , the extension still doesn't work. If I open any serverless workflow file, the diagram cannot be opened. There is the error in console log: Error opening 'fileName.sw.json'. in NotificationsAlerts.ts:42.

Yep, I can also reproduce this issue here with the latest artifact from CI.

It's fixed now, @LuboTerifaj . Ready for review.

Hey  guys,
Sorry for late responses. I am starting the review process, will provide feedback during the following days.
@danielzhe is there any vsix being uplodaded for the manual testing of this stuff?

@romartin Artifacts are in Checks -> Full build -> Artifacts OR
https://github.com/kiegroup/kie-tools/actions/runs/3024908781#artifacts

@danielzhe Hi, could you please check if this test passes locally:
SWEditorSeleniumIT.testProcessTransactionsExample:249->testExample:256->waitCanvasPanel:281 » Timeout
The issue we observe in builds is that it does not load the canvasPanel. Asking if we shold investigate unstable test or not. Thanks

Hey  @domhanak
Thanks for the pointer! But I still can't find the vsix in the Linux_build-artifacts :( Where do you get the vsix from?? Thx!

@romartin ah I see, the build won't reach the package as this stunner package fails to build.

The (build) kie-tools-stunner-editors check has failed. Please check the logs.

Hello @danielzhe , what's the status of this PR? Is it ready for testing?

@danielzhe can you please rebase ? thx

@danielzhe as already discussed in today's call, for now 2 things to do from your side please:

Rebase from main upstream
Bug Fix -> Assume there could not exist an initial start state (if not defined in the json).This way, multiple states can have no transition, if no other incoming connectors or not defined as start states.

Finally, once both above points are done, it's supposed the builds and tests will work, and so the vsix will be automatically generated. So we will be able to go ahead with another review iteration
Thanks!

@romartin @LuboTerifaj Rebased.

Hey  @danielzhe !
Thanks a lot for this work, looks and performs really good!
I had been testing and found a few edge cases, that would be nice, at least, considering how hard can be to tackle, and ikf necessary, fixing as well.

When the wf's start attribute is pointing to a non existing node (for instance when a typo there), the start shape is on top, just floating, with no outgoing lines. Could we just NOT display the start shape in that case? The idea is: if the start node has no lines at all, no need to show it.

Same for end shape -> In case no states are end, the end shape just floats there... same as start, could we just not display the end shape as well?

When a state has some reference to a previous state, a line back to the state is created, but it is attached to the bottom magnet (of the source state), and also it not really looking nice IMO. Could we improve that in some way?  I would recommend using the top magnet, and maybe doing an orthogonal line back to the state, instead of  a line with just 1 point as it is now. OR maybe also a line with more points would work too

End shape when having lots of incoming lines -> This is already reported at https://issues.redhat.com/browse/KOGITO-7197 . Can we fix this in some way too? IMO this doesn't block the UI, but would be nice trying to find some quick win that makes this look better. We can ask UX (Missy) as well. WDYT?

Will continue with more manual tests and provide any other feedback if so
Thanks again for this good work!! :+1:

Thanks @LuboTerifaj  for the review as well!
@danielzhe @LuboTerifaj I think guys that we should now take a look at the reported issues in this PR, and have some discussion about what's feasible, what can wait, or what still needs work. This way, also as @LuboTerifaj will be on PTO during next weeks, I have just proposed a quick call for tomorrow. Also added @domhanak in the call, so he can help on the review while Lubo will be off.

Hello @danielzhe ,
regarding the issues I commented above, there is one issue that might not be clear:

The states connected with transition are sometimes shown in the same level, but they shouldn't.

The issue happens if the last state doesn't have end property. For example:

VSIX: https://github.com/kiegroup/kie-tools/actions/runs/3185392984#artifacts
Changes applied! Thank you for your review, guys! Here are some comments about the issues you guys reported:

The issues 1, 2, and 3 reported by @romartin  are done.
Issue 4 requires more time and discussion. I think there are other priorities in auto layout, but we can do it in the future.

Done:
[X] If you specify non-existing state as a start node, the start is shown in top left corner.
[X] If end node is not specified, or if it is specified, but it's not boolean, or it is false, it is shown in top left corner.
Those issues are doable but require a bit more time:
[ ] All states without specified transition or end are shown in top left corner.
Need clarification
I don't understand those issues, but by description, I think it can be fixed with the previous issue and the last one in this list:
[ ] The states with the transition to the first level of states are shown next to the Start node and the Start node is not in the center.
[ ] If there is odd number of states below Start node, the Start state is not in the center.
This issue is not related to this PR:
[-] If there are two states with the same name, the diagram gets broken
Not done:
This issue requires a lot of time and effort because we need to implement another step in the auto layout algorithm specific to handle edges:
[-] The connections intersect the other nodes, or the connections overlap each other.
I tried to fix this issue with a "easy" fix but the result wasn't good. There is a solution: we handle each isolated group of nodes as a single diagram, apply the layout, and put the results on the screen. This solution can also fix the issue "All states without specified transition or end are shown in top left corner."
[-] The states connected with transition are sometimes shown in the same level, but they shouldn't
@romartin @LuboTerifaj

+1 for this strategy @romartin . Delivering iterative is always better and gives us smaller PR's. Hopefully, we can have all those points fixed before the next release!

Hey @danielzhe
Thanks for the updates! I have been testing the vsix form the generated artifacts in this PR, and the start / end node are now not showing, if not present, but I still see issues with magnets.
See both cases:
Issue1 - Line back to previous layer

The magnet for for "Wait for completion" is correct, the below one. But the magnet used in the "DetermineCompletion" is still the bottom one, and it should be the top one. This way the line will not overlap the shape itself.
Issue2 - Line back in same layer

The magnet for for "State2" is correct, the left one. But the magnet used in the "State1" is still the bottom one, and it should be the right one. This way the line will not overlap the shape itself.
Rather than this, I have properly updated the improvements identified for a further task, see KOGITO-8100
Can you please fix both issues? Then I'll be ok to approve..
@LuboTerifaj WDYT?
Thanks guys!

@romartin Changes applied!

@LuboTerifaj review on your side now! :) Thanks!


Build Hadoop with Java 17

We are bumping the compiler version of Elasticsearch to Java 17 meaning that build-tools will now target Java 17. For this not to break elasticsearch-hadoop, we need to start building it with Java 17 as well.

Relates #1802


[SPARK-34534] Fix blockIds order when use FetchShuffleBlocks to fetch blocks

What changes were proposed in this pull request?

Fix a problems which can lead to data correctness after part blocks retry in OneForOneBlockFetcher when use FetchShuffleBlocks .
Why are the changes needed?
This is a data correctness bug, It's is no problems when use old protocol to send OpenBlocks before fetch chunks in OneForOneBlockFetcher;
In latest branch, OpenBlocks  has been replaced to FetchShuffleBlocks. Howerver, FetchShuffleBlocks read shuffle blocks order is not the same as blockIds in OneForOneBlockFetcher; the blockIds is used to match blockId with shuffle data with index, now it is out of order;
It will lead to read wrong block chunk when some blocks fetch failed in OneForOneBlockFetcher, it will retry the rest of the blocks in blockIds  based on the blockIds's order.
Does this PR introduce any user-facing change?

How was this patch tested?

Can one of the admins verify this patch?

@xuanyuanking

ok to test

Test build #135463 has started for PR 31643 at commit 0af3b01.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40043/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40043/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40043/

Test build #135463 has finished for PR 31643 at commit 0af3b01.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135463/

+CC @otterc

Can we add a test to validate and ensure this does not happen in future ?

@seayoun Can this be fixed by using a LinkedHashMap for mapIdToReduceIds in createFetchShuffleBlocksMsg?
https://github.com/apache/spark/blob/f7ac2d655c756100c33e652402cefc507d2493b7/common/network-shuffle/src/main/java/org/apache/spark/network/shuffle/OneForOneBlockFetcher.java#L119
LinkedHashMap will return the keys in insertion order and the values are already ordered.
Or is the problem is something different?

@seayoun Can this be fixed by using a LinkedHashMap for mapIdToReduceIds in createFetchShuffleBlocksMsg?
https://github.com/apache/spark/blob/f7ac2d655c756100c33e652402cefc507d2493b7/common/network-shuffle/src/main/java/org/apache/spark/network/shuffle/OneForOneBlockFetcher.java#L119
LinkedHashMap will return the keys in insertion order and the values are already ordered.
Or is the problem something different?

Yes, and we shoud add an assert when blockIds parsed, so I use a arrayList to build mapIds and to check mapId order in blockIds. cc @cloud-fan

The change LGTM. Can we add a test?

We can add a UT in OneForOneBlockFetcherSuite. It doesn't have to test the retry behavior, but just test that the block id matches its data.

Test build #135488 has started for PR 31643 at commit 384f43c.

Test build #135488 has finished for PR 31643 at commit 384f43c.

This patch fails Java style tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40069/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135488/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40069/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40069/

Test build #135497 has started for PR 31643 at commit 006a5ec.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40078/

Test build #135499 has started for PR 31643 at commit a08ca1d.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40078/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40078/

Test build #135497 has finished for PR 31643 at commit 006a5ec.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135497/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40080/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40080/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40080/

Test build #135499 has finished for PR 31643 at commit a08ca1d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135499/

Test build #135509 has started for PR 31643 at commit 1234253.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40090/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40090/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40090/

Test build #135509 has finished for PR 31643 at commit 1234253.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135509/

LGTM

Test build #135544 has started for PR 31643 at commit 7987a25.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40125/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40125/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40125/

Test build #135544 has finished for PR 31643 at commit 7987a25.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135544/

Test build #135573 has started for PR 31643 at commit e823930.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40154/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40154/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40154/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135573/

Seems like there are two proposals:

regenerate the block ids when building the FetchShuffleBlocks request.
leverage the fact the block ids are ordered already.

I think the goal is the same: keep block ids and the fetch request in sync. And these 2 proposals have no actual difference if the block ids are indeed ordered (you will regenerate the same ordered block ids).
I'm in favor of 2 because it ensures the things specified in the doc of createFetchShuffleBlocksMsg. I think it's better to not only keep block ids and the fetch request in sync, but also ensure the block ids are ordered, to eliminate randomness.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40201/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40201/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40201/

Revert initial fix @cloud-fan @otterc @Ngone51

Test build #135623 has started for PR 31643 at commit 0748d20.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40203/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40203/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40203/

Test build #135623 has finished for PR 31643 at commit 0748d20.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135623/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135646/

Test build #135647 has started for PR 31643 at commit c73c316.

Test build #135647 has finished for PR 31643 at commit c73c316.

This patch fails Java style tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40227/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40228/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135648/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135647/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40229/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40227/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40227/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40228/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40228/

Test build #135653 has started for PR 31643 at commit 6377217.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40233/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40233/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40233/

Test build #135653 has finished for PR 31643 at commit 6377217.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135653/

Test build #135686 has started for PR 31643 at commit 9cf23df.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40268/

GA passed, merging to master/3.1/3.0!

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40268/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40268/

Test build #135686 has finished for PR 31643 at commit 9cf23df.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135686/


Datepicker - Open in specific month/date

What problem does this feature solve?
In some use cases it's useful that the date picker opens in a month/date that is not the current day. In this case would be useful to be able to specify a date where the datepicker calendar would open.
What does the proposed API look like?
<nz-date-picker [openInDate]="Date Object"></nz-date-picker>

is any one working on this feature

Added [nzDefaultPickerValue] which works when the [ngModel] is null. #4843


Fix crash

Task linked: CU-m573rg HotFix PlayerDeath

Please add a more descriptive name or description to this PR


Add methods to JSON AST

[ ] final def transformAt[A <: Json](cursor: JsonCursor[_, A])(f: A => Json): Either[String, Json] = ???
[ ] final def delete(cursor: JsonCursor[_, _]): Either[String, Json] = ???
[ ] final def diff(that: Json): JsonDiff = JsonDiff(self, that)
[ ] final def intersect(that: Json): Either[String, Json] = ???
[ ] final def relocate(from: JsonCursor[_, _], to: JsonCursor[_, _]): Either[String, Json] = ???

@jdegoes If you clarify what we you’ve had in mind here we can decompose it into smaller ones for beginners to pick up.

I think that the most common pattern of using Json AST directly is something like :
  given JsonDecoder[ApiTransaction] = JsonDecoder[Json].map { json =>
    val c = json.cursor // somehow perform multiple ops on the cursor like this
    for {
      id         <- c.downField("id").as[TxId]
      inputs     <- c.downField("inputs").as[ArraySeq[ApiInput]]
      dataInputs <- c.downField("dataInputs").as[List[ApiDataInput]]
      outputs    <- c.downField("outputs").as[ArraySeq[ApiOutput]]
      size       <- c.downField("size").as[Int]
    } yield ApiTransaction(id, inputs, dataInputs, outputs, size)

Which is currently quite hard to put together and probably even inefficient.


IrisShaders for OF shader support

Mod name
IrisShaders

Curseforge link
not yet available

Modrinth link
not yet available

Other link
https://github.com/IrisShaders/Iris

What it does
A new shaders mod for Minecraft intended to be compatible with existing ShadersMod/Optifine shaders

Why should it be in the modpack
propper shader support
parity with Optifine

Why shouldn't it be in the modpack
the turn on and of shader button is broken to toggle it you need to press the hotkey
needs a custom sodium version or the builtin one
incompatible with canvas

Categories

[ ] Performance optimization
[x] Graphics optimization
[ ] New feature
[x] Optifine parity
[ ] Fixes a bug/dependency
[x] Replaces an existing mod

Additional details
there is work being done to make the official version of sodium compatible

Thanks for the suggestion! The mod is already being tracked on #12


Publish a new version of the package

Hi !
Could you republish a new version of the package on npm so we all can benefit from the latest fixes please ?
That would be much appreciated.
Thank you in advance

done


feat: asyncApi files-scenarios link

Description

Create association between asyncApi file and scenario file in order to aquire and structure all information needed to
send and event to an endpoint.

Not ready yet
Related issue(s)
Resolves #27

@jonaslagoni


Submission for Loan Eligibility Prediction

Description
I have come up with a predictive model for the Loan Eligibility Estimator, addressing the improvisation in the previous implementation. The model incorporates additional attributes that significantly impact loan approval, improving the accuracy and functionality of the estimator
Issue Resolved
This PR resolves #5  by providing a fully developed model for the Loan Eligibility Estimator
Changes Made

Implemented a machine learning model using [Model Type: Decision Trees, Random Forest and KNN(outperformed model) ]
Incorporated additional attributes that influence loan eligibility, such as
[ no_of_dependents, education, self_employed, income_annum, loan_amount, loan_term, cibil_score, residential_assets_value, commercial_assets_value, luxury_assets_value, bank_asset_value ]
Trained and tested the model using available data to ensure accuracy (90.66) and performance improvements.
Didnt implement model details functional as it was optional.

Checklist

[x] My code follows the current project structure
[x] I have thoroughly reviewed and updated the requirements.txt file to include any new packages
[] The predict.py file includes a properly implemented model_details() function, or the notebook contains this function to print a detailed model report. The model will not be accepted without this function, as it is essential for generating the necessary model details.
[x] I have added relevant tests (if necessary).
[x] I have added comments in the code where needed.
[x] This PR is submitted under Hacktoberfest.
[x] This PR is submitted under GirlScript Summer of Code (GSSoC-Extd).

should i create a new python file for this method, or should it be there in my notebook

Create a proper model_details fxn in the jupyter notebook only.