b can't figure out main.main when using vips

Delve Debugger OSX
Version: 1.0.0
Build: $Id: c98a142125d0b17bb11ec0513bde346229b5f533
go version go1.10.2 darwin/amd64
package main

import (
	"fmt"
	"os"
	"os/signal"
	"syscall"

	"github.com/davidbyttow/govips/pkg/vips"
)

var testChannel = make(chan os.Signal, 1)

func main() {
	x := 1
	fmt.Println("Hello 1", x)
	signal.Notify(testChannel, syscall.SIGTERM)
	signal.Notify(testChannel, os.Interrupt)
	fmt.Println("Hello 2", os.Getenv("ENVIRONMENT"))
	fmt.Println("Hello 2", x)
	vips.Startup(&vips.Config{
		ConcurrencyLevel: 1,
		MaxCacheFiles:    1,
		MaxCacheMem:      200 * 1024 * 1024,
		MaxCacheSize:     200,
		ReportLeaks:      false,
	})
	defer vips.Shutdown()
	var imgRef *vips.ImageRef
	imgRef, err := vips.NewImageFromFile("test.png")
	if err != nil {
		fmt.Printf("%v", err)
		return
	}
	defer imgRef.Close()
	fmt.Printf("%+v", imgRef.Height)
}

$ dlv debug
Type 'help' for list of commands.
(dlv) b main.main
Breakpoint 1 set at 0x40d376d for main.main() ./main.go:27

When you comment out vips, it correctly find main.main
$ dlv debug
Type 'help' for list of commands.
(dlv) b main.main
Breakpoint 1 set at 0x40d358b for main.main() ./main.go:14

I've tested this with go1.11 (built from tip) and I can't reproduce it. I can reproduce it with go 1.10 so I'm going to guess that this was a bug with either go itself, or with dsymutil, or the interaction between the two.

Ok, did you also test with backend native / lldb mode? Don't know if it has anything to do with it just asking

It doesn't matter, this all happens at a higher layer.


fix: sampling messages should be at debug level

:tada: This PR is included in version 1.41.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


I want on click image

I want on click image

I guess you meant on click of cell. If so, have you tried - collectionView:didSelectItemAtIndexPath:?

Yes

Doesn't it meet your requirement? You could add gesture recognition to handle on touch image.

Close this, reopen if need be.


linux: clearer origin for settings configuration

Motivation for this change
I am looking into improving kernel configuration composition (if we could move all kernelPatches to use extraConfigStructured instead of extraConfig, that would help) but I guess I won't have time to finish a PR before a few months. This just adds a _file entry so that when kernel configurations clash, we can actually see where the conflict comes from.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@sphalerite @dtzWill any comment ? it's quite a simple change


React Native support

i have a problem when i run this compotent  on android
i knows react not enough dasy sorry

As of right now, hedron is completely untested with react-native. I would definitely love to add support for it in the future, but I'm unable to do it myself right now.
If you, or any one else wants to step up and get hedron working in react-native, that would be amazing 😸

Since react-native now supports percentage based dimensions, porting hedron should be very trivial. I'm hoping that somebody who has more experience than me in react-native can tackle this. I could attempt to add support myself, but I'm not too well versed in react-native, and I definitely want it to be implemented the proper way.

@garetmckinley Is this something you (and others) are interested in? I am happy to spend the time porting this over if you think others would be interested.

That's totally up to you @jim-at-jibba. Native support would be a welcome addition IMO, but I can't speak for the amount of demand there is for it. If it's something that you'd like to tackle, I'll, of course, accept a PR for it :smile_cat:

Ok cool. I will have a poke around and see how much work it is. I know i would use it so will probably be worth it. Thanks for merging in my PR

No problem, I appreciate the PR :+1: feel free to reach out if you have any questions. Twitter DMs are probably the quickest way to reach me, but I scroll through my GitHub notifications at least once daily.


luaPackages.protobuf: init -> 0.4.0

Description of changes
A lua module to interact with google protobuf

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Does the update script accept parameters to only generate expressions for new packages?

Unlike the vim updater, I dont think it's that smart yet. The way you did is my preferred one. I am bit surprised you didn't need any other dependencies ? other than that ok. Are there some tests you could run ?

Does the update script accept parameters to only generate expressions for new packages?

Unlike the vim updater, I dont think it's that smart yet. The way you did is my preferred one. I am bit surprised you didn't need any other dependencies ? other than that ok. Are there some tests you could run ?

Ok, I see.
I had some hickup with running the test-suite because the needed deps aren't in nixpkgs yet.
I'll create some extra PRs to bring them in as well.
Anyway, the test-suite passed, as well as running the example code snippet from the Readme in a nix-shell and it worked.

very few packages run the testsuite and support for it in rockspecs is recent so no issue. this can be done later.
Could you add yourself as maintainer in maintainers/scripts/luarocks-packages.csv ? then we can merge.

very few packages run the testsuite and support for it in rockspecs is recent so no issue. this can be done later. Could you add yourself as maintainer in maintainers/scripts/luarocks-packages.csv ? then we can merge.

Okay. I don't fully understand the whole lua related stuff in nixpkgs yet, but ok, I registered for maintainership. ⛴

Okay. I don't fully understand the whole lua related stuff in nixpkgs yet, but ok, I added myself to the maintainership.

You understand 95% of it, it's a not very active part of nixpkgs so it may feel a bit clunky.


[WIP][TIR][OP] Add New Tir Ops

This PR intends to introduce a few new target dependent intrinsic lowering function of tir level ops for better support. The ops are selected from numpy ops and supported in cmath.

As the intrinsic lowering pull request is merged, I would rebase and reopen other PR later to make it work.


stats: add new BoolIndicator stat type

Description: Add the BoolIndicator stat type. A followup PR will migrate a number of gauges that only ever set 1 or 0, meaning them as true/false. Beyond adding more meaningful type distinction to stats, this will get us closer to consist logic for migrating/combining gauges during hot restart.
I chose BoolIndicator because Bool/BoolSharedPtr is not obviously something other than slightly-wrapped plain old data, and the stats classes' naming conventions would call for a function named bool(). On the other hand, I wasn't entirely sure if just Indicator would imply boolean strongly enough to make everyone happy. I'm open to suggestions (including chopping it down to Indicator).
Risk Level: low (a lot of code, but still unused, and really just duplicating the existing gauge code)
Testing: roughly duplicated every bit of test logic involving the word "gauge"
#4974 #5790

I tried migrating GrpcMux/GrpcStream's connected_state gauge over to this new type, as an example to confirm that it works in the actual code. I have left those changes out of this PR, though.

I left the return type of value() as uint64_t, assuming that people could potentially have hard-to-change stuff built around that. But, taking a look at Google's use of them, I see we were actually already wanting a bool, and just doing a "> 0" to get it.
So, is it reasonable to change the return type to bool, and expect people to adapt their code?

@jmarantz are you planning on taking a pass on this one?

No problem, there's nothing waiting on this!
Yes, there are several existing stats that will become this type. They are all among https://github.com/envoyproxy/envoy/issues/5790#issuecomment-459755480

@fredlas I think it's better to change the type now. The call-sites will need to be explicitly changed anyway from Gauge& to BoolIndicator& so that's a good time also change the value() references to expect a bool.

Thanks, that makes sense.
Actually, now having gone further with the main hot restart work, I'm starting to think this change might also need to be part of the big hot-restart-breaking PR. Not sure yet, though.

I think this doesn't have to be hot-restart breaking. Just lay out the BoolIndicator impl struct exactly the same as Gauge's impl, and ensure in the impl that the bit-patterns are the same.
Leave a TODO to simplify the BoolIndicator impl once hot-restart does not use shared mem.

Oh, yeah, you're totally right; as long as this change goes in before #5910 it's very straightforward. I was too far into the #5910 mindset when I wrote that!

And in fact you could write an evil unit-test to prove it, by reinterpret_cast-ing a BoolIndicator& to a Gauge& and making sure the data written to one is correctly read by the other :)

I gave that test a try, and it didn't work, I'm guessing because the Gauge and BoolIndicator classes are laid out a bit differently (like BoolIndicator missing add/sub/inc/dec). Anyways, PTAL.

@fredlas I think my reinterpret_cast suggestion was a little misleading (ie wrong). Casting between the Gauge* and the BoolIndicator* doesn't make sense. It makes more sense to construct a GaugeImpl<RawStatData> and BoolIndicatorImpl<RawStatData> using the same RawStatData object declared in a test method. You should be able to then use the Gauge's write method and read from the BoolIndicator and vice versa. Does that make more sense?

Yup, test added. Seeing the test pass, I think I get it, and am now largely confident that the gauge->indicator auto-conversion will work as desired. This whole stats store setup is very interesting/spooky. I didn't fully understand until now the extent to which stat name strings are important. It's like it's just a string->[raw chunk of memory] map, and the counter vs gauge classes are just syntactic sugar hiding conceptual casts of that raw memory.
In this most recent commit, I also converted every actually-a-bool gauge I could find.
PTAL!

Merged to get whatever PR fixed the build breakage.


node version update

Task
Change Node's version that is used in branch "next" from 14 to 16
Changes

node:16-ubuntu-cypress image added

Author
Signed-off-by: Naghme Mohammadifar<EMAIL_ADDRESS>

Fixed in dev pr 548


Average charging power calculation

My Zoe50 does not return charging power data, but maybe the average power could be added to the output, given that duration and charged kWh are returned by /charge-history:
/charge-history
        {
            "day": "20220317",
            "totalChargesNumber": 1,
            "totalChargesEnergyRecovered": 5.4,
            "totalChargesDuration": 241
        },

/charges:
        {
            "chargeStartDate": "2022-03-17T01:01:10Z",
            "chargeEndDate": "2022-03-17T05:02:01Z",
            "chargeDuration": 14451,
            "chargeEndBatteryLevel": 74,
            "chargeEndStatus": "error"
        },

Beware of different unit of measure in /charge-history (minutes) and /charge (seconds).

I haven't figured out yet why, but my ZOE40 stopped reporting the charge power since last week. The original app also doesn't know; so this may be more interesting anyway...

@epenet that's what the car API knows, right? regardless, you'd have to know valid timestamps no? There's no 'now()' or 'now()' and 'previous()' so you'd have to do quite a bit of math.
Obviously this would be a hass change only; but the idea would be that when you get the current measurant, you also get the one 'just before' it (or remember your previous one) and calculate the average charge power over that interval. But so far I haven't heard anybody else stating they have lost this information like I have here https://github.com/hacf-fr/renault-api/issues/1213 so that makes me wonder if the car simply stopped reporting it; and the TCU is using an older version of the firmware.

The Renault API has been all over the place these past few months.
Endpoints keep changing one way, and then another way.
Even the official phone app can't keep up - with data disappearing and reappearing.
I will still happily take PRs for Home Assistant and for this project

@epenet did you not also have an ZE40? I'm just surprised I'm the only one suffering from these changes :p

Yes I have a Zoe40, and I suffer also from these changes - but that doesn't mean that I am responsible for the dodgy API from Renault that keeps changing and breaking.

Yes I have a Zoe40, and I suffer also from these changes - but that doesn't mean that I am responsible for the dodgy API from Renault that keeps changing and breaking.

Haha, no that's not what I meant, but it IS confirmation that the issue is not just mine :) Thanks for confirming :)

Closing this - feel free to open a PR


Light UI's Focus slider is not synced with the configuration panel

When the focus is changed in the Configuration panel, the slider in the Light UI does not update.
Moreover, the number indicator next to the slider not only has no visual link with the former, but it also does not reflect a correct value in terms of unit.
However, when the Light UI slider is used, the one in the Configuration panel does update.

This issue was a mistake. It was a bug introduced by my own work on branch fix_closing advsett, the behaviour was fine in dev. The work is now fixed in the corresponding branch and pull request.


File not found: 'pwsh'

Hey,
I run this action on our sef-hosted runner. (https://github.com/evryfs/github-actions-runner)
Got this:
Run egor-tensin/setup-gcc@v1
  with:
    platform: x64
    cygwin: 0
    cc: 1
    hardlinks: 0
  env:
    pythonLocation: /home/runner/_work/_tool/Python/3.9.2/x64
    LD_LIBRARY_PATH: /home/runner/_work/_tool/Python/3.9.2/x64/lib
Error: File not found: 'pwsh'

I wanted to run this action on Linux & Windows, and pwsh seemed like the only choice for writing cross-platform steps (the other one is bash, but I don't like the Git bash used on Windows, or whatever).
It says in the docs:

This is the default shell used on Windows. The PowerShell Core. GitHub appends the extension .ps1 to your script name. If your self-hosted Windows runner does not have PowerShell Core installed, then PowerShell Desktop is used instead.

So I'm afraid you need to install PowerShell Core to use this action.

I'm running this in a self-host ubuntu 18.04 runner too.
It seems your script recognize the self-host as a windows and try to run pwsh
Can we force the os to linux?
@egor-tensin


fix pprof config missing double quote

fix pprof config missing double quote

Codecov Report

Merging #69 (28ea716) into develop (f51cb68) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop      #69   +/-   ##
========================================
  Coverage    41.82%   41.82%
========================================
  Files           32       32
  Lines         1315     1315
========================================
  Hits           550      550
  Misses         690      690
  Partials        75       75

Continue to review full report at Codecov.

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


Test: Add Registry to network as a FullNode

This will make Validators gossip TXs/enrollments/preimages
to the name registry node.

wait this should be a part of #2487, not a standalone PR. Closing.


Closing tab animation

currently when you open a new tab you get the nice pop animation, but when you close it there is no animation, it just disappears.
it would be nice to have a closing pop animation

Sorry for never adding this but for now I probably will not. The problem is vscode deletes elements for tabs and you cannot apply an animation on delete unless you use some custom javascript and catch the deletion. I tested the basics of that and vscode messes up detecting the "deleted" elements as tabs and it just gets messy quick. Maybe in the future or if anyone has ideas on this then I will add closing animations but for now I think it is better to not introduce a bunch of bugs.

Not a problem, thank you for your time and keep it up!
On Sun, 13 Aug 2023 at 6:26 PM BrandonKirbyson @.***>
wrote:

Closed #8 https://github.com/BrandonKirbyson/VSCode-Animations/issues/8
as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/BrandonKirbyson/VSCode-Animations/issues/8#event-10080189891,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A22ZLFH42CFKKWA3Y4FA3VDXVD5ZXANCNFSM6AAAAAAYYCVMPQ
.
You are receiving this because you are subscribed to this thread.Message
ID: <BrandonKirbyson/VSCode-Animations/issue/8/issue_event/10080189891@
github.com>


Client Examples for Several Applications

hi all, could you please provide client examples for the following applications?:

Language Modeling
Sentiment Analysis
Object Detection
Speech Recognition
Language Translation

Thanks

We will likely have some additional examples of clients that use TRTIS but doing an exhaustive implementation of all these is beyond the scope of the TRTIS project. Please share any you have and we can help curate links to them.


Incorrect IPv4 detection

The main physical interface of my nodes gets a /31 ip v4 cidr from the cloud's dhcp. This seems to be confusing calico address detection. I have a cluster with 4 nodes, and calico consistently detects the correct address minus one. This in turn breaks VXLAN setup, and as a result I have no network between nodes.
Let's look at a node:

ip addr show eth0 gives net <IP_ADDRESS>/31 metric 1024 scope global dynamic eth0
ip route show table local gives local <IP_ADDRESS> dev eth0 proto kernel scope host src <IP_ADDRESS>
DNS A query for the node name gives <IP_ADDRESS>
kubernetes correctly infers the IP: Node.status.addresses is

  - address: <IP_ADDRESS>
    type: InternalIP
  - address: sf02
    type: Hostname

the default detection configuration (findFirst) doesn't work for me because it picks the wrong interface. Using canReach or kubernetes picks eth0 and the calico node is:

spec:
  addresses:
  - address: <IP_ADDRESS>/31
    type: CalicoNodeIP
  - address: <IP_ADDRESS>
    type: InternalIP
  bgp:
    ipv4Address: <IP_ADDRESS>/31
  ipv4VXLANTunnelAddr: <IP_ADDRESS>

Moving to the calico-node pod we have (lines omitted):

startup/autodetection_methods.go 225: Including CIDR information from host interface. CIDR="<IP_ADDRESS>/31"
felix/int_dataplane.go 1585: Received *proto.HostMetadataUpdate update from calculation graph msg=hostname:"sf02" ipv4_addr:"<IP_ADDRESS>"
felix/vxlan_mgr.go 534: Failed to configure VXLAN tunnel device, retrying... error=Unable to find parent interface with address <IP_ADDRESS> ipVersion=0x4

For reference here's the whole log : calico-node.log

So my understanding is that the CIDR is correctly autodetected, I don't find anything in the logs that would indicate if the correct IP address is detected at this point. Then the "calculation graph" finds that the IP address is actually <IP_ADDRESS> which is incorrect, and the subsequent errors and my lack of connectivity come from this bad address.
Expected Behavior

Reading the documentation about nodeAddressAutodetection.kubernetes: NodeInternalIP:

Calico will select the first internal IP address listed in the Kubernetes node’s Status.Addresses field

So if kubernetes has a single InternalIP for a node, I expect calico to pick that.
Current Behavior

Calico is correctly detecting the whole IP block allocated to the underlying interface, although that's not the same as "select the first internal IP address listed in the Kubernetes node". And then it somehow picks the wrong address in that block. Because of this VXLAN cannot initialize, and inter-node communication is broken.
Possible Solution

I just started looking at calico, so I don't know the internals enough. I found a workaround though: disable IP autodetection with nodeAddressAutodetectionV4: {} and patch every calico node manually to set its IP. I got the network up this way and will continue evaluating calico.
But for larger clusters and dynamic IP addresses this would require to automate the node patching and in effect reimplement the kubernetes IP detection manually with a script that does the patching, and I guess defining the right trigger for the automatic patching is not trivial...
Steps to Reproduce (for bugs)

I don't know what's specifically is triggering the bug in my environment. I'm guessing the fact the I get non /32 IPs, but maybe that alone is not enough.

Pick at least 2 nodes with /31 IP addresses assigned to the physical interface which connects them
Install kubernetes (kubeadm)
Install calico (through operator) and setup kubernetes IPv4 detection
If network works, wait and/or reboot

Context

I'm trying to switch from weave to calico hoping it would be more stable and maintained. Followed the docs to install. Discussed my issue on calico's slack and was advised to report here.
Your Environment

Calico version: 3.23.1
Orchestrator version (e.g. kubernetes, mesos, rkt): kubernetes 1.23.6 (kubeadm), containerd 1.6.4, CNI 1.1.1
Operating System and version: linux 5.17.7 (ArchLinux)

xref: https://github.com/projectcalico/calico/issues/6142

Thanks @caseydavenport for mentioning that. Also possible duplicate of #5851.
Although I don't think the issue is specific to the kubernetes detection mode (as other issues and mine imply). I also tested canReach and it has the same behavior, so I believe the root cause of the issue is bad handling of network masks and not the kubernetes/internalIP logic.


Project Branching Documentation

This is adapted from previous documentation written by @robline. Feedback is welcome. If you find a typo/grammatical error then please just fix it rather than commenting.

Updated based on feedback and included a new section on production releases. Please take another look.

:gem:

@rebecca-caktus @dpoirier @kmtracey do you feel like your feedback has been addressed/incorporated?

Updated again.

:umbrella:


[Bug]: Unable to close loading dialog in CropRotateEditor.memory and ProImageEditor.memory

Package Version
^4.3.3
Flutter Version
3.22.2
Platforms
Android, iOS

How to reproduce?
I want the user to capture/select an image, navigate to a crop screen (forcing it to crop 16:9), navigate to an edit screen to let the user edit the image and show a preview screen.

Capture/select image -> CropScreen(force 16:9) -> EditScreen -> PreviewScreen

There is a problem with the loading dialog that comes with the package.
What I expect:

Capture/select image
Navigate to CropScreen(force 16:9)
Finished cropping and press check mark on top right
[Loading shows and dismiss]
Navigate to EditScreen with onImageEditingComplete
Finished editing and press checkmark on top right
[Loading shows and dismiss]
Navigate to PreviewScreen with onImageEditingComplete

What happened:

Capture/select image
Navigate to CropScreen(force 16:9)
Finished cropping and press check mark on top right
[Loading keeps showing]
Navigate to EditScreen with onImageEditingComplete
Need to dismiss loading dialog before can interact with EditScreen
Finished editing and press checkmark on top right
[Loading keeps showing]
Navigate to PreviewScreen with onImageEditingComplete
Need to dismiss loading dialog before can interact with PreviewScreen

I saw the readme file regarding async in onImageEditingComplete and the loading dialog, however my IDE forces me to use async because your return type is Future Function(Uint8List bytes)
Logs (optional)
No response
Example code (optional)
I use the go_router package, but I tried using Navigator.of(context).push() and it doesn't fix the problem

CropScreen buildBody()

CropRotateEditor.memory(
        _image,
        initConfigs: CropRotateEditorInitConfigs(
          theme: ThemeData.dark(),
          convertToUint8List: true,
          configs: const ProImageEditorConfigs(
            cropRotateEditorConfigs: CropRotateEditorConfigs(
              initAspectRatio: 16 / 9,
              canChangeAspectRatio: false,
              canRotate: false,
            ),
          ),
          onImageEditingComplete: (Uint8List image) async {
            await context.pushNamed(
              HostingChallengeCoverImageImageEditorScreen.path,
              extra: HostingChallengeCoverImageEditorScreenArgs(
                _title,
                _description,
                _deadline,
                _hasRewards,
                _message,
                image,
              ),
            );
          },
        ),
      )

EditScreen buildBody()
ProImageEditor.memory(
        widget._image,
        configs: const ProImageEditorConfigs(
          cropRotateEditorConfigs: CropRotateEditorConfigs(enabled: false),
        ),
        callbacks: ProImageEditorCallbacks(
          onImageEditingComplete: (Uint8List editedImage) async {
            final String coverImagePublicId;
            const String prefix = 'challenge-cover-image';
            try {
              coverImagePublicId = await _repository.postFile(
                editedImage.toFile(
                  prefix: prefix,
                  //pro_image_editor's default format
                  extension: 'jpg',
                ),
              );
            } on Exception catch (e) {
              if (!context.mounted) return;
              await showPostFileExceptionMixAlertDialog(
                context,
                filePrefix: prefix,
                exception: e,
              );
              return;
            }
            if (!context.mounted) return;
            await context.pushNamed(
              HostingChallengePreviewScreen.path,
              extra: HostingChallengePreviewScreenArgs(
                coverImagePublicId,
                widget._title,
                widget._description,
                widget._deadline,
                widget._hasRewards,
                widget._message,
              ),
            );
          },
        ),
      )

### Device Model (optional)

_No response_

Hi,
The problem is that when you open the editor as a new page, it's required that you call Navigator.pop inside the onImageEditingComplete function. The new page should be opened inside onCloseEditor so that the loading-dialog does not close it directly. I know it's sometimes a bit confusing why the loading-dialog closes after the onImageEditingComplete function has been called. The idea here is that when you upload the final image to your server, which will definitely take some time, the same loading-dialog will still be active for the generation and upload part.
Anyway, I had a small issue with the loading-dialog that it was close to early, but in my tests it didn't affect anything. However, that everything will work fine, I still recommend you to update to version 4.3.4.
Below is a demo code but without the package go_router. Please let me know it in the case it didn't work for you.
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'package:pro_image_editor/pro_image_editor.dart';

void main() async {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Pro-Image-Editor',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue.shade800),
        useMaterial3: true,
      ),
      home: const MyHomePage(),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key});

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  Uint8List? _image;

  _openCropRotateEditor() {
    Navigator.push(
      context,
      MaterialPageRoute(
        builder: (context) {
          return CropRotateEditor.network(
            'https://picsum.photos/id/230/2000',
            initConfigs: CropRotateEditorInitConfigs(
              theme: ThemeData.dark(),
              convertToUint8List: true,
              configs: const ProImageEditorConfigs(
                cropRotateEditorConfigs: CropRotateEditorConfigs(
                  initAspectRatio: 16 / 9,
                  canChangeAspectRatio: false,
                  canRotate: false,
                ),
              ),
              onImageEditingComplete: (Uint8List image) async {
                _image = image;
                Navigator.pop(context);
              },
              onCloseEditor: () {
                if (_image != null) _openMainEditor();
              },
            ),
          );
        },
      ),
    );
  }

  _openMainEditor() {
    Navigator.push(
      context,
      MaterialPageRoute(
        builder: (context) {
          return ProImageEditor.memory(
            _image!,
            configs: const ProImageEditorConfigs(
              cropRotateEditorConfigs: CropRotateEditorConfigs(enabled: false),
            ),
            callbacks: ProImageEditorCallbacks(
              onImageEditingComplete: (Uint8List image) async {
                _image = image;
                Navigator.pop(context);

                /// TODO: Upload your image...
              },
              onCloseEditor: () {
                if (_image != null) _openPreviewEditor();
              },
            ),
          );
        },
      ),
    );
  }

  _openPreviewEditor() {
    Navigator.push(
      context,
      MaterialPageRoute(
        builder: (context) {
          return Scaffold(
            appBar: AppBar(
              title: const Text('Preview'),
            ),
            body: Center(
              child: Image.memory(_image!),
            ),
          );
        },
      ),
    );
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: FilledButton(
          onPressed: _openCropRotateEditor,
          child: const Text('Test'),
        ),
      ),
    );
  }
}

Thanks a lot for your detailed explanation, I've spent lots of time trying out various scenarios and your example alone worked for the forward flow, however the back flow does not work.
I upgraded to ^4.3.5 and  edited my code to something similar to your's. It worked 1/10 times, which is very strange.
I suspect the issue is from here in the source code, where you actually hide the dialog if it is mounted, however I have already navigated to a new screen and the mount state has changed:

    WidgetsBinding.instance.addPostFrameCallback((_) async {
      LoadingDialog loading = LoadingDialog();
      await loading.show(
        context,
        theme: _theme,
        configs: configs,
        message: i18n.doneLoadingMsg,
      );

      if (callbacks.onThumbnailGenerated != null) {
        if (_imageInfos == null) await decodeImage();

        final List<dynamic> results = await Future.wait([
          captureEditorImage(),
          _controllers.screenshot.getOriginalImage(imageInfos: _imageInfos!),
        ]);

        await callbacks.onThumbnailGenerated!(results[0], results[1]);
      } else {
        Uint8List? bytes = await captureEditorImage();
        await onImageEditingComplete?.call(bytes);
      }

      **if (mounted) loading.hide(context);**

      onCloseEditor?.call();

      /// Allow users to continue editing if they didn't close the editor.
      setState(() => _processFinalImage = false);
    });

Or maybe the issue is due to async and await, where I noticed that you do not use "await" before Navigator.push() in the example that you have given me.
In my scenario, using or not using "await" Navigator.push() with GoRoute.push both does not work for me all the time.
As a workaround, I used SizedBox.shrink() as my ImageEditorCustomWidgets.loadingDialog, is there a way to totally disable the  LoadingDialog? (Setting ImageEditorCustomWidgets.loadingDialog = null uses the default dialog)
My workaround now requires the user to tap on the screen twice to interact with it, because he/she has to disable the invisible custom SizedBox.shrink().

Thanks a lot for your detailed explanation, I've spent lots of time trying out various scenarios and your example alone worked for the forward flow, however the back flow does not work.

To clarify, the issues is only when navigating back from the preview or main-editor page, correct? Navigating back is not straightforward because the editor is designed to be destroyed upon leaving the page. If you keep the editor active and do not call Navigator.pop inside onImageEditingComplete, you will have many background isolates or web workers running unnecessarily. Therefore, if the user wants to navigate back, I recommend having them restart the entire process or use import/export functionality to save the state history and transformConfigs to create a new editor instance.

I suspect the issue is from here in the source code, where you actually hide the dialog if it is mounted, however I have already navigated to a new screen and the mount state has changed:

The code will only run when generating the final image, but that should not be a problem. As you can see, I call onCloseEditor after checking if(mounted) loading.hide(context), so when you open the new editor inside onCloseEditor, if (mounted) should still evaluate to true.

Or maybe the issue is due to async and await, where I noticed that you do not use "await" before Navigator.push() in the example that you have given me.
In my scenario, using or not using "await" Navigator.push() with GoRoute.push both does not work for me all the time.

Yes, it should not be necessary to await call Navigator.push because no other code will be executed which needs to await that task.

As a workaround, I used SizedBox.shrink() as my ImageEditorCustomWidgets.loadingDialog, is there a way to totally disable the LoadingDialog?

No, that's not possible because it's necessary that the user can't interact with the editor until we're done creating the final image.

Could you create a single-file example similar to the one I provided above, using the code you are currently trying to implement? If the example requires additional packages, please include the versions you are using. I can then help guide you toward a working solution. Keep in mind to just post code, which is really necessary.

@hm21 I upgraded the package to ^5.0.2 and everything worked fine! Thanks a lot for maintaining this package!


php artisan nova:publish breaks nova-dependency-container

Launching the command php artisan nova:publish --force the new files app.js and vendor.js from nova are published and obviously these are not compatible with this package because epartment/nova-dependency-container stops working.

@fede91it I'm closing this issue, please open a new issue if still is relevant.


Add the license headers

Please add a description, which gives context on why this is needed and link to a relevant issue in the releases repo.


Ds webpack util

Closes #

Changes

Flags

Screenshots or Video

Related Issues

Issue #
Pull Request #

Author Checklist

[ ] Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
[ ] Vital features and changes captured in unit and/or integration tests
[ ] Commits messages follow AP format
[ ] Extend the documentation, if necessary
[ ] Merging to main from fork:branchname

coverage: 98.767%. remained the same
when pulling e03e9d270150a3bda139ae53b6391c5705db38c2 on ds-webpack-util
into 47f753fb5c07cdf72ef200af2dc64ff6a975fa73 on main.


GOSSIP-14 Periodically attempt to contact dead members

This bug is a bit of a special case. I'm still getting familiar with the code, but it appears to happen because of the PUSH nature of the detection algorithm, which is basically this: if node A thinks node B is  DOWN, the only way B can be marked UP is if B contacts A. However, with the code as it  is currently written, this never happens because B will only contact nodes it thinks are UP (B thinks A is DOWN).
I think the right way to fix this bug is to figure out how come the states are wrong on the first place, when the nodes first come up. Still digging in.
This PR also does a tiny bit of cleanup:

cancel the Future in GossipCore when a timeout happens.
modify the logging in RandomActiveGossipThread to give a clear indication of who (in anybody) is being contacted.

I'm guessing the broken state happens because it appears there is only one node getting contacted at a time. If that one node is not the UP node, it takes 10sec for a socket timeout, by which time none of the other nodes have posted state, so they're all marked DOWN.

Nice troubleshooting ! Will review and merge!


Invalid byte sequence error when building on Ubuntu 22.04

This repository's issues are reserved for feature requests, and bug reports, and questions.
I'm submitting a ...

[x] bug report
[ ] feature request
[ ] question

Expected Behavior
The website builds without issue
Actual Behavior
$ jekyll serve --trace
Configuration file: /home/ooblack/projects/arfc.github.io/_config.yml
            Source: /home/ooblack/projects/arfc.github.io
       Destination: /home/ooblack/projects/arfc.github.io/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
    Jekyll-scholar: Option `use_raw_bibtex_entry` is no longer supported
  Liquid Exception: invalid byte sequence in US-ASCII in /home/ooblack/projects/arfc.github.io/_layouts/publications.html
/home/ooblack/gems/gems/bibtex-ruby-6.0.0/lib/bibtex/lexer.rb:220:in `scan_until': invalid byte sequence in US-ASCII (ArgumentError)
	from /home/ooblack/gems/gems/bibtex-ruby-6.0.0/lib/bibtex/lexer.rb:220:in `parse_meta'
	from /home/ooblack/gems/gems/bibtex-ruby-6.0.0/lib/bibtex/lexer.rb:180:in `analyse'
	from bibtex.y:110:in `parse'
	from /home/ooblack/gems/gems/bibtex-ruby-6.0.0/lib/bibtex/bibliography.rb:67:in `parse'
	from /home/ooblack/gems/gems/jekyll-scholar-7.0.0/lib/jekyll/scholar/utilities.rb:193:in `bibliography'
	from /home/ooblack/gems/gems/jekyll-scholar-7.0.0/lib/jekyll/scholar/utilities.rb:219:in `entries'
	from /home/ooblack/gems/gems/jekyll-scholar-7.0.0/lib/jekyll/scholar/utilities.rb:838:in `cited_entries'
	from /home/ooblack/gems/gems/jekyll-scholar-7.0.0/lib/jekyll/scholar/tags/bibliography.rb:20:in `render'
	from /home/ooblack/gems/gems/liquid-4.0.3/lib/liquid/block_body.rb:103:in `render_node_to_output'
	from /home/ooblack/gems/gems/liquid-4.0.3/lib/liquid/block_body.rb:91:in `render'
	from /home/ooblack/gems/gems/liquid-4.0.3/lib/liquid/template.rb:208:in `block in render'
	from /home/ooblack/gems/gems/liquid-4.0.3/lib/liquid/template.rb:242:in `with_profiling'
	from /home/ooblack/gems/gems/liquid-4.0.3/lib/liquid/template.rb:207:in `render'
	from /home/ooblack/gems/gems/liquid-4.0.3/lib/liquid/template.rb:220:in `render!'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/renderer.rb:131:in `render_liquid'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/renderer.rb:194:in `render_layout'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/renderer.rb:163:in `place_in_layouts'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/renderer.rb:93:in `render_document'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/renderer.rb:63:in `run'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/site.rb:547:in `render_regenerated'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/site.rb:539:in `block in render_pages'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/site.rb:538:in `each'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/site.rb:538:in `render_pages'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/site.rb:211:in `render'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/site.rb:80:in `process'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/command.rb:28:in `process_site'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/commands/build.rb:65:in `build'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/commands/build.rb:36:in `process'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/command.rb:91:in `block in process_with_graceful_fail'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/command.rb:91:in `each'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/command.rb:91:in `process_with_graceful_fail'
	from /home/ooblack/gems/gems/jekyll-4.2.2/lib/jekyll/commands/serve.rb:86:in `block (2 levels) in init_with_program'
	from /home/ooblack/gems/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `block in execute'
	from /home/ooblack/gems/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `each'
	from /home/ooblack/gems/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `execute'
	from /home/ooblack/gems/gems/mercenary-0.4.0/lib/mercenary/program.rb:44:in `go'
	from /home/ooblack/gems/gems/mercenary-0.4.0/lib/mercenary.rb:21:in `program'
	from /home/ooblack/gems/gems/jekyll-4.2.2/exe/jekyll:15:in `<top (required)>'
	from /home/ooblack/gems/bin/jekyll:25:in `load'
	from /home/ooblack/gems/bin/jekyll:25:in `<main>'

I initially thought that Jekyll was having trouble rendering the raw bibtex (use_raw_bibtex_entry is no longer supported), however after downgrading both jekyll and jekyll-scholar to versions that would support this option, I ran into the same issue.
Steps to Reproduce the Problem

Checkout yardasol-patch-1
Run jekyll serve

Specifications

Version:

jekyll 4.2.2
ruby 3.0.2p107
gem 3.3.5
GNU Make 4.3
gcc 11.2.0

Platform: Ubuntu 22.04

How can this issue be closed?
This issue can be closed when a PR exists that makes changes that allow the website to build.

I'll try it when I get a chance!

@munkm bump

This is relevant to #247

On my machine I am able to build and preview the site. Here are the commands I used:
$rake generate
Configuration file: /Users/madicken/repos/arfc/arfc.github.io/_config.yml
    Jekyll-scholar: Option `use_raw_bibtex_entry` is no longer supported

$jekyll serve
Configuration file: /Users/madicken/repos/arfc/arfc.github.io/_config.yml
            Source: /Users/madicken/repos/arfc/arfc.github.io
       Destination: /Users/madicken/repos/arfc/arfc.github.io/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
    Jekyll-scholar: Option `use_raw_bibtex_entry` is no longer supported
                    done in 3.703 seconds.
 Auto-regeneration: enabled for '/Users/madicken/repos/arfc/arfc.github.io'
    Server address: http://<IP_ADDRESS>:4000/
  Server running... press ctrl-c to stop.

I am using rvm to manage ruby versions. I haven't updated ruby in a while, so I'm using ruby-2.7.2, rake version 13.0.1, and jekyll 4.2.0


[WIP] stdenv: inherit src.meta to allow moving most of meta into src.meta

Motivation for this change
You can now move meta.license or any other such thing to the src attribute of your derivation and by doing so ban the accidental downloading of the sources of softwares you blacklisted with check-meta.
In my opinion, moving most of meta into src makes sense. For instance, homepage is an attribute of a source, not an attribute of a derivation.
See commit messages for more info.
Things done

[X] Nothing really changes (except meta.evaluates -> meta.available).
[X] Fits CONTRIBUTING.md.

I guess src.meta.homepage better corresponds to meta.repositories.git than meta.homepage
https://github.com/NixOS/nixpkgs/search?utf8=✓&q=repositories.git&type=

Not really, as its very git specific, and I have a more general feature
in mind (see the commit message of
97494769c61966426ab75890662ab75d213b11f5) and hope nixpkgs will
eventually move all meta.licenses to src.
The build failure I will now investigate.

Strictly speaking its still WIP as many other packages that do throw in src will be broken by check-meta. But I don't want to touch them before we decide what to do with #34755 as it proposes a better syntax than 37dedf64536f366df730584b5fb285b0469d2bea.

Btw

[X] Nothing really changes.
is still correct. The manual changes a bit because I added some documentation. Other changes seen by ofborg are not actual changes. The contents of .drvs doesn't change, their hashes change, but since they are fixed-output it wouldn't rebuild anything.

I like most of the changes, but I think the allowBinary should be a separate PR, because there are a lot of things to discuss about it. Technically, bootstrap tools for stdenv (a transitive dependency of everything…) are a binary blob. Then there are Rust, GHC, SBCL, FPC… that we bootstrap from upstream binaries.

Agreed. Will do after a couple of other TODO items.

I probably like the meta.available name better, but renaming meta.evaluates is an externally visible change.

I just introduced it in #33057, so

I don't think anyone outside nixpkgs uses it yet.
There were no stable releases with this feature so I feel like its fine to change it without any grace period. Its master, after all.

Actually, that patch is from another related branch where it makes even more sense, but I though it wouldn't hurt if it cuts in line here instead (as that other branch will almost surely generate copious amounts bikeshedding).

I agree no-grace-period is OK, I would just list it in the description below ‘‘Nothing really changes’’, as it is a change.

Added a WIP tag because you explicitly say that there are TODO items you plan to implement here anyway (you wouldn't be able to drop a label, but you can undo my change to the title).

Ok. allowBinary stashed away. The only TODO left here is https://github.com/NixOS/nixpkgs/pull/35075#issuecomment-366470877. I feel like stealing a patch from #34755 and fixing all the things this breaks using it here. Lets discuss the thing there.

I think getAttrByName you proposed there is called builtins.getAttr, but maybe you want better error reporting.

Maybe, I'm yet unsure myself. The more I think about it the less I like the "lazy fetchurl" patch. Maybe I'll completely change the approach there. Will see in the next couple of days.
Would be nice if somebody comfortable with networking looked at #27688. Wink, wink :)
I would love it to be merged before 18.03.

@oxij re: platform-specific downloads: so, what is your current opinion? builtins.getAttr and platform-indexed attrset of source information?

@@ -36,7 +36,7 @@ let
package = args.package or (lib.attrByPath path (throw "Invalid package attribute path `${toString path}'") pkgs);
in ""
+ "pkgs.${name} (${package.meta.name})"

   + lib.optionalString (!package.meta.evaluates) " <emphasis>[UNAVAILABLE]</emphasis>"

   + lib.optionalString (!package.meta.available) " <emphasis>[UNAVAILABLE]</emphasis>"

could the broken attribute be re-used there?
I think broken has a more narrow meaning (this stopped working where it worked before), and the check also includes platforms and license?

Right. broken is set by expression authors, evaluates/available is a cheap (because tryEval on derivation .outPath is not cheap, as it computes all the hashes) approximation of the result of trying to actually evaluate the expression (hence the old name).
With current implementation of check-meta broken implies !available, unless custom check-meta error handler decides its fine for a select packages to be broken.

Michael Raskin<EMAIL_ADDRESS>writes:

@oxij re: platform-specific downloads: so, what is your current opinion? builtins.getAttr and platform-indexed attrset of source information?

Generally, yes. But now I'm syntactically more inclined to something like
src = fetchWith fetchurl {
  license = licenses.whatever;
  ... other meta goes here ...
} {
  url = ...;
  hash = ...;
}

# and

src = fetchWithSystem fetchurl {
  ... meta goes here ...
} {
  x86_64-linux = {
    url = ...
    hash = ...
  };
  i686-linux = x86_64-linux;
  ... etc ...
}

# or, more modular,

src = fetchWith fetchurl {
  ... meta goes here ...
} (selectSystem rec {
  x86_64-linux = {
    url = ...
    hash = ...
  };
  i686-linux = x86_64-linux;
  ... etc ...
})

# in the last example `selectSystem` then has to generate another `meta` with `platforms`

I also want to either merge it or make it play nice with source selection from SLNOS (because its awesome), so I have not finalized the design yet.
Btw, I also want to fix fetchgit to produce the same hash as fetchFromGitHub most of the time by using git-archive (not by default at first, obviously).

Let's postpone the discussion around pkgs/development/mobile/androidenv/platform-tools.nix and fetchurl. The rest of the code makes sense and could be merged already. I would also like to have a multi-fetcher but it has to be fleshed out a bit more.

You see, I just wanted the first two commits. But manual build then fails because src.meta fails for the unlazy fetchurl which breaks meta of platformTools which is used to generate documentation. So I started fixing that and got where I'm now. Of course, I can just hack around it, but I prefer to waste some time now experimenting, that waste some time later hacking around the hacks.

Rebased to remove already merged commits. Still WIP and is going to be WIP for a while.

let
  meta = { ... };
in
  fetchSource {
    x86_64-linux = fetchurl { url = ...; sha256 = ...; inherit meta; };
    ...
  } stdenv.system;

Firstly, that fetchSource is just getAttr.
Secondly, I don't like the idea of separating metas and repeating fetchurls. Too much copy-paste.
Also, I would like to have meta.platforms to be autogenerated and make the whole thing sufficiently lazy so that accessing package.src.outPath would naturally fail with "unsupported on this platform" but looking up the fields would still work. Your example can't trivially do that but my example from several messages above copy-pasted below can
src = fetchWith fetchurl {
    ... meta goes here ...
  } (selectSystem rec {
    x86_64-linux = {
      url = ...
      hash = ...
    };
    i686-linux = x86_64-linux;
    ... etc ...
  })


Prepared statements cache computation improvements

Thanks for sending a pull request! Here are some tips if you're new here:

Ensure you have added or run the appropriate tests for your PR.
Be sure to keep the PR description updated to reflect all changes.
Write your PR title to summarize what this PR proposes.
If possible, provide a concise example to reproduce the issue for a faster review.
Read our contributor guidelines
If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:
<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

CI j8 and j11

Ci j8 and j11

CI j8 j11
LGTM where the only failure passes locally, flaky test imo.

Here are 500 repeats for the detected flaky test fix


revert(alert): use negative,positive variants instead of critical,success

Originally the naming change to critical and success was made to try and align things more correctly as a system but we decided to scope breaking changes down in Warp 1.0.
These changes require respective tokens to be renamed and published in @warp-ds/tokens so until that's done, this will be a draft PR.

 MOB: Apply tokens to Alert components


fix OOM

Change-Id: I4fce78be15179722fea1fa645495783c60b28573
Signed-off-by: yuandm<EMAIL_ADDRESS>What is the purpose of the change
fix OOM when deserializing data
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #6848 into master will decrease coverage by 0.03%.
The diff coverage is 66.66%.

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


Incompat with BOP Customization

I noticed that the menu allows me to select World Type: Biomes O Plenty, but not to use it's customization menu. Is this something which can be added?

This bug is already present. If i try to click on the customize button nothing happen.


deps: update test-app dependencies

Current coverage is 85.80% (diff: 100%)

Merging #461 into master will not change coverage

@@             master       #461   diff @@
==========================================
  Files           170        170
  Lines          1818       1818
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1560       1560
  Misses          258        258
  Partials          0          0

Powered by Codecov. Last update 54db513...8c941ef


Set TCCL to mock class

This helps make sure the mock is created in the correct ClassLoader

@stuartwdouglas are we doing anything specific here that breaks it or will everyone using Mockito be affected?

Mocking a class from a 3rd party lib with a package private constructor. It's possible users will run into it, but probably not super common.


Modify Makefile and artifacts/data/Makefile to allow for optional building of artifacts

After #66 is complete, modify the Makefiles to default to downloading artifacts rather than building them.

done


Use part of VAL in open source project not under LGPL license

Dear VAL developers,
I would like to reuse VAL's PDDL+ parser in a future open-source project aiming at modelling and solving RL/planning/scheduling problems. This project will not be under the LGPL license but MIT or BSD-like. I do not intend to modify your PDDL parser source code but rather to ship it in a separate sdk directory. Also, I would like to provide only the source of the parser instead of the full VAL repository because, for instance, I do not need the compiled binaries you provide in the repository.
Would you allow me to do that?
Thank you very much in advance!
Kind regards,
Florent

Hi Florent
As it happens, I am currently involved in a project to port all the VAL source to a new repository with a BSD license. I have permission for this from the original contributors and plan to consult with more recent contributors to confirm that they are happy to allow their contributions to be ported into the new repository. However, I have to also request permission from the (technical) IP owner (the University) and this is in progress - in fact I have a call to explore this tomorrow. Therefore, I hope to be able to provide you with a definitive response very shortly.
Cheers
Derek

From: fteicht<EMAIL_ADDRESS>Sent: 12 June 2019 11:14:30
To: KCL-Planning/VAL
Cc: Subscribed
Subject: [KCL-Planning/VAL] Use part of VAL in open source project not under LGPL license (#37)
Dear VAL developers,
I would like to reuse VAL's PDDL+ parser in a future open-source project aiming at modelling and solving RL/planning/scheduling problems. This project will not be under the LGPL license but MIT or BSD-like. I do not intend to modify your PDDL parser source code but rather to ship it in a separate sdk directory. Also, I would like to provide only the source of the parser instead of the full VAL repository because, for instance, I do not need the compiled binaries you provide in the repository.
Would you allow me to do that?
Thank you very much in advance!
Kind regards,
Florent
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKCL-Planning%2FVAL%2Fissues%2F37%3Femail_source%3Dnotifications%26email_token%3DAB2KOVEKTIFT6R4PJJX63ZDP2DEANA5CNFSM4HXHN42KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZAWQYQ&data=01|01|derek.long%40kcl.ac.uk|7d2a624381a648af73aa08d6ef1ec387|8370cf1416f34c16b83c724071654356|0&sdata=URCLYgIYSJtXlwyrXux9lS4eqQKOVrp0wVbrjHuPrt4%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB2KOVEKAI5VETQ6NPVYC6TP2DEANANCNFSM4HXHN42A&data=01|01|derek.long%40kcl.ac.uk|7d2a624381a648af73aa08d6ef1ec387|8370cf1416f34c16b83c724071654356|0&sdata=sELYAAQ1WZG5SQW0kMOKcd5N1H4gbdbH3ztV7smzCsE%3D&reserved=0.

That would be excellent!
Thank you for your quick answer and support. I hope your effort to port the library to the BSD license will succeed, it will significantly help the community build upon your library.
Cheers,
Florent

Hi Florent
Just to keep you updated - the discussions were helpful, but incomplete. I am also discussing things with Strathclyde, who actually technically own the IP for most of the work (although Durham is also involved and I need to contact them, too). I'll keep you updated as things move forward - I really hope to have a useful conclusion shortly.

Derek

From: fteicht<EMAIL_ADDRESS>Sent: 12 June 2019 11:22:30
To: KCL-Planning/VAL
Cc: Long, Derek; Comment
Subject: Re: [KCL-Planning/VAL] Use part of VAL in open source project not under LGPL license (#37)
That would be excellent!
Thank you for your quick answer and support. I hope your effort to port the library to the BSD license will succeed, it will significantly help the community build upon your library.
Cheers,
Florent
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKCL-Planning%2FVAL%2Fissues%2F37%3Femail_source%3Dnotifications%26email_token%3DAB2KOVDU225HHSNI7UQQSOLP2DE6NA5CNFSM4HXHN42KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXP6KWY%23issuecomment-501212507&data=01|01|derek.long%40kcl.ac.uk|c362d1bdda144074ba3908d6ef1fe0c7|8370cf1416f34c16b83c724071654356|0&sdata=26sf9kc9v45ztF3%2BmqFFmPIhq665rHaO7kASlOA3lHE%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB2KOVHL3JU7XMF2JVDBKJ3P2DE6NANCNFSM4HXHN42A&data=01|01|derek.long%40kcl.ac.uk|c362d1bdda144074ba3908d6ef1fe0c7|8370cf1416f34c16b83c724071654356|0&sdata=%2F%2BcteIZbhS4KTy0tY6OOWroCqgUblMocf9Hu4HUlhpY%3D&reserved=0.

FYI, the change of license was agreed by all the involved parties and the Pull Request is coming very soon.

FYI, we are taking a little bit longer to set the continuous integration right and to ensure the binaries work on Linux and MacOS without having to set the library path.


[machinst x64]: implement load*_zero for x64

Like #2480, this should not be merged until #2432 is resolved and x64 Wasm SIMD spec tests are turned back on. The simd_load_zero.wast test is now in-tree since #2481 but will have to be enabled in the build.rs file.

As mentioned on Zulip, this runs into issues. When I run RUST_LOG=cranelift_codegen=debug cargo run --features experimental_x64 -- wast --disable-cache --enable-simd scratch.wast on:
(module
  (memory 1)
  (data (i32.const 0) "\00\01\02\03\04\05\06\07\08\09\0A\0B\0C\0D\0E\0F\80\81\82\83\84\85\86\87\88\89")
  (data (i32.const 65520) "\0A\0B\0C\0D\0E\0F\80\81\82\83\84\85\86\87\88\89")
  (func (export "v128.load32_zero") (param $0 i32) (result v128)
    (v128.load32_zero (local.get $0))
  )
)
(assert_return (invoke "v128.load32_zero" (i32.const 0)) (v128.const i32x4 0x03020100 0x00000000 0x00000000 0x00000000))

The test fails with:
Error: failed to run script file 'scratch.wast'

Caused by:
    0: failed directive on scratch.wast:9:1
    1: expected V128(I32x4([50462976, 0, 0, 0])) (0x00000000000000000000000000010203), got V128(2595974132930443020774722140989752) (0x00007ffdccd1730000007ffdccd16938)

After lowering, the MOVSS is present (as it should be):
DEBUG cranelift_codegen::machinst::compile    > vcode from lowering:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (successor: Block 1)
  (instruction range: 0 .. 9)
  Inst 0:   movq    %rdi, %v0J
  Inst 1:   movq    %rsi, %v1J
  Inst 2:   movq    %rdx, %v2J
  Inst 3:   movl    %v2Jl, %v3Jl
  Inst 4:   movq    28(%v0J), %v4J
  Inst 5:   movl    0(%v4J,%v3J,1), %v6Jl
  Inst 6:   movss   %v6J, %v7V
  Inst 7:   movdqa  %v7V, %v8V
  Inst 8:   jmp     label1
Block 1:
  (original IR block: block1)
  (instruction range: 9 .. 12)
  Inst 9:   movdqa  %v8V, %v9V
  Inst 10:   movdqa  %v9V, %xmm0
  Inst 11:   ret
}}

But after regalloc it is gone!
DEBUG cranelift_codegen::machinst::compile    > vcode after regalloc: final version:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (successor: Block 1)
  (instruction range: 0 .. 6)
  Inst 0:   pushq   %rbp
  Inst 1:   movq    %rsp, %rbp
  Inst 2:   movl    %edx, %esi
  Inst 3:   movq    28(%rdi), %rdi
  Inst 4:   movl    0(%rdi,%rsi,1), %xmm0
  Inst 5:   jmp     label1
Block 1:
  (original IR block: block1)
  (instruction range: 6 .. 9)
  Inst 6:   movq    %rbp, %rsp
  Inst 7:   popq    %rbp
  Inst 8:   re

Weirdly, a CLIF filetest like the following will produce the expected code:
test compile
set enable_simd
target x86_64 has_ssse3 has_sse41
feature "experimental_x64"

function %load32_zero(i64) -> i32x4 {
block0(v0: i64):
    v1 = load.i32 v0
    v2 = scalar_to_vector.i32x4 v1
    ; check:  movss   0(%rdi), %xmm0
    return v2
}

When I run that with cargo run --features experimental_x64 -p cranelift-tools -- compile --target="x86_64" -dDp scratch.clif I see the following before regalloc:
 DEBUG cranelift_codegen::machinst::compile    > vcode from lowering:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (instruction range: 0 .. 5)
  Inst 0:   movq    %rdi, %v0J
  Inst 1:   movss   0(%v0J), %v2V
  Inst 2:   movdqa  %v2V, %v3V
  Inst 3:   movdqa  %v3V, %xmm0
  Inst 4:   ret
}}

And after, the correct MOVSS:
 DEBUG cranelift_codegen::machinst::compile    > vcode after regalloc: final version:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (instruction range: 0 .. 6)
  Inst 0:   pushq   %rbp
  Inst 1:   movq    %rsp, %rbp
  Inst 2:   movss   0(%rdi), %xmm0
  Inst 3:   movq    %rbp, %rsp
  Inst 4:   popq    %rbp
  Inst 5:   ret
}}

Weirdly, a CLIF filetest like the following will produce the expected code:
test compile
set enable_simd
target x86_64 has_ssse3 has_sse41
feature "experimental_x64"

function %load32_zero(i64) -> i32x4 {
block0(v0: i64):
    v1 = load.i32 v0
    v2 = scalar_to_vector.i32x4 v1
    ; check:  movss   0(%rdi), %xmm0
    return v2
}

When I run that with cargo run --features experimental_x64 -p cranelift-tools -- compile --target="x86_64" -dDp scratch.clif I see the following before regalloc:
 DEBUG cranelift_codegen::machinst::compile    > vcode from lowering:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (instruction range: 0 .. 5)
  Inst 0:   movq    %rdi, %v0J
  Inst 1:   movss   0(%v0J), %v2V
  Inst 2:   movdqa  %v2V, %v3V
  Inst 3:   movdqa  %v3V, %xmm0
  Inst 4:   ret
}}

And after, the correct MOVSS:
 DEBUG cranelift_codegen::machinst::compile    > vcode after regalloc: final version:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (instruction range: 0 .. 6)
  Inst 0:   pushq   %rbp
  Inst 1:   movq    %rsp, %rbp
  Inst 2:   movss   0(%rdi), %xmm0
  Inst 3:   movq    %rbp, %rsp
  Inst 4:   popq    %rbp
  Inst 5:   ret
}}

@cfallin, I am bringing this out of draft since:

it seems like we are still merging x64 SIMD code despite the tests being disabled (I checked locally and this passes the tests)
I think this side-steps most of the stuff we found in #2545, though we should still fix that separately.

@cfallin, I am bringing this out of draft since:

it seems like we are still merging x64 SIMD code despite the tests being disabled (I checked locally and this passes the tests)
I think this side-steps most of the stuff we found in #2545, though we should still fix that separately.

Will review soon; re: merging SIMD, yes, at least my position right now is that we should be able to keep making progress on SIMD despite the CI heisenbug and disabled tests; when we resolve that bug and turn the tests back on, we'll see any issues and be able to trace them back to one of N PRs merged recently. IMHO that's better than holding all SIMD work until we track down the issue, given that it's proven elusive so far.

Will review soon; re: merging SIMD, yes, at least my position right now is that we should be able to keep making progress on SIMD despite the CI heisenbug and disabled tests; when we resolve that bug and turn the tests back on, we'll see any issues and be able to trace them back to one of N PRs merged recently. IMHO that's better than holding all SIMD work until we track down the issue, given that it's proven elusive so far.

@abrown I think this broke the build on main as it went in after the multi-reg refactor but tests had run before it.

@abrown I think this broke the build on main as it went in after the multi-reg refactor but tests had run before it.


Use Req.Request.halt/1 and return redirect exception instead of raising on "too many redirects"

Currently, the included redirect step raises an exception with a message when the maximum number of redirects is reached.  This change modifies the existing raise behavior to instead use the halt and return exception behavior used by other steps in the pipeline.

Thank you!


Suggestions for the output Movementscript

https://github.com/KandyWrong/blender2camera2/blob/137c9e1d08195b010a6912d2d844cd66ffff73cd/b2c2_export.py#L261
you should set duration instead of holdTime. holdTime dictates how long the script should freeze on this frames final values, duration dictates the time over which the camera will transition coming from the previous frame, so using the former, if you exported the script at 20 FPS, it would still be very smooth ingame due to interpolation in between frames.
Furthermore, you could consider only outputting the FOV if it actually changed coming from the previous frame to minimize script size 👍

You're right, now that I look at it more closely I realize that definitely needs to be fixed. Thanks for pointing that out!
C'est la vie with software development, something always needs fixing 🙃

I changed holdTime to duration in the v1.1 release. See #3
As for the other bit about including changed values only when needed, as opposed to on every single frame, I'm gonna punt that to v1.2 which will happen sometime after my next major video release. 👍


Change CODEOWNERS for Azure Cognitive Search

We would like to have different code owners for the Azure Cognitive Search data plane and management plane. Currently there is only a single code owner (me), which causes a lot of confusion and extra work when triaging issues and PRs.
FYI @arv100kri @miwelsh @tjacobhi @abhi1509

/azp run automation - sdk

/azp run automation - sdk


warn, not fail, on non-auth in sbtools_GET

Public information should be accessible via sbtools_GET without authentication, but sbtools_GET currently calls check_session(session) on the second line, and check_session(session) calls stop() if the session isn't authenticated. I propose a second argument to check_session, on_fail, that accepts either stop or warning and then uses that function to sound the alarm. Then sbtools_GET could call check_session(session, warning) whereas other REST_helpers could call check_session(session) where the default is on_fail=stop.
This gets at the somewhat thorny, recurring issue of how to alert the user when they're not logged in but maybe want to be, e.g., when they're searching for something and they don't find it, and we don't know if that's because it doesn't exist or because they're not logged in. How can we best help the user in that case?
This is related to issue  #118 and discussion in PR #133

The coding is easy, but I'd like thoughts from others before I do anything because this is a big API thing - @lawinslow , @sckott , @jread-usgs ?

I think GET should be a little different, because sbtools should be useful for people who just want to find and download public data. They shouldn't need an account, so I would like to support that use case.
I think GET used to do something along the lines of verify the session was either NULL or valid, and then try the GET. So, users that aren't logged in are NULL, and this worked unless you hit a private item, in which case you didn't know if the issue was because you weren't logged in or the item didn't exist. Curious how others think this should work. Didn't really like the old way, but it made public data pass through cleanly.

Yeah, even a warning is a bit strong when the data are actually public and can be found, isn't it? I'm now wondering if we could just delete the check_session(session) line from sbtools_GET, because handle_errors already stops with "check authorization and/or content" if there's a problem.

I think it makes sense to delete. Just tested removing the check line now, which means public items work fine, and private gives e.g.,
item_get('55569325e4b0a92fa7e9cf36')
#> Error: Item not found for ID=55569325e4b0a92fa7e9cf36. Either the item does not exist or the item is #> secured and requires authentication to access.


feat: set default config for pylsp.

I set the default config for pylsp and solved the problem in https://github.com/ayamir/nvimdots/issues/767 by enable roff to do lint.
Main config:

Use python-lsp-ruff to provide lint function due to its high performance.
Use pylsp-rope to provide code refactor function in code action's way as mentioned in https://github.com/ayamir/nvimdots/discussions/708#discussioncomment-5890640.
Use python-lsp-black and pyls-isort to provide format function.
Remove black config in null-ls.
Users no need to install or update these plugins manually after pylsp installed or updated.

The result:

@fecet @CharlesChiuGit

I just started learning about Python's linter and formatter today, so I may not be able to provide any assistance beyond testing.
What could be the reasons for neodim not supporting it? Ruff support both format and lint. How about using ruff provided by ruff-lsp or null-ls? I've seen https://github.com/CharlesChiuGit/nvimdots.lua/blob/df6576052e3d72f8a76e59457c0101203c634d42/lua/core/settings.lua#L109
configure it that way, if I understand correctly.

I tend to use ruff as plugin of pylsp because the dependency is linear.

I have tried this PR and everything works fine! Except I notice two things:

python-lsp-ruff lint seems too strict, sources like "import but unused" or "line too long" would be considered as "Error".
ruff's code action "Ruff organize import" will randomly move character:

Of course all of them are upstream issues.

I added F401 and E501 to ignore.
Disable isort because ruff can do the same thing.

I think it's better not to include any ignore as default, if anyone found this was annoyed, they could add that in ther pyproject.toml or set  diagnostics_virtual_text as false (I did this). As there is hope for this issue to be resolved quickly per https://github.com/python-lsp/python-lsp-ruff/issues/36

OK，we can wait for this.

Agree with @fecet , we can just comment out the ignore table.


Propagates preprocessor SWIFT_PACKAGE

I have a target that when it depends on an SPM package, the preprocessor definition SWIFT_PACKAGE becomes true.
I think that the expected behavior should have a value of false.

True, it should only be set for the target itself, instead of propagated. Basically local_define instead of define.

@leohidalgo Can you check if #1094 fixes your issue?

@leohidalgo Can you check if #1094 fixes your issue?

It works, thanks.


How to unit test a view?

Is it possible to render a view to string (html) inside a unit test and then assert whether the html contains the expected tags.
Something like
		[Fact]
		public void GivenControllerShouldReturnIndexView(){
			HomeController controller = new HomeController();
			ViewResult result = controller.Index() as ViewResult;
		    string html = result.RenderAsString();
			Assert.True(html.Contains("
My h1 text
"));
		}

@nojaf there's no built-in way of doing exactly that because it would generally work in only the simplest cases, in which case you wouldn't need a test to begin with :smile:
However, with ASP.NET 5 and MVC 6 it's quite easy to use an in-memory server to make requests to an app in the form of a functional test or integration test.
You can check out MVC's functional tests for many examples of this, for example, https://github.com/aspnet/Mvc/blob/eef6c3883a7e27b8387b0925f0b6a88df0a484c5/test/Microsoft.AspNet.Mvc.FunctionalTests/CustomRouteTest.cs
Part of the key to these tests is the MVC test fixture: https://github.com/aspnet/Mvc/blob/f25aab8df7ef935a6d4c67a0ba112de6621ad29d/test/Microsoft.AspNet.Mvc.FunctionalTests/MvcTestFixture.cs

Thanks, this looks very promising for end 2 end scenarios.


Revert "Forget auth token when going offline so we can reconnect (#26630)

Description:
#26630 broke previously working Amcrest cameras.
Related issue (if applicable): fixes #28539
Pull request with documentation for home-assistant.io (if applicable): N/A
Example entry for configuration.yaml (if applicable):
N/A
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.

We should tag this for 0.104


coding challenge processing port

#267

@GypsyDangerous Thank you for this port.
As always I requested @shiffman for a review to guarantee the quality.
Please rename the files according to this general structure. E.g processing/Fourier_Transform.pde-> Processing/CC_130_Fourier_Transform_3/CC_130_Fourier_Transform_3.pde
If you need help, let me know.
─ CodingChallenges
    └── CC_XXX_ThisIsTheTitle
        |── P5
        |   └── P5 Stuff
        └── Processing
            └── CC_XXX_ThisIsTheTitle
                |── CC_XXX_ThisIsTheTitle.pde
                └── ... (more Processing files)

-N

@gruselhaus the only way i know how to change names is to create a new pull request, is that okay or do you have a way to do without creating a new pull request.

@gruselhaus I need to add a new folder and I don't know how to do that within this pull request.


Clarify code

Where does _defaultFormOptions come from ?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9a5cfa38-0e6c-4346-dafc-84ea5c513fcf
Version Independent ID: c6787f0f-3e9a-6efb-0e6e-5ccb957d3f4a
Content: File uploads in ASP.NET Core
Content Source: aspnetcore/mvc/models/file-uploads.md
Product: asp.net-core
GitHub Login: @ardalis
Microsoft Alias: riande

It's in the StreamingController ...
https://github.com/aspnet/Docs/blob/74a44669d5e7039e2d4d2cb3f8b0c4ed742d1124/aspnetcore/mvc/models/file-uploads/sample/FileUploadSample/Controllers/StreamingController.cs#L25
Note that the topic+sample are due for an overhaul on #5331, and we've had some reports that the sample is broken.
@dementic, I'll close now, but we can re-open this issue if you want to discuss it further.


Conjure hijacks my gd mapping

I get this error message when I press <leader>gd (for Goto Definition) in a Python buffer in normal mode, even though I haven't added Python to the ft list in the Conjure config:
E5108: Error executing lua: Vim:Error executing Lua callback: Conjure client 'conjure.client.python.stdio' doesn't support function: def-str
stack traceback:
	[builtin#19]: at 0x7f5c982dba40
	[C]: at 0x55df00247d73
stack traceback:
	[C]: at 0x55df00247d73

Even disabling conjure.mapping or adding vim.g["conjure#filetype#python"] = false as suggested here doesn't help.
Here is my conjure.lua file:
vim.g["conjure#filetype#python"] = false
return {
    "Olical/conjure",
    ft = {
        "clojure",
        "fennel",
        "hy",
        "racket"
    },
    dependencies = {
        { "Olical/nfnl",           ft = "fennel" },
        { "Olical/aniseed" },
        { "PaterJason/cmp-conjure" },
    },
    config = function()
        require("conjure.main").main()
        -- require("conjure.mapping")["on-filetype"]()
    end,
    init = function()
        vim.g["conjure#debug"] = true
    end,
}

In the on_attach function in LSP config I've mapped that combination like so:
buf_set_keymap(bufnr, 'n', '<leader>gd', '<Cmd>lua vim.lsp.buf.definition()<CR>', opts)

I just found out here that I can disable Conjure's mappings altogether with this:
vim.g["conjure#mapping#enable_ft_mappings"] = false

That would mean I'd have to set all mappings myself, just because I want to disable one specific mapping for one specific file type. Or are there other options that I've overlooked?

You can also disable each mapping, the help text gives the exact variable
for go to Def, I think you also just need to set it to false?
On Sat, 2 Nov 2024, 23:01 Mick Krippendorf, @.***>
wrote:

I get this error message when I press gd (for Goto Definition)
in a Python buffer in normal mode, even though I haven't added Python to
the ft list in the Conjure config:
E5108: Error executing lua: Vim:Error executing Lua callback: Conjure client 'conjure.client.python.stdio' doesn't support function: def-str
stack traceback:
[builtin#19]: at 0x7f5c982dba40
[C]: at 0x55df00247d73
stack traceback:
[C]: at 0x55df00247d73
Even disabling conjure.mapping or adding vim.g["conjure#filetype#python"]
= false as suggested here
https://github.com/Olical/conjure/issues/472#issuecomment-1484073000
doesn't help.
Here is my conjure.lua file:
vim.g["conjure#filetype#python"] = false
return {
"Olical/conjure",
ft = {
"clojure",
"fennel",
"hy",
"racket"
},
dependencies = {
{ "Olical/nfnl",           ft = "fennel" },
{ "Olical/aniseed" },
{ "PaterJason/cmp-conjure" },
},
config = function()
require("conjure.main").main()
-- require("conjure.mapping")"on-filetype"
end,
init = function()
vim.g["conjure#debug"] = true
end,
}
In the on_attach function in LSP config I've mapped that combination like
so:
buf_set_keymap(bufnr, 'n', 'gd', 'lua vim.lsp.buf.definition()', opts)
I just found out here
https://github.com/Olical/conjure/issues/533#issue-1952543152 that I
can disable Conjure's mappings altogether with this:
vim.g["conjure#mapping#enable_ft_mappings"] = false
That would mean I'd have to set all mappings myself, just because I want
to disable one specific mapping for one specific file type. Or are there
other options that I've overlooked?
—
Reply to this email directly, view it on GitHub
https://github.com/Olical/conjure/issues/614, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACM6XN3B35ZHFCBQCFMLR3Z6VKV3AVCNFSM6AAAAABRCEFJJSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTAOBVGAZTMNY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Here's the config for the def word mapping
https://github.com/Olical/conjure/blob/6d2bc7f7b24c2c43d54f263bee7b9b08aef5d1a1/doc/conjure.txt#L555-L558
And here's the part that mentions how mappings can be un-prefixed or disabled
https://github.com/Olical/conjure/blob/6d2bc7f7b24c2c43d54f263bee7b9b08aef5d1a1/doc/conjure.txt#L217-L231
So setting this should do the trick!
" Disable the mapping entirely. Notice the `b:` prefix, this can be used in a Python ft autocmd to disable it ONLY in Python. Use g: if you want to disable it everywhere.
let b:conjure#mapping#def_word = v:false

Alternatively, you could remap it to something like "gD" so <leader>gd would be LSP and <leader>gD would be Conjure. I hope some of this helps!


Update supported versions of Fedora

17.12 won't support F24 or F25, but will support F27. 🎉
This work will need to be done in vnext-engine.

Duplicate of #5554


Support for the Finalized W5 (V5R2) Contract

(WIP - Do not merge yet)
Hello tonutils community and @xssnick!
We have refactored V5R1 to V5Beta. The Ton Foundation recommends calling it beta to prevent the premature spread of the Beta contract. Additionally, we have prepared support for the V5 Final contract (latest revision).
We can now wait for finalized contracts and update to the new naming and contract once it’s ready to go.
I’m submitting this pull request here so the community can test their software before the big day.
Have fun, and feel free to comment or make adjustments.

The V5 repo was just updated with the finalized contract.
https://github.com/tonkeeper/w5
Happy testing, everyone! Now this can be merged to the dev branch and adjusted further to be ready for the official wallet V5 release.

Eventually, we can implement similar message.ActionType to the struct for full V5 implementation. Currently, it only supports send_msg [0x0ec3c86d].
Similarly, the v5_final.go (packV5FinalActions) can be updated in the near future, but that requires a more in-depth rewrite of the codebase.
                case "add_ext":
			msg = cell.BeginCell().MustStoreUInt(0x02, 32). // action_add_ext prefix
				MustStoreRef(outMsg)                        // message reference
		case "delete_ext":
			msg = cell.BeginCell().MustStoreUInt(0x03, 32). // action_delete_ext prefix
				MustStoreRef(outMsg)                        // message reference
		case "set_signature_auth_allowed":
			msg = cell.BeginCell().MustStoreUInt(0x04, 32). // action_set_signature_auth_allowed prefix
				MustStoreUInt(uint64(message.Mode), 1)       // allowed

Hi, thank you! But let’s leave the names for backward compatibility and flexibility, Beta = V5R1, Final = V5R2, there is no guarantee that in future it will be a new revision :)
But we can add a comments for constants where mention what is final and what is beta, so it will be easier to understand.

Hi, thank you! But let’s leave the names for backward compatibility and flexibility, Beta = V5R1, Final = V5R2, there is no guarantee that in future it will be a new revision :)
But we can add a comments for constants where mention what is final and what is beta, so it will be easier to understand.

Made the requested changes.
The only thing left is to wait for Tonkeeper and other wallets to integrate it. Hopefully, we will generate the same wallets as the other wallets. In theory, this should be due to the network ID and subwallet IDs matching.
https://github.com/Totemancer/tonutils-go/blob/v5final/ton/wallet/address.go#L117
Let us know if you need any other updates.

Seems will be called V5R1 and previous one is V5Beta
https://github.com/tonkeeper/tonkeeper-ton/commit/c4ca40117450baaa0b013ec5a3b64f6dea2a67d1

Using the official naming and reviewing the tonkeeper-ton repo, I assembled another test branch for review.
It seems they are building addresses differently. Both methods result in a working script deployment. Maybe we can stick to this one as expected by Tonkeeper and other wallets.
I think it’s better to keep V5R1 and rename it to V5Beta as a recommendation. We just need to communicate that anyone who built a script on the V5 Beta contract will need to adjust that one line of code in their codebase. It will create more confusion in the community if we choose to go with V5R2 now.
https://github.com/Totemancer/tonutils-go/commit/a1fa67f840671d52bb41e747b23a5b413cce4c87#diff-690fe05c81bdf07d34a3afd3b777e8f0c10c3b6bc2ec9487b11f989898770a51R46
go get -u github.com/Totemancer/tonutils-go@e041724db2d3cb52d2c82340a9268afdb3d8a539

It will be easier to decide and adjust the code after reviewing tongo new commits.
Official V5R1 Implementation: https://github.com/tonkeeper/tongo/commit/1a48da39e1d596d3c5738e67fa3e4023abec73dc

Actually, there’s no need to overcomplicate things. We can hardcode the new wallet IDs according to this scheme:
https://github.com/tonkeeper/tonkeeper-ton/commit/d9aec6adfdb853eb37e0bba7453d83ae52e2a170#diff-c8ee60dec2f4e3ee55ad5e40f56fd9a104f21df78086a114d33d62e4fa0ffee6R149

Finished the integration according to the Tonkeeper integration.
Kept the name as V5R1 as that will be the name of this contract. We do not want to confuse future users with V5R2, as it might be a different revision down the line.
To test from the master branch:
go get -u github.com/Totemancer/tonutils-go@f14e3612e7e5748f3afd28daa7d37a44dbbf494d
We can wait a few days until it appears in wallets to compare addresses, then merge. But it should be good to go now.

Compared results with the tonkeeper-ton TypeScript library.
let wallet = WalletContractV5R1.create({ publicKey: keyPair.publicKey });

Good news! The wallet address matches! The integration is good. We can wait a couple of days to make sure Wallet V5 is finalized. There are a couple of open pull requests https://github.com/ton-blockchain/wallet-contract-v5/pulls about proposed changes (minor). These will be finalized in a few days max.
Let me know your decision on the wallet naming discussed above.

Now, explorers on this contract are reporting v5r1. Arriving early next week, we can have this ready for release day.
Official naming as follows: https://github.com/tonkeeper/tonkeeper-web/commit/2b26520c7aaae14cb09b3627f0ca2285b3841dbd#diff-a566641f3f297280b5460b335bf1cb1aabfdb583b75957c3c9132e1d372289beR15

Thank you, merged, I did small naming refactoring, because if we make V5R1 with new code, users who used V5R1 previously could get a problems after upgrade (wallet address will be changed silently), so I renamed both of them, to V5R1Beta and V5R1Final

Thank you, merged, I did small naming refactoring, because if we make V5R1 with new code, users who used V5R1 previously could get a problems after upgrade (wallet address will be changed silently), so I renamed both of them, to V5R1Beta and V5R1Final

Yes, it makes sense. Agreed.
Not a problem - people can change that one line of code in their libraries to continue using Beta or switch to Final.
Using the merged V5R1 codes for 2 weeks now and it has been rock solid so far. Thank you for merging.
Hopefully, we can contribute to the library in the future too!
Thank you for your work.


How to make completion block after all pictures have been loaded

I need to show ActivityIndicator while the images is loading and ActivityIndicator disappears when the images have been loaded but I can't do this because there is no "global" completion after all images appeared, I know that I can use async: true but I want that user can see that the images appearing on the screen while spinner is animating. Because of async my activity stop animating immediately. So how can I make completion block after all my pictures have been appeared in the screen and I can stop activity animation?

Sorry, it's Friday. My brain decided to leave in vacation)


Trade Corner Update , Various Bug Fixes, and Systemd/Nginx Examples.

I've modified the trade corner program to do the following things:
Support different versions of pokemon crystal by supplying the game id as the first command line argument.
Load mysql connection information from the config.json file as the second command line argument.
I've also included the english tamago files suggested by PR #3 and added support for English Crystal in the exchange and news scripts as well as some Systemd service and Nginx examples.

I'm sorry, I missed a file in my last commit. I will fix it in a bit.