Insufficiently wide char code on some platforms

Both C and POSIX only specifies that int must be at least 16 bits wide (Linux says 32 bits), so charCode in stf_char should either be an uint_least32_t, an unsigned long int, or a long int (uint32_t could also be used if you only care for normal computers).

I'd like to avoid using overly specific integer types where possible, so I'm definitely in favour of unsigned long.

Done as of eeefd2f.


Bash regex matching problem

First of all, thank you for creating this script and sorry for bring up this repo after such long time from last commit.
I have seen some weird termination of script recently and find out that it is relative to bash regex support. Bash is not accept lazy token, i.e. question mark. For example, this line. I have to remove question mark in order to make it works, and here is a reference for this problem: Lazy Regex Using Bash
This problem happens on both MacOS 12.1 bash 3.2.57 and FreeBSD 12.2 bash 5.0.16, so this might be a general problem for bash.
It will be great if you have time to take a look about this and see if something need to be change. Thank you very much.

Thanks for bringing this to my attention!
I reproduced the issue on FreeBSD 12.2 with bash 5.1.8.
#/bin/bash

NINELINE="[2022-01-08 12:23:37] (911) Some text"
LASTNL=$([[ "$NINELINE" =~ \[([^\]]+?)\] ]] && echo "${BASH_REMATCH[1]}")
echo "$LASTNL"

This produces no output unless the regex is changed to \[([^\]]+)\].
The lazy match really isn't necessary; [^\]+ already guarantees that we'll match the correct ] even if more appear later in the string. I'll push an update to remove ?.

Looks like I can reproduce https://github.com/mdmower/bash-no-ip-updater/issues/17 in FreeBSD as well. That would affect you. I'll address that next.


Please use the Release name in the name of created k8s objects

Using the Release name in the k8s object names ensures that multiple installations of the chart in a single namespace cannot conflict, and also helps identify resources that belong together.
The default helm create template provides an example for this as a named template <CHART>.fullname, which also supports overriding either the entire 'fullname' or just the .Chart.Name aspect, and can then be used as the name or name prefix for objects created by the chart.
Helpfully, all resources currently created have "valheim-server" as a name or prefix, so this is a reasonably easy thing to change.
However, for continuity when upgrading, either the default for fullnameOverride would be "valheim-server", and that's stuck there forever, or at some point users upgrading need to know to add that setting to their config when upgrading. Either one is a pain. >_<

Fixed in PR#50

Fixed in #50

Yep, closing.


Crash when placing energy conduit with shift at an other energy conduit

Minecraft crashes when placing an energy conduit with shift at an other energy conduit
Bug with Bibliocraft ToolRack: tesselating
It only happens when placing an energy conduit at an other energy conduit while holding shift

Crash-Report:
---- Minecraft Crash Report ----
// Surprise! Haha. Well, this is awkward.

Time: 07.02.15 17:59
Description: Rendering Block Entity

java.lang.IllegalStateException: Already tesselating!
at net.minecraft.client.renderer.Tessellator.func_78371_b(Tessellator.java:374)
at net.minecraftforge.client.model.obj.WavefrontObject.renderAll(WavefrontObject.java:181)
at jds.bibliocraft.models.OBJToolRack.render(OBJToolRack.java:21)
at jds.bibliocraft.rendering.TileEntityWeaponRackRenderer.func_147500_a(TileEntityWeaponRackRenderer.java:133)
at net.minecraft.client.renderer.tileentity.TileEntityRendererDispatcher.func_147549_a(SourceFile:100)
at net.minecraft.client.renderer.tileentity.TileEntityRendererDispatcher.func_147544_a(SourceFile:92)
at net.minecraft.client.renderer.RenderGlobal.func_147589_a(RenderGlobal.java:766)
at net.minecraft.client.renderer.EntityRenderer.func_78471_a(EntityRenderer.java:1552)
at net.minecraft.client.renderer.EntityRenderer.func_78480_b(EntityRenderer.java:1298)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:990)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887)
at net.minecraft.client.main.Main.main(SourceFile:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Stacktrace:
at net.minecraft.client.renderer.Tessellator.func_78371_b(Tessellator.java:374)
at net.minecraftforge.client.model.obj.WavefrontObject.renderAll(WavefrontObject.java:181)
at jds.bibliocraft.models.OBJToolRack.render(OBJToolRack.java:21)
at jds.bibliocraft.rendering.TileEntityWeaponRackRenderer.func_147500_a(TileEntityWeaponRackRenderer.java:133)

-- Block Entity Details --
Details:
Name: ToolRackTile // jds.bibliocraft.tileentities.TileEntityWeaponRack
Block type: ID #693 (tile.BiblioRack // jds.bibliocraft.blocks.BlockWeaponRack)
Block data value: 0 / 0x0 / 0b0000
Block location: World: (-778,161,797), Chunk: (at 6,10,13 in -49,49; contains blocks -784,0,784 to -769,255,799), Region: (-2,1; contains chunks -64,32 to -33,63, blocks -1024,0,512 to -513,255,1023)
Actual block type: ID #693 (tile.BiblioRack // jds.bibliocraft.blocks.BlockWeaponRack)
Actual block data value: 0 / 0x0 / 0b0000
Stacktrace:
at net.minecraft.client.renderer.tileentity.TileEntityRendererDispatcher.func_147549_a(SourceFile:100)
at net.minecraft.client.renderer.tileentity.TileEntityRendererDispatcher.func_147544_a(SourceFile:92)
at net.minecraft.client.renderer.RenderGlobal.func_147589_a(RenderGlobal.java:766)
at net.minecraft.client.renderer.EntityRenderer.func_78471_a(EntityRenderer.java:1552)

-- Affected level --
Details:
Level name: MpServer
All players: 1 total; [EntityClientPlayerMP['playername'/699, l='MpServer', x=-777,14, y=156,66, z=792,13]]
Chunk stats: MultiplayerChunkCache: 289, 298
Level seed: 0
Level generator: ID 04 - BIOMESOP, ver 0. Features enabled: false
Level generator options:
Level spawn location: World: (8,64,8), Chunk: (at 8,4,8 in 0,0; contains blocks 0,0,0 to 15,255,15), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
Level time: 1026749 game time, 1240000 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: true), thunder time: 0 (now: false)
Level game mode: Game mode: survival (ID 0). Hardcore: false.  Unsupported mods in environment: optifine
TConstruct Environment: Environment healthy.
Stencil buffer state: Function set: GL30, pool: internal, bits: 8
Forestry : [Forestry] Warning: You have mods that change the behavior of Minecraft, ForgeModLoader, and/or Minecraft Forge to your client:
Optifine
These may have caused this error, and may not be supported. Try reproducing the crash WITHOUT these mods, and report it then.
AE2 Integration: IC2:ON, RotaryCraft:OFF, RC:ON, BC:ON, MJ6:OFF, MJ5:ON, RF:ON, RFItem:ON, MFR:ON, DSU:ON, FZ:OFF, FMP:ON, RB:OFF, CLApi:OFF, Waila:ON, InvTweaks:ON, NEI:ON, CraftGuide:OFF, Mekanism:ON, ImmibisMicroblocks:OFF, BetterStorage:OFF
Launched Version: 1.7.10-Forge<IP_ADDRESS>0
LWJGL: 2.9.1
OpenGL: GeForce GT 635M/PCIe/SSE2 GL version 4.5.0 NVIDIA 347.25, NVIDIA Corporation
GL Caps: Using GL 1.3 multitexturing.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Anisotropic filtering is supported and maximum anisotropy is 16.
Shaders are available because OpenGL 2.1 is supported.

Is Modded: Definitely; Client brand changed to 'fml,forge'
Type: Client (map_client.txt)
Resource Packs: [NuclearControl_Sound.zip, CCResourcePack.zip]
Current Language: English (UK)
Profiler Position: N/A (disabled)
Vec3 Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Anisotropic Filtering: Off (1)

How is this EIO's fault? Seems bibliocraft is doing weird things.

Also try without Optifine

Yep

Was having the same issue and removed optifine and no crash


Future of param & return docblocks with PHP7

Hey,
On PHP5 we had :
    /**
     * @param Request $request
     *
     * @Route("/queue/wanna-speak/process", name="ws_queue")
     * @Method({"GET"})
     *
     * @return Response
     */
    public function queueAction(Request $request)
    {
        return new Response();
    }

on PHP7 we can simplify this by using:
    /**
     * @Route("/queue/wanna-speak/process", name="ws_queue")
     * @Method({"GET"})
     */
    public function queueAction(Request $request): Response
    {
        return new Response();
    }

Since we can take advantage on advanced type hinting AND return types, the functions/methods can now contains everything we need (parameters & returns) to not write the @param and @return docblock
What do you think of dropping those rules ?

I am currently dropping them, but the type hints do not cover all scenarios - e.g. mixed types and objects? possility of returning a NULL value?
/**
 * @param object $foo
 * @param int|string $bar
 *
 * @return string|null
 */
public function doSomething($foo, $bar)

So maybe just add them when something is not clear.

Where the language conveys the same information as the docblock, drop it

Sadly PhpStorm doesn't use type-hints for viewing usefull doc blocks..

@dantleech returning null values is covered by PHP7.1
function returns_nothing() : void
{
    // This function returns null
    return;
}

function does_not_return() : void
{
    // This function returns null too
}

source

@tristanbes thanks, also nullable type declarations: function fonc02(?int $a, ?int $b) : ?int

@tristanbes wrong RFC for this case. The https://wiki.php.net/rfc/nullable_types do the job :)
So my answer is: I totally agree with your idea but you need to wait 7.1 :D

The purpose of @param and @return tags is also to support a description.

I'm not suggesting to remove them. I'm suggesting to not trigger a CS error when ommiting them when you have self-description-named variable with supported type hiting :-)

seems reasonable to me. you could even complain when empty annotations without further explanation are found.
imho using param and return to further explain input and output is good practice, but when no further explanation is given, the annotations should be removed

We're currently dropping docblocks with no added value too. By the way, we switched to PHP-CS-Fixer and are using this new profile https://github.com/M6Web/php-cs-fixer-config which doesn't force you to add docblocks and which is more Symfony3 and PHP7 compliant.


Configuration: when building the dirinfo structure, include shared_sources

This makes sure that any resulting directory target in the build files
also depend on object files meant for shared libraries.
As a side effect, we move the production of the dirinfo structure from
common.tmpl to Configure, to make it easier to check the result.

@dot-asm, this should answer your comment on missing dependencies for the directory targets.

Anyone, feel free to review

PING

Merged.
master:
b6e660754c2e799cffe4906269fcace0e07c73bc Configuration: when building the dirinfo structure, include shared_sources
1.1.1:
222b0a8e1a43e67c8d65fd325828d8860ed2d348 Configuration: when building the dirinfo structure, include shared_sources

@dot-asm, this should answer your comment on missing dependencies for the directory targets.

On Linux for no-shared config:
make crypto/bn
make: *** No rule to make target 'crypto/bn/libcrypto-shlib-bn_add.o', needed by 'crypto/bn'.  Stop.

Would you mind making that comment an issue?


Fix for #5865

See #5865 and http://stackoverflow.com/q/35486239/1461210

@@            master   #5867   diff @@
======================================
  Files          237     237
  Stmts        43510   43510
  Branches      8159    8159
  Methods          0       0
======================================
  Hit          33940   33940
  Partial       2600    2600
  Missed        6970    6970

Review entire Coverage Diff as of 51a6541

Powered by Codecov. Updated on successful CI builds.

thanks, merged


[view] [conultEdit]  listUrl is defined two times

the listUrl is defined ine the view options and as property

Done.


[WIP] QL: EOS-S3: enable new flow

This PR updates platform flow for EOS-S3 and common modules to enable support for QL EOS-S3 devices in new toolchain wrappers flow. It also adds new stages that are QL or EOS-S3 specific:

generation of iomux configuration (variants: binary, jlink, openocd)
VPR analysis (post implementation verilogs are created, variants: all ports are single bit; merged multi-bit ports)
write_bitheader,
write_binary,
write_jlink,
write_openocd,
fasm2bels,

Rebased on top of https://github.com/chipsalliance/f4pga/pull/587.

Blocked by chipsalliance/f4pga-examples#342.


No license

Hi guys,
The repo is missing a license file. AFAIK if there is no license it's proprietary therefore nobody can use it without your explicit permission.
Maybe this is helpful: https://choosealicense.com/
Bitcoin Core (and many other Bitcoin projects) use MIT.

Fixed by 4fc54903e0064f4ebcc829f42e39e4fb400a528c. Closing.


LSODA implementation of dense output yields incorrect result

I am using solve_ivp with LSODA to integrate an ODE in the presence of an event; the event function and the solve_ivp call look like
def interrupt_integration(t, y, *tuple_of_args):
        return y[0] - initial_value / 1e5

interrupt_integration.terminal = True
interrupt_integration.direction = -1

sol = solve_ivp(func, integration_range, [initial_value], method="LSODA", t_eval=t_values,
                events=interrupt_integration, args=tuple_of_args,
                first_step=1e-9, max_step=np.inf, rtol=5e-4, atol=5e-7,
                jac=jac, lband=0, uband=0, min_step=1e-11)

I am experiencing an issue following the occurrence of the event. Specifically, the value of y calculated by LSODA differs from the one returned by the call to the interpolant generated by LsodaDenseOutput. I obtain the following
0.002851754215052383 [1.21218232e-05] 1.2e-05 1.218231563465635e-07
0.0029674726381464737 [7.54816189e-06] 1.2e-05 -4.451838114260822e-06
0.002851754215052383 [1.19125649e-05] 1.2e-05 -8.743505742940739e-08
0.0029674726381464737 [7.54816189e-06] 1.2e-05 -4.451838114260822e-06

The values printed correspond to t, y, initial_value / 1e5 and y[0] - initial_value / 1e5. On the first line, one can see that the returned value from the event is positive, hence the event is inactive. On the second line, however, the returned value is negative and the event becomes active. As a result, solve_event_equation within ivp.py is called and the third and fourth lines are produced. The fourth line is identical to the second line, which is the expected behaviour but, in the third line, the value of y differs from that in the first line, meaning that the value calculated by the interpolant from LsodaDenseOutput is incorrect.
I have had a look at _dense_output_impl within lsoda.py, but this is beyond my knowledge. Does anyone have an idea of why the interpolant yields an erroneous value at the lower end of the interpolation range?
Scipy/Numpy/Python version information:

Python 3.9.6, Numpy 1.21.1, Scipy 1.7.0

Hi,
do you have a minimal code sample that we can directly copy/paste to reproduce such an issue ?

Thanks for looking into this. I have sort of a reproducer, but considering some values within func are calculated within complex functions, I figured it would be best to just dump them into dictionaries. As a result, I have this:
import numpy as np
from scipy.integrate import solve_ivp

def func(t, y):
    return y / (1 - t) - y / (foo[t] - bar[t] * t)

def jac(t, y):
    return 1 / (1 - t) - 1 / (foo[t] - bar[t] * t)

def stop(t, y):
    print(t, y, y[0] - y0 / 1e5)
    return y[0] - y0 / 1e5

stop.terminal = True
stop.direction = -1

foo = {0.0: 0.029476812948995148, 1e-09: 0.02947681040077826,
       2e-09: 0.02947680785256066, 1.0002e-05: 0.02945128433533103,
       2.0002000000000003e-05: 0.029425678101783845,
       3.0002000000000002e-05: 0.029399989088615703,
       0.000130002: 0.029230452355455988,
       0.00023000199999999998: 0.029191774167678885,
       0.000330002: 0.029152915220043835,
       0.00043000199999999997: 0.029113875310867024,
       0.001430002: 0.02876766834368568, 0.002430002:
       0.02847185665295307, 0.003430002: 0.028202751722422884,
       0.004430002000000001: 0.027952662825450645,
       0.008519605788205807: 0.022905984940179824,
       0.007281063006042693: 0.027300979492089986,
       0.010132124012085386: 0.02025345412862362,
       0.008660010923042845: 0.021214768184557208,
       0.007556852589442723: 0.02724175078517937,
       0.007832642172842753: 0.02718479976564211,
       0.008384221339642813: 0.02527129401858587,
       0.008935800506442873: 0.019528292281649904,
       0.009487379673242933: 0.02037676066704014,
       0.00934000544054084: 0.01989416388865358,
       0.009744210374638808: 0.02032775867521952,
       0.010148415308736775: 0.020250325840727494,
       0.010866168034960004: 0.020113393229186118,
       0.011583920761183234: 0.019981633614217835,
       0.012301673487406463: 0.01984881183755286,
       0.014538351128642633: 0.019447584430548222,
       0.016775028769878804: 0.019058597729832413,
       0.01901170641111497: 0.018678455557851265,
       0.02423145283713465: 0.017814548563380436,
       0.02945119926315433: 0.016969990116954593,
       0.02759309012139257: 0.0172698529171475,
       0.03095472740565049: 0.016729649690162277,
       0.03431636468990841: 0.016192717307204542,
       0.03370112503574072: 0.01629065815929285,
       0.03644752266583095: 0.0158532553587958,
       0.03919392029592118: 0.015417187561523906,
       0.03864347589924936: 0.015504231290303634,
       0.04083942913266777: 0.015157383813710517,
       0.04303538236608618: 0.014809684936033558,
       0.042660331506766305: 0.014868650294859016,
       0.04448123388086484: 0.014581292474113251,
       0.04630213625496338: 0.014293458984378008,
       0.04951943560969117: 0.013785937182894536,
       0.048852300487073494: 0.0138912794370001,
       0.05140246471918361: 0.013488961724187341,
       0.05395262895129373: 0.013085220816138231,
       0.05650279318340384: 0.012679840416492304,
       0.05459017000932126: 0.012984291473056365,
       0.05522771106734879: 0.01288307272299171,
       0.055865252125376325: 0.01278156463465979,
       0.05650279318340386: 0.0126798404164923,
       0.057777875299458915: 0.012478571735661786,
       0.059052957415513974: 0.012276204069044047,
       0.06032803953156903: 0.012072821582693105,
       0.06160312164762409: 0.011870364583737523,
       0.0606468100605828: 0.012022308152748701,
       0.060965580589596564: 0.011971727504618139,
       0.06128435111861033: 0.011921079645771786,
       0.0616031216476241: 0.011870364583737521,
       0.062208813701492865: 0.011773816371676687,
       0.06281450575536163: 0.011677025613681216,
       0.06342019780923039: 0.011579992363122005,
       0.06402588986309915: 0.01148271667413238}
bar = {0.0: 0.0, 1e-09: 3.4086535954356014, 2e-09: 3.4086542978849566,
       1.0002e-05: 3.4159427995254577,
       2.0002000000000003e-05: 3.4232346887012572,
       3.0002000000000002e-05: 3.4305299687566397,
       0.000130002: 0.5756975084092468,
       0.00023000199999999998: 0.5771698633237826,
       0.000330002: 0.5786426287815926,
       0.00043000199999999997: 0.580115804987956,
       0.001430002: 0.5024993883592048,
       0.002430002: 0.4589098021277861,
       0.003430002: 0.430273623161857,
       0.004430002000000001: 0.4013637154514233,
       0.008519605788205807: 0.29037630343847937,
       0.007281063006042693: 0.3592207609391992,
       0.010132124012085386: 0.24566161928918345,
       0.008660010923042845: 0.2685977026683152,
       0.007556852589442723: 0.3570232800585041,
       0.007832642172842753: 0.35153277854189896,
       0.008384221339642813: 0.3207871254518165,
       0.008935800506442873: 0.2468874833078626,
       0.009487379673242933: 0.25151150476846235,
       0.00934000544054084: 0.24708375042521946,
       0.009744210374638808: 0.24843356077119336,
       0.010148415308736775: 0.24568640999109434,
       0.010866168034960004: 0.2452380786270683,
       0.011583920761183234: 0.2388955900978546,
       0.012301673487406463: 0.2366961569546367,
       0.014538351128642633: 0.22747068350665495,
       0.016775028769878804: 0.2209836035536901,
       0.01901170641111497: 0.2150464347549513,
       0.02423145283713465: 0.2052438158186673,
       0.02945119926315433: 0.19818362781401422,
       0.02759309012139257: 0.20039935988879123,
       0.03095472740565049: 0.1965611123586582,
       0.03431636468990841: 0.19323644827923409,
       0.03370112503574072: 0.19374659715079648,
       0.03644752266583095: 0.19099864724820126,
       0.03919392029592118: 0.18874966613397598,
       0.03864347589924936: 0.18944350874581367,
       0.04083942913266777: 0.1873057119526678,
       0.04303538236608618: 0.1854254416360881,
       0.042660331506766305: 0.1859252389311718,
       0.04448123388086484: 0.18458656503930682,
       0.04630213625496338: 0.1831337661765724,
       0.04951943560969117: 0.18076074209302737,
       0.048852300487073494: 0.1812626936758732,
       0.05140246471918361: 0.1794895940007729,
       0.05395262895129373: 0.17846279401370146,
       0.05650279318340384: 0.17759866407692976,
       0.05459017000932126: 0.17807580722623323,
       0.05522771106734879: 0.17789876937610216,
       0.055865252125376325: 0.17775444177480337,
       0.05650279318340386: 0.17759866407692948,
       0.057777875299458915: 0.17668665156727248,
       0.059052957415513974: 0.1759666871808635,
       0.06032803953156903: 0.17555528345585283,
       0.06160312164762409: 0.17483524999613184,
       0.0606468100605828: 0.17537267580783927,
       0.060965580589596564: 0.17519182162596608,
       0.06128435111861033: 0.17501268983427154,
       0.0616031216476241: 0.17483524999613087,
       0.062208813701492865: 0.17450265408093713,
       0.06281450575536163: 0.17420312944304941,
       0.06342019780923039: 0.1741284993925215,
       0.06402588986309915: 0.17405523810115953}

y0 = 0.772
sol = solve_ivp(func, [0.0, 0.07], [y0], method="LSODA",
                events=stop, first_step=1e-9, max_step=np.inf, rtol=5e-4,
                atol=5e-7, jac=jac, lband=0, uband=0, min_step=1e-11)

This fails for me:
0.06342019780923039 [7.88337564e-06] 1.6337564465948222e-07
0.06402588986309915 [1.71524262e-06] -6.004757381989139e-06
0.06342019780923039 [7.39591984e-06] -3.240801624861349e-07
0.06402588986309915 [1.71524262e-06] -6.004757381989139e-06
Traceback (most recent call last):
  File "/home/thomas/mwe.py", line 152, in <module>
    sol = solve_ivp(func, [0.0, 0.07], [y0], method="LSODA",
  File "/home/thomas/.local/lib/python3.9/site-packages/scipy/integrate/_ivp/ivp.py", line 601, in solve_ivp
    root_indices, roots, terminate = handle_events(
  File "/home/thomas/.local/lib/python3.9/site-packages/scipy/integrate/_ivp/ivp.py", line 108, in handle_events
    roots = [solve_event_equation(events[event_index], sol, t_old, t)
  File "/home/thomas/.local/lib/python3.9/site-packages/scipy/integrate/_ivp/ivp.py", line 108, in <listcomp>
    roots = [solve_event_equation(events[event_index], sol, t_old, t)
  File "/home/thomas/.local/lib/python3.9/site-packages/scipy/integrate/_ivp/ivp.py", line 77, in solve_event_equation
    return brentq(lambda t: event(t, sol(t)), t_old, t,
  File "/home/thomas/.local/lib/python3.9/site-packages/scipy/optimize/zeros.py", line 776, in brentq
    r = _zeros._brentq(f, a, b, xtol, rtol, maxiter, args, full_output, disp)
ValueError: f(a) and f(b) must have different signs

where you can clearly see that y values associated to t = 0.06342019780923039 are not consistent.

Reading through the FORTRAN code, Scipy's implementation is correct. Using the values denoted T, TCUR and HCUR to calculate S, NQCUR + 1 to obtain L, and the YH values, DKY as coded in DINTDY yields the exact same value as given by Scipy. The mathematical formula is correct, but I am wondering if there could be an error somewhere in the scaling of YH; it is mentioned multiple times in DSTODA that YH has to be rescaled.
>>> S = (0.06342019780923039 - 0.06402588986309915) / 0.00019480871245159827
>>> L = 3
>>> YH = [1.71524262e-06, -1.24130739e-06, 1.88400737e-07]
>>> DKY = YH[-1]
>>> for JB in range(1, L):
...     DKY = [1.71524262e-06, -1.24130739e-06,  1.88400737e-07][2 - JB] + S * DKY
...
>>> DKY
7.395919849794794e-06

Thanks Scipy for making really awesome stuff.
I also ran into this problem. LSODA Fortran intdy() routine uses yh data (rwork[20 to end] sort of) to interpolate solution (states) only for within the last time stoda subroutine was called, so the last solver step. Scipy has written an interpolant object which allows the user to provide a time value which can be earlier than the time range of the last stoda step (and no warning is provided to user), while intdy() will error out for the same use case. I even had an exchange with Alan Hindmarsh about the operational scope of LSODA solution interpolation and he confirmed it's only the last step. Since Scipy essentially only allows the user to interact with LSODA in its itask=1 mode (integrate to some future time t_out), Scipy should then keep track of the time span of the last step, then restrict the user interpolation requests to that time span. or, let the user interact with LSODA with itask=2 (single stoda step mode).

@albert-mathews Thank you for contributing to the discussion. I am not sure I understand why you assume the SciPy interpolant can reach outside of the timestep. Is there a different timestep between LSODA and STODA? If not, all that SciPy does is concatenate each step-specific interpolant as the integration progresses, which then allows for interpolation across the full integration range. This issue described here corresponds to an erroneous choice in terms of how many terms should be included in Taylor's theorem and an erroneous scaling in one of the required terms. Out of curiosity, what do you think about the proposed changes in the PR associated with this issue?

@Patol75

If not, all that SciPy does is concatenate each step-specific interpolant as the integration progresses, which then allows for interpolation across the full integration range.

thanks for the clarification, i was not aware of that. It was not clear to me from looking at the code. it looks like Scipy is just fetching the latest rwork data from LSODA memory:

I read the PR, and I cannot comment as I'm familiar with the C implementation of LSODA, and not much the Fortran implementation, though it's highly likely the C implementation would share bugs if any. What I do know is that when I remove the time range check on intdy(), i get bogus interpolation back. When write my outer loops so as to ensure I'm only ever making calls to intdy() such that i can guarantee that time is within the last stoda step, i never get inaccurate interpolation results.
The way I understand it, when LSODA is requested to advance to some arbitrary future time tf starting from t, it may take any number of single steps, each step is performed by subroutine STODA. Typically the last step taken passes tf, and LSODA uses intdy() to find and return the solution at tf. For each STODA subroutine step (one step of length h), there is yh data written to the working memory, and this is used by intdy() to interpolate the solution from the last step. If t=0.0, tf=1.0, and the last step was 0.05s in length, and ended at 1.02, then the yh data in memory is only valid for interpolation of the solution between 0.97s and 1.02s. If the Fortran user calls intdy() with t=0.8, intdy() returns an error. If the Scipy user calls sol.sol with t=0.8s, Scipy returns a value.
My understanding is that the yh data is specific to the method (functional iteration or chord method), the order of the method, and the time range of the step (tn - h to tn, where tn is time after the completed step, and h is the step size). So if Scipy is saving each version of yh data after each step and concatenating (thus growing yh history with each stoda step), I would think it would also have to save the order, and time range associated with each given yh data, and for an arbitrary time provided by the user, it would first have to identify the set of yh and order data associated with the time range that contains the time provided by the user. If this is what Scipy is doing, then it was not evident to me from looking at Scipy code that it was doing this, so sorry for missing that.
Still, using sol.sol with LSODA, at least for me, results slightly inaccurate results in some cases (likely those for which the time request was not within the last stoda step), where as running the exact same code by switching solve_ivp to RK45, the problem goes away. If this is not the right place for reporting this, sorry for muddying the waters, please point me to the right place, and if it's helpful, ill provide the code to recreate.
thanks again for the response, and of course for creating such amazing python libraries. I have benefitted so much from Scipy, I am truly grateful. cheers.

That is valuable feedback, thanks for that.
Regarding the implementation in SciPy, I can give some details about solve_ivp. SciPy uses a while loop to make progress through the integration. The loop depends on the status of the integration, initially set to None and which can take the value 0, -1, or 1 at any loop step if integration successfully reaches the requested final ŧ value, fails or encounters a terminating event, respectively. At each loop step, solver.step() is called, and thereby, integration marches one step further. The rest of the loop mainly corresponds to dealing with keyword arguments provided by the user, such as t_eval, dense_output and events. What we are interested in here is solver.step() and solver.dense_output(), with the latter called when dense_output=True. solver.step(), if using LSODA, will call _step_impl in lsoda.py, and the FORTRAN code will run for one integration step. After the step completes, solve_ivp will call solver.dense_output() if requested, which, in turn, calls _dense_output_impl in lsoda.py. As a result, rwork is effectively accessed after every integration step. The result of _dense_output_impl is then stored in interpolants in solve_ivp at each loop step, and the final full interpolant is built through OdeSolution after execution left the while loop. I hope this clarifies what is being done.
Considering that you too experience inaccurate results through sol.sol with LSODA, could you compile the branch associated with the linked PR and report if results improve? That would definitely be helpful.

@Patol75
thanks  for the detailed explanation. this makes sense now.
We have stopped development on our python implementation and have switched to C. I cannot promise I'll will have time to go back and do this test, but if I do, I'll report my findings here.

@Patol75 I don't think I can review at this time.
@drhagen I see you have some history with this code. We're short on maintainers who are familiar with this code - would you be able to take a look at this?

@mdhaber I wrote the wrapper code around the solvers, but I don't know any of the math behind LSODA. If there is data not being copied properly or an array being improperly reused, I can help fix that, but if the branching or scaling or something mathy is wrong, I am not going to be much help.

Thanks @drhagen. Could you take a look at the OP's PR to fix this, gh-14552? If it doesn't fit your skill set, that's fine, but it's worth a look. Thanks!

@mdhaber I read through that PR when it first landed, but I can't help today anymore than I could then. The PR is not a standard bugfix. It claims that the original LSODA algorithm is wrong. We need an expert in numerical ODEs to judge the appropriateness of this solution, and that is not me. All I can say is that I am with Nikolay in that the addition of the alt_segment parameter to OdeSolution feels off, but that is not really the main issue of the PR anyway.

I’m not really an expert, but have done some stuff with numerical ODEs. I could start looking into this, but not until after I finish rewriting hyp2f1. I could probably get to it in around 6 months time if no one else does by then.

Hi @steppi,
Is reviewing gh-14552 still something you would consider? Thank you for your potential help.

Hi @steppi, Is reviewing gh-14552 still something you would consider? Thank you for your potential help.

Yes, thanks for the reminder. I still want to take a look at this but have been extremely busy. I can't promise anything but will do my best to get to it within a couple months. Please ping me again in two months if I haven't started looking into it by then.

@Patol75, I'm less busy now and can start taking a look at this next week. I'm a little astonished at how accurately I gauged when I would have time to do it. It will probably take me a couple weeks to review because I'm a little rusty on this stuff.

That is great news, thanks. The PR I set up should have everything you need to properly reproduce the error and confirm that the proposed fix works. If you want to dig deeper into the Fortran, good luck, but I am happy to also have a look and help if needed.

That is great news, thanks. The PR I set up should have everything you need to properly reproduce the error and confirm that the proposed fix works. If you want to dig deeper into the Fortran, good luck, but I am happy to also have a look and help if needed.

Thanks. I'm going to dig into the Fortran and also make sure I understand the math involved. I'll let you know if I have any questions.


Loading of types :decimal and :time

Issue was firstly posted here: https://elixirforum.com/t/ecto-time-and-decimal-types-throw-error-on-load-from-database/49494
Is there really lack of support for these types?

Thanks for the report, i missed those, fixed in version https://github.com/YgorCastor/ravix-ecto/releases/tag/v0.3.2

When I updated Ravix-Ecto, I started getting this error while compiling:
== Compilation error in file lib/ravix_ecto/parsers/query_parser.ex ==
** (CompileError) lib/ravix_ecto/parsers/query_parser.ex:386: Ravix.RQL.Tokens.Order.Field.__struct__/1 is undefined, cannot expand struct Ravix.RQL.Tokens.Order.Field. Make sure the struct name is correct. If the struct name exists and is correct but it still cannot be found, you likely have cyclic module usage in your code
    lib/ravix_ecto/parsers/query_parser.ex:383: (module)
could not compile dependency :ravix_ecto, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile ravix_ecto", update it with "mix deps.update ravix_ecto" or clean it with "mix deps.clean ravix_ecto"

When I updated Ravix-Ecto, I started getting this error while compiling:
== Compilation error in file lib/ravix_ecto/parsers/query_parser.ex ==
** (CompileError) lib/ravix_ecto/parsers/query_parser.ex:386: Ravix.RQL.Tokens.Order.Field.__struct__/1 is undefined, cannot expand struct Ravix.RQL.Tokens.Order.Field. Make sure the struct name is correct. If the struct name exists and is correct but it still cannot be found, you likely have cyclic module usage in your code
    lib/ravix_ecto/parsers/query_parser.ex:383: (module)
could not compile dependency :ravix_ecto, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile ravix_ecto", update it with "mix deps.update ravix_ecto" or clean it with "mix deps.clean ravix_ecto"

Can you do a mix deps.clean and mix deps.update --all? It can be a mismatch or corrupted dependency. I'm using the same version right now/

Okay, I found the problem. I was using outdated version of Ravix. For future I should look at package versions on hex.pm instead Github releases. Anyway big thanks for help!


Cannot truncate a table referenced in a foreign key constraint

I've need to use the cities table as a FK in another table. But the seeders call db:truncate before seeding and thus I get this error:
Cannot truncate a table referenced in a foreign key constraint (db.addresses, CONSTRAINT addresses_city_id_foreign FOREIGN KEY (city_id) REFERENCES db.cities (id)) (SQL: truncate cities)
There is no need for db:truncate since we can use migrate:refresh or migrate:fresh to reset the entire database and keep the integrity of the ids.
PR #30

@ichtrojan can you do this for me?


Corral update error

I get a lot of errors if I use the following corral.json and run corral update before running corral fetch.
{
  "deps": [
    {
      "locator": "github.com/niclash/jay.git"
    },
    {
      "locator": "github.com/ponylang/crypto.git"
    },
    {
      "locator": "github.com/niclash/pony-metric.git"
    },
    {
      "locator": "github.com/niclash/jennet.git"
    },
    {
      "locator": "github.com/niclash/pony-websocket.git"
    },
    {
      "locator": "github.com/ponylang/http.git"
    }
  ],
  "info": {}
}

Some of the errors:
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_regex
Error loading dep bundle: github_com_ponylang_regex
  exit: Exited(128)
  out:
  err: fatal: Unable to create '/home/sean/tmp/ctest/_repos/github_com_ponylang_regex_git/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_regex
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_regex
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_net_ssl
  exit: Exited(128)
  out:
  err: error: unable to create file /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl/assets/cert.pem: File exists

It looks like an error in transitive dependency code.

Doesn't happen if the corral.json is only:
{
  "deps": [
    {
      "locator": "github.com/ponylang/http.git"
    }
  ],
  "info": {}
}

It appears to be sometimes run two checkouts at the same time for the same tag and repo:
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_regex
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl

You can see here that it is doing it many times:
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_net_ssl
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_regex
Error loading dep bundle: github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_regex
Error loading dep bundle: github_com_ponylang_net_ssl
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_net_ssl
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_net_ssl
git checking out @1.0.0 into /home/sean/tmp/ctest/_corral/github_com_ponylang_net_ssl
Error loading dep bundle: github_com_ponylang_net_ssl

and just happens to not run them at the same time.

So with this corral.json:
{
  "deps": [
    {
      "locator": "github.com/niclash/pony-metric.git"
    },
    {
      "locator": "github.com/niclash/jay.git"
    }
  ],
  "info": {}
}

I get this result:
update: updating from /home/sean/tmp/ctest
update: will load dep: github.com/niclash/pony-metric @
update: will load dep: github.com/niclash/jay @
git cloning github.com/niclash/pony-metric.git into /home/sean/tmp/ctest/_repos/github_com_niclash_pony_metric_git
git cloning github.com/niclash/jay.git into /home/sean/tmp/ctest/_repos/github_com_niclash_jay_git
git checking out @master into /home/sean/tmp/ctest/_corral/github_com_niclash_jay
git fetching github.com/niclash/pony-metric.git into /home/sean/tmp/ctest/_repos/github_com_niclash_pony_metric_git
Error loading dep bundle: github_com_niclash_jay
git checking out @master into /home/sean/tmp/ctest/_corral/github_com_niclash_pony_metric
Error loading dep bundle: github_com_niclash_pony_metric
git checking out @master into /home/sean/tmp/ctest/_corral/github_com_niclash_pony_metric
Error loading dep bundle: github_com_niclash_pony_metric

You'll note we try to check out pony-metric twice.
It appears that there's a bug where because there are 2 dependencies it tries checking out the last corral.json entry twice.
With more than 2 entries, this would probably change in same way as you can see even more check outs in earlier errors.
So, this isn't a transitive dependency error. It's a more than 1 thing in corral.json error.

Ok, I know the problem but not the fix.
All checkout, fetch etc actions are processed via a called to ProcessMonitor in the primitive Runner.
Interactions with the process monitor are async.
However...
in   be collect_dep_tags(locator: Locator, tags: Array[String] val) =>
for the updater... at the end it calls try_complete
which does this...
if deps_to_load.size() > 0 then
  ctx.log.fine("try_complete still have deps to load: " + deps_to_load.size().string())
  load_queued_deps()

so that "load queued deps" will see "o hey, we haven't finished with every dep, so lets run them" even though they are all running already.
the more deps, the worse this gets.
try complete is a nice idea, but we need more smarts.
we need to know not only are there other deps to load BUT... have the failed before doing anything.
I think try_complete might be needed to deal with transitive dependencies.
i'll test that later.

so transitive dependency fetching works fine with that try_complete removed. I'm not sure what, if anything, it is useful for. I'm included to remove it.

so starting from ponylang/glob works. it has a single transitive dependency.
i want to test with a fake one that goes a -> b -> c with and without try_complete to see if it works.

Ok, a -> b -> c works with no try_complete.
There's no documentation for try_complete, so I'm saying that can be removed. If it turns out later it was needed, then we can figure out how to address then as it is buggy now.

I'll open a PR for this soon.

So I looked further and discovered further issues. The try_complete was really a symptom of a larger problem.
The real issue is a mixing of OOP and FP idioms as well as async and synchronous.
The problems should go away however if the queueing of dependencies to load in cmd_update goes away:
https://github.com/ponylang/corral/blob/master/corral/cmd/cmd_update.pony#L44
The issue is that we queue these dependencies then start queueing up asynchronous updates to them. If transitive dependencies are found during any of those asynchronous updates, it calls load_bundle_deps to queue up new dependencies to look up (adding them to the existing queue) and then calls load_queued_deps.
It's this call to load_queued_deps where things really go sideways. Because we have a single _Update actor, there's a single queue of deps to load. This makes sense, if multiple bundles share a dependency, we need to serializing loading (and ideally deduping) otherwise, we can end up with two simultaneous attempts to modify a repos checkout. Bad things would happen if that was the case.
So, its a single queued list in a single actor. However, because we of said transitive dependency check about. If a bundle as more than 1 locator AND those each have a corral.json, the following will happen.

Queue to load is 2 locators
Both are figured out in terms of future actions to happen. Those actions result in 1 message per locator being sent to the _Updater actor
Start processing locator 1 because of 1 of the messages generated in the previous step
Hit transitive dependency check. The corral.json can be empty.
From transitive code, call load_bundle_deps to add new dependencies to the queue.
Add 0 to * new dependencies to the queue
Call load_queued_deps at the end of load_bundle_deps
There will be 1 or more locators in the queue at this time (the 1 of the 2 from our beginning state, plus any new transitive additions)
The 1 locator from our beginning state already has a message sent to _Updater in to process it. However, because it is still in the queue at this time, ANOTHER message will be queued up for it and sent to _Updater so it will be repeated.
The more locators, the worse this will get.

Based on this comment when locators are removed from the work queue, it appears this was intentional and the buggy nature of it wasn't perceived at the time.
The logic in the fetch command works correctly in the same scenario and should be replicated.
Interestingly, the fetch style logic is how Update originally worked but was changed in this commit. Unfortunately, the commit doesn't explain why the recursion and queuing was added. I'm assuming that Carl didn't realize the bug that was being introduced.
The important difference with Fetch is that is tracks what it has fetched and will not fetch it again if seen. That allows us to avoid the "processing the queue multiple times" issue. The way Fetch is implemented is A-OK, the change to Update that was introduced at the same time, not so much.

I've started working on getting this to be something we can unit test, its currently very hard and there aren't any unit tests for any of the commands (or really any unit tests in general).

Test for this is here:
https://github.com/ponylang/corral/pull/128


Devtools change the behavior of source code

I create computed value base on DOM element getBoundingClientRect() data.

starPosition: function() {
if (this.$refs["icon"]) {
let bounds = this.$refs["icon"].getBoundingClientRect();
let xy = {
x: bounds.x + this.left,
y: bounds.y + this.top
};
console.log(xy)
return xy;
} else {
let xy = {
x: 0,
y: 0
};
console.log(xy)
return xy;
}
}

console.log(xy) not write any in the console.
But if select root element in devtool it's starting to log data.
If there any watcher on starPosition. I.e. {{starPosition}} or watch: {starPosition: ...} this behavior is not observed.
Source: https://pastebin.com/0jb6GU8N
Video: https://www.youtube.com/watch?v=qJTy8Gt6kN0

$refs are not reactive and on entering the computed property, it skips the code that uses this.top and this.left and therefore Vue thinks that starPosition doesn't have any dependency. You need to make sure Vue can track that dependency if (this.left || this.top || this.$refs["icon"]) { should work.
With the devtools opened and the vue instance selected, you probably trigger another call on computed, that's why they appear later


AMScrollingNavbar broke post Cocoapods integration

Solution: https://github.com/yoha/Notes/commit/7913cdeaa8a86bb03ee31932a8c1cd76542a1565


Flutter inspector: Toggle select Widget Mode crashes

Steps to Reproduce
On tapping the 'Toggle Select Widget Mode button' in the Flutter Inspector (IntelliJ IDEA) I get this error:

Logs
IntelliJ console output
Launching lib/main.dart on iPhone X in debug mode...
Starting Xcode build...
Xcode build done.                                            8.5s
Syncing files to device iPhone X...
flutter: ══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
flutter: The following assertion was thrown building Title(color: MaterialColor(primary value:
flutter: Color(0xff2196f3))):
flutter: 'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 2158 pos 12:
flutter: 'WidgetInspectorService.instance.selectionChangedCallback == null': is not true.
flutter:
flutter: Either the assertion indicates an error in the framework itself, or we should provide substantially
flutter: more information in this error message to help you determine and fix the underlying cause.
flutter: In either case, please report this assertion by filing a bug on GitHub:
flutter:   https://github.com/flutter/flutter/issues/new?template=BUG.md
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #2      _WidgetInspectorState.initState (package:flutter/src/widgets/widget_inspector.dart:2158:12)
flutter: #3      StatefulElement._firstBuild (package:flutter/src/widgets/framework.dart:3830:58)
flutter: #4      ComponentElement.mount (package:flutter/src/widgets/framework.dart:3696:5)
flutter: #5      Element.inflateWidget (package:flutter/src/widgets/framework.dart:2950:14)
flutter: #6      Element.updateChild (package:flutter/src/widgets/framework.dart:2753:12)
flutter: #7      ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #8      Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #9      StatelessElement.update (package:flutter/src/widgets/framework.dart:3781:5)
flutter: #10     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #11     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #12     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #13     ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #14     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #15     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #16     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #17     ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #18     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #19     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #20     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #21     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #22     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #23     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #24     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #25     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #26     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #27     ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #28     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #29     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #30     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #31     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #32     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #33     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #34     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #35     ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #36     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #37     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #38     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #39     ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #40     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #41     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #42     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #43     StatelessElement.update (package:flutter/src/widgets/framework.dart:3781:5)
flutter: #44     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #45     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #46     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #47     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #48     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #49     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #50     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #51     ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #52     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #53     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #54     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #55     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #56     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #57     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #58     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #59     StatelessElement.update (package:flutter/src/widgets/framework.dart:3781:5)
flutter: #60     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #61     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #62     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #63     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #64     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #65     StatelessElement.update (package:flutter/src/widgets/framework.dart:3781:5)
flutter: #66     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #67     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #68     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #69     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #70     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #71     RenderObjectElement.updateChildren (package:flutter/src/widgets/framework.dart:4585:32)
flutter: #72     MultiChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4975:17)
flutter: #73     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #74     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #75     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #76     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #77     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #78     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #79     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #80     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #81     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #82     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #83     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #84     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #85     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #86     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #87     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #88     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #89     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #90     SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #91     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #92     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #93     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #94     StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #95     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #96     ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #97     Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #98     StatelessElement.update (package:flutter/src/widgets/framework.dart:3781:5)
flutter: #99     Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #100    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #101    Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #102    StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #103    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #104    SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #105    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #106    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #107    Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #108    ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #109    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #110    SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #111    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #112    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #113    Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #114    StatefulElement.update (package:flutter/src/widgets/framework.dart:3878:5)
flutter: #115    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #116    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #117    Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #118    StatelessElement.update (package:flutter/src/widgets/framework.dart:3781:5)
flutter: #119    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #120    SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:4867:14)
flutter: #121    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #122    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #123    Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #124    ProxyElement.update (package:flutter/src/widgets/framework.dart:3990:5)
flutter: #125    Element.updateChild (package:flutter/src/widgets/framework.dart:2742:15)
flutter: #126    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3732:16)
flutter: #127    Element.rebuild (package:flutter/src/widgets/framework.dart:3547:5)
flutter: #128    BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:2286:33)
flutter: #129    _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding&WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:676:20)
flutter: #130    _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:219:5)
flutter: #131    _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:990:15)
flutter: #132    _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:930:9)
flutter: #133    _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:842:5)
flutter: #134    _invoke (dart:ui/hooks.dart:154:13)
flutter: #135    _drawFrame (dart:ui/hooks.dart:143:3)
flutter: (elided 2 frames from class _AssertionError)
flutter: ════════════════════════════════════════════════════════════════════════════════════════════════════

flutter doctor -v :
[✓] Flutter (Channel beta, v1.0.0, on Mac OS X 10.14.1 18B75, locale en-IN)
    • Flutter version 1.0.0 at /Users/rumaankhalander/Flutter/flutter
    • Framework revision 5391447fae (3 weeks ago), 2018-11-29 19:41:26 -0800
    • Engine revision 7375a0f414
    • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)
    • Android SDK at /Users/rumaankhalander/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[!] iOS toolchain - develop for iOS devices (Xcode 9.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.3.1, Build version 9E501
    ✗ Verify that all connected devices have been paired with this computer in
      Xcode.
      If all devices have been paired, libimobiledevice and ideviceinstaller may
      require updating.
      To update with Brew, run:
        brew update
        brew uninstall --ignore-dependencies libimobiledevice
        brew uninstall --ignore-dependencies usbmuxd
        brew install --HEAD usbmuxd
        brew unlink usbmuxd
        brew link usbmuxd
        brew install --HEAD libimobiledevice
        brew install ideviceinstaller
    • ios-deploy 2.0.0
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build
      1.8.0_152-release-1136-b06)

[✓] IntelliJ IDEA Community Edition (version 2018.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 29.0.2
    • Dart plugin version 181.4203.498

[✓] VS Code (version 1.30.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.21.1

[✓] Connected device (1 available)
    • iPhone X • 7011A89B-7A8A-473C-BEAF-870C623A6E53 • ios • iOS 11.3
      (simulator)

! Doctor found issues in 1 category.

Attached Dart File (in zip):
fileio.dart.zip

I can reproduce with the reduced code below when I nest MaterialApp.
This is again a great example why a reproduction should be complete and runnable including main() {}
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      home: FileioPage(),
    );
  }
}

class FileioPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
        home: Scaffold(
      body: Container(),
    ));
  }
}

[✓] Flutter (Channel master, v1.1.4-pre.9, on Mac OS X 10.14.1 18B75, locale en-AT)
    • Flutter version 1.1.4-pre.9 at /Users/zoechi/flutter/flutter
    • Framework revision 3d8aec2b99 (3 days ago), 2018-12-19 20:09:07 -0800
    • Engine revision 5ec8ef8509
    • Dart version 2.2.0 (build 2.2.0-dev.1.1 f9ebf21297)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /usr/local/opt/android-sdk
    • Android NDK at /usr/local/opt/android-sdk/ndk-bundle
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /usr/local/opt/android-sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[!] iOS toolchain - develop for iOS devices (Xcode 10.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.1, Build version 10B61
    ✗ Verify that all connected devices have been paired with this computer in Xcode.
      If all devices have been paired, libimobiledevice and ideviceinstaller may require updating.
      To update with Brew, run:
        brew update
        brew uninstall --ignore-dependencies libimobiledevice
        brew uninstall --ignore-dependencies usbmuxd
        brew install --HEAD usbmuxd
        brew unlink usbmuxd
        brew link usbmuxd
        brew install --HEAD libimobiledevice
        brew install ideviceinstaller
    • ios-deploy 1.9.4
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 23.1.2
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[✓] IntelliJ IDEA Ultimate Edition (version 2018.2.5)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin version 30.0.2
    • Dart plugin version 182.5124

[✓] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 9 (API 28) (emulator)

! Doctor found issues in 1 category.

@zoechi Is this a flutter-intellij issue?

Why would you want to nest MaterialApp?
I'd say just don't do it.
Perhaps there could be a better error message.

@zoechi Ok thank you! I just removed the inner MaterialApp and it works! 😄

Bumping up the priority. This assert can safely be ignored and we need to start ignoring it instead of crashing users.

Hi @zoechi
Not able to reproduce this issue on latest Android Studio and dev channel

flutter doctor -v
[✓] Flutter (Channel dev, v1.18.0-8.0.pre, on Mac OS X 10.15.4 19E287, locale
    en-GB)
    • Flutter version 1.18.0-8.0.pre at /Users/taha/Code/flutter_dev
    • Framework revision e0c63cd35e (5 days ago), 2020-04-23 22:29:01 -0400
    • Engine revision d2ec21221e
    • Dart version 2.9.0 (build 2.9.0-3.0.dev b0d35855d8)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/taha/Code/sdk
    • Platform android-29, build-tools 29.0.3
    • ANDROID_HOME = /Users/taha/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4.1, Build version 11E503a
    • CocoaPods version 1.9.1
[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 45.1.1
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.9.1
[✓] Connected device (5 available)
    • SM M305F      • 32003c30dc19668f          • android-arm64  • Android 10
      (API 29)
    • Taha’s iPhone • 00008020-001059882212002E • ios            • iOS 13.4.1
    • macOS         • macOS                     • darwin-x64     • Mac OS X
      10.15.4 19E287
    • Web Server    • web-server                • web-javascript • Flutter Tools
    • Chrome        • chrome                    • web-javascript • Google Chrome
      81.0.4044.129
• No issues found!

if you're still experiencing this problem, please create a new issue and provide the information
required in the template.
Thank you


Unclear window name for compositor exclusion

Hello!
I'm running gnome-pie under openbox and I think it's the best launcher for my set up; however, I'm unable to figure out how to add it to the exclusions for compton for casting a shadow. Not doing so appears to cause strange visual effects.
Normally, this exclusion would be done by adding the application name to the compositor; however, I'm unable to identify what to use. I've tried "gnome-pie", "pie", and the names of individual pies to no avail.
Do you have any suggestions for exclusions to try?
Thanks in advance.

Hey! I recommend Googling (or DuckDuckGo-ing) "how to identify window in openbox". I know KDE has some built-in tools for it, but maybe OpenBox has as well. If not, then maybe there is a window-manager independent X11 solution for getting a window's name. This question doesn't sound like a problem with Gnome-Pie itself. But I get it might be difficult to find a place to ask this, I would recommend askubuntu.com for all beginner friendly Linux questions. Out of all the StackExchange sites I use that one the most.
That said. My KDE thing is telling me the following information:
Class: gnome-pie-109 (gnome-pie gnome-pie-109)
Role:
Type: Dock (panel)
Title: Gnome-Pie
Machine: mypchostname

Hope that helps!


Add ability to restart vscode extension

It would be cool to have such feature because the extension sometimes is not working as expected. Related: https://github.com/vuejs/language-tools/issues/4037

Just restart the TS Server, that will have the same effect.


feat: added extendSession() method to Browser Client

Summary
** Add extendSession() method to Browser SDK to allow customers to extend the current session without sending events / using quota.
amplitude.extendSession();

Checklist

[x] Does your PR title have the correct title format?
Does your PR have a breaking change?:  No

we should also update the snippet loader to include the new public facing method


[BUG] + button in FAQ overlap issue

Description

Button in FAQ section overlaps with the text content. I would like to fix that, kindly assign.

Screenshots

Any additional information?
No response
What browser are you seeing the problem on?
Chrome
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I have read the discussion tab thoroughly and got the project idea
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

@Devil1205 go for it :)


Mode in API request

Description
Hi,Is it necessary to put "mode" in the API request? This wasn't there before and I have no idea whether the API will work properly if I don't include the mode.
Issue Type
Support
Operating System
Linux
Do you use Docker?
I don't use Docker

https://github.com/zfcsoftware/cf-clearance-scraper/blob/767c2808ad055c9aa2f7101c5c6d2d03fd33c789/src/module/reqValidate.js#L12
Hello is mandatory. The library has been rewritten and many additions have been made. Please check the use cases in the readme file.


[NME] Adding a Voronoi block for 2D noise

We have a Worley block for 3D noise, but it would be great to have a 2D Voronoi block for things like texture manipulation without the calculations for the extra dimension in the noise.
Inputs

UVs (vector2)
Point Offset (float)
Cell Density (float)

Output

Noise (float)
Cells data (float)

Closing for now as the WorleyNoise can output 2d and 1d values now


do not set DeploymentGroup to FAILED when ignoreFailure is true

When rolloutOptions.ignoreFailures is true, the RollingUpdateOpFactory will
quietly transition to the next task in the deployment group's rollout plan
(the DeploymentGroupTasks object) when one of the overlaods for error(..)
is called.
This will have the effect of moving the rolling update to the next task in
the plan when the group/rollout otherwise would have FAILED, only if the
ignoreFailures option is set to true.
At first glance one problem with this method of internally returning the
result of nextTask() when error(..) is that sometimes nextTasks is
called with a list of ZookeeperOperations supplied as a parameter by the
calling code; however, this only occurs when the ZookeeperMasterModel is
first processing an action of DEPLOY, MARK_UNDEPLOYED or UNDEPLOYED. The
overload of nextTasks() with no argument is called whenever the task
action is AWAIT_RUNNING and the task reaches running, therefore it should
be safe (unless the callers are refactored).
This is an alternate approach to #1103 to try to achieve the same goals but
with less downside.

the first commit (to add this to the CLI and client) is the same; only the server-side implementation is changed compared to #1103
@gimaker

Codecov Report

Merging #1105 into master will decrease coverage by 0.03%.
The diff coverage is 68%.

@@             Coverage Diff              @@
##             master    #1105      +/-   ##
============================================
- Coverage        52%   51.96%   -0.04%
- Complexity     1571     1575       +4
============================================
  Files           266      266
  Lines         12759    12779      +20
  Branches       1469     1473       +4
============================================
+ Hits           6635     6641       +6
- Misses         5620     5634      +14
  Partials        504      504

Continue to review full report at Codecov.

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

@spotify/helios-team

Add ignore-failures to user output as well.

https://github.com/spotify/helios/blob/051622b2fb1bea279c40f655cb23892580345c9e/helios-tools/src/main/java/com/spotify/helios/cli/command/RollingUpdateCommand.java#L176
https://github.com/spotify/helios/blob/051622b2fb1bea279c40f655cb23892580345c9e/helios-tools/src/main/java/com/spotify/helios/cli/command/RollingUpdateCommand.java#L186

One difference I noticed between this and #1103 is that here a failing health check will need to exceed the default rolling-update timeout duration for AWAIT_RUNNING before the rollout moves onto the next host.
In #1103 a failing health check won't stall the rollout because the AWAIT_RUNNING task is never inserted into the rollout plan.
As a user, it'd be nice not to have to wait for health checks if I don't care if they fail anyways.

Another difference is that now all these errors will also be ignored. Which might be fine. But then the description for the switch should be updated to say instead of "take down your service by rolling out a broken job" that the job might not even be attempted to be deployed because, for example, empty token.

Testing this locally:
# two hosts in my cluster
$ bin/helios -z http://localhost:5801 hosts
running in helios project, using /Users/mattbrown/code/helios/helios-tools/target/helios-tools-0.9.0-SNAPSHOT-shaded.jar
HOST              STATUS           DEPLOYED    RUNNING    CPUS    MEM     LOAD AVG    MEM USAGE    OS                  HELIOS            DOCKER               LABELS
host2.            Up 1 minute      0           0          4       8 gb    1.85        1.00         Mac OS X 10.12.4    0.9.0-SNAPSHOT    17.03.1-ce (1.27)    foo=bar
mattbrown-air.    Up 30 seconds    0           0          4       8 gb    1.72        1.00         Mac OS X 10.12.4    0.9.0-SNAPSHOT    17.03.1-ce (1.27)    foo=bar

# create a DG for the two hosts
[mattbrown@mattbrown-air helios]$ bin/helios -z http://localhost:5801 create-deployment-group my-group foo=bar
running in helios project, using /Users/mattbrown/code/helios/helios-tools/target/helios-tools-0.9.0-SNAPSHOT-shaded.jar
Creating deployment group: {"hostSelectors":[{"label":"foo","operand":"bar","operator":"EQUALS"}],"name":"my-group"}
{"status":"CREATED"}

# create a job for an image that does not exist (as an example of something that would otherwise fail the rollout/group)
$ bin/helios -z http://localhost:5801 create failing-job:1 registry.spotify.net/dev/null:does-not-exist
running in helios project, using /Users/mattbrown/code/helios/helios-tools/target/helios-tools-0.9.0-SNAPSHOT-shaded.jar
Creating job: {"addCapabilities":[],"command":[],"created":null,"creatingUser":null,"dropCapabilities":[],"env":{},"expires":null,"gracePeriod":null,"healthCheck":null,"hostname":null,"id":"failing-job:1","image":"registry.spotify.net/dev/null:does-not-exist","metadata":{},"networkMode":null,"ports":{},"registration":{},"registrationDomain":"","resources":null,"secondsToWaitBeforeKill":null,"securityOpt":[],"token":"","volumes":{}}
Done.
failing-job:1:9044bc35b5183426216de2668c564c2267be97cc

# do a normal rollout of this job - the first host times out after 300 seconds because the image is not found, and then the group is failed
$ bin/helios -z http://localhost:5801 rolling-update failing-job:1 my-group
running in helios project, using /Users/mattbrown/code/helios/helios-tools/target/helios-tools-0.9.0-SNAPSHOT-shaded.jar
Rolling update started: my-group -> failing-job:1:9044bc3 (parallelism=1, timeout=300, overlap=false, token=)

Failed: host2: timed out waiting for job failing-job:1:9044bc35b5183426216de2668c564c2267be97cc to reach state RUNNING due to missing Docker image (terminal job state FAILED, previous states: PULLING_IMAGE->FAILED->PULLING_IMAGE->FAILED->PULLING_IMAGE->FAILED)
Duration: 303.24 s

# do the same operation with --ignore-failures
$ bin/helios -z http://localhost:5801 rolling-update --ignore-failures failing-job:1 my-group
running in helios project, using /Users/mattbrown/code/helios/helios-tools/target/helios-tools-0.9.0-SNAPSHOT-shaded.jar
Rolling update started: my-group -> failing-job:1:9044bc3 (parallelism=1, timeout=300, overlap=false, token=)

Done.
Duration: 606.91 s

# the rollout took 2 * 300 seconds, but was left in an ACTIVE state even though the job failed on each host:
$ bin/helios -z http://localhost:5801 deployment-group-status my-group
running in helios project, using /Users/mattbrown/code/helios/helios-tools/target/helios-tools-0.9.0-SNAPSHOT-shaded.jar
Name: my-group
Job Id: failing-job:1:9044bc3
Status: ACTIVE
Host selectors:
  foo = bar

HOST              UP-TO-DATE    JOB                      STATE
host2.            X             failing-job:1:9044bc3    FAILED
mattbrown-air.    X             failing-job:1:9044bc3    FAILED

With this change, rolling out a "bad" job to an individual host still takes the entire timeout duration - but a failure of a host does not impact the rest of the rollout or the final status of the group.

@davidxia

Add ignore-failures to user output as well.

done in 746da8a

As a user, it'd be nice not to have to wait for health checks if I don't care if they fail anyways.

Yeah, I agree, but I am not sure the best way to find the balance between the way this implementation (follow through the normal steps and respect the parallelism setting, but never set the state to FAILED) versus what #1103 did (remove AWAIT_RUNNING and just roll through every undeploy/deploy practically at the same time).
I think this might be the better choice so that we can a) be sure the status is never failed if the user told us to --ignore-failures and b) still respect parallelism/overlap/etc settings so that the rolling-update has the same general plan as always, except that the failure is ignored.

@davidxia I've also updated the field's help message:
When specified, the rolling-update will ignore *all* failures and will proceed
to deploying the job to all hosts in the deployment group. The rolling-update
will go through the normal rollout plan (respecting the --par and --overlap
settings), and will wait for the job to reach RUNNING on each host as normal;
however, any failure that would otherwise cause the rolling-update to abort and
set the deployment group's status to FAILED is *ignored*. Be *VERY* careful
about using this option, as it has the potential to completely take down your
service by rolling out a broken job to all of the hosts in your group.


Variable in calc() fails to interpolate

// ok
element {
  height: calc(100% - 50px)
}
/* =>
element {
  height: calc(100% - 50px)
}
*/

// fails to interpolate! $a appears in the compiled output
$a: 50px
element {
  height: calc(100% - $a)
}
/* =>
element {
  height: calc(100% - $a)
}
*/

This a known issue in Sass. It will be fixed in node-sass once it's fixed in Sass.
https://github.com/sass/sass/issues/818


Make releases more often?

The latest release was a long time ago, on January 2020, so about 2 and half years ago.
Although it is possible to import gems via GitHub, most people will really use the tagged version via Ruby Gems.
Having more frequent releases would be awesome so people would be really benefiting from the most recent changes.

I agree.  I think this gem has been fairly stagnant for a while. I'm hoping we can get it moving again now we've got GH Actions happening for CI so we can release with more confidence.

@andreynering New release just published to RubyGems now.


PurgeJmsQueuesAction not purging all the messages on the queue

The PurgeJmsQueuesAction is not purging all the messages on the queue.
In the method purgeDestination a new messageConsumer is created every time in the do-while loop.
This should be only created once, and moved out of the do-while loop. In my implementation this consumes the only 2 - 6 messages unpredictably. When moved out of the do-while loop it consumes all the messages instantly from the queue. My implementation is done with SonicMQ broker.
The method that works well with my implementation is follows:
private void purgeDestination(Destination destination, Session session, String destinationName) throws JMSException {
    if (log.isDebugEnabled()) {
        log.debug("Try to purge queue " + destinationName);
    }
    MessageConsumer messageConsumer = null;
    try {
        javax.jms.Message message;
        messageConsumer = session.createConsumer(destination);
        do {
            message = (receiveTimeout >= 0) ? messageConsumer
                    .receive(receiveTimeout) : messageConsumer.receive();
            if (message != null && log.isDebugEnabled()) {
                log.debug("Removed message from queue " + destinationName);
            }
        } while (message != null);
        JmsUtils.closeMessageConsumer(messageConsumer);
    } finally {
        JmsUtils.closeMessageConsumer(messageConsumer);
    }
}

Greetings.

I've seen the same thing with ActiveMQ

I will have to think about implementing explicit purge actions using the JMS message broker API instead of having a generic purge approach as before. Unfortunately purge operaitons in JMS message broker API are not standardized. Hm, that's a tough one I think. However thank you for pointing to this one again.


Helper methods for device attestation  PR

Problem
Provide data access methods for device attestation PR (#8435)
Change overview

Construct Attestation Elements TLV
Deconstruct Attestation Elements TLV
Sign and Validate Attestation Info
Extract Authority Key Id from x509 Certificate
Extract Vendor ID from Attestation x509 Certificate
Added new unit tests to support testing of new methods
Added Generic Implementation of methods to retrieve DAC/PAI/PAA Certificates
Added Generic Implementation of methods to retrieve Certification Declaration
Added Generic Implementation of methods to retrieve Attestation Signature

Testing
Matter unit tests

Note stale, still in progress from @mleisner

From offline convos w/ @mleisner, updates to come in next few days. Action occurring in fork daily, but not ready for mainline. Not stale.


[ENHANCE] Navbar: Replace pot emoji with png

Summary
Currently navbar uses pot emoji, which displays differently on different devices. Using a PNG instead would provide for consistent display across devices.
However, lowest quality PNG export option on Figma for this icon is 1.5KB, and we are trying to avoid large icons which can provide issues for users, and using native emoji is only one byte.
TBD how to proceed with this.
Motivation
[More detailed explanation of the motivation for the enhancement, including any benefits it would provide]
Description
[Detailed description of the enhancement, including how it would work and any design considerations]
Alternatives
[Discussion of any alternative solutions that were considered and why the proposed solution is preferred]
Risks
[Identification and mitigation of any potential risks associated with the enhancement]
Acceptance Criteria
[List of criteria that must be met for the enhancement to be considered accepted]
Additional Information
[Any other relevant information, such as links to related issues or pull requests]

Closing as duplicated in https://github.com/PotLock/bos-app/issues/441


pex reactor fixes

See TODO's in pex_reactor.go.
Namely, remove peers, prevent abuse, improve some logic.

The addrbook was taken from conformal/BTCD, so updates might be incorporated from there too.

@ebuchman is the simple counter ("not more than 1000 messages per hour") enough to prevent abuse?

Implemented a simple counter per peer.


Loading state preventing closeButton dismiss to work

Describe the feature / bug 📝:
Currently closeButton is not working when toast is in loading state.
Steps to reproduce the bug 🔁:

Go to https://sonner.emilkowal.ski/
Click on Promise button
Try to dismiss the toast using the closeButton while in loading state.

The reason a toast of type loading does not close is due to the condition set in the code. Specifically, in the Toast component, there are checks to prevent the automatic closing of a loading toast.
// https://github.com/emilkowalski/sonner/blob/main/src/index.tsx#L175
if ((toast.promise && toastType === 'loading') || toast.duration === Infinity || toast.type === 'loading') return;

This logic ensures that if the toast has a loading type, it will not proceed with the auto-close functionality.
It seems that the toast is prevented from closing while loading to ensure that the user can see the completed result.
It does not seem to be a bug.


Drop default to oneway=yes for highway=motorway_link

When adding a highway=motorway_link, iD automatically adds oneway=yes. In addition, it complains about missing oneway=yes if oneway=* is missing.
While there might be a default oneway value for motorways in OSM, there is no such for their link roads. There are too many motorway links which are (and should be) mapped as one way for both directions because they have no physical separation between forward and backward lanes.
The current oneway handling seems to be introduced after issue #4727. I agree that adding explicit tagging in this single case might be helpful but assuming defaults should happen with caution.
Therefore, I would like to ask

to remove this default from the tagging preset and
to remove the default operation from the validation rule and changing the wording to something like "explicitly adding oneway=yes/no is recommended for the sake of clarity"

The default of the preset is not needed any more since iD has validation rules warning its users.
EDIT: Changed reference to correct ticket.

I think #2555 adds the explicit oneway=yes (per wiki direction) and #4727 changed the message so that a missing oneway tag doesn't display the message "Assumed to be yes" anymore (also I guess per wiki direction).

The default of the preset is not needed any more since iD has validation rules warning its users.

Yes, I think defaulting the tag is still important.  We don't want to let users add stuff and then use the validator to nag them that it's incomplete.  That's just mean.

generally, defaults in OpenStreetMap mean fallback if not explicitly stated. According to user feedback iD currently even changes oneway=no to yes when you apply the motorway link preset, is this intentional?

iD currently even changes oneway=no to yes when you apply the motorway link preset, is this intentional?

Yes, again please see #2555
It even says on there "Pointed out by @dieterdreist." so it sounds like you asked for this feature and we added it for you over 4 years ago.

IMHO it would be better to ask the mapper when she applies the preset: is it a oneway road? yes / no / dunno

iD doesn't ask users questions like this.. It would get very tedious to get asked for every road whether you wanted it to be oneway or not.
Anyway I will remove the default oneway=yes for motorway links.. It doesn't look like we do this for any of the other _link roads, so it seems weird to add it for these ones.

sent from a phone

Il giorno 4 nov 2019, alle ore 01:24, Bryan Housel<EMAIL_ADDRESS>ha scritto:
Yes, again please see #2555
It even says on there "Pointed out by @dieterdreist." so it sounds like you asked for this feature and we added it for you over 4 years ago.

no, from what I read there it seems I pointed out that explicit oneway-tagging is common for motorway links, but surely I didn’t say that 4% error rate is fine (i.e. tagging them all as oneway=yes).

IMHO it would be better to ask the mapper when she applies the preset: is it a oneway road? yes / no / dunno
iD doesn't ask users questions like this.. It would get very tedious to get asked for every road whether you wanted it to be oneway or not.

not for every road, for every motorway link...


Start markdown

This is an <h1> header, which is the largest
This is an <h2> header
This is an <h6> header, which is the smallest

we learn to use h1 ,h2, andh6


feat(webhook): Add GitLab webhook end-point.

Add a dedicated GitLab webhook end-point for push events on a
GitLab-hosted project.
The GitLab webhook end-point must be separate from GitHub as the
contents of GitLab's POST message, resulting from a push event, has
different payload data than what is found in an equivalent GitHub POST.
Closes #1442

I don't have a gitlab account, but is there a good way for us to test this locally? Or have you run it locally and confirm that it works?

I'm hesitant on mangling data to fit the existing test case here. I'd rather this test what we can expect to see from Gitlab more precisely.

@ericholscher I'm not sure I would call GitLab's developer documentation easy. Though it's available if you're interested in setting up GitLab locally.
I did end up testing this change internally. Using a custom web hook in GitLab I was able to setup a project that, on a code push to master or a branch, the proper Read the Docs version was re-built.
@agjohnson I agree. I would prefer to use the GitLab example verbatim, but I'm not familiar enough with Read the Docs' testing fixtures to know what I need to change to support my GitLab tests.

Feeling like we should get this merged in, and we can test it more in prod. Gitlab is something lots of people have wanted, so it makes sense to have in the codebase. It's annoying their dev docs aren't the best. We should add documentation though, before this gets merged in, so folks know how to use it.

I'm guessing the conflict is on our massive import renaming, so that should be an easy fix.

@ericholscher do you mean add documentation to https://read-the-docs.readthedocs.org/en/latest/webhooks.html?
As for testing what is sent from GitLab, I agree that the tests data is mangled a little, but the structure is not. I just replaced a lot of gitlab URLs with github URLs. Actually, that may not be to far from the use case as GitLab is used heavily as an on-premise source code platform by companies, so the URL could be pretty much anything.
However, I am more than willing to update the mock data to me more inline with what gitlab.com sends, but I would like to, if it's alright, wait until we can refactor how we provide mock data to the database ( as it will also effect #1446 ).


Neotest-zig does not function in a native windows environment

Describe the bug
Currently neotest-zig is not supported/does not work on windows. It seems that from reading previous issues that there was some compatibility in previous versions? I don't know under what circumstances it was compatible.
Right now I am running neovim, neotest, neotest-zig on a native windows 11 x64 machine.
Steps To Reproduce

Create a Windows machine 11 x64 installation
Install chocolatey
Using chocolatey, install neovim, zig
Setup neo-test and and neo-test-zig
run zig init to initialize a new project
Try running tests with neo-test

Current behavior
Running tests will give an error of
C:\ProgramData\chocolatey\lib\zig\tools\zig-windows-x86_64-0.13.0\lib\std\posix.zig:101:33: error: root struct of file 'c' has no member named 'STDERR_FILENO' pub const STDERR_FILENO = system.STDERR_FILENO;                           ~~~~~~^~~~~~~~~~~~~~ C:\ProgramData\chocolatey\lib\zig\tools\zig-windows-x86_64-0.13.0\lib\std\c.zig:1:1: note: struct declared here const std = @import("std");
Expected behavior
I expect the test runner to run the tests in a windows environment without test runner errors.
Environment

OS: Windows 11 x64
Zig version: 0.13.0
Nvim version: NVIM v0.10.0
Neotest version: v5.4.0
Neotest Zig version: 1.2.0

Additional context
I looked into the error myself and have started an attempt to fix it. The current issue is because of the use of try std.posix.dup2 methods calls. They zig posix API is not supported on windows (from I understand and what I have been reading).
If you try to use std.posix.dup2 in a zig init base project will generate the same error. as mentioned above.

Hi,
Yes, Windows is not currently supported. As you've found out dup2 is only supported by POSIX environments. We use dup2 to redirect the stderr stream to a test result file, as Zig prints test output to stderr. Would WSL be an option for you?
There were some issues in the past with Windows that I managed to resolve, but I don't think I can support that platform alone as I don't use/have a Windows system readily available.
If you, or someone else, manages to bring Windows support, then a PR would be appreciated. I can hopefully help with some questions if there are any.

Hey thanks for the quick response.
Unfortunately, do to the nature of the work I want to do(game dev, computer graphics) a windows environment would be better suited.
I would not mind looking into bringing windows support. Would you object to have Neotest-zig link against libc or is that a nonstarter?
Thanks for your time.

I don't mind linking against libc by itself, but due to zig code in this plugin being injected into build process via --build-file and -Dneotest-runner I'm not sure how would that affect running tests on user codebases which don't link against libc and those who already link to libc. Both scenarios should be supported. As long as there are no issues with that we could link against libc.

Is this now solved by #30, or is there more work needed to have Windows working?

To my knowledge and testing that should be it.

I'm closing this issue then. Thanks for the PR!


Tome of Fire boosts Trident of the Swamp DPS ... (#88)

calc: Ensure player is either autocasting or manually casting before applying tome bonuses

Closes #88

I'm not sure I understand what the original bug here was. It seems the check in compute should check whether the spell is being cast. Is the spell field not cleared when using a powered staff?
Also, make sure you update the unit test to check for this behaviour.

That's exactly right, the spell field isn't cleared. It's easy enough to check in client (select target, trident+attack style, and magic level -> observe trident max hit -> equip tome of fire and choose a fire spell -> switch back to previous attack style -> observe max hit has increased).
I added a guard for it in this case rather than clearing it properly because I'm not familiar enough with the project to know if it's a good idea to clear that spell field, do you think it could be a problem elsewhere?
Right, I'll look into the unit tests in a bit.

Adding a guard is indeed the correct approach, although it might also be good to add a clear in the ComputeContext builders. If combat style is not auto/manual-cast, don't set spell. Ideally, guarded in both places, but the one in CC doesn't need to be included here if you'd rather keep it simple.

Adding a guard is indeed the correct approach, although it might also be good to add a clear in the ComputeContext builders. If combat style is not auto/manual-cast, don't set spell. Ideally, guarded in both places, but the one in CC doesn't need to be included here if you'd rather keep it simple.

The problem is there is no 'null' spell, and context.get() throws an exception if we were to 'clear' the spell field by setting it to null. After writing maybe 3 catch-except blocks in case the spell field has been set to null, I'm starting to think this isn't really a great idea and we should keep it at guarding against non-autocast/non-manual cast, your thoughts?

Yeah, just leave it out of this PR and I'll make a more global solution later using a SpellComputable.