Segfault when saving PNG too often

Here is a MWE. I tried to make it smaller, but it seems like all of these steps are needed:
import Pkg
Pkg.activate(mktempdir())
Pkg.add([
    Pkg.PackageSpec(name="Images", version="0.23.3"),
    Pkg.PackageSpec(name="ImageIO", version="0.4.1"),
])

using Images

default_iocontext = IOContext(devnull, :color => false, :limit => true, :displaysize => (18, 88))

io() = IOContext(IOBuffer(), default_iocontext)

img = load(download("https://user-images.githubusercontent.com/6933510/107239146-dcc3fd00-6a28-11eb-8c7b-41aaf6618935.png"))
small = img[1:7,1:7]

for i in 1:10000
    show(io(), MIME"image/png"(), small)
end

Result:
fons@rekenmachine Documents % julia imageieosegfault.jl
 Activating new environment at `/var/folders/v_/fhpj9jn151d4p9c2fdw2gv780000gn/T/jl_OojTpv/Project.toml`
   Updating registry at `~/.julia/registries/General`
  Resolving package versions...
Updating `/private/var/folders/v_/fhpj9jn151d4p9c2fdw2gv780000gn/T/jl_OojTpv/Project.toml`
  [82e4d734] + ImageIO v0.4.1
  [916415d5] + Images v0.23.3
Updating `/private/var/folders/v_/fhpj9jn151d4p9c2fdw2gv780000gn/T/jl_OojTpv/Manifest.toml`
  [621f4979] + AbstractFFTs v1.0.0
  [79e6a3ab] + Adapt v3.2.0
  [4fba245c] + ArrayInterface v3.1.1
  [56f22d72] + Artifacts v1.3.0
  [13072b0f] + AxisAlgorithms v1.0.0
  [39de3d68] + AxisArrays v0.4.3
  [fa961155] + CEnum v0.4.1
  [aafaddc9] + CatIndices v0.2.2
  [d360d2e6] + ChainRulesCore v0.9.29
  [3da002f7] + ColorTypes v0.10.9
  [c3611d14] + ColorVectorSpace v0.8.7
  [5ae59095] + Colors v0.12.6
  [34da2185] + Compat v3.25.0
  [e66e0078] + CompilerSupportLibraries_jll v0.3.4+0
  [ed09eef8] + ComputationalResources v0.3.2
  [150eb455] + CoordinateTransformations v0.6.1
  [dc8bdbbb] + CustomUnitRanges v1.0.1
  [9a962f9c] + DataAPI v1.5.1
  [864edb3b] + DataStructures v0.18.9
  [b4f34e82] + Distances v0.10.2
  [da5c29d0] + EllipsisNotation v1.1.0
  [4f61f5a4] + FFTViews v0.3.1
  [7a1cc6ca] + FFTW v1.3.2
  [f5851436] + FFTW_jll v3.3.9+7
  [5789e2e9] + FileIO v1.4.5
  [53c48c17] + FixedPointNumbers v0.8.4
  [a2bd30eb] + Graphics v1.1.0
  [bbac6d45] + IdentityRanges v0.3.1
  [615f187c] + IfElse v0.1.0
  [2803e5a7] + ImageAxes v0.6.8
  [f332f351] + ImageContrastAdjustment v0.3.6
  [a09fc81d] + ImageCore v0.8.20
  [51556ac3] + ImageDistances v0.2.10
  [6a3955dd] + ImageFiltering v0.6.19
  [82e4d734] + ImageIO v0.4.1
  [bc367c6b] + ImageMetadata v0.9.4
  [787d08f9] + ImageMorphology v0.2.9
  [2996bd0c] + ImageQualityIndexes v0.2.1
  [4e3cecfd] + ImageShow v0.2.3
  [02fcd773] + ImageTransformations v0.8.9
  [916415d5] + Images v0.23.3
  [9b13fd28] + IndirectArrays v0.5.1
  [1d5cc7b8] + IntelOpenMP_jll v2018.0.3+2
  [a98d9a8b] + Interpolations v0.13.1
  [8197267c] + IntervalSets v0.5.2
  [c8e1da08] + IterTools v1.3.0
  [692b3bcd] + JLLWrappers v1.2.0
  [4af54fe1] + LazyArtifacts v1.3.0
  [856f044c] + MKL_jll v2021.1.1+1
  [1914dd2f] + MacroTools v0.5.6
  [dbb5928d] + MappedArrays v0.3.0
  [e1d29d7a] + Missings v0.4.5
  [e94cdb99] + MosaicViews v0.2.4
  [77ba4419] + NaNMath v0.3.5
  [f09324ee] + Netpbm v1.0.0
  [6fe1bfb0] + OffsetArrays v1.5.3
  [efe28fd5] + OpenSpecFun_jll v0.5.3+4
  [bac558e1] + OrderedCollections v1.3.3
  [f57f5aa1] + PNGFiles v0.3.5
  [5432bcbf] + PaddedViews v0.5.8
  [d96e819e] + Parameters v0.12.2
  [b3c3ace0] + RangeArrays v0.3.2
  [c84ed2f1] + Ratios v0.4.0
  [189a3867] + Reexport v1.0.0
  [ae029012] + Requires v1.1.2
  [6038ab10] + Rotations v1.0.2
  [699a6c99] + SimpleTraits v0.9.3
  [a2af1166] + SortingAlgorithms v0.3.1
  [276daf66] + SpecialFunctions v1.2.1
  [90137ffa] + StaticArrays v1.0.1
  [2913bbd2] + StatsBase v0.33.2
  [06e1c1a7] + TiledIteration v0.2.5
  [3a884ed6] + UnPack v1.0.2
  [efce3f68] + WoodburyMatrices v0.5.3
  [83775a58] + Zlib_jll v1.2.11+18
  [b53b4c65] + libpng_jll v1.6.37+6
  [2a0f44e3] + Base64
  [ade2ca70] + Dates
  [8bb1440f] + DelimitedFiles
  [8ba89e20] + Distributed
  [b77e0a4c] + InteractiveUtils
  [76f85450] + LibGit2
  [8f399da3] + Libdl
  [37e2e46d] + LinearAlgebra
  [56ddb016] + Logging
  [d6f4376e] + Markdown
  [a63ad114] + Mmap
  [44cfe95a] + Pkg
  [de0858da] + Printf
  [3fa0cd96] + REPL
  [9a3f8284] + Random
  [ea8e919c] + SHA
  [9e88b42a] + Serialization
  [1a1011a3] + SharedArrays
  [6462fe0b] + Sockets
  [2f01184e] + SparseArrays
  [10745b16] + Statistics
  [8dfed614] + Test
  [cf7118a7] + UUIDs
  [4ec0a83e] + Unicode

signal (11): Segmentation fault: 11
in expression starting at /Users/fons/Documents/imageieosegfault.jl:19
jl_object_id_ at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:349
typekey_hash at /Users/julia/buildbot/worker/package_macos64/build/src/jltypes.c:1014 [inlined]
jl_precompute_memoized_dt at /Users/julia/buildbot/worker/package_macos64/build/src/jltypes.c:1048
inst_datatype_inner at /Users/julia/buildbot/worker/package_macos64/build/src/jltypes.c:1314
jl_apply_tuple_type_v_ at /Users/julia/buildbot/worker/package_macos64/build/src/jltypes.c:1385 [inlined]
jl_apply_tuple_type_v at /Users/julia/buildbot/worker/package_macos64/build/src/jltypes.c:1395
arg_type_tuple at /Users/julia/buildbot/worker/package_macos64/build/src/gf.c:1851
jl_lookup_generic_ at /Users/julia/buildbot/worker/package_macos64/build/src/gf.c:2361
jl_apply_generic at /Users/julia/buildbot/worker/package_macos64/build/src/gf.c:2394
_writecallback at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:422
unknown function (ip: 0x138973dbf)
png_write_data at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_chunk_header at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_complete_chunk at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_compress_IDAT at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_finish_row at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_filtered_row at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_find_filter at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_row at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
png_write_image at /Users/fons/.julia/artifacts/fb2695d9f2ba598ca2213b0768aac906ebcd1000/lib/libpng<IP_ADDRESS>.dylib (unknown line)
_write_image at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:426 [inlined]
#_save#15 at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:414
_save##kw at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:344
JuliaIO/ImageIO.jl#13 at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:326
maybe_lock at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:36 [inlined]
maybe_lock at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:38 [inlined]
#save#12 at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:323
save at /Users/fons/.julia/packages/PNGFiles/CQUsD/src/io.jl:315
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1690 [inlined]
do_apply at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:655
jl_f__apply at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:669 [inlined]
jl_f__apply_latest at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:705
#invokelatest#1 at ./essentials.jl:710
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1690 [inlined]
do_apply at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:655
invokelatest at ./essentials.jl:709
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1690 [inlined]
do_apply at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:655
#save#7 at /Users/fons/.julia/packages/ImageIO/uPn5K/src/ImageIO.jl:46
save##kw at /Users/fons/.julia/packages/ImageIO/uPn5K/src/ImageIO.jl:41
inner at ./essentials.jl:713
unknown function (ip: 0x138984e2c)
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1690 [inlined]
do_apply at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:655
jl_f__apply at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:669 [inlined]
jl_f__apply_latest at /Users/julia/buildbot/worker/package_macos64/build/src/builtins.c:705
#invokelatest#1 at ./essentials.jl:714 [inlined]
invokelatest##kw at ./essentials.jl:709 [inlined]
#save#33 at /Users/fons/.julia/packages/FileIO/TyKdX/src/loadsave.jl:233
unknown function (ip: 0x13898349a)
save##kw at /Users/fons/.julia/packages/FileIO/TyKdX/src/loadsave.jl:217
unknown function (ip: 0x138982667)
#show#13 at /Users/fons/.julia/packages/ImageShow/9kpaq/src/showmime.jl:43
unknown function (ip: 0x138980478)
show at /Users/fons/.julia/packages/ImageShow/9kpaq/src/showmime.jl:28
unknown function (ip: 0x13897a456)
top-level scope at /Users/fons/Documents/imageieosegfault.jl:20
jl_toplevel_eval_flex at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:834
jl_parse_eval_all at /Users/julia/buildbot/worker/package_macos64/build/src/ast.c:913
jl_load_rewrite at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:914 [inlined]
jl_load at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:919
include at ./Base.jl:380
include at ./Base.jl:368
exec_options at ./client.jl:296
_start at ./client.jl:506
jfptr__start_57081 at /Applications/Julia-1.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
true_main at /usr/local/bin/julia (unknown line)
main at /usr/local/bin/julia (unknown line)
Allocations: 43572662 (Pool: 43555600; Big: 17062); GC: 44
zsh: segmentation fault  julia imageieosegfault.jl

System info:
julia> versioninfo()
Julia Version 1.5.3
Commit 788b2c77c1 (2020-11-09 13:37 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin18.7.0)
  CPU: Apple M1
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-9.0.1 (ORCJIT, westmere)

I brought this over from ImageIO
Reduced one small step further. The IOContext kwargs aren't needed. This segfaults
using PNGFiles
begin
  img = PNGFiles.load(download("https://user-images.githubusercontent.com/6933510/107239146-dcc3fd00-6a28-11eb-8c7b-41aaf6618935.png"))
  small = img[1:7,1:7]
  default_iocontext = IOContext(devnull)
  for i in 1:500_000
      PNGFiles.save(IOContext(IOBuffer(), default_iocontext), small)
  end
end

As a Base sanity check, this doesn't segfault
begin
    img = rand(UInt8, 7, 7)
    for i in 1:1_000_000
         write(IOBuffer(), img)
    end
    println("first loop done")
    for i in 1:1_000_000
         write(IOContext(IOBuffer()), img)
    end
end

Potential work-around/fix here https://github.com/JuliaIO/PNGFiles.jl/pull/33
On that PR, both loops complete.

Ok, this should be fixed in v0.3.6 that was just released. I'll close the issue, but please say if it's not fixed. or perhaps even if it is :)


fix(cyclops-ui): node card details added

closes #440
📑 Description
✅ Checks

[ ] I have updated the documentation as required
[x] I have performed a self-review of my code

ℹ Additional context
added last transition time and heart beat time and message to the node conditions card

@petar-cvit can you please review this PR?

@petar-cvit can please review this PR in your free time?

done @petar-cvit, can you please review now?

squashed all commits

Can you move the timestamps and the message in the next row

@petar-cvit made changes can you please review now?


2.2: Actor migration fails for Group type actors as they do not have system.tools

Also occurs on vehicle sheets


timestamps option no longer working

I use the timestamps option from mongoose to automatically add created and updated timestamps but they don't seem to work anymore.
I tested this with typegoose 5.4.0 and mongoose 5.3.1.
Minimal reproduction:
var mongoose = require('mongoose');
import { prop, Typegoose, InstanceType, staticMethod, instanceMethod, pre, Ref } from 'typegoose'

mongoose.connect('mongodb://localhost/bug');

class Kitten extends Typegoose {
  @prop()
  name: String
}

const KittenModel = new Kitten().getModelForClass(Kitten)

KittenModel.schema.set('timestamps', true);

(async () => {
  var fluffy = new KittenModel()

  await fluffy.save()

  console.log('saved')

  process.exit(0)
})()

Notice in the database that createdAt and updatedAt are not added to the record.

Have you tried passing the options to getModelForClass?
const KittenModel = new Kitten().getModelForClass(Kitten, { schemaOptions: { timestamps: true }})

Thanks that does work.

I would like to add that in my case the updatedAt is not updating when I call updateOne. The value remains the original value when this record was created although I set schemaOptions: { timestamps: true } when I create model with getModelForClass.
Any help would be greatly appreciated


Mobs rendering error

when I install this mod it "breaks" mobs textures. It looks like it turns them inside out and I can't figure out the reason, but when I remove the mod it goes back to normal

Duplicates https://github.com/irtimaled/BoundingBoxOutlineReloaded/issues/134
Fixed by #133
See https://github.com/irtimaled/BoundingBoxOutlineReloaded/issues/134#issuecomment-894983070


WIP: Improve builder

FYI @carlossvg

@LanderU do we still need to work on this PR or we can close it?

@razr, no, closing here.


ref(quick-start): Use http for services if Let's Encrypt is disabled

Update automation such that the default URLs are http-based but with option to use LE for tls.
Closes https://github.com/fermyon/nomad-aws-demo/issues/16

Thanks @vdice. Will test in a second. In the meantime would you mind resolving the conflict after merging #14?


feat: show current dir name in tab

This PR introduces a new option max_width in [tab] section for controlling the max width of current directory name in tab. Default value is 0 which means directory name won't be displayed in tab. This matches current behavior.
Here is an example for setting value to 10:

The first tab's directory is "raffia" whose length is less than the threshold we set; the second tab's directory is "swc-plugin-react-remove-properties" whose length is greater than the threshold, so it's truncated and only the first 10 chars are displayed. (Should we add ellipses for this case?)

Thanks for your work, merged!


Enable ppc64le; build against TexLive 2018

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Rebuild for ppc64le;
Note - set icu to 58 due to the new texlive rebuild, which needed poppler 64/65, which wants cairo 1.14, which wants icu 58.
Do not merge yet. I'll investigate this.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you but ran into some issues, please ping conda-forge/core for further assistance.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@conda-forge-admin, rerender

win2008 failure is unexpected, I think?

I'm afraid I'm not much use debugging old windows stuff. Did we somehow break win2008?

You can ignore that.( There shouldn't be two check vs2008 vs vs2015 for this repo, but I haven't been able to figure that out yet)

Gotcha. Anything else you recommend for this PR then?

@conda-forge/r
Hello magnificent R contributors! I have a PR here to enable r-base for a brand new architecture to play with: ppc64le.  I'd love some feedback on this PR and your approval to merge this in. The benefits include a new set of users to conda-forge and a least a few contributors and/or maintainers as well.
Details in the PR include a move up to a newer TexLive-core version (2018), which was recently added to conda-forge, and a bit of a workaround for a mismatched ICU lib at build time. (thanks @isuruf !)
I'm hoping that once this is in, to kick off another efforts to add ppc64le to many of the R packages in conda-forge. A fresh look and rebuild will likely be a good thing. Also, the hope is to follow this with builds for aarch64 as well once a few more of the dependencies are available on that arch.
Please let me know of any concerns, comments, or feedback on the PR please. Thank you!

@bgruening @dpryan79 @isuruf @jdblischak @johanneskoester @mingwandroid, @ocefpaf @sodre
Can I get a review guys? I'm willing to help maintain this for ppc64le arch if necessary.
Thanks!!

I don't see the ppc64le build, is it enabled? How is that done?

Hi @mingwandroid thanks for looking.
Travis-ci.org has native ppc64le hardware now and conda-smithy has been enabled to generate build scripts for it.
For this PR, I added provider: {linux_ppc64le: default} to the conda-forge.yaml and did a rerender and that worked to generate the needed ppc64le scripts.
The other change in the build.sh script is to workaround a conflict in ICU levels between r-base and texlive-core, the latter of which still has a few dependency pins that require ICU 58 and here we are using the latest conda-forge version (64).
There are no other changes and nothing specific for ppc64le needed to build r-base.
I do plan on starting on the large set of non noarch R packages once this is in (perhaps with the help of the arch migrator).

Thanks for looking!
Anyone else have comments or concerns?

There are no other changes and nothing specific for ppc64le needed to build r-base.

As long as supporting ppc64le doesn't make it too much more complex to maintain r-base, I'm fine with this.

I do plan on starting on the large set of non noarch R packages once this is in (perhaps with the help of the arch migrator).

That was my other concern. It'll be a decent amount of work to migrate all of the non-noarch packages. My advice would to 1) don't bump the build number since there is no reason to re-build the packages for every platform when the PR is merged, and 2) see if you can skip the other builds so that your PR is checked faster.

Thanks @jdblischak.
Maintenance shouldn’t be hard. Major Linux distorts already include R (perhaps not as new as here, though. I can help fix any issue that may arise.
And sure I can skip bumping the build number if that’s best. What do you mean by skipping other builds? Add temporary skip lines in PRs? With some exceptions, most of the packages build pretty quick, right?

What do you mean by skipping other builds? Add temporary skip lines in PRs?

@jayfurmanek Yes, if possible this would be convenient. I know with the previous CI platforms that conda-forge used it was possible to put a skip directive in the commit message. Unfortunately as far as I know this is not possible with Azure, but I mentioned it since maybe conda-forge has a workaround.

With some exceptions, most of the packages build pretty quick, right?

Each individual build takes anywhere from 5-15 minutes depending on the platform and package. And the queue will start to back up as you try to build 100s of R packages. It's not terrible (I've been impressed with Azure processing times), but worth trying to minimize if possible.

@jdblischak ok makes sense.
@isuruf any idea if this works on azure somehow?
Speaking of queue though, we can use the arch migrator but that is set up for both aarch64 and ppc64le and at least for now, aarch64 doesn’t have all the dependencies built, so that route may not be the most appropriate.
Anything else need addressing before getting this started? :) thx!

We can skip azure. I can't remember the exact phrase.

Speaking of queue though, we can use the arch migrator but that is set up for both aarch64 and ppc64le and at least for now, aarch64 doesn’t have all the dependencies built, so that route may not be the most appropriate.

I think we should do this together to reduce the amount of work for the @conda-forge/r team unless @conda-forge/arm-arch doesn't have any plans in making r-base work soon.

If anyone in @conda-forge/arm-arch wants to help divide and conquer that'd be great!

have you tried to simply enable aarch64 as well? there should be a way to add this stack to the migrator.
The general issue is we are still stuck on gstreamer.... not fun to build up the graphicsstack. r doesn't depend on graphics??? I feel like you'll get stuck there pretty soon!

Aarch64 needs texlive-core first. And that was painful enough for me to get working on a platform I have first hand access to. I didn’t attempt it on aarch64. I think there are missing CDTs there as well.
For graphics it looks like R uses r-rlg which has similar dependencies (including more CDTs) to gstreamer, but it doesn’t directly depend on gstreamer.
I have some short term personal interest in getting R working as well, hence the push for it. I do plan on helping with the rest of the packages currently in the migrator (gstreamer included) once I get this one through.

honestly, i thought doing ppc64le and aarch64 at the same time was a little ambitious. not sure if i have the bandwidth at this time to help with texlive core. I'm sure aarch64 + python will need it soon but yeah...

They are actually quite similar in a lot of ways, not the least of which being the need for cos7 CDTs. The changes I made to texlive-core may really just work on aarch64, but I didn't attempt it for the same reasons as not having the bandwidth.
Likewise, if we decide to diverge here (for now) any gotcha's I come across in the R ecosystem will likely have similar solutions for ppc64le and aarch64. One example I've already looked at was the requirement for java in r-rjava, which is provided by the openjdk package, which needs a fully build JDK to bootstrap the build. I plan on using adopopenjdk.org builds for that on ppc64le as they have builds for non-x86 arches (aarch64 included). Point being, there will be a bit of a blueprint for aarch64 whenever we come back for it.

lets see: https://github.com/conda-forge/texlive-core-feedstock/pull/31

[crosses-fingers] :)

Some of those pkgs it's failing for actually come from defaults for ppc64le, I think. That certain version of poppler 0.64 is needed because no amount of patching could get it to work with a newer version - and poppler 0.64 pulls in those other ones (cairo 1.14, icu58 etc.)

I see. So we need to rebuild those specific versions on conda forge.

Yea, that would work as well.

So what do you think? Worth pursuing and keeping the arches together. Or we diverge here (temporarily)?

i'm trying to revive poppler now. lets see what will happen. Can you create a 0.65 branch?
https://github.com/conda-forge/poppler-feedstock/commit/bd3ac5d792b582a3b1117ee37faaf709ea38840b

Ok. I'm not able to create a branch. @isuruf ?

I would like to caution against moving too fast and not using the migrator.
The ppc64le and aarch builds are not so different anymore, especially since we have drone. Without a specific issue, I think it is best to follow the migrator so as to avoid pulling in old dependencies from defaults for these strange packages.
In either case, I think this should block until

[ ] https://github.com/conda-forge/cairo-feedstock/pull/51
[ ] https://github.com/conda-forge/mpfr-feedstock/pull/22
[ ] https://github.com/conda-forge/texlive-core-feedstock/pull/31

As they build ppc64le dependecies as well.

They are actually quite similar in a lot of ways, not the least of which being the need for cos7 CDTs. The changes I made to texlive-core may really just work on aarch64, but I didn't attempt it for the same reasons as not having the bandwidth

Agreed. I cannot think of a better pairing than AArch64 and ppc64le. They are so alike it's uncanny (and from our compiler, tooling and CDT choice perpective, deliberate). At worst you may end up patching some software due to some #defines in the kernel headers and glibc port that conflict with some of our packages, still they are easily spotted and avoided.

@hmaarrfk while avoiding things from defaults is better, can you explain why you think it would be problematic? In the past when we used different compilers then sure! If it's just the case that our packages are too old resulting in too-old run_export pinning then I'd happily push for us to prioritize updating the AD builds to be built from the latest conda-forge recipe.
Still, we've largely slain the binary incompatibility dragon now.

If it's just the case that our packages are too old resulting in too-old run_exports pinning then I'd happily push for us to prioritize updating the AD builds to be built from the latest conda-forge recipe.

Could you build r-base with the conda-forge recipe then? https://github.com/AnacondaRecipes/r-base-feedstock/issues/1 has been open for a while now.

Mostly for consistency purposes.
Binary incompatibility is addressed, but sometimes we have updated versions of packages or in rare cases, different organization (numpy)

@mingwandroid, perhaps the best part of not avoiding the migrator is that this migration comes at a good time where we can cleanup some of the recipes to remove the hard pinnings. Because aarch64 doesn't exist in defualts, it is a good way to test if we accidentally left some old code in the metal file.
For example, the texlive recipe used the old way to pin dependencies, but the latest PR I submitted frees up many of them, and uses the pinnings from the global pinnings repo.

Thanks for all the work @hmaarrfk ! Once that texlive PR is in, we'll need to update this one (or close and push a new one) and pull out that ICU workaround in the build.sh file. Much better all around.


upgrade to jboss-ip-bom 6.0.0.CR28

we had to put temporarily org.jgroups:jgroups:3.1.13.Final to dashbuilder-deps as this artifact doesn't exist in the version inherited by the IP BOM CR28 (3.1.14.Final).
This will be a temporary workaround.

Reviewed & merged on 0.3.x


whiteboard-hypercard build is broken

Describe the issue
As part of #700 I attempted to retrigger the build of the whiteboard-hypercard package. The build keeps failing due to a timeout when trying to fetch one of the git submodules. This will need to be resolved separately.
To Reproduce

Open a PR where the version number for the whiteboard-hypercard package is incremented
The build will error

Expected behaviour
The package should build with no error.
Upstream issue
N/A
Screenshots
N/A
Device/Package information (please complete the following information):
N/A
Additional context
[    INFO] toltec.builder: whiteboard-hypercard [rmall]: Fetching source files
[    INFO] toltec.builder: whiteboard-hypercard [rmall]: Building artifacts
[    INFO] toltec.builder: whiteboard-hypercard [rmall]: Only showing up to 50 lines of context. Use --verbose for the full output.
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: info: downloading component 'rustfmt'
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: info: installing component 'rustfmt'
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Updating crates.io index
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Updating git repository `[https://github.com/canselcik/libremarkable`](https://github.com/canselcik/libremarkable%60)
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Updating git submodule `git://github.com/ricardoquesada/libfreetype`
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: warning: spurious network error (2 tries remaining): failed to connect to github.com: Connection timed out; class=Os (2)
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: warning: spurious network error (1 tries remaining): failed to connect to github.com: Connection timed out; class=Os (2)
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: error: failed to get `libremarkable` as a dependency of package `marauder v0.3.4 (/src/marauder)`
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Caused by:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: failed to load source for dependency `libremarkable`
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Caused by:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Unable to update https://github.com/canselcik/libremarkable?branch=master#6e5ce150
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Caused by:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: failed to update submodule `legacy-c-impl/libfreetype`
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Caused by:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: failed to fetch submodule `legacy-c-impl/libfreetype` from git://github.com/ricardoquesada/libfreetype
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: Caused by:
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: failed to connect to github.com: Connection timed out; class=Os (2)
[   ERROR] toltec.builder: whiteboard-hypercard [rmall]: build() failed

https://github.com/toltec-dev/toltec/pull/747 should have closed this I believe

It was linked, not sure why it didn't auto close.


fix issue #192 by compiling to es5

I made some changes so that this library exports an es5 compatible module instead of es6.
This also required changing all the require statements to import statements andding some configs.
The module is built using rollup and compiled with babel.
I didn't change the version number in package.json, but this would be a minor or patch level change.
Here are some docs related to the difference between ES6 modules via 'importand legacy modules viarequire`
https://www.quora.com/What-are-the-benefits-of-using-ES6-modules-import-and-export-statement
https://rollupjs.org/guide/en
https://github.com/rollup/rollup
And why rollup instead of browserify, gulp/babel, webpack, etc.:
https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/
https://survivejs.com/blog/rollup-interview/

Thanks for the PR! I really like the idea here. It would maybe be easier if you'd just submitted the build change, and let us build the dist on our end.
The problem is that as it stands, this PR changes nearly every line of the project, making it almost impossible to review. I like what it claims to do, but I don't have time to go through this right now.

I agree there a lot of changes, but they are mostly the same semantic change applied across the library. That is, changing require statements to import statements.
I have a similar PR over at ethereum/ethereumjs-vm if you are interested in following that conversation.


log:normalized text can not be formed for

Hello,
I am seeing the below logs for certain Bengali documents:

I would like to know in this case if normalization is not possible then does the normalizer return the text as it? What does it do when it cannot normalize?

Hi , can you please share the texts? The following part is the relevant part i believe.. while executing the normalization operations is the text lenght becomes 0 for some reason (removing invalid endings/ startings) this log is shown and then it returns None
for op in ops:
            if not self.__checkOp(op):
                print(f"log:normalized text can not be formed for {text}")
                return None


Docs could use some TLC

There is opportunity to improve docs. It'd be nice to have just have a minimum requirements and then a table with green checkmarks for the proven environments and tech versions you're using

Hosted Docs
Heres the repo for the docs. Feel free to contribute.


Define process.resourcesPath for the CLI

Electron extends the process object with a read-only resourcesPath
property, which the generator uses. This property is not defined when we
are not using the Electron framework.
This commit adds defines that property for the CLI.
Fixes #4.

thank you!


Missing attribute for chef 12.4

Chef 12.4 seems to require the following attribute defined with a timeout.
attribute :timeout,       :kind_of => Integer, :default => 300
Figure 300 is a fairly sane starting point. Thoughts?

Resolved.


[ST] User bridged into low liquidity pool

Describe the bug
A user bridged ~373 DAI to Gnosis Chain, where the pool's TVL is merely 800 nextDAI-DAI. We need to prepare the calldata for him to force receive nextDAI and be able to bridge back.
Link to ticket in discord
https://discord.com/channels/454734546869551114/1185810170866044968/1185810718906396782

This has been resolved by funding the bump ~$14 - on the house

Closed the wrong issue. This tx is still pending https://connextscan.io/tx/0xab15a2dd885dede29ef44d4af0f78422ceb92c4d44a1133e08dec6317ff17210


Not able to see the apps in the rancher ui

Internal reference: SURE-6972
Reported in 2.7.5
In one environment, users are no longer able to see the installed apps in the rancher ui. Users are able to see the installed apps using a kubectl command so the guess is that this is a UI issue.
Notes:

In certain namespaces, Helm charts did not appear in the install apps section.
Initially, it was thought that this was a permissions issue but upon closer inspection, it was noticed in the logs that there were some cattle-cluster-agent errors.
Subsequent thinking was that maybe it was a corrupted helm chart, but there wasn't enough evidence to conclude this theory.
They have another issue where CPU and Memory consumption was running ramped.

Upgrade to 2.7.6 requested.

/backport

Note to self: this fix will need to be forward-ported to steve:release/v2.8

Fixing the cause of the 500 status error results in a UI problem: curl -s …/k8s/clusters/$CLUSTER/v1/catalog.cattle.io.apps | jq '.data[] | [.type, .metadata.namespace, .metadata.name]' returns the expected apps, and the Installed Apps count in the UI is updated correctly, but the list of apps in the details table is always empty.
This is with rancher 2.8. I haven't been able to stand up a local version of rancher 2.9 that can create a digital ocean cluster - when I try to create one I get an error: "No version info found in KDM"

This is not a problem in 2.9.x, closing.


Is there any HA solution for Burrow?

Hi guys,
as we known,lag metric is very important for monitoring Kafka.We do not want to lose any error alarm on Kafka。I have a solution that simply running the two Burrow servers independently with the same configuration. However this solution is too heavy which will cause double burden for Kafka.
Is there any effective and lightweight HA solution for Burrow?

I have't try this function


Cannot read property 'ember-bootstrap' of undefined

In and Ember 2.7 app, at this line I have this error :
Cannot read property 'ember-bootstrap' of undefined

If I do app = app.app it workes. I'm not working on an addon and the if statement is not true.
I don't know what's the definitive solution. What you think?

I have no idea, but ember-bootstrap has a lot of tests that also run for ember 2.7, so really there should be no problem in general. I think there must be something with your particular app. I just recently set up a fresh app with ember-cli 2.7 / ember 2.7 without any problems, so the problem must lie somewhere else unfortunately!

@simonihmig I tried to contribute to this addon and I have the problem. I don't see anything special. Please, can you check it?

Sorry, I was wrong. Your addon seems to be correct. Thanks.

I finally found a way to reproduce the bug. I when ember-bootstrap is an dependency of an addon. For example, a package with this in package.json :
{
  ...
  "dependencies": {
    "ember-cli-babel": "^5.1.3",
    "ember-bootstrap": "0.10.0"
  }
  ...
}

And I have this stack trace :
Cannot read property 'ember-bootstrap' of undefined
TypeError: Cannot read property 'ember-bootstrap' of undefined
    at CoreObject.included (/frontend/node_modules/ember-bootstrap/index.js:26:53)
    at /frontend/node_modules/ember-cli/lib/models/addon.js:258:34
    at Array.map (native)
    at CoreObject.eachAddonInvoke (/frontend/node_modules/ember-cli/lib/models/addon.js:252:24)
    at CoreObject.extend.included (/frontend/node_modules/ember-cli/lib/models/addon.js:435:10)
    at CoreObject.superWrapper [as included] (/frontend/node_modules/core-object/lib/assign-properties.js:32:18)
    at EmberApp.<anonymous> (/frontend/node_modules/ember-cli/lib/broccoli/ember-app.js:468:15)
    at Array.filter (native)
    at EmberApp._notifyAddonIncluded (/frontend/node_modules/ember-cli/lib/broccoli/ember-app.js:463:45)
    at new EmberApp (/frontend/node_modules/ember-cli/lib/broccoli/ember-app.js:136:8)
    at module.exports (/frontend/ember-cli-build.js:7:15)
    at CoreObject.module.exports.Task.extend.setupBroccoliBuilder (/frontend/node_modules/ember-cli/lib/models/builder.js:74:19)
    at CoreObject.module.exports.Task.extend.init (/frontend/node_modules/ember-cli/lib/models/builder.js:54:10)
    at CoreObject.superWrapper [as init] (/frontend/node_modules/core-object/lib/assign-properties.js:32:18)
    at CoreObject.Class (/frontend/node_modules/core-object/core-object.js:32:33)
    at CoreObject.module.exports.Task.extend.run (/frontend/node_modules/ember-cli/lib/tasks/build.js:15:19)
    at CoreObject.<anonymous> (/frontend/node_modules/ember-cli/lib/commands/test.js:164:27)
    at tryCatch (/frontend/node_modules/rsvp/dist/rsvp.js:538:12)
    at invokeCallback (/frontend/node_modules/rsvp/dist/rsvp.js:553:13)
    at /frontend/node_modules/rsvp/dist/rsvp.js:628:16
    at flush (/frontend/node_modules/rsvp/dist/rsvp.js:2370:5)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)

I don't understand why it do that... can you help me?

@GCorbel Same here: I have an addon that includes ember-bootstrap as its dependency. When I install the addon into another app, I have this error.

@viniciussbs @GCorbel Can you share the addons that include ember-bootstrap with us?
Can you tell us what versions of ember, ember-cli, and ember-bootstrap you're using?

@srvance It's my own private addon with core UI componentes shared with other apps.
$ ember -v
ember-cli: 2.11.0

"ember-bootstrap": "0.11.1"
One of the apps already have ember-bootstrap (same version) into "devDependencies" as its own dependency.

Same here. My case exactly is similar to @viniciussbs

Any chance you can upgrade to the latest? We're not making changes to the 0.* versions, and there have been several changes to how the hosting app is identified.
We know that there are some issues with ember-bootstrap as an addon dependency, at least one of which is that ember-cli doesn't have a story for running blueprints of addon dependencies.

@srvance I did point to master and it worked like charm. Thanks 🌮


Add example of isomorphic REST API fetching

I think it will be really helpful if /src has an example of use of isomorphic-fetch for REST API fetching.
It's very confusing to realize how to deal with asynchronousness and ensure server-rendering.
For example: I want to get product from external API and render it on server but only for first load of page, then I want to load other products (JSONs) on client, and I want all these products on client state (as cache).
So I'm just looking for some best-practices how to use REST API with este.js. Thank you.

There was an example which was removed, see e192695c2d527297cfd40ae0ecc9804344ee3a86. I think, originally @steida wanted to replace it with #819, but didn't go through with it. What do you favor right now, @steida? I may have time to implement an example with the todos at the weekend.
I also think it's an important piece which, currently, is missing.

I just don't like XmlHttpRequest :-) Feel free to use something else, or rework XHR with current pre-rendering approach. Thank you for offer, but Este is tied with web sockets.

Ok. But if you need to use some external API - let's say Youtube API - and you need to use pre-render. How will you do that?

Probably via some library like https://github.com/ericclemmons/react-resolver or similar. Maybe I would just copy queryFirebase and use some common list of promises.


Adding Netbox Plugins

Is it possible to get more detailed document/examples about adding 'Netbox plugins' in netbox-chart.
In values.yaml it's mentioned:
Enable installed plugins. Add the name of each plugin to the list.
plugins: []
How to install these plugins before adding here?

The easiest way to install them is to build a new image, as is noted here: https://github.com/bootc/netbox-chart/issues/118

Indeed, it's not feasible for the chart to influence the plugins available in the image. We deliberately run with a read-only root filesystem for security, for example, which makes it impossible to install plugins. You can probably override this if you really want to, but that's not something we recommend. The recommended route is to build your own customised image.

Ok..Thanks.


Implement condact

See tests/jkind/condact.lus

Should work as of a4801b914d86226e505abc8c0ad091159e8b073c

The implementation is not quite right.  It looks like the idea is that the guarded expression should be evaluated only when the trigger is true, rather then being evaluated all the time, and only showing
the results when the trigger is true.

Seems to work on at least one complex test :)


C_cifoaixd$C_lcybgaxw$C_amqftyfx$C_iinezlaz is broken

Its in ChunkBuilder.BuiltChunk.RebuildTask. I found it by that class' render method, its return value is that class C_cifoaixd$C_lcybgaxw$C_amqftyfx$C_iinezlaz and it is very broken. It wont let me import it. C_cifoaixd$C_lcybgaxw$C_amqftyfx (the first part of it) just maps to ChunkBuilder.BuiltChunk.RebuildTask. I dont know what else to put here.

Could you provide a bit more information? Like how are you decompiling, which QM version this is, or some screenshots

The issue is right here https://github.com/QuiltMC/quilt-mappings/blob/1.19.3/mappings/net/minecraft/client/render/chunk/ChunkBuilder.mapping#L121
All my settings are from the Quilt Template mod. I dont think its an issue on my side. It should be a simple fix, just change the thing. Idk tho I've never done mappings before.

This is what the method looks like to me

I cannot ctrl click to open it up.
IntelliJ has a feature where you can search anywhere in a project, so I did just that.
This class is what shows up.

Yet I search in the very folder that its from and theres nothing of it!

I looked in the sources-jar manually and found it.
Eclipse? Same story. Cant click it to open it. Cannot find it. and of course, cannot import it even when using an access widener which does work.
As the first part technically maps to ChunkBuilder.BuiltChunk.RebuildTask I thought maybe its hidden in there? But there's nothing to be found.
Tried to open up the bytecode but it says its unable to parse.
I am using quilt_mappings = "1.19.3+build.16", quilt_loader = "0.17.8", quilt_loom = { id = "org.quiltmc.loom", version = "1.0.+" }, mappings "org.quiltmc:quilt-mappings:${libs.versions.quilt.mappings.get()}:intermediary-v2"
I don't know what other information is necessary.

Hm, this is quite the issue. We'll have to invesigate

#371 explicitly said "Doesn't fix #334 yet", which was bad phrasing. I guess this was closed by accident.

this actually did fix the inner class issues, see this comment!
https://github.com/QuiltMC/quilt-mappings/pull/371#issuecomment-1457001078

this actually did fix the inner class issues, see this comment!
https://github.com/QuiltMC/quilt-mappings/pull/371#issuecomment-1457001078

Thanks for the clarification. I didn't have the domain knowledge to catch that. I'm just subscribed, because a mc mod dev I'm waiting to update his work depends on this fix and I wanted to stay in the loop XD.


训练自己的数据出错

Tuning checkpoint from ./dfine_l_obj365_e25.pth
Load model.state_dict, {'missed': ['decoder.denoising_class_embed.weight'], 'unmatched': ['decoder.enc_score_head.weight', 'decoder.enc_score_head.bias', 'decoder.dec_score_head.0.weight', 'decoder.dec_score_head.0.bias', 'decoder.dec_score_head.1.weight', 'decoder.dec_score_head.1.bias', 'decoder.dec_score_head.2.weight', 'decoder.dec_score_head.2.bias', 'decoder.dec_score_head.3.weight', 'decoder.dec_score_head.3.bias', 'decoder.dec_score_head.4.weight', 'decoder.dec_score_head.4.bias', 'decoder.dec_score_head.5.weight', 'decoder.dec_score_head.5.bias']}
Initial lr: [1.25e-05, 0.00025, 0.00025]
building train_dataloader with batch_size=2...
building val_dataloader with batch_size=64...
------------------------------------- Calculate Flops Results -------------------------------------
Notations:
number of parameters (Params), number of multiply-accumulate operations(MACs),
number of floating-point operations (FLOPs), floating-point operations per second (FLOPS),
fwd FLOPs (model forward propagation FLOPs), bwd FLOPs (model backward propagation FLOPs),
default model backpropagation takes 2.00 times as much computation as forward propagation.

Traceback (most recent call last):
File "/home/D-FINE-master/train.py", line 84, in
main(args)
File "/home/D-FINE-master/train.py", line 54, in main
solver.fit()
File "/home/D-FINE-master/src/solver/det_solver.py", line 62, in fit
train_stats = train_one_epoch(
^^^^^^^^^^^^^^^^
File "/home/D-FINE-master/src/solver/det_engine.py", line 78, in train_one_epoch
loss_dict = criterion(outputs, targets, **metas)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/anaconda3/envs/dfine/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1736, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/anaconda3/envs/dfine/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1747, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/D-FINE-master/src/zoo/dfine/dfine_criterion.py", line 236, in forward
indices = self.matcher(outputs_without_aux, targets)['indices']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/anaconda3/envs/dfine/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1736, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/anaconda3/envs/dfine/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1747, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/anaconda3/envs/dfine/lib/python3.11/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/home/视频/D-FINE-master/src/zoo/dfine/matcher.py", line 99, in forward
cost_bbox = torch.cdist(out_bbox, tgt_bbox, p=1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/anaconda3/envs/dfine/lib/python3.11/site-packages/torch/functional.py", line 1478, in cdist
return _VF.cdist(x1, x2, p, None)  # type: ignore[attr-defined]
^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: CUDA error: device-side assert triggered
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with TORCH_USE_CUDA_DSA to enable device-side assertions.
我已将数据转成coco格式，只有一个类别，训练不起来，同样的代码，训练coco2017没有问题，请问这个问题怎么解决？

this issue: https://github.com/Peterande/D-FINE/issues/12


Missing whenNotPaused modifier on approve

Severity: Low
Description
DToken's approve function is missing a whenNotPaused modifier. The other entry points for users have the modifier so it appears to be an oversight to omit it from this function.
DToken.approve(address,uint256) (contracts/DToken.sol#866-870) should use the Pausable modifier. It changes:
        -DToken.allowance (contracts/DToken.sol#42)

This issue was identified by Slither.
Recommendation
Short term, add the missing whenNotPaused modifier.
Long term, use crytic.io—Crytic catches this bug. This will help ensure that vulnerabilities are not introduced into the codebase.

Will add it.

Fixed in 792bb333a1770e8da6a67c3730246f920049153e


How to add an argument of type enum item?

I have this case:
query {
  search(type: REPOSITORY, query: "is:public archived:false", first: 100) {
    edges {
    	node {
			....
      	}
      }
    }
  }
}

I have no idea how add the "type" argument as it's not a string
EDIT: To be more clear: I'm trying to use this lib to build a query against GitHub using https://docs.github.com/en/graphql/reference/queries#search
EDIT2: Accordint to GitHub GraphQL documentation, the search(type: ...) argument is a enumeration. See https://docs.github.com/en/graphql/reference/enums#searchtype
So we need a way to stringify this type.

Opened #25 to fix this issue


Koozies for Datapalooza!

Navy blue with white imprint can koozies.
The artwork has been supplied by Leo.

checked with House of Swank and they said they are too busy due to the State Fair and gave me another place to check but I can't get a promise date that I feel good about or a "preview" of my order.
Going with Custom Ink this time....tried to keep it local

they have been ordered!!


validate graph queries before making calls to devx API

GE to validate user queries before making API calls to DevX API for both permissions and code snippets and display correct error message to the user.
Today:

Expected:
GE to display error message on the permissions tab & code snippets that the query is incorrect instead of 'snippets not available' & 'check permissions panel'. Snippets not available & check permissions panel message should only be used in scenarios where a user has run a valid query, but we do not have support for snippets or permissions..

@darrelmiller we had a debate this morning with Caleb and the team around the URLs validation and the metadata challenges. I'd love your opinion as our trusted architect :)


Changed test value for Bank Routing due to new feature #84 breaking it

Pays to run tests before commiting. By default, there are usually 10 failing tests in security regression testing. 3 are false alarms, 7 are from the input fields on the profile route. With the new ReDoS regex validation none fail, because selenium can't warm up Zap due to failing the initial post. Once I fixed the initial post to accommodate the new ReDoS feature, What we tell the Zap API also needed to be changed. Once all this is done, We get 9 defects (3 false positives, 6 defective input fields), so we're one down, so the training video is no longer correct Just as well I checked this, as I'm using this here next week.

Ah..sorry I completely missed the security regression tests on the profile route. Also, worse timing for it to break before your workshop next week. Next time before merging profile related changes, I will ensure with you that zap tests are all set.

I wouldn't worry to much, I know to check it. I knew I'd have to do quite a bit before my workshop with NodeGoat, as @lirantal has added some good features. At some stage, I'll get better coverage of the tests and add it to the readme.

Sorry guys! I was actually not even aware we have in place tests, and btw I'm also planned to have a short workshop next week with NodeGoat so it seems we're all in good company :-)
With regards to the tests - How about we tie this as part of the build that runs on every PR? this way no one can ever forget.

Ah, yeah, it'll take some work though, it's on my list of things to do.

Cool. Need to remember to review the tests there.

Currently there is only one test (tests all inputs in profile), and it's very broad. Zap does all the work, once you give it what it needs.

Kim do we have documentation on how to run the tests, how do they work, etc?
I'd be happy to look into what we have there.

Yip: https://github.com/OWASP/NodeGoat/wiki/NodeGoat-Security-Regression-tests-with-ZAP-API
I'm keen to own this though.

All yours :-)
Was just curious about the testing framework.

This isn't an issue, it's a PR, of which I've provided the fix.

Makes sense.

Thanks @binarymist for the PR and @lirantal your interest in the testing framework. Best wishes for your workshops!

Thanks @ckarande!


feat: Azure Blob Storage Support

Introduce Azure blob storage support.
Ref: longhorn/longhorn#1309

also, PR check failed.

@mantissahz the below code seems incorrect. We should always override s.ServiceURL if azureEndpoint is not empty, right?
/azblob/azblob_service.go#L44-L55
	connStr := fmt.Sprintf(azureConnNameKey, accountName, accountKey)
	if azureEndpoint != "" {
		blobEndpointURL := strings.TrimRight(azureEndpoint, "/") + "/" + accountName
		connStr = fmt.Sprintf(connStr+blobEndpoint, blobEndpointURL)
	}

	if s.ServiceURL == "" {
		s.ServiceURL = azureURL
	}
	if s.ServiceURL != azureURL {
		connStr = connStr + fmt.Sprintf(blobEndpointSuffix, s.ServiceURL)
	}

azureEndpoint will use blobEndpoint ("BlobEndpoint=%s;")
and s.ServiceURL will use blobEndpointSuffix ("EndpointSuffix=%s;") (Default EndpointSuffix is azureURL )
They will be concatenated together into connStr.

You are right. It will be always respected if the value is provided.


Error while connecting to device (Chromecast with Google TV)

Hi there!
I have a Chromecast with Google TV and encountering errors when castblock trying to connect:
$ docker run --rm --network host erdnaxeli/castblock --debug
2021-10-03T18:11:10.837517Z   INFO - castblock.chromecast: Found go-chromecast at /usr/bin/go-chromecast.
2021-10-03T18:11:10.840001Z   INFO - castblock.chromecast: Starting the go-chromecast server.
2021-10-03T18:11:10.841673Z  DEBUG - http.client: Performing request -- method: "GET", host: "<IP_ADDRESS>", port: 8011, resource: "/"
2021-10-03T18:11:11.340612Z  DEBUG - http.client: Performing request -- method: "GET", host: "<IP_ADDRESS>", port: 8011, resource: "/"
2021-10-03T18:11:11.345441Z   INFO - castblock.chromecast: The go-chromecast server is up
2021-10-03T18:11:11.843229Z  DEBUG - castblock.blocker: Checking for new devices
2021-10-03T18:11:11.843234Z  DEBUG - http.client: Performing request -- method: "GET", host: "<IP_ADDRESS>", port: 8011, resource: "/devices"
2021-10-03T18:11:14.854489Z   INFO - castblock.blocker: New device found -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:14.854490Z   INFO - castblock.blocker: Connect to device -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:14.854493Z  DEBUG - http.client: Performing request -- method: "POST", host: "<IP_ADDRESS>", port: 8011, resource: "/connect?uuid=5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:17.860145Z  DEBUG - castblock.chromecast: Error while connecting to device -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21", status_code: 400, error: "'port' and 'addr' missing from query params and uuid device lookup returned no results"
2021-10-03T18:11:17.860168Z  ERROR - castblock.blocker: Error while connecting -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:47.863855Z  DEBUG - castblock.blocker: Checking for new devices
2021-10-03T18:11:47.863858Z  DEBUG - http.client: Performing request -- method: "GET", host: "<IP_ADDRESS>", port: 8011, resource: "/devices"
2021-10-03T18:11:50.866541Z   INFO - castblock.blocker: New device found -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:50.866542Z   INFO - castblock.blocker: Connect to device -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:50.866545Z  DEBUG - http.client: Performing request -- method: "POST", host: "<IP_ADDRESS>", port: 8011, resource: "/connect?uuid=5f28da17d5c93111ec4b8aca70c6de21"
2021-10-03T18:11:53.869772Z  DEBUG - castblock.chromecast: Error while connecting to device -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21", status_code: 400, error: "'port' and 'addr' missing from query params and uuid device lookup returned no results"
2021-10-03T18:11:53.869794Z  ERROR - castblock.blocker: Error while connecting -- name: "Chromecast LG TV", uuid: "5f28da17d5c93111ec4b8aca70c6de21"

Any chance you can take a look at this?
Thank you for such awesome project!

Connecting to android TV devices is problematic at the moment, even when it works you cannot skip sponsor blocks as seen in #24


DBusMenuExporterDBus::getProperties error

Please, can you help me with this : I have this error when I click on rViz to run the quick start demo  :
QVariantMap DBusMenuExporterDBus::getProperties(int, const QStringList&) const: Condition failed: action
Thanks.

any update for this issue?I have met the same problem

this seems to be a problem of either Rviz or Qt, unrelated to Autoware.


Import: Postfix for duplicated files starts with number 2

EPAM AI DIAL chat version
0.9.0
How to reproduce

Create "Chat_with_file" with attachment "file.png"
Export "Chat_with_file" with attachment
Import zip file with option postfix for chat ( only 1 dialog appeared)
Import zip file again with postfix option for file and chat

Actual result

New "Chat_with_file 1" was created, attached file has original name  "file.png" ( without postfix)
New "Chat_with_file 2" was created,  attached file has name "file 2.png" (with postfix 2)

Expected result

Postfix for files should start with 1 as for chats and prompts, file name should be "file 1.png"

Confidential information

[X] I confirm that do not share any confidential information

Verified on staging successfully


proposal: database/sql: Rows.Scan should return lasterr if present

When a context has been cancelled or timed out, Rows.Scan will return sql: Rows are closed. It would be nice to return the result of lasterr if it was not nil and not io.EOF, since an error was encountered between the call to Rows.Next and Rows.Scan. Additionally, for Row.Scan, there is no interface to detect if there was an error that occurred between Next and Scan, since only the results of Scan are exposed.
The caller could check context.Err() when it encounters sql: Rows are closed, but it would be more convenient for Scan to return the error value.
I believe it would be sufficient to add:
if rs.lasterr != nil && rs.lasterr != io.EOF {
	rs.closemu.RUnlock()
	return rs.lasterr
}

at the top of Scan, after:
rs.closemu.RLock()

I'll accept there is a documentation issue here at the least and there is possibly a reasonable code change..
The related issue is https://github.com/golang/go/issues/24329
And comment in issue here: https://github.com/golang/go/issues/23738#issuecomment-366919083
Right now if rows.Scan produces an error, it isn't a good idea to necessarily just return that error and run. You'd really want to:

Check Rows.Scan, assume err != nil.
Check Rows.Err
If Rows.Err == nil, call Rows.Close and return Rows.Scan's error.
If Rows.Err != nil, return that error.

If Rows.Scan does not return an error, you may safely omit the Rows.Err check, but you shoud still check for an error from Rows.Close. Let's see what that would look like:
for rows.Next() {
    var id int64
    err := rows.Scan(&id)
    if err != nil {
        if rows.Err() != nil {
            return rows.Err()
        }
        rows.Close()
        return err
    }
}
if err := rows.Close(); err != nil {
    return err
}
// Do work.

or
var scanErr error
for rows.Next() {
    var id int64
    scanErr = rows.Scan(&id)
    if scanErr != nil {
        break
    }
}
if rows.Err() != nil {
    return rows.Err()
}
if err := rows.Close(); err != nil {
    return err
}
if scanErr != nil {
    return scanErr
}
// Do work.

With your proposal you could write:
for rows.Next() {
    var id int64
    err := rows.Scan(&id)
    if err != nil {
        rows.Close() // We may be able to ignore this error.
        return err // This would be either a scan error or Rows.Err(lasterr) from Rows.Next.
    }
}
if err := rows.Close(); err != nil {
    return err
}
// Do work.

It does seem like it could simplify some code, or make existing code actually more useful. The downside someone may be (probably is) checking the text of rows.Scan's error and doing something with it. So this may be a compatibility issue.

I'd assume that calling Scan would always return a syntax/parsing/type casting failure from reading the value, and I might rewrap in a different way than I'd wrap rows.Err or rows.Close, which I would expect to be a connection failure or timeout.

One of the motivations for this is that in the case of Row, there isn't an option to check Close or Err from the underlyingRows. To catch the context close error would require this (or something similar):
err := db.QueryRowContext(ctx, q).Scan(&id)
if err.Error() == "sql: Rows are closed" && ctx.Err() != nil {
    return ctx.Err()
} else if err != nil {
    return err
}

Which could just be simplified to:
err := db.QueryRowContext(ctx, q).Scan(&id)
if err != nil {
    return err
}

Rows Next->Scan->Err seems to have been built with a single-threaded use in mind, but with the additional of context timeouts and cancellations, other errors can happen between the successive calls. Scan already returns an error (sql: Rows are closed), but sometimes the error could be more specific or give the cause.

@erykwalder Your last comment isn't convincing; Row.Scan checks for Rows.Err and Rows.Scan and Rows.Close errors all in one.
But I agree with you in general, I really see no reason not to return the lasterr if present on scan if Rows is closed.
@bradfitz I don't think this will be a compatibility problem, but theoretically someone could be checking the error text from rows.Scan. Do you have an opinion on this? If you don't I lean to doing this.

@erykwalder Your last comment isn't convincing; Row.Scan checks for Rows.Err and Rows.Scan and Rows.Close errors all in one.

It does, but again, does not handle errors that can happen asynchronously or from separate routines (specifically a context being timed out or cancelled). This is demonstrated by a simple program which runs inconsistently:
package main

import (
	"context"
	"database/sql"
	"fmt"
	"time"

	_ "github.com/lib/pq"
)

func main() {
	db, err := sql.Open("postgres", "postgres:///test?sslmode=disable")
	if err != nil {
		panic(err)
	}

	ctx, cancel := context.WithTimeout(context.Background(), 50*time.Microsecond)
	defer cancel()

	err = db.QueryRowContext(ctx, `SELECT 1`).Scan(new(int))
	if err != nil && err != context.DeadlineExceeded {
		fmt.Println(err)
	}
}

With sufficient runs, it will print sql: Rows are closed.
Looking at the source of Row.Scan, the problem is identifiable (comments are mine):
func (r *Row) Scan(dest ...interface{}) error {
	if r.err != nil {
		return r.err
	}

	defer r.rows.Close()
	for _, dp := range dest {
		if _, ok := dp.(*RawBytes); ok {
			return errors.New("sql: RawBytes isn't allowed on Row.Scan")
		}
	}

	if !r.rows.Next() {
		if err := r.rows.Err(); err != nil {
			return err
		}
		return ErrNoRows
	}
	// lastErr updated if context is closed by another routine here
	// won't be caught or returned
	err := r.rows.Scan(dest...)
	if err != nil {
		return err
	}
	if err := r.rows.Close(); err != nil {
		return err
	}

	return nil
}

@bradfitz I don't think this will be a compatibility problem, but theoretically someone could be checking the error text from rows.Scan. Do you have an opinion on this? If you don't I lean to doing this.

Let's try this and test it over the next 4 months and see.
I think making Scan return the correct errors on context cancels makes sense. Returning "Rows are closed" when they were really just canceled is slightly misleading, even if they were closed by the context-cancel-waiting goroutine.

@kardianos I'm happy to work on this if you don't already have something. I've already submitted a CLA fwiw.

@erykwalder That would be fine with me.


@Returns doesn't display in template

See: https://github.com/neogeek/doxdox/blob/master/templates/markdown.hbs#L53

This has been fixed with the release of #12


how to use automated template for creating command,query,service & more in all layers

@samanazadi1996 It would be great if you please guide , how to add new entity , its command ,query,service or anymore through template/automated way...
Continuation of

thats awesome man... I really love that much quick clip... Thanks @samanazadi1996
WIll come up more trouble

I did quick test for my sample entity, mostly all working good... small observations for corrections,
1> Commands no issue template working good
2> Query & Pagelist both working good but namespaces are missing

3>querypagelist here "D" letter missing documentaion,after adding it looks awesome

cool will come up with more...
I also created repo, PR and adding more & more, if am wrong in any sense please correct me...

You must have already created the return type.
If you pay attention to the example of Products, this type is located in the domain layer.

The document was also updated.


Error of assert xt.grad is not None

Hi, I am trying to evaluate on tsp100 data, and have this error saying
File "/T2TCO/diffusion/pl_tsp_model.py", line 247, in test_step
    g_xt = self.guided_categorical_denoise_step(points, g_xt, t1, device, edge_index, target_t=t2)
  File "/T2TCO/diffusion/pl_tsp_model.py", line 91, in guided_categorical_denoise_step
    assert xt.grad is not None

The function has this assert statement to assert xt has gradient, but the input g_xt is converted to long type in line 238, and long type tensor cannot have gradient. Can someone help me with this? Thanks
(g_xt > 0).long()

Hi, @jiajinghu19
Please kindly note that this tensor has been converted to float format in line 61 xt = xt.float(). The gradient here is estimated based on x_t. This issue is likely caused by the incorrect version of PyTorch Lightning. PyTorch Lightning itself does not support gradient computation during the testing phase. Therefore, we added two lines of code, torch.set_grad_enabled(True) and with torch.inference_mode(False):, to enable gradient computation. If you still encounter gradient computation issues, please check the version of the libraries or refer to relevant solutions for the version you are using, such as those available at https://github.com/Lightning-AI/pytorch-lightning/issues/13948.
Should you have any further inquiries, please feel free to reach out. By the way, kindly mention me in the comments (@ me) so that I can promptly receive notifications and address your question.


ICRC-29: broadcast ready message

Motivation
The icrc29_ready cannot be scoped to a particular origin because the origin is unknown at the time the notification is emitted. Therefore, I think it is worth highlighting in the specification that this is a broadcast.
Notes
Limitation, or approach, is  notably similar to Internet Identity specification for authorize-ready.

Discussed offline. I understood this specification as the specification of the "ready" message while it actually covers the general data exchange flow. There I close this PR and let @frederikrothenberger provides adjustments to the structure of the document if necessary in another PR.


[Question] Segfaults when creating default app

[REQUIRED] Please fill in the following fields:

Pre-built SDK from the website or open-source from this repo: repo
Firebase C++ SDK version: latest from repo
Main Firebase Components in concern: app
Other Firebase Components in use: app
Platform you are using the C++ SDK on: Linux
Platform you are targeting: desktop

[REQUIRED] Please describe the question here:
Update: I was able to resolve the build errors by using gcc-8. Maybe that should be mentioned as the lowest version of gcc required.
But then with a very simple app, with the built libraries copied to the lib folder, and a google-services.json with the requested fields valid, the following app segfaults.
Static tracepoint 1 at 0x7ffff70124e1: file ../sysdeps/x86_64/multiarch/strlen-avx2.S, line 65.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x0000555555562c7e in firebase::AppOptions::LoadFromJsonConfig(char const*, firebase::AppOptions*) ()
#2  0x0000555555559ee7 in firebase::(anonymous namespace)::LoadAppOptionsFromJsonConfigFile(char const*, firebase::AppOptions*) ()
#3  0x0000555555559bef in firebase::AppOptions::LoadDefault(firebase::AppOptions*) ()
#4  0x000055555555a04a in firebase::App::Create() ()
#5  0x000055555555989f in main ()

Example code

#include <firebase/app.h>
#include <iostream>
#include <unistd.h>

int main(int argc, char** argv) {

  firebase::App* app = firebase::App::Create();
  // std::cerr << "Database URL " << app->options().database_url() << std::endl;
  std::cerr << "Storage Bucket " << app->options().storage_bucket() << std::endl;
  std::cout << "Project ID " << app->options().project_id() << std::endl;
  std::cout << "API Key " << app->options().api_key() << std::endl;
  std::cout << "App ID " << app->options().app_id() << std::endl;
  // std::cout << "Messaging ID " << app->options().messaging_sender_id() << std::endl;
  // std::cout << "GA Tracking ID " << app->options().ga_tracking_id() << std::endl;
  std::cout << std::endl;
  std::cout.flush();

}

Makefile
all:
	g++ test.cc -Iinclude -Llib -lfirebase_app -lflatbuffers -lpthread

When I only print out the API key and App ID it doesn't segfault but I get bogus information: (It reports the API Key as being the actual storage bucket url and it reports the App ID as an empty string, though it is obviously not).

Forgot the -D_GLIBCXX_USE_CXX11_ABI=0 in my makefile


Where is PUBLIC_URL variable defined?

I saw the .env file only has API_URL. It did not have any  PUBLIC_URL right?
I ran my source code but it got an error GET https://localhost:3000/%PUBLIC_URL%/env-config.js net::ERR_ABORTED 400 (Bad Request).
My source code's using the webpack and do not use CRA, I use react-boiler-plate template, may be the issue comes from the webpack? I don't know
Please, help me out with the issue

https://create-react-app.dev/docs/using-the-public-folder/
it is CRA specific..

You may define any environment variables of your choice, instead of calling it API_URL you may call it PUBLIC_URL, at the end all environment variables become properties of the object that you injected into window.


Documentation

Want to improve the english and correct some grammatical errors in the website.

Any update ? @Akanksha-Sen


v8debug is not defined

VSCode Version: 1.6.0
OS Version: Windows 10
NodeJS: 4.6.0, 6.7.0, does not matter

After recent upgrade of VSCode (not sure which), language client does not utilize debug parameters sent to it because variable v8debug is not defined when debugging through vscode.
Steps to Reproduce:

Create a new extension according to official documentation https://code.visualstudio.com/Docs/extensions/example-language-server
Launch the extension in debug mode and set a breakpoint in language client, main.js
See the following code for reference:
https://github.com/Microsoft/vscode-languageserver-node/blob/master/client/src/main.ts#L1027
The variable v8debug is not defined, therefore the next line json = runDebug.debug; is never executed.

VS Code 1.6 uses a newer version of Electron which uses a newer node version. That could explain why v8debug is no longer defined.

Ok, does it mean that vscode-languageserver-node should keep up and update their sources to whatever is needed for newer version of node?
Let me know if you want me to move this issue to the language server project.

@dennisfrostlander yes, if vscode-languageserver-node uses node version specific APIs, then it has to keep up with node versions. I've assigned @dbaeumer to provide more details.

@weinand ok, let's then close this issue and track this in the language server repository.


fix(chart): use filer data PVC correctly

Follow-up to #4384
... Not sure if there's other related lurking bugs related to this ongoing enablePVC -> data.*.type transition. What's the plan on that? Maybe better to carry it out sooner rather than later ;) (I'm offering to do the work!)

Thanks! Please help since you have more expertise here!

Thanks! Please help since you have more expertise here!

I'm not sure about that, but I'll help if I can :)
The Helm chart is being versioned in-line with the main SeaweedFS project. Personally, I'm a big fan of this!
Unfortunately though, it means if we want to actually remove the enablePVC option, we should be doing that as a major breaking change. (i.e a 4.x version).
If you're not too worried about strictly observing semantic versioning guarantees on the Helm chart, we could instead add a small patch to NOTES.txt that causes the chart to fail installation if filer.enablePVC is set, with a message asking the user to instead switch to filer.data.
Please let me know what you think and I'll open an appropriate follow-up PR :)

@chrislusf ping! I can open another issue to continue the discussion if you'd prefer.

the latter approach should be easier for users to migrate.


Add a README

I added Dashvisor to the list of Supervisor dashboards.  It would be great if you could add a file to help people install and run it.  Supervisor users who are not familiar with Django may still want to try it.
There's a pretty good README for one of the other dashboard projects.  Adding a screenshot helps users compare the dashboards without having to install them.

Closing due to inactivity.


Turbo CLI prune method panics when scope not found

What version of Turborepo are you using?
1.0.15
Describe the Bug
turbo prune doesn't work
Expected Behavior
to create pruned output
To Reproduce
yarn turbo prune --scope=admin-api --docker
yarn run v1.22.15
$ /Users/mantas/Projects/sandbox/monorepo/node_modules/.bin/turbo prune --scope=admin-api --docker
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13c8764]
goroutine 1 [running]:
turbo/internal/prune.(*PruneCommand).Run(0xc0000977c0, {0xc0000b0060, 0x2, 0x2})
/Users/jared/dev/vercel/turbo/cli/internal/prune/prune.go:108 +0x3c4
github.com/mitchellh/cli.(*CLI).Run(0xc0000eb7c0)
/Users/jared/go/pkg/mod/github.com/mitchellh/cli@v1.1.2/cli.go:262 +0x5f8
main.main.func9({0x0, 0x14cd35e}, {0xc0000b0050, 0x100cf01, 0x3}, {0x0, 0x180d568}, {0x0, 0x0}, 0xc0000eb7c0, ...)
/Users/jared/dev/vercel/turbo/cli/cmd/turbo/main.go:161 +0x385
main.main()
/Users/jared/dev/vercel/turbo/cli/cmd/turbo/main.go:166 +0xb3b
error Command failed with exit code 2.

@jaredpalmer Do you need more information about env or usage?

I am experiencing exactly the same issue. In example project command works just fine but in my project the command always crash.
$ /home/vavra/Projects/ww/node_modules/.bin/turbo prune --scope=product
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7cc124]

goroutine 1 [running]:
turbo/internal/prune.(*PruneCommand).Run(0xc0000a76f0, {0xc0000a8170, 0x1, 0x1})
        /Users/jared/dev/vercel/turbo/cli/internal/prune/prune.go:108 +0x3c4
github.com/mitchellh/cli.(*CLI).Run(0xc0000f37c0)
        /Users/jared/go/pkg/mod/github.com/mitchellh/cli@v1.1.2/cli.go:262 +0x5f8
main.main.func9({0x0, 0x8cf3b5}, {0xc0000a8160, 0x40d201, 0x2}, {0x0, 0xc0c168}, {0x0, 0x0}, 0xc0000f37c0, ...)
        /Users/jared/dev/vercel/turbo/cli/cmd/turbo/main.go:161 +0x385
main.main()
        /Users/jared/dev/vercel/turbo/cli/cmd/turbo/main.go:166 +0xb3b

turbo v1.0.19

@vavra7 I found out my mistake, when providing scope it has to be the exact package name that is set in the package.json. turbo v1.0.19
@jaredpalmer I could close this issue, but it could be better to throw a human-readable error, that package was not found or something like that

Will change title

@bernessco ou there is the problem! I provided folder name which is ${appName} as scope but in package.json the name of the app is @${projectName}/{appName}. Thank you.

This now gives a proper error message


Automatic PR from RestAPI-PR470

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/470

Coverage decreased (-0.07%) to 57.892% when pulling f720cb4d6e92397bbd3e46da81577e94abd78b83 on AutorestCI:RestAPI-PR470 into fccf37ae25b10fab4a8c94549dcabb7f6957e16f on Azure:dev.


👷 Limit max pygit2 version due to breaking changes

Limit pygit2 max version to <1.15 due to breaking changes pygit2-changelog it introduces.
At least one of the deprecations affects this codebase: Remove deprecated oid.hex, use str(oid) (see #758).
Fix #758
PS: I tried to mimick the emojis you use on commit messages, but I'm not sure if I got it it 😅 .

@cjolowicz, when running pipx locally I was finding the same issue that's happening on CI right now.
Changing to an absolute path solved it locally, so I added a commit including this change.

Well, at least the error changed. I guess new errors mean progress, right? 😅
From the new error the issue is that I used a more up to date version of poetry, which created an incompatible lock file.
Is it ok if I upgrade the dependencies on the constraints file, @cjolowicz ?

OK, CI is now finally passing for almost all checks. Only safety is failing now. 5 dependencies would require action, but I'm not sure how you prefer to tackle these kind of issue.

Thank you for working on this! I'm fine with upgrading any dependencies that cause errors in Safety or other CI jobs.

Wow, what started as a "hey, a single line of code can fix this here" became a visit to dependency hell haha.
It was worth it.
Summary of changes:

had to drop support to python 3.7 (which is EOL, so I think its fine) in order to bump the affected libraries
since I was playing with python versions, also updated the support matrix with up to 3.12
had to adjust the code to play nice with updated linter versions, with exception to type guard. That one I just downgraded back to the version that was in use before because there were more than 20 failures.

All checks passed on my fork (bruno-fs/retrocookie#1)


Python readimage improvement series imageio

This PR improves how images and image series are read using ITK Python.
Image series can now be read the same way single image files could already be read, relying on the automatic pixel type and image dimension detection. This can be done both by explicitly calling itk.ImageSeriesReader.New(FileNames=["xxx", "yyy"]) or by using the Pythonic function itk.imread(["xxx", "yyy"]) providing a list of images to the function.
When using itk.ImageFileReader.New() or itk.ImageSeriesReader.New() to read an image for which the pixel type and image dimension is automatically detected, one can now specify which image IO that is going to be used. Previously, this could only be done if the pixel type and image dimension were manually specified. Otherwise, the image IO was selected automatically.

How does differ from #258 ?

@hjmjohnson This PR was done against python-builds to test the Python wrapping. #258 was done against master. What I understand is that, at least for now, on Github, for PR addressing Python issues, one has to create one PR against master that will eventually be merged, and one PR against python-builds to test the Python wrapping. @thewtex , can you confirm my statement?


Enable GPU/RE teags for pytorch/*/TARGETS that needs GPU

Summary: Convert pytorch_gpu to use GPU/RE
Reviewed By: malfet
Differential Revision: D26264102

I don't think the PR intended to target fbsync as it's a protected branch. I'm closing the PR to avoid accidental merges/issues and I'll comment on Phabricator to see what's the best way to merge this. :)

@datumbox sorry it was auto generated in phabricator. should I change it to master?

@walterddr Actually, this was my bad. We don't get lots of PRs from phabricator so I was not aware of the full process. To summarize, you did good to send a PR this way, even if we won't merge it at the end. Sending this PR allow us to check that the CI tests pass. After confirming that the PR passes, we would close it and wait for the shipit to merge it after it's done on phabricator.
For this specific PR, it seems that the lint fails. All other tests (minus flaky) pass without problem.

Thanks for the follow up @datumbox
I will reopen this PR when I push more commits internally to trigger CIs.

reopen


Update outdated commands

@jeremymeng : Thanks for your contribution to the Azure documentation! The author, @cephalin, has been notified to review your proposed change.

This change is already being staged in the private repo. Thanks! #please-close


Config Option For Shorthand Recipes?

Hello,
Is there a config option to disable CR's shorthand recipes for vanilla items? I looked through and can't seem to find the entry for disabling it.
Thank you,
Darkosto

You mean the shorthand recipe for pistons? No, there's no option. Just crafttweaker it out if it causes a problem somehow.


Upload collection not picking up some cards

I and my friends have noticed an issue where some cards (generally white) are not being picked up from the MTGA log when importing a collection.
Using Theros Beyond Death as an example, Captivating Unicorn, Daybreak Chimera and Dreadful Apathy commons are missed, as are a number of uncommons. These are also shown at the bottom of the Collection Statistics as oppose to at the top with the other white cards (after not-in-booster cards).

Good catch, it's easy to reproduce, looks like there's a problem with at least the first cards of Theros (Collector Number 1 to 14, Arena IDs 70801 to 70814) when importing a collection. Not sure what's causing it for now.
Thank you for the report.

Should be fixed by 4053b1714eb8bbbc5cfc3a59131c571c0eb6dda9

Fix works for me, thank you for the speedy fix.


Revert 69705 and fix #72344

https://github.com/zephyrproject-rtos/zephyr/pull/69705
Introduced a regression in main in which tests/subsys/logging/log_timestamp started failing.
Let's revert the PR. It can be submitted after with the issue fixed.
Fixes #72344

@aescolar did you consider reverting just the one commit that @fabiobaltieri identified as the culprit? I was able to verify that simply reverting it also fixes the issue.

@aescolar did you consider reverting just the one commit that @fabiobaltieri identified as the culprit? I was able to verify that simply reverting it also fixes the issue.

I did, but I was concerned that reverting only that one I would leave something else broken. It just seemed the cleaner and safer thing to do was revert the whole PR; And once the author identifies the cause behind the issue the PR can be resubmitted with it fixed.

Thanks @najumon1980 , does that mean you will be able to have a patch ready and passing soon? (in a matter of an hour or so). Otherwise we can just merge the revert and the original PR can be resubmitted without time pressure.

let see I can provide a fix for this

Provided following fix for the regression:
https://github.com/zephyrproject-rtos/zephyr/pull/72352

@najumon1980 The fix in #72352 does not seem too trivial. I'm quite inclined to merge this revert PR and unblock main. If you don't say otherwise in the next few minutes I'll go ahead and merge this one.

Yes, I think it's better to give the correct fix some more time for review, especially from @andyross, so let's merge the revert first.

Random aside: this is the second time in a week we've seen core tests regress from PR's that didn't see them in CI?  Is something getting skipped?  Basically how was this not caught?


[Suggestion] Easy implementation (but i can’t code)

Someone, preferably @danielkrupinski, should add the option to force onshot on a key. With this simple implementation, osiris wouldn’t be half bad for semi rage

Or a Checkbox with setting Only on stand still and check (localPlayer->velocity()).length2D() < 0.0015f or (localPlayer->getAimPunch()).x == 0.0f && (localPlayer->getAimPunch()).y == 0.0f.

Or a Checkbox with setting Only on stand still and check (localPlayer->velocity()).length2D() < 0.0015f or (localPlayer->getAimPunch()).x == 0.0f && (localPlayer->getAimPunch()).y == 0.0f.

Someone, preferably @danielkrupinski, should add the option to force onshot on a key. With this simple implementation, osiris wouldn’t be half bad for semi rage

If you're talking about semi rage, people mostly have legitaa. Against legitaa onshot is mostly useless

Someone, preferably @danielkrupinski, should add the option to force onshot on a key. With this simple implementation, osiris wouldn’t be half bad for semi rage

If you're talking about semi rage, people mostly have legitaa. Against legitaa onshot is mostly useless

Someone, preferably @danielkrupinski, should add the option to force onshot on a key. With this simple implementation, osiris wouldn’t be half bad for semi rage

If you're talking about semi rage, people mostly have legitaa. Against legitaa onshot is mostly useless. Nevertheless it's very easy to implement

that’s not true.  With this simple implementation, osiris wouldn’t be half bad for semi rage

If you're talking about semi rage, people mostly have legitaa. Against legitaa onshot is mostly useless. Nevertheless it's very easy to implement

that’s not true. Antiaim disables for a split second on shot. hence why shit resolvers prefer onshot

Or a Checkbox with setting(s) Only on stand still/ Only on no recoil and check (localPlayer->velocity()).length2D() < 0.0015f or (localPlayer->getAimPunch()).x == 0.0f && (localPlayer->getAimPunch()).y == 0.0f

would you mind compiling this into a dll with AVX2? ion have a pc rn

Or a Checkbox with setting(s) Only on stand still/ Only on no recoil and check (localPlayer->velocity()).length2D() < 0.0015f or (localPlayer->getAimPunch()).x == 0.0f && (localPlayer->getAimPunch()).y == 0.0f

would you mind compiling this into a dll with AVX2? ion have a pc rn


Transaction Tests

Summary
This PR adds integration tests for the get_transactions and compile_tx_script web client calls in transactions.rs.

Once https://github.com/0xPolygonMiden/miden-base/pull/951 gets merged, the CI can be re-run since the WASM build should be fixed

@igamigo sounds good thanks for the heads up! In the meantime, the rest of the feedback has been addressed @tomyrd @SantiagoPittella 🙌

@dagarcia7 can you rebase your fork from next? It should contain fixes to your failing tests.


"Camera successfully connected!" shows twice

Thank you for sharing your code. I'm using it on raspberry pi to connect with GoPro session 4. I've successfully sync'd the GoPro date and time. I notice that the "Camera successfully connected!" appears twice after >>> gpCam = GoProCamera.GoPro(constants.gpcontrol) is entered. Maybe exceptions to try are queued causing prepare_gpcontrol() to restart in another loop?

Yes, once the camera is woken up it checks again.

Then I'll not worry. Thanks again.


key :cached_memory not found

First of all, thanks for this lib. It makes it easy to cache http results without having to do anything besides a small setup; which makes my development easier.
One thing I do notice it that it crashes while running on OTP 26 / Elixir 1.16.2 on Mac OS X

Erlang/OTP 26 [erts-14.2.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1]
Elixir 1.16.2 (compiled with Erlang/OTP 26)

[error] GenServer :http_cache_store_disk_lru_nuker_memory terminating
** (KeyError) key :cached_memory not found in: %{
  system_total_memory:<PHONE_NUMBER>4,
  free_memory: 468860928,
  total_memory:<PHONE_NUMBER>4
}

 :erlang.map_get(:cached_memory, %{system_total_memory:<PHONE_NUMBER>4, free_memory: 468860928, total_memory:<PHONE_NUMBER>4})
    (http_cache_store_disk 0.3.0) /my/dev/folder/deps/http_cache_store_disk/src/http_cache_store_disk_stats.erl:42: :http_cache_store_disk_stats.system_memory_use/1
    (http_cache_store_disk 0.3.0) /my/dev/folder/deps/http_cache_store_disk/src/http_cache_store_disk_stats.erl:31: :http_cache_store_disk_stats.allocated_memory_used/1
    (http_cache_store_disk 0.3.0) /my/dev/folder/deps/http_cache_store_disk/src/http_cache_store_disk_lru_nuker_memory.erl:38: :http_cache_store_disk_lru_nuker_memory.nuke/1
    (http_cache_store_disk 0.3.0) /my/dev/folder/deps/http_cache_store_disk/src/http_cache_store_disk_lru_nuker_memory.erl:31: anonymous fn/0 in :http_cache_store_disk_lru_nuker_memory.handle_info/2
    (telemetry 1.2.1) /my/dev/folder/deps/telemetry/src/telemetry.erl:321: :telemetry.span/3
    (http_cache_store_disk 0.3.0) /my/dev/folder/deps/http_cache_store_disk/src/http_cache_store_disk_lru_nuker_memory.erl:28: :http_cache_store_disk_lru_nuker_memory.handle_info/2
    (stdlib 5.2) gen_server.erl:1095: :gen_server.try_handle_info/3
    (stdlib 5.2) gen_server.erl:1183: :gen_server.handle_msg/6
    (stdlib 5.2) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
Last message: :check
State: []
[notice] Application http_cache_store_disk exited: shutdown

Hi, thanks for reporting!
Looks very similar to https://github.com/tanguilp/http_cache_store_memory/issues/1 but I didn't port it to this lib (just forgot it seems). Can you confirm it looks like the same issue?
Associated fix here: https://github.com/tanguilp/http_cache_store_memory/commit/cb758b4ef6f04ba0285ef60f805adb6dae12c11a

Fix in https://github.com/tanguilp/http_cache_store_disk/commit/3b805e818872cd94835274d51e4730f6ba668b35
v0.3.1 was just published.


fixed match does not recreate provisioning profile

bundle exec rspec
Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

Why is this change required? What problem does it solve?
When the provisioning profile is invalid, it might be caused by deleting the provisioning profile on the Dev Portal.
fastlane does not work! fastlane match do not recreate provisioning when i set readonly is false , meanwhile, it do not  recreate provisioning when the provisioning file is invalid.

If it fixes an open issue, please link to the issue here.
Not found.

Please describe in detail how you tested your changes.
I delete adhoc provisioning file in apple developer website, then i run fastlane match adhoc,
It work!

Description
If  the provisioning file is invalid , it should not raise a exception right now. May be we need recreate the   the provisioning file.

@wade0317 Hey, quick question that I thought of while reviewing that might help me review this a bit better and make some suggestions... Without introducing this change, does setting force: true somewhat accomplish the same thing for you?
I'm not saying force: true is the correct thing to do here but just curious if that is another solution to this problem 😊

@wade0317 While looking at this I wanted to try out a different approach to solving this problem. I created a separate PR for this if you don't mind taking a look 😊 #12539

@joshdholtz  Yes , even set  force as true , the provisioning profile will not be created. It seem that we both solve a same problem,  but i think it may be some more for adding a option with recreate_deleted_profiles, since it already has  readonly options. if readonly is false, it mean match need recreate something which is invalid.
Meanwhile ,  it should check if the provisioning profile if valid, then install it to the local directory. if match find a valid provisioning profile, it's bette delete it from the local directory, so i exchange some logic in

@wade0317 Weird, setting force: true should have definitely solved it for you 🤔 I was able to recreate your situation and setting force: true worked for me. Can you try pulling down PR #12539 and seeing if my new option (recreate_deleted_profiles: true) works for your situation?
I think we would like to add a new option to solve this as an opt-in approach reduces confusion in "new behavior" and will reduce of the risk regressions but changing simply adding a new path 🙃

@joshdholtz ok, I accept your PR ~  ~

Closing this in favor of https://github.com/fastlane/fastlane/pull/12539


Problems starting a fresh created react app in folders with '#' in the name.

Describe the bug
Creating a fresh application in a folder structure, in which any folder has a name including a '#' symbol, for example D:\projects\web\something#something\myapp (might be the same case with other symbols), results in errors.
Did you try recovering your dependencies?

yes
Which terms did you search for in User Guide?

I made a lot of search about the module versions and dependencies and encountered another issue #11789 which has the '#' character in their folder structure and having the same problem. I am not sure whether this is the right place to issue the bug since it seems like a webpack thing to me, but since i have encountered this problem while i was trying to create a new react app using this tool, this is where it felt like the right place.
Environment

Environment Info:

  current version of create-react-app: 5.0.0

  System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz
  Binaries:
    Node: 14.18.3 - D:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.15 - D:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 97.0.4692.71
    Edge: Spartan (44.22000.120.0), Chromium (97.0.1072.55)
    Internet Explorer: 11.0.22000.120
  npmPackages:
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    react-scripts: 5.0.0 => 5.0.0
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

create a folder with '#' in its name eg: "app#folder".
cd into that folder.
create a new react app using npx create-react-app new-app
cd new-app.
npm start

Expected behavior

The app should start with default react welcome page.
Actual behavior

you get compilation errors saying module not found.

what's the solution of this problem?

I ran into a similar problem today, all for me to see this issue. I spent a ton of the day thinking I did something wrong

Describe the bug
Creating a fresh application in a folder structure, in which any folder has a name including a '#' symbol, for example D:\projects\web\something#something\myapp (might be the same case with other symbols), results in errors.
Did you try recovering your dependencies?
yes
Which terms did you search for in User Guide?
I made a lot of search about the module versions and dependencies and encountered another issue #11789 which has the '#' character in their folder structure and having the same problem. I am not sure whether this is the right place to issue the bug since it seems like a webpack thing to me, but since i have encountered this problem while i was trying to create a new react app using this tool, this is where it felt like the right place.
Environment
Environment Info:

  current version of create-react-app: 5.0.0

  System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz
  Binaries:
    Node: 14.18.3 - D:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.15 - D:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 97.0.4692.71
    Edge: Spartan (44.22000.120.0), Chromium (97.0.1072.55)
    Internet Explorer: 11.0.22000.120
  npmPackages:
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    react-scripts: 5.0.0 => 5.0.0
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

create a folder with '#' in its name eg: "app#folder".
cd into that folder.
create a new react app using npx create-react-app new-app
cd new-app.
npm start

Expected behavior
The app should start with default react welcome page.
Actual behavior
you get compilation errors saying module not found.

I ran into a similar problem today, all for me to see this issue. I spent a ton of the day thinking I did something wrong


Updated to app-services-sdk-go in Core SDK

Description
This PR updates the location and version of the app-services-sdk-go used. The old package used here is now deprecated and is being replaced by the Core SDK.
Verification Steps

Check if all unit tests and linting has passed

Checklist (Definition of Done)

[x] All acceptance criteria specified in JIRA have been completed
[x] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks

@jackdelahunt can you rebase?

it needs a rebase

Done 👍

@machi1990 done 👍


refac: redefine builders as create methods in AppBio QuantStudio

Refactor builders as create methods in AppBio QuantStudio

first part at https://github.com/Benchling-Open-Source/allotropy/pull/128
second part of https://github.com/Benchling-Open-Source/allotropy/pull/38

Thanks again for all the hard working improving code consistency!


Binary Search [JavaScript]

This issue is about Binary Search.

[x] Issue Title is in form Algo/DS Name [Language].
[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
[x] This Algo/DS is worth adding to this repository.
[ ] Assign this issue to me (I want to work on this).
[x] I will send my PR only after I'm assigned to this issue by any maintainer.

@Anshuman-Verma: Please complete previously assigned issues first.

@singhpratyush Please assign me this one.


fixing markdown

Coverage remained the same at 93.319% when pulling 9c77cca5b384b7aefba7373f51b6f851a77bb635 on rawb0t:patch-1 into 782bf6f86c3967fa488aa75bb5f590a8741eaa3a on bitpay:master.