Simple ptrace probe that reports writes to stdout and stderr

I decided to go with the stdout and stderr writes as an example as they have an easy to interpret first argument and return value. It's probably not ideal to go much further with ptrace because of the difficulty of tracing a multithreaded program that forked before attaching the probe. This probe simply traces the main thread.
Oh, it also should be run with root permissions; it's difficult to safely allow ptrace to be used by a non-root user.

Unfortunately, I can't test this on my machine, but maybe @strohel could give it a try. :wink:

Will do!

[1] The second to last page of this awesome zine.

Oh that is pure love, how have you found this gem?

[1] The second to last page of this awesome zine.

Haha that's awesome! She has a lot on that blog, wow. Reminds me of a youtuber called Vihart that explained math concepts very creatively on a notebook.
And yeah, ptrace is very invasive so we should probably not use it on tonari proper.

@PabloMansanet @strohel IDK, I stumbled upon Julia's zines when researching ptrace and dtrace. The one I linked is quite old and raw. Since then she produced quite a collection of polished zines at https://wizardzines.com/. They all look cool but I hadn't yet bought any.
I love vihart too, especially the videos on hexaflexagons!


2.0.6: geo.strictFilter() - panic: attempting to access non-existant value "ST_Contains"

In 2.0.6 OSS geo.strictFilter()  result in a panic. It works fine in InfluxDB Cloud (Flux v0.113.2-0.20210428163201-b47eeb0678b8)
Steps to reproduce:
import "experimental/geo"
import "csv"

data="
#group,false,false,false,true,false,false,false
#datatype,string,long,dateTime:RFC3339,string,string,double,double
#default,_result,,,,,,
,result,table,_time,_measurement,id,lat,lon
,,0,2021-05-02T11:37:40Z,the_measurement,us7000dzhg,-30.133,-71.5399
"

csv.from(csv: data)
  |> filter(fn: (r) => r["_measurement"] == "the_measurement")
  |> geo.strictFilter(region: { lat: -30.000, lon: -71.0000, radius: 100.0 })

Expected behavior:
One record should be returned.
Actual behavior:

panic: attempting to access non-existant value "ST_Contains"

Environment info:
2.0.6 OSS
Flux: v0.113.0

As a workaround, it is possible to add this to a flux script:
import "planner"
option planner.disableLogicalRules = ["MergeFiltersRule"]

#21356 does this across all flux scripts until we can fix the underlying bug, and adds a test for this broken case.


No response from other requests while uploading video

[x] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?
My app sends multiple requests while uploading video.
It takes about 1 mins to upload video.
Problem is that app can't get any response of multiple requests until video upload finished.
(It get response soon without uploading video.)
What did you expect to happen?
It should receive response of other requests while uploading video.
What happened instead?
No response until video uploading finished.
Alamofire Environment
Alamofire version: 4.6
Xcode version: 9.2
Swift version: 4.0
Platform(s) running Alamofire: iPhone 5
macOS version running Xcode: High Sierra
Demo Project
No available at the moment, under progressing...

Thanks for the report! I can't think of anything Alamofire might be doing to prevent this offhand, I think it's possible that URLSession itself throttles your requests while a long running upload is in progress, both for efficiency and speed. However that's just speculation. So while I can't think of anything specific that might be causing this, ultimately a demo app is the only way for us to really investigate, so we'd really appreciate if you could create one.

I'm closing this pending further input.


Research [2 days]: Identify marketing material needs for internal GSA (CIC, ITC, CASE)

In order to provide the right marketing materials to our internal GSA partners (Cloud Information Center, ITC, CASE), we need to understand their needs and make a plan for what to provide to them and what we need to update before shipping the updated materials to them.
Acceptance criteria:

[ ] We have a brief description of what CIC needs
[ ] We have a brief description of what ITC needs
[ ] We have a brief description of what CASE needs

Implementation sketch:

Meet with CASE
Meet with ITC

slick sheets, decks, etc as needed...

cloud.gov strategic positioning
talking points
briefing memo

We're considering this card obsolete.


Way to analyse Microphone input along with Annyang

Hi there,
we can analyse microphone's input by web audio api while using browser default recognition.. Ref: https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode/getByteFrequencyData
well i tried to do the same with annyang but i failed.. any help or suggestions will be appreciated

According to my tests, using the microphone input for a second purpose along with annyang can produce a useful result only on desktop environments and not mobile. It is not just an issue of Android. I have tried it on a Nexus tablet and several phones (all Android). Although none of the devices gave a reliable performance, I remember that one Sony phone was better than the others. Don't know how and why.

i moved to python from js for my particular use, thanks for your input anyway


feature request: draggable mask shapes

No idea about the feasibility of this, but I would really appreciate if the shapes drawn with the MaskToolsWidget could be dragged around with the mouse. That way you could very conveniently experiment with different mask/ROI selections.
Alex

Hi.
What do you mean by dragged around with the mouse?
That's about moving the mask? dropping another external image? stretching the mask?

I mean moving an existing patch (or even the whole mask).
2017-01-04 9:11 GMT+01:00 Valentin Valls<EMAIL_ADDRESS>
Hi.
What do you mean by dragged around with the mouse?
That's about moving the mask? dropping another external image? stretching
the mask?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/silx-kit/silx/issues/479#issuecomment-270315742, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATLKXFvbVObEFs7IBzqIyeQqsnR04LyRks5rO1Q7gaJpZM4LT7_p
.

Closed PR #239 was an attempt to it but it would now need quite some rework...

PR #1758 is a first step to provide resizable/editable shapes support in silx, it is not linked to the mask tools though.


Correct misspellings and revise documentation

I corrected misspellings in method names and documentation. These are breaking changes, but I do think it is important to ensure grammatical correctness, so I hope you will accept this PR. I also reworded some documentation.

Current coverage is 90.29%

Merging #2 into master will not affect coverage as of 65038ec

@@            master      #2   diff @@
======================================
  Files            1       1
  Stmts          103     103
  Branches         0       0
  Methods                  0
======================================
  Hit             93      93
  Partial          0       0
  Missed          10      10

Review entire Coverage Diff as of 65038ec

Powered by Codecov. Updated on successful CI builds.

👍 Thanks!


Cant read SOC on VW

Describe the bug
SOC of Passat GTE is not shown in evcc
Steps to reproduce

added config, evcc is working fine with hyundai
tried both templates for vw. With "id" and "vw"
see error
...

Configuration details
- type: template
  template: vw
  name: ev4
  title: GTE
  user: xxx # Benutzerkonto (bspw. E-Mail Adresse, User Id, etc.)
  password: xxx # Passwort des Benutzerkontos (bei führenden Nullen bitte in einfache Hochkommata setzen
  vin: xxxxx # Erforderlich, wenn mehrere Fahrzeuge des Herstellers vorhanden sind (optional)
  capacity: 13 # Akkukapazität in kWh (optional)
  timeout: 60s # optional

and also tried with template "id"

Log details
ERROR 2024/09/14 09:15:27 vehicle soc: unknown engine type: electric, got [, ]

What type of operating system are you running?
Docker container

[X] I have verified that the issue is reproducible with the latest nightly build

Version
0.130.9

Siehe https://github.com/evcc-io/evcc/issues/16097

Unfortunately your report is missing a detailed log file. Without log, we don‘t have the information for diagnosing the issue described. See https://docs.evcc.io/docs/faq#wie-kann-ich-ein-logfile-zur-fehleranalyse-erstellen.

Hi,
i have changed the password and also checked the AGB.
It connects to VW but i still dont get the SOC
[lp-1  ] DEBUG 2024/09/14 14:25:17 vehicle odometer: 54212km
[lp-1  ] DEBUG 2024/09/14 14:25:17 charger status: C
[lp-1  ] ERROR 2024/09/14 14:25:17 vehicle soc: unknown engine type: electric, got [, ]

I think you should run a
evcc -l trace vehicle

to produce a log file with enough information.

I have the same issue.
I formatted the output of the trace.
{
"charging": {
"batteryStatus": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:16Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
},
"chargingStatus": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:16Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
},
"chargingSettings": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
},
"plugStatus": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:16Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
},
"chargeMode": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
}
},
"climatisation": {
"climatisationSettings": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
},
"climatisationStatus": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
},
"climatisationTemperatureOutside": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Something went wrong. Please try to re-login. If the problem persists, please contact our support.",
"code": 4004,
"group": 3,
"retry": true
}
},
"windowHeatingStatus": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
}
},
"fuelStatus": {
"rangeStatus": {
"error": {
"message": "Bad Gateway",
"errorTimeStamp": "2024-12-12T18:27:14Z",
"info": "Upstream service responded with an unexpected status. If the problem persists, please contact our support.",
"code": 4007,
"group": 2,
"retry": true
}
}
},
"measurements": {
"rangeStatus": {
"value": {
"carCapturedTimestamp": "2024-12-12T17:49:12Z",
"gasolineRange": 510,
"totalRange_km": 510
}
},
"odometerStatus": {
"value": {
"carCapturedTimestamp": "2024-12-12T17:49:12Z",
"odometer": 51914
}
},
"fuelLevelStatus": {
"value": {
"carCapturedTimestamp": "2024-12-12T17:49:12Z",
"currentFuelLevel_pct": 81,
"primaryEngineType": "gasoline",
"secondaryEngineType": "electric",
"carType": "hybrid"
}
}
}
}

Heute gab es wieder neue Einwilligungen zu akzeptieren bei VW....

Bringt aber Nix. Geht trotzdem nicht Von meinem iPhone gesendetAm 12.12.2024 um 19:38 schrieb Tobias Huber @.***>:
Heute gab es wieder neue Einwilligungen zu akzeptieren bei VW....
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Is it the WeConnect Plus needed?
I bought the car a month ago and just got my car back today from the VW as the multimedia device had an old SW and I was not able to become the primary user. Now it has SW version 330 and I was able to setup my account as the primary user. Even if it is now configured, the VW app does not show any charging status or battery status.
Maybe I need to enable some of the services. I will go to check this.

"Laden" is not active without the We Connect Plus.

Bought the "Plus" and now it works:
[id    ] TRACE 2024/12/12 19:59:21 {"charging":{"batteryStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","currentSOC_pct":97,"cruisingRangeElectric_km":32}},"chargingStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","chargingState":"notReadyForCharging","chargeMode":"invalid","chargeType":"unsupported"}},"chargingSettings":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","maxChargeCurrentAC":"maximum"}},"plugStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","plugConnectionState":"disconnected","plugLockState":"unlocked","externalPower":"unavailable","ledColor":"none"}},"chargeMode":{"error":{"message":"Bad Gateway","errorTimeStamp":"2024-12-12T19:59:21Z","info":"Upstream service responded with an unexpected status. If the problem persists, please contact our support.","code":4111,"group":2,"retry":true}}},"climatisation":{"climatisationSettings":{"value":{"carCapturedTimestamp":"2024-12-12T19:49:45Z","targetTemperature_C":22,"targetTemperature_F":72,"climatisationWithoutExternalPower":false,"heaterSource":"automatic"}},"climatisationStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:57:49Z","climatisationState":"off"}},"climatisationTemperatureOutside":{"error":{"message":"Bad Gateway","errorTimeStamp":"2024-12-12T19:59:20Z","info":"Something went wrong. Please try to re-login. If the problem persists, please contact our support.","code":4004,"group":3,"retry":true}},"windowHeatingStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:57:50Z","windowHeatingStatus":[{"windowLocation":"front","windowHeatingState":"off"},{"windowLocation":"rear","windowHeatingState":"off"}]}}},"fuelStatus":{"rangeStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","carType":"hybrid","primaryEngine":{"type":"gasoline","currentSOC_pct":81,"remainingRange_km":510,"currentFuelLevel_pct":81},"secondaryEngine":{"type":"electric","currentSOC_pct":97,"remainingRange_km":32},"totalRange_km":542}}},"measurements":{"rangeStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","electricRange":32,"gasolineRange":510,"totalRange_km":542}},"odometerStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:41:53Z","odometer":51914}},"fuelLevelStatus":{"value":{"carCapturedTimestamp":"2024-12-12T19:58:19Z","currentFuelLevel_pct":81,"currentSOC_pct":97,"primaryEngineType":"gasoline","secondaryEngineType":"electric","carType":"hybrid"}}}}
Soc:            97%
Capacity:       13.0kWh
Charge status:  A
Range:          32km
Odometer:       51914km
Finish time:    2024-12-12 19:58:00 +0000 UTC
Climate active: false
Limit Soc:      not available
OnIdentified:   Mode:now, MinCurrent:6, MaxCurrent:16


Killing a node process

Hi,
First of all, great job on this project!  I'm surprised how fast node is on mobile. Not sure if its due to some of the stuff being stripped out, but easily keeps up with my i7 desktop on an average android device. Amazing.
Anyways, I have a large cross-platform node project that is designed to be long running (think days or weeks).  The code base is large and complex. Sometimes things just go wrong and require a fresh restart.  I found service.getProcess().exit(), but strangely this doesn't seem to really release the process. Sometimes the onProcessExit() event is called on the java side, and sometimes not.  It seems to depend on what the node process is doing when its called. I've even tried calling process.exit() from within node.  That fires the process.on('exit') event in node, but modules like Express continue to listen to their ports and setIntervals() are still in the event loop.
Is there a trick to kill and release the node thread that I'm missing?

Hmm, interesting.  Does it behave this way on desktop, too?  Or don't you really know since you just Ctrl^C anyway?
I just added a nuclear option to Android which will be released in 0.6.1 by this weekend.  It's there in master if you want to try it.
It is JSContextGroup.terminateExecution()
It isn't specific to Node, so I am not sure what will happen to running worker threads, but you can try it.  Given what you are saying, though, I am not sure it will stop all the callbacks and may wind up crashing your app.
If you want to hack around a bit, the node process is actually started in java here.  You may be able to forcefully kill that thread, however a quick read of StackOverflow suggests this may not be possible anymore.
The right way to do this is to execute process.exit() like you've done.  In fact, that is all service.getProcess().exit() does anyway.  I am surprised you get different results from doing it both ways.
If you can create a simple, repeatable test case, I can take a look more closely.

Ok, I'll give that a try.
On desktop, after process.exit() call, the app takes maybe 2-3 seconds to close. So I'm not sure what node is doing during that time, but it does eventually exit.  On android it just stays around forever.  So maybe it doesnt actually close on desktop either, and the os kicks in and kills it at some point? Not sure.
I hope I can produce a simple test case for you. Working on that now. The app as it is has a bundled size if about 8mb. I haven't yet tried to narrow it down beyond just calling process.exit().

I have encountered a similar issue as @AbortingMission . The HTTP servers that were created in the Node.js Microservice do not appear to release their ports on process exit (if the process even exits at all).
I've added logic to ServiceErrorListener and ServiceExitListener to initialize a new Microservice if the old one has crashed or exited. I've played around with delays up to 10 seconds between crash/exit and before calling the new Microservice startup routine. Below is the very bare-bones script I've been using for my Microservice that should crashes the first time, and if the restart happens without the process exiting, should crash repeatedly after that due to EADDRINUSE errors.
'use strict';

const http = require('http');

process.on('exit', () => {
    if (myServer) {
//		myServer.close();
    }
});

var myServer = http.createServer();
myServer.listen(9001);

setTimeout(() => {
	console.log('Hello friends, I have started!');
	LiquidCore.emit('ready');
}, 5000);

setTimeout(() => {
	console.log('Sorry friends, I have crashed');
	throw new Error('Sadness');
}, 12000);

// Keepalive
setInterval(() => {}, 1000);

@pdulapalli @AbortingMission I think I know why this is happening.  I need to figure out how to deal with it, however.  In node, when you call process.exit() it basically throws an abort signal and exits to the OS.  I capture the exit call, and instead of aborting, I clear the event queue which will cause the process to exit when it finishes its current task without executing any new tasks that are in the queue.  This is because I don't want process.exit() to crash the entire app.  The problem with this is that if the current task is in an endless loop, then it never gets to where it can exit the event loop cleanly.  I need to abort execution of the existing task, which I can do as mentioned above on Android.  However, this will not work on iOS.  There is no exposed public method in JavaScriptCore to do this (there is a private one, but using it will get your app declined in the app store).


[iOS] Add Fabric dynamic color support

Summary:
Fixes #42006 .
Changelog:
[IOS] [ADDED] - Add Fabric dynamic color support
Test Plan:
Dynamic color worked.

There are also some CI failures that need to be addressed.

For the CI, I see that it is failing for Dynamic Frameworks only. It looks like that RCT-Folly has no access to double-conversion.
/tmp/iOSTemplateProject/ios/Pods/RCT-Folly/folly/Conv.h:120:10: fatal error: 'double-conversion/double-conversion.h' file not found
#include <double-conversion/double-conversion.h> // V8 JavaScript implementation
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Which is weird because RCT-Folly.podspec has both the DoubleConversion dependency and the HEADER_SEARCH_PATH.
I'll try to repro this issue locally.

Figured out how to fix it. 😄
Add these lines here:
  header_search_paths = [
    "\"$(PODS_ROOT)/boost\"",
    "\"$(PODS_TARGET_SRCROOT)/../../../\"",
    "\"$(PODS_ROOT)/RCT-Folly\"",
+   "\"$(PODS_ROOT)/DoubleConversion\"",
+    "\"$(PODS_ROOT)/fmt/include\"",
  ]

And these lines, here:
  s.dependency "React-Core/Default", version
  s.dependency "React-utils"
+  s.dependency "DoubleConversion"
+  s.dependency "fmt", "9.1.0"
end

@cipolleschi Thanks for your review and help. :)

Hi @zhongwuzw!
I just want to set expectation that this change will take a little longer than usual to land.
There are some internal apps and libraries that are not building due to this change, and I'll have to invest some time in updating their calling sites. That's not a major issue, but I just wanted to provide an update on this.

@cipolleschi Seem it breaks the internal tests, anything I can do?

Hi @zhongwuzw, unfortunately not. This is something we (as Meta engineers) as to take care.
Internally we use a different tool to build (BUCK2) and we need to make it happy. A lot of the files that I had to touch are not published in OSS.
Yesterday evening I got to a point where everything is green. I'm waiting for a review internally and I hope to land this PR and my changes for the internal system on Monday (just to avoid landing stuff over the weekend! :P )

@cipolleschi I rebased from the latest main branch, please pull and review again :)

Hi @zhongwuzw, thanks for that. I'm going to try to land this today. I'll not be importing the new version as I had to apply some changes to the code to make it work internally and importing the new version will overwrite those changes, but I will manually apply the new ones you added to make CI green.
The commit will still be attributed to you anyway, so we should be fine! :D


Adding my pixel

Such a neat idea.. thanks! It taught me some new git commands too.
Checklist

[x] I ran npm test locally and it passed without errors.
[x] I only edited the _data/pixels.json file.
[x] I entered the username in the pixels.json that I'm also using to create this pull request.
[x] I acknowledge that all my contributions will be made under the project's license.

I'm struggling a bit with the merge conflict, would love some guidance if someone is available.

@teejayen no problem :) I helped out! The trick for this one was to accept their changes and then add you to it. Thank you for your contribution!


ci: Add code coverage with Jacoco and Codecov

Description
Added code coverage so we can ensure a level of quality.
Checklist

[x] I have read the contributing guidelines.
[ ] I wrote/updated tests for new/changed code
[x] I ran ./gradlew check without errors

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@3cb68e5). Click here to learn what that means.
The diff coverage is 100%.

@@           Coverage Diff           @@
##             master     #4   +/-   ##
=======================================
  Coverage          ?   100%
=======================================
  Files             ?      1
  Lines             ?      2
  Branches          ?      0
=======================================
  Hits              ?      2
  Misses            ?      0
  Partials          ?      0

Impacted Files
Coverage Δ

...kuten/tech/mobile/remoteconfig/RealRemoteConfig.kt
100% <100%> (ø)

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 3cb68e5...235d7db. Read the comment docs.


Add -insecure option to skip TLS certificate verification

Adds -insecure flag to skip TLS verification when making HTTP requests to
./detect-angular-dashboards -j -insecure https://localhost:3000/api

This can be used to use the program against instances that have a self-signed certificate.
Fixes #7

Any progress here?

Hi @toporek3112 , this has been added in the latest release: https://github.com/grafana/detect-angular-dashboards/releases/tag/v0.8.0

Perfect, thank you guys!


Adding better docs for authors

Tugboat has finished building the preview for this pull request!
Link:

https://pr207-l3bowct4pz3won1ufajgula2xrh7hgs1.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/61c377215f46ed13d85c02e6


Unable to get horizontal scrolling for to_wavedom() to work

Hi I am running peeker_options,ipynb in examples directory.  The example for horizontal scrolling, doesn't display any output unless I comment the line #Peeker.clear_traces(). If I comment this line output will display but is compressed to width of browser with no scroll bars.
import myhdlpeek
myhdlpeek.USE_JUPYTERLAB = False
Peeker.clear_traces()
Simulation(add_1, test(100), *Peeker.instances()).run()
Peeker.to_wavedrom(signals, width=4000)
Peeker.clear_traces()

The other examples in this notebook render fine but they do display the following Javascript error which may be related:
Javascript error adding output!
TypeError: Cannot read property 'removeChild' of null
See your browser Javascript console for more details.

Here's the Console error detail
main.min.js:34573
TypeError: Cannot read property 'removeChild' of null
    at m (main.min.js:2)
    at Re (main.min.js:2)
    at w.fn.init.append (main.min.js:2)
    at OutputArea._safe_append (main.min.js:34570)
    at OutputArea.append_execute_result (main.min.js:34607)
    at OutputArea.append_output (main.min.js:34439)
    at OutputArea.handle_output (main.min.js:34370)
    at output (main.min.js:36214)
    at Kernel._handle_output_message (main.min.js:37973)
    at i (main.min.js:2)

outputarea.js:460
TypeError: Cannot read property 'removeChild' of null
    at m (jquery.min.js:2)
    at Re (jquery.min.js:2)
    at w.fn.init.append (jquery.min.js:2)
    at OutputArea._safe_append (outputarea.js:457)
    at OutputArea.append_execute_result (outputarea.js:494)
    at OutputArea.append_output (outputarea.js:326)
    at OutputArea.handle_output (outputarea.js:257)
    at output (codecell.js:391)
    at Kernel._handle_output_message (kernel.js:1196)
    at i (jquery.min.js:2)

Finally, my setup: Ubuntu 18.04,
Software	Version
Python	3.5.6 64bit [GCC 7.3.0]
IPython	6.5.0
OS	Linux 4.15.0 58 generic x86_64 with debian buster sid
myhdl	0.11
myhdlpeek	0.0.8
Fri Aug 16 10:20:14 2019 PDT

Have also tried on Windows 10, python 3.7 (am running 3.5 due to pygmyhdl issue with byteplay3), jupyter lab vs notebook, firefox v chrome

Thanks for the detailed bug report. I created an Ubuntu 18.04 VM with the software versions you listed and I got the same behavior.
You were on the right track by setting myhdlpeek.USE_JUPYTERLAB = False. I did the same but it had no effect. I'm wondering if that ever worked. I had to go directly into the myhdlpeek.py file and set USE_JUPYTERLAB to False in order to get the scrolling to work and also to eliminate the Javascript errors.
Obviously, there needs to be a setter function in myhdlpeek.py for setting the USE_JUPYTERLAB flag.

Thanks for your quick reply. I was able to get scrolling to work in jupyter notebook by setting USE_JUPYTERFLAG=False in myhdlpeek.py as you said.  Still no luck with jupyter lab no matter which setting but at least I have a way to view scrolling (and eliminate the other js errors) in notebook.

Hi, I just wanted to confirm that you were also able to replicate "no scrolling" behaviour in jupyter lab (with of course the default myhdlpeek.USE_JUPYTERLAB = True; i.e. no edits). I can get it to work in jupyter notebook by applying the edit directly to myhdlpeek.py but is there a work around for jupyter lab? (Or maybe it just works for you in jupyter lab?).

I'll try Jupyter Lab tomorrow. If it's not working for you, then I'm betting there's something wrong with the wavedrom function that I'm calling when USE_JUPYTERLAB is True.

OK cool. Thanks for looking into it


Updated expect-failure docs

expect-failure didn't fully describe how it worked: It checks if err is contained in the thrown error. So I added that. It's nice to have that info in there.

Hi, this needs to be added to the native definition itself, not to the docs which are auto-generated: https://github.com/kadena-io/pact/blob/master/src/Pact/Repl/Lib.hs#L170-L176

Is this something you want to attempt, @Luzzotica? Or shall I close this and reference it in a follow up.

I can try to figure it out. Give me until the end of the week. :)On Nov 16, 2022, at 2:56 PM, Emily Pillmore @.***> wrote:
Is this something you want to attempt, @Luzzotica? Or shall I close this and reference it in a follow up.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


[BUG] The filter type of the useTable is strange

Describe the bug
The filter type of the useTable is strange
Currently, I'm
You are using filters, the useTable return value of '@refinedev/core'. However, when the actual filter is selected, there is a field attribute in the filter object in the array, but the type does not seem to be.
Steps To Reproduce

Get 'useTable' from '@refinedev/core'.
Use the useTable as shown below.
Set the filter and check the object type in the array of filters.
At this time, there is no field.

Expected behavior
The type of 'filters' returned from the useTable should be 'LogicalFilter[]'.
Screenshot

Desktop
No response
Mobile
No response
Additional Context
No response

Hello @KoYoungWock, filters are union to support OR and AND values.
export type LogicalFilter = {
    field: string;
    operator: Exclude<CrudOperators, "or" | "and">;
    value: any;
};

export type ConditionalFilter = {
    key?: string;
    operator: Extract<CrudOperators, "or" | "and">;
    value: (LogicalFilter | ConditionalFilter)[];
};

export type CrudFilter = LogicalFilter | ConditionalFilter;
export type CrudFilters = CrudFilter[];

The type of filters correct but you need to check is LogicalFilter or ConditionalFilter.
If you are sure about filters you can use as:
const tableFilters = filters as LogicalFilter[]

or you can use field key check:
if("field" in filters) {
// in this scope typeof filters will be LogicalFilter[]
}


Gui hookspecs

Description
This PR would combine #1849 and #1816 in one, handling the menubar adding for both. It's still WIP. In particular I want to namespace the menubar options.
Type of change

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

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

I've updated this following some nice work from @tlambert03 on https://github.com/napari/napari-plugin-engine/pull/10, so that the menubars are now nested plugin name followed by function/ class name for both dock widgets and function generated widgets. I quite like this now, but am thinking that we should probably prevent these widgets from appearing in the Window drop down too otherwise it's just too many places right?
The biggest thing I'm probably still uneasy about is that Tuple[Callable, Dict, Dict] for the provide_function hookspec. The first thing is the function, the second the magic_kwargs dict, and then the third are keyword arguments to add_dock_widget. I'm sort of tempted just to drop the third dict.
Maybe asking people to provide
my_func.napari_menu_name
my_func.napari_area
my_func.napari_allowed_areas

directly on the function itself, like we do for the QWidget.
I might go ahead and implement that now to see how it feels. Curious how others feel? This is probably ready for some light review @tlambert03 @jni but it is still got some rough edges as mentioned above

I've updated this following some nice work from @tlambert03 on https://github.com/napari/napari-plugin-engine/pull/10, so that the menubars are now nested plugin name followed by function/ class name for both dock widgets and function generated widgets. I quite like this now, but am thinking that we should probably prevent these widgets from appearing in the Window drop down too otherwise it's just too many places right?
The biggest thing I'm probably still uneasy about is that Tuple[Callable, Dict, Dict] for the provide_function hookspec. The first thing is the function, the second the magic_kwargs dict, and then the third are keyword arguments to add_dock_widget. I'm sort of tempted just to drop the third dict.
Maybe asking people to provide
my_func.napari_menu_name
my_func.napari_area
my_func.napari_allowed_areas

directly on the function itself, like we do for the QWidget.
I might go ahead and implement that now to see how it feels. Curious how others feel? This is probably ready for some light review @tlambert03 @jni but it is still got some rough edges as mentioned above

Forgot to include screenshot!

Forgot to include screenshot!

Maybe asking people to provide
my_func.napari_menu_name
my_func.napari_area
my_func.napari_allowed_areas
directly on the function itself, like we do for the QWidget.

When I proposed something like this for scikit-image (function.extras), I asked Emma to ask Gaël what he thought, since he is somewhat of a stickler for simple APIs. He proposed shipping me a rubber duck with long curly hair that would respond "no." any time I asked about creating some exotic, non-standard API. 😂
It was a good proposal, because now I imagine the gaël-duck every time this question comes up! 😂
So, to be clear, I'm 👎 on this proposal, following the duck's advice.
All of the above "extras" are optional, right? In which case, I suggest replacing Tuple[Callable, Dict, Dict] with Union[Callable, Tuple[Callable, Dict], Tuple[Callable, Dict, Dict]] — would that work? Again, my medium/long term vision is that we come up with a set of type annotations that is descriptive enough that people just give us their type annotated functions and nothing else: the type annotations are enough for magicgui to do its magic, and simultaneously we come up with an awesome enough layout engine that allowed_areas is no longer needed.
As an example, we would something like:
def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

Maybe asking people to provide
my_func.napari_menu_name
my_func.napari_area
my_func.napari_allowed_areas
directly on the function itself, like we do for the QWidget.

When I proposed something like this for scikit-image (function.extras), I asked Emma to ask Gaël what he thought, since he is somewhat of a stickler for simple APIs. He proposed shipping me a rubber duck with long curly hair that would respond "no." any time I asked about creating some exotic, non-standard API. 😂
It was a good proposal, because now I imagine the gaël-duck every time this question comes up! 😂
So, to be clear, I'm 👎 on this proposal, following the duck's advice.
All of the above "extras" are optional, right? In which case, I suggest replacing Tuple[Callable, Dict, Dict] with Union[Callable, Tuple[Callable, Dict], Tuple[Callable, Dict, Dict]] — would that work? Again, my medium/long term vision is that we come up with a set of type annotations that is descriptive enough that people just give us their type annotated functions and nothing else: the type annotations are enough for magicgui to do its magic, and simultaneously we come up with an awesome enough layout engine that allowed_areas is no longer needed.
As an example, we would something like:
def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

As an example, we would something like:
def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

This is already supported by magicgui, but you need to provide a dict:
def gaussian(image, sigma: Annotated[float {'min': 1, 'max': 100}]):

As an example, we would something like:
def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

This is already supported by magicgui, but you need to provide a dict:
def gaussian(image, sigma: Annotated[float {'min': 1, 'max': 100}]):

and tangentially related, just so people know... It's also possible to modify these annotations dynamically after the function definition, by modifying the __annotations__ dict:
In [1]: def f(x):
   ...:     pass
   ...:

In [2]: f.__annotations__
Out[2]: {}

In [3]: f.__annotations__['x'] = int

In [4]: f
Out[4]: <function __main__.f(x: int)>

In [5]: f?
Signature: f(x: int)
Docstring: <no docstring>
File:      ~/Dropbox (HMS)/Python/forks/napari/<ipython-input-1-79a43d98d2b6>
Type:      function

and tangentially related, just so people know... It's also possible to modify these annotations dynamically after the function definition, by modifying the __annotations__ dict:
In [1]: def f(x):
   ...:     pass
   ...:

In [2]: f.__annotations__
Out[2]: {}

In [3]: f.__annotations__['x'] = int

In [4]: f
Out[4]: <function __main__.f(x: int)>

In [5]: f?
Signature: f(x: int)
Docstring: <no docstring>
File:      ~/Dropbox (HMS)/Python/forks/napari/<ipython-input-1-79a43d98d2b6>
Type:      function

and tangentially related, just so people know... It's also possible to modify these annotations dynamically after the function definition, by modifying the __annotations__ dict:
In [1]: def f(x):
   ...:     pass
   ...:

In [2]: f.__annotations__
Out[2]: {}

In [3]: f.__annotations__['x'] = int

In [4]: f
Out[4]: <function __main__.f(x: int)>

In [5]: f?
Signature: f(x: int)
Docstring: <no docstring>
File:      ~/Dropbox (HMS)/Python/forks/napari/<ipython-input-1-79a43d98d2b6>
Type:      function

and tangentially related, just so people know... It's also possible to modify these annotations dynamically after the function definition, by modifying the __annotations__ dict:
In [1]: def f(x):
   ...:     pass
   ...:

In [2]: f.__annotations__
Out[2]: {}

In [3]: f.__annotations__['x'] = int

In [4]: f
Out[4]: <function __main__.f(x: int)>

In [5]: f?
Signature: f(x: int)
Docstring: <no docstring>
File:      ~/Dropbox (HMS)/Python/forks/napari/<ipython-input-1-79a43d98d2b6>
Type:      function

This is already supported by magicgui, but you need to provide a dict:

Yeah I did get a sense of déjà vu but I couldn't tell if it was real 😅
But, then the extra dict should indeed be optional, right?

This is already supported by magicgui, but you need to provide a dict:

Yeah I did get a sense of déjà vu but I couldn't tell if it was real 😅
But, then the extra dict should indeed be optional, right?

This is already supported by magicgui, but you need to provide a dict:

Yeah I did get a sense of déjà vu but I couldn't tell if it was real 😅
But, then the extra dict should indeed be optional, right?

Correct, both int and Annotated[int, {...}] are valid annotations,  and lacking the options, it will use magicgui’s default settings

This is already supported by magicgui, but you need to provide a dict:

Yeah I did get a sense of déjà vu but I couldn't tell if it was real 😅
But, then the extra dict should indeed be optional, right?

Correct, both int and Annotated[int, {...}] are valid annotations,  and lacking the options, it will use magicgui’s default settings

As an example, we would something like:
def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

This is already supported by magicgui, but you need to provide a dict:
def gaussian(image, sigma: Annotated[float, {'min': 1, 'max': 100}]):

I wonder if we shouldn't start supporting all the pydantic custom types, for example their constrained types - see https://pydantic-docs.helpmanual.io/usage/types/#constrained-types
from pydantic import confloat

def gaussian(image, sigma: confloat(ge=0, le=100)):

Their list is really quite comprehensive for generic types, and I'd prefer to reuse this system rather than invent our own. For example they have confloat(ge=0, le=100) and confloat(gt=0, lt=100) for both <= and < like inequalities. It's unclear what the default behavior with float, {'min': 1, 'max': 100} or FloatRange(1, 100) would be, and I think we'd just end up reinventing a lot of their system as we needed more complexity.
Note this doesn't have to be right now, but it's something we might want to consider if we start using pydantic for our base models.

As an example, we would something like:
def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

This is already supported by magicgui, but you need to provide a dict:
def gaussian(image, sigma: Annotated[float, {'min': 1, 'max': 100}]):

I wonder if we shouldn't start supporting all the pydantic custom types, for example their constrained types - see https://pydantic-docs.helpmanual.io/usage/types/#constrained-types
from pydantic import confloat

def gaussian(image, sigma: confloat(ge=0, le=100)):

Their list is really quite comprehensive for generic types, and I'd prefer to reuse this system rather than invent our own. For example they have confloat(ge=0, le=100) and confloat(gt=0, lt=100) for both <= and < like inequalities. It's unclear what the default behavior with float, {'min': 1, 'max': 100} or FloatRange(1, 100) would be, and I think we'd just end up reinventing a lot of their system as we needed more complexity.
Note this doesn't have to be right now, but it's something we might want to consider if we start using pydantic for our base models.

So, to be clear, I'm 👎 on this proposal, following the duck's advice.
All of the above "extras" are optional, right? In which case, I suggest replacing Tuple[Callable, Dict, Dict] with Union[Callable, Tuple[Callable, Dict], Tuple[Callable, Dict, Dict]] — would that work?

I can do that, but should we do that for the QWidget case too? @tlambert03 what are your thoughts here? I think I have the least strong preference about this, so will go with whatever people want.

So, to be clear, I'm 👎 on this proposal, following the duck's advice.
All of the above "extras" are optional, right? In which case, I suggest replacing Tuple[Callable, Dict, Dict] with Union[Callable, Tuple[Callable, Dict], Tuple[Callable, Dict, Dict]] — would that work?

I can do that, but should we do that for the QWidget case too? @tlambert03 what are your thoughts here? I think I have the least strong preference about this, so will go with whatever people want.

just some thoughts ... haven't looked again at code yet:

the menubars are now nested plugin name followed by function/ class name for both dock widgets and function generated widgets.

yeah this is great! From a ux perspective, I'm a little worried we're going to have a lot of subwindows with a single option (i.e. a plugin that only provides a single dock widget, which will probably be most of them?).
The Dock Widgets menu is great, but I'm wondering if we can't maybe avoid the submenus if the plugin only provides on widget? (To avoid naming conflicts, I'd prefer renaming the menu item to QWidget (builtins) as opposed to a "builtins" menu with 1 "QWidget").

but am thinking that we should probably prevent these widgets from appearing in the Window drop down too otherwise it's just too many places right?

Yeah, totally agree. Also, at the moment, there's some desynchronization: if you close the widget in the Windows menu (or click the x button in the widget), it remains checked in the DockWidgets menu... but unchecking it in DockWidgets removes it from the other two.

The biggest thing I'm probably still uneasy about is that Tuple[Callable, Dict, Dict] for the provide_function hookspec.

Yeah I agree with you, and I agree with @jni's comments that ultimately it'd be nice to just have a well-annotated function. (which is also why I brought up the Annotated feature in euro-dev meeting the other day).  However, as @sofroniewn also pointed out during the meeting, there are rather useful some "widget-global" options (call_button=True, labels=False, auto_call=True) that can't be tucked into an Annotated` parameter type.  Add to that the need for people to provide some additional metadata for how this function should look in the menu, shortcuts, area restrictions, etc... and I think we're quite a ways away from the ideal of just being able to take a function.
I'm probably more in favor of an "overloaded single argument" approach like @jni's tuples (Union[Callable, Tuple[Callable, Dict], Tuple[Callable, Dict, Dict]]) than I am of adding attributes to the function like my_func.napari_menu_name

should we do that for the QWidget case too?

It feels very normal for a class which is already a natural "namespace object" and often has class attributes ... but it feels awkward for a function, which almost never has attributes like this.  So I don't "mind" the class attribute approach (lots of libraries use it). But if the symmetry of the Union[...] hookspec API was super appealing to anyone, I could be convinced either way.

I wonder if we shouldn't start supporting all the pydantic custom types

I like that idea!  But I'd probably leave it forever (?) at "support", and not "require".  Happy to add some code to check if it's a pydantic constrained type, and convert it to some internal Annotated[float, {...}] type... but not looking to require any non-standard-lib stuff just to annotate a parameter.

just some thoughts ... haven't looked again at code yet:

the menubars are now nested plugin name followed by function/ class name for both dock widgets and function generated widgets.

yeah this is great! From a ux perspective, I'm a little worried we're going to have a lot of subwindows with a single option (i.e. a plugin that only provides a single dock widget, which will probably be most of them?).
The Dock Widgets menu is great, but I'm wondering if we can't maybe avoid the submenus if the plugin only provides on widget? (To avoid naming conflicts, I'd prefer renaming the menu item to QWidget (builtins) as opposed to a "builtins" menu with 1 "QWidget").

but am thinking that we should probably prevent these widgets from appearing in the Window drop down too otherwise it's just too many places right?

Yeah, totally agree. Also, at the moment, there's some desynchronization: if you close the widget in the Windows menu (or click the x button in the widget), it remains checked in the DockWidgets menu... but unchecking it in DockWidgets removes it from the other two.

The biggest thing I'm probably still uneasy about is that Tuple[Callable, Dict, Dict] for the provide_function hookspec.

Yeah I agree with you, and I agree with @jni's comments that ultimately it'd be nice to just have a well-annotated function. (which is also why I brought up the Annotated feature in euro-dev meeting the other day).  However, as @sofroniewn also pointed out during the meeting, there are rather useful some "widget-global" options (call_button=True, labels=False, auto_call=True) that can't be tucked into an Annotated` parameter type.  Add to that the need for people to provide some additional metadata for how this function should look in the menu, shortcuts, area restrictions, etc... and I think we're quite a ways away from the ideal of just being able to take a function.
I'm probably more in favor of an "overloaded single argument" approach like @jni's tuples (Union[Callable, Tuple[Callable, Dict], Tuple[Callable, Dict, Dict]]) than I am of adding attributes to the function like my_func.napari_menu_name

should we do that for the QWidget case too?

It feels very normal for a class which is already a natural "namespace object" and often has class attributes ... but it feels awkward for a function, which almost never has attributes like this.  So I don't "mind" the class attribute approach (lots of libraries use it). But if the symmetry of the Union[...] hookspec API was super appealing to anyone, I could be convinced either way.

I wonder if we shouldn't start supporting all the pydantic custom types

I like that idea!  But I'd probably leave it forever (?) at "support", and not "require".  Happy to add some code to check if it's a pydantic constrained type, and convert it to some internal Annotated[float, {...}] type... but not looking to require any non-standard-lib stuff just to annotate a parameter.

I wonder if we shouldn't start supporting all the pydantic custom types

I like that idea! But I'd probably leave it forever (?) at "support", and not "require". Happy to add some code to check if it's a pydantic constrained type, and convert it to some internal Annotated[float, {...}] type... but not looking to require any non-standard-lib stuff just to annotate a parameter.

Agreed. Also, the pydantic stuff actually affects runtime behaviour of the function, clamping/raising on values outside their range, right? I don't think that's desirable. In the case of scikit-image, for example, I can see us using Annotated, but not confloat.

But if the symmetry of the Union[...] hookspec API was super appealing to anyone, I could be convinced either way.

🙋
But, I agree that class attributes are also fine. I wouldn't mind supporting both in this case. But in any case I think a single widget class should be supported, just like a single callable should be supported.

Then not entirely, as there are some global widget magicgui options (auto_call, labels, layout, etc...) that aren’t captured in parameter annotations.

Yes yes, we are agreed! I meant, "since we can get so much functionality out of Annotated, then I can imagine many use cases being met by just that, and we should allow the hookspec to provide just an annotated Callable. The dict could be provided for users that want additional options.

I wonder if we shouldn't start supporting all the pydantic custom types

I like that idea! But I'd probably leave it forever (?) at "support", and not "require". Happy to add some code to check if it's a pydantic constrained type, and convert it to some internal Annotated[float, {...}] type... but not looking to require any non-standard-lib stuff just to annotate a parameter.

Agreed. Also, the pydantic stuff actually affects runtime behaviour of the function, clamping/raising on values outside their range, right? I don't think that's desirable. In the case of scikit-image, for example, I can see us using Annotated, but not confloat.

But if the symmetry of the Union[...] hookspec API was super appealing to anyone, I could be convinced either way.

🙋
But, I agree that class attributes are also fine. I wouldn't mind supporting both in this case. But in any case I think a single widget class should be supported, just like a single callable should be supported.

Then not entirely, as there are some global widget magicgui options (auto_call, labels, layout, etc...) that aren’t captured in parameter annotations.

Yes yes, we are agreed! I meant, "since we can get so much functionality out of Annotated, then I can imagine many use cases being met by just that, and we should allow the hookspec to provide just an annotated Callable. The dict could be provided for users that want additional options.

Also, the pydantic stuff actually affects runtime behaviour of the function, clamping/raising on values outside their range, right? I don't think that's desirable.

Agreed, not desirable... but I don't think simply annotating a parameter as such would have any runtime effect, it would need to be the annotation for a field (class attribute) in a subclass of pydantic.BaseModel for it to have any runtime validation

Ok changes pushed, this now includes a new menubar style, and I've dropped the additional function args that @jni didn't like, but I haven't added in the third dict argument to the hookspec. Maybe @jni can do that. This then needs a little cleaning up, but should be close.

Ok changes pushed, this now includes a new menubar style, and I've dropped the additional function args that @jni didn't like, but I haven't added in the third dict argument to the hookspec. Maybe @jni can do that. This then needs a little cleaning up, but should be close.

Ok, made some updates, it needs some work inside register_function and register_dock_widget to account for all the different types of return values we now support, and needs some comprehensive tests. Getting close, but still needs a push

Ok, made some updates, it needs some work inside register_function and register_dock_widget to account for all the different types of return values we now support, and needs some comprehensive tests. Getting close, but still needs a push

Ok, following some suggestions from @tlambert03 this now has a List if people provide more than 1 thing, and a tuple if people are providing dicts. I don't do any validation, but i think we should (could be in future PR, could be now). I also have the type alias (?), but not sure if @jni will like that. I'm still missing tests and we need to write good doc strings.
I'd say with those caveats this is ready for review, and if @tlambert03/ @jni wanted to directly work on the type alias/ remove them or work on the doc strings then this would be much appreciated. I'm worried I'm not doing the best job possible here. Commits directly to the PR are welcome. I'll help with the tests.
I think this is pretty close now though!!! Which is very exciting :-)

Ok, following some suggestions from @tlambert03 this now has a List if people provide more than 1 thing, and a tuple if people are providing dicts. I don't do any validation, but i think we should (could be in future PR, could be now). I also have the type alias (?), but not sure if @jni will like that. I'm still missing tests and we need to write good doc strings.
I'd say with those caveats this is ready for review, and if @tlambert03/ @jni wanted to directly work on the type alias/ remove them or work on the doc strings then this would be much appreciated. I'm worried I'm not doing the best job possible here. Commits directly to the PR are welcome. I'll help with the tests.
I think this is pretty close now though!!! Which is very exciting :-)

if @tlambert03/ @jni wanted to directly work on the type alias/ remove them or work on the doc strings then this would be much appreciated.

will review tonight.  I think the type aliases are fine (and I don't think @jni is globally against them?)  but in this case, I don't think I'd put them in types.py.  I know there are some other type aliases there, but that's just because we use them internally as type annotations throughout the repo.  In this case, particularly to make it easier for someone just looking at at the hookspecs file, I think you should put the aliases next to the function.  Also, I wouldn't call it MagicFunction (the function is just the callable, so it's misleading to include a Tuple in the Union)  ... maybe just:
ValidFunctionGuiArg = Union[Callable, Tuple[Callable, dict], Tuple[Callable, dict, dict]]
def hookspec() -> Union[ValidFunctionGuiArg, List[ValidFunctionGuiArg]]: ...

if @tlambert03/ @jni wanted to directly work on the type alias/ remove them or work on the doc strings then this would be much appreciated.

will review tonight.  I think the type aliases are fine (and I don't think @jni is globally against them?)  but in this case, I don't think I'd put them in types.py.  I know there are some other type aliases there, but that's just because we use them internally as type annotations throughout the repo.  In this case, particularly to make it easier for someone just looking at at the hookspecs file, I think you should put the aliases next to the function.  Also, I wouldn't call it MagicFunction (the function is just the callable, so it's misleading to include a Tuple in the Union)  ... maybe just:
ValidFunctionGuiArg = Union[Callable, Tuple[Callable, dict], Tuple[Callable, dict, dict]]
def hookspec() -> Union[ValidFunctionGuiArg, List[ValidFunctionGuiArg]]: ...

that's just because we use them internally as type annotations throughout the repo

... oh I guess you do also use them in plugins.__init__, ah well, I don't know :) maybe keep 'em in types

that's just because we use them internally as type annotations throughout the repo

... oh I guess you do also use them in plugins.__init__, ah well, I don't know :) maybe keep 'em in types

@sofroniewn @tlambert03 see https://github.com/sofroniewn/napari/pull/8
Still to do:

tests for gui elements
.. class directives to describe the typedefs

Maybe these can come in followup PRs, though...

@sofroniewn @tlambert03 see https://github.com/sofroniewn/napari/pull/8
Still to do:

tests for gui elements
.. class directives to describe the typedefs

Maybe these can come in followup PRs, though...

@sofroniewn @tlambert03 see sofroniewn#8

just reviewed

Maybe these can come in followup PRs, though...

i'm happy to give this one another 24hrs. I think we can have it wrapped up by then, but good to know this now has green light from you @jni and @tlambert03 and I can put some finishing touches on it maybe during our day tomorrow and then merge.

@sofroniewn @tlambert03 see sofroniewn#8

just reviewed

Maybe these can come in followup PRs, though...

i'm happy to give this one another 24hrs. I think we can have it wrapped up by then, but good to know this now has green light from you @jni and @tlambert03 and I can put some finishing touches on it maybe during our day tomorrow and then merge.

more tests added @sofroniewn ... I think this more or less covers it

more tests added @sofroniewn ... I think this more or less covers it

Ok, great. This looks done to me! I've marked this as ready to review, maybe @tlambert03 @jni you can approve it and I will merge!! Thanks for all the hard work, this is a huge milestone for the project!!!

Ok, great. This looks done to me! I've marked this as ready to review, maybe @tlambert03 @jni you can approve it and I will merge!! Thanks for all the hard work, this is a huge milestone for the project!!!


Rename UIExplorer to RNTester

This is a scary change because this is tightly integrated with our testing and development workflow. This rename is worth it because it will allow us to properly license this code as a normal part of our test infrastructure, rather than as sample code.
Tests seem to pass locally, but I'm sending this PR out early to make sure it can pass on CI.
I still to make this pass tests internally

Great, looks like tests are passing on this! I'll attempt to land this internally tonight


Swap classnames for selected radios and checkboxes

As mentioned in the CHANGELOG for the frontend toolkit.
Version 20.0.0
We've changed a classname in our markup so now the tests need to select other things.

👍


Video Available For Use On Page Before Fully Uploaded

Bug Description
A video dragged from user's PC to canvas or media panel is available for a user to use (move, crop, etc.) BEFORE it is fully uploaded. Seems to "disappear" to user
Expected Behaviour
Thought that perhaps the video would be greyed out in the media panel or canvas - or something to show the user that it hasn't finished uploading
Steps to Reproduce
Dragged this video to Media Panel:

Was able to click it and add it to the canvas:

After a minute or two, video has disappeared from Media Panel:

NOTE: User CAN still click the video in teh canvas and the video will play
NOTE: On Preview, video appears as an image
NOTE: Nothing, neither video nor image, appears in the Media Library (which is what I'd expect)
Screenshots

Additional Context

Plugin Version:
Operating System:
Browser:

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

Implementation Brief

One more NOTE, as an fyi: Tried to upload the video by clicking "Upload" in the media panel. It's a 10,514 kb mp4 file and it does indeed fail:

The video disappearing from the media panel seems concerning. @diegovar is this something the team could look at?

I think what‘s happening is this:

Drag video from computer to editor
Video is added to media library and usable on canvas immediately while being uploaded (a feature!)
Video fails to upload (e.g. some unexpected server error)
Video is removed again from library because it never actually uploaded successfully

Oh, in that case there are two things to do if the video fails:

Tell user that upload failed when they drag video onto canvas
Disable/remove the video from canvas

This may be more on Workspace then? @barklund

@merapi Did #2730 fix this as well?

No, #2730 took care of happy path upload when dropped on canvas. Upload failure case is still TBD (more on this here). A low effort fix is to remove all elements using the given resource (NOTE: blob issues still can happen thanks to history).

@merapi So this report here is essentially the upload failure case from #2730, right?

I think we need to clarify what is expected here, because "Video Available For Use On Page Before Fully Uploaded" sounds like a feature, not a bug 😉  (should we disable any operation on video element? blob can still play and be cropped, so not sure) and another thing is a failure case.

Yes, that is a feature. But please read my comment https://github.com/google/web-stories-wp/issues/1910#issuecomment-635643869:
Video is added to media library and usable on canvas immediately while being uploaded -> Video fails to upload -> Video is removed again from library because it never actually uploaded successfully

@merapi So this report here is essentially the upload failure case from #2730, right?

Correct (the bug part) and exact behavior should be discussed further, because "Disable/remove the video from canvas" will not fix all the issues.
My point regarding this issue was that the Expected Behaviour is not clear or this issue should be removed/renamed.

Does this need further clarification? Is the real issue that a failed upload didn't show a snackbar describing that it failed?

@diegovar Yes, that‘s my understanding as per the conments above. Exact behavior needs to be defined first.

Duplicate of #2706


"Watch-only" accounts should be hidden in list of "Confirm connection"

Is your feature request related to a problem? Please describe.
Once i get in development mode of NFT portal, i tried to connect the portal with a "Watch-only" account, and then i get the following feedback: Error: Failed to reveal public key
Screenshots

After i click on Connect

Describe the solution you'd like
When "Confirming a connection" try to delete "Watch-only" accounts from the list because obviously the portal requires "full" accounts
Describe alternatives you've considered
Maybe different DApps may interact normally with a "Wach-only" account but in this case for the NFT portal, tbh i think is not necessary to show them...

fixed


missing static location for nginx-uwsgi in documentation

Hello,
In the document describing setting up nginx-uwsgi:
http://graphite.readthedocs.io/en/latest/config-webapp.html#nginx-uwsgi
the static content configuration is missing. This works:
server {
    listen 80;
    location /static/ {
        alias /opt/graphite/webapp/content/;
    }

    location / {
        include uwsgi_params;
        uwsgi_pass localhost:8080;
    }
}

just realized, I posted this under wrong project, I opened same issue under graphite-web. Sorry guys!


[8.x] Enforce implicit Route Model scoping

This PR implements the functionality requested in #32144.
With this PR, any Route (or route group) with the scoping action set to true will tell the framework to scope the second Eloquent model as such that it must be a child of the previous Eloquent model in the same route, without the need to provide a slug.
use App\Models\Post;
use App\Models\User;

Route::group(['scoping' => true], function () {
    Route::get('/users/{user}/posts/{post}', function (User $user, Post $post) {
        return $post;
    });
});

This is useful when:

You always want this behaviour everywhere, or in a subset of routes (extra / automatic safety net)
You don't want to look silly by specifying the id slug everywhere just to enable this behaviour
(Route::get('/users/{user}/posts/{post:id}', function (User ...)

While by itself this is only a somewhat useful feature, I think it would be quite useful when also providing the ability to enable it application-wide using a class-level property in the RouteServiceProvider, essentially making it very easy to either opt-in or opt-out, and to what extent:
    /**
     * Define the routes for the application.
     *
     * @param  \Illuminate\Routing\Router $router
     * @return void
     */
    public function map(Router $router)
    {
        $router->group([
            'namespace' => $this->namespace,
            'middleware' => 'web',
            'scoping' => $this->scoping,            // <----------------
        ], function ($router) {
            require base_path('routes/web.php');
        });

        $router->group([
            'middleware' => ['api'],
            'namespace' => 'App\Http\ApiControllers',
            'scoping' => $this->scoping,
            'prefix' => 'api/v1',
        ], function ($router) {
            require base_path('routes/api.php');
        });
    }
}

Actually, you don't need to give the model route key in order to scope the post to the given user
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Database/Eloquent/Model.php#L1933
You can just define your parameter with an extra :
Route::get('/users/{user}/posts/{post:}', function (User $user, Post $post) {
    // $post belongs to $user and route parameter is the default one
    return $post;
});

Maybe it just deserves to be documented ;-)

Not sure if trolling, @bastien-phi
That's how it works right now, which is documented. You are providing a key, but because the key you are providing is an empty string, it falls back to the Eloquent model key.
Furthermore, this still feels like a hacky way to enable this feature's behaviour. This PR enables the possibility to enable it application wide by default using a feature flag.

@claudiodekker
I was just saying that passing {post:} without slug will fallback to the model route key (not the model key) and this behavior is not documented. (solving You don't want to look silly by specifying the id slug everywhere just to enable this behaviour)

This PR enables the possibility to enable it application wide by default using a feature flag.

Indeed, not possible for now. Good job !

Made a few tweaks here:
You can now do:
Route::get('/posts/{post}/comments/{comment}', function (Post $post, Comment $comment) {
    return $comment;
})->scopeBindings();

Or:
Route::scopeBindings()->group(function () {
    Route::get('/posts/{post}/comments/{comment}', function (Post $post, Comment $comment) {
        return $comment;
    });
});


Finetuning on Llama 3.1 instruct version throws Untrained tokens found error

Replicating my issue from Discord here.
I'm following the provided notebook on my dataset, but it keeps throwing the following error:
Unsloth: Untrained tokens of [[128042, 128036]] found, but embed_tokens & lm_head not trainable, causing NaNs. Restart then add embed_tokens & lm_head to FastLanguageModel.get_peft_model(target_modules = [..., "embed_tokens", "lm_head",]). Are you using the base model? Instead, use the instruct version to silence this warning.
I generated data via llama only (so not sure why it is happening!)
See my notebook:
https://colab.research.google.com/drive/1YhKQk4lAhlO0rGwjlQQ6fiv680nimXXE?usp=sharing
Thanks for help!

@paraschopra Sorry on the delay - the issue is weirdly your dataset is using <|reserved_special_token_28|> and <|reserved_special_token_34|>?


Research data sources for token balances

We need to find possible data sources for fetching token balance(s) for an arbitrary address.

@shazarre shared the research on Slack and pinged G$ on Telegram.

[ ] Next step:  follow up with them until they migrate to the celoscan API (away from calling Forno directly).

As of today, G$ clients have still been making a lot of ethLogs request per minute in the last days (see chart, source: grafana).

Once they migrate, I’d expect that chart to reflect a significant drop in requests.

@shazarre: When you find a moment, could you link the Valora POC repo here and link the PRs you made to it (for future reference). Thanks!

Approaches have been presented in the PoC repository.


Author: bio display issue

The biography input doesn't seem to recognise line breaks. Lars's bio consists of two paragraphs--the front-end of the site only draws in the second.
Link: http://plus.zakgroup.co.uk/en/podium/issue-one-visual-culture/out-of-the-shadows-and-into-the-sunshine-a-reflection-on-the-contemporary-art-scenes-of-l.a-and-hong-kong
Front-end display and CMS input disparity:

Thanks, was indeed ignoring line breaks. Implemented a fix, seems to be working now.
Closing, will keep an eye on it.


Does KRANK work with long reads?

Hi,
I recently discovered CONSULT, CONSULT-II, and KRANK. I'm curious if these tools are compatible with long-read genomic sequencing reads (PacBio HiFi for my case), as the test data I've seen are all 150bp short reads.
Additionally, for contamination removal from genomic sequencing reads, would you recommend CONSULT-II or KRANK over CONSULT? Are there any noticeable improvements in accuracy or speed?
Thanks in advance for your insights!

Hi,

We haven't done any benchmarking with long reads, so I don't really have a strong insight. I believe it is worth testing, as I cannot think of any particular reason for it to not perform reasonably. But of course, I hesitate to recommend it for long reads without some benchmarking, which I hope to do soon.

I strongly recommend KRANK over CONSULT and CONSULT-II because I believe it is a better piece of software, and easier to use. Performance-wise, there wouldn't be a noticeable difference for contamination removal, but resource use (both memory and time) will be lower with KRANK.

I'd be happy to help if you have any issues or further questions.
Good luck!


TokeCredential support

Added support for tokencredential to allow extension usage on a non-Azure VM
Fix #2, #25

Hi, may I ask when this change will be released to Nuget.

@xinlifoobar the NuGet should be available in the next few days

Hi, I noticed you're referencing Azure.Identity 1.10.1, which has a high severity Remote Code Execution Vulnerability. The latest version is 1.10.3 which has a fix.


Show better errors if the user lacks network connectivity

Some of our users might access through a VPN, or might just lack connectivity to Coder. In these cases, we shouldn't display a connection failure error, and instead guide the user with a better error.

Closing because of inactivity. cc: @stirby


[Debugger Integration Test] Fix and enable debug pause test

Description:
The debug pause test is disabled with https://github.com/ballerina-platform/ballerina-lang/pull/35011 to avoid intermittent test failures during the build and, need to be enabled after fixing the root cause.
Describe your task(s)
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

We are closing this issue due to inactivity. If you need further assistance or have additional input, feel free to reopen it. Thank you for helping us maintain a relevant and focused issue list!


[iOS] :sparkles: Radius was added as a theme.

Issue

close #890

Overview (Required)

The title says it all.

@ry-itto @tkhs0604
For some reason, no reviewers were assigned, so I mentions it. :bow:


typings.json "main" field ignored?

I was just upgrading a very simple project to use typings with v0.6.8.
Directory structure:
dist/code-block-writer.js
src/code-block-writer.ts
code-block-writer.d.ts

I created this typings.json:
{
  "name": "code-block-writer",
  "main": "code-block-writer.d.ts",
  "ambientDependencies": { /* omitted */ }
}

And I have a package.json main field specified as "main": "dist/code-block-writer.js".
When installing this by running:
npm install<EMAIL_ADDRESS>--save
typings install npm:code-block-writer --save

I get the error:
typings ERR! message Unable to read typings for "code-block-writer". You should check the path is correct
typings ERR! caused by ENOENT: no such file or directory, open 'omitted-project-path\node_modules\code-block-writer\dist\code-block-writer.d.ts'

I notice that the main field in typings.json is completely ignored and I only see changes to this error message by changing the "main" field in package.json. Removing package.json's main field will make it use index.d.ts
Is this a bug? Or am I not understanding something?

Initially it was a feature, but mostly the result of a decision I made during coding the first version of Typings that didn't become apparent until recently. There's a couple of similar reports and 0.7 will likely change this behaviour and opt for using typings.json always as the override.
I'm sorry this has blocked you for now, I'll get around to fixing this ASAP.

Thanks! I agree with using typings.json always as the override. That makes the most sense to me.
For anyone reading this the obvious workaround is to put the definition file in the same folder with the same name (except with a .d.ts extension) as what is specified in package.json's main field. I'll wait until this is implemented though.

@blakeembrey thanks for fixing this one! Just tried it out now and works great.


Git Hook Invalid checksum

Describe the bug
I am getting an invalid checksum error when running gitleaks --verbose --redact --pretty.
To Reproduce
Run the following to reproduce:
https://github.com/bkuhlmann/dotfiles.git
cd dotfiles
gitleaks --verbose --redact --pretty

Expected behavior
I would expect this to come back as valid according to docs, especially when used in a Git Hook.
Screenshots

Basic Info (please complete the following information):

OS: Mac OS X 10.15.6 (19G2021)
Gitleaks Version: 6.1.2

Additional context
My only other guess is that this has something to do with my Global Git Config. Maybe there is a setting that conflicts with a Git Leaks configuration?
cc @zricethezav

:information_source: I'm closing this issue as it looks like this project has been abandoned and want to clean up my Inbox.

@bkuhlmann lol abandoned?

Im unable to reproduce your bug.

@zricethezav Ah, sorry. I was going through my Inbox and realized this was 25 days old and figured I should close this. 😅 Maybe this is an issue on my side still, not sure, but I'm fine with leaving this closed for now.


DP-91 Add logging aspect; Add string holder for confidential data

Enable automatic logging against a pointcut. This is intended for uniform logging against all application API methods (command and query services) but could also be used for other layers.
Because potential confidential information is passed via the API, a simple string holder is also added, which does not display the string content in its toString() method. This is intended to hold strings passed to API methods like passwords and credit card numbers.
Signed-off-by: Steffan Westcott<EMAIL_ADDRESS>

2 comments.

@clicktravel-basharat Purged unnecessary constructor, ready for re-review


Bug: Adding SimpleS3 core to a DI container w/o Logging added, throws

[x] I hereby verify that I am a sponsor.
Sponsorship is required before you can submit bug reports. See https://github.com/sponsors/Genbox

Describe the bug
Using the library in its simplest form (empty DI container) throws on some instantiations, as it cannot resolve any ILogger's.
How to reproduce?
var sc = new ServiceCollection();

var s3Core = SimpleS3CoreServices.AddSimpleS3Core(sc);
s3Core.UseAmazonS3();
s3Core.UseHttpClient();
sc.Configure<AmazonS3Config>(config =>
{
    config.Credentials = new StringAccessKey("MyKeyId", "MyAccessKey");
    config.Region = AmazonS3Region.EuWest1;
});

var provider = sc.BuildServiceProvider();
var myClient =  provider.GetRequiredService<IObjectClient>();

The above throws while creating IObjectClient, with:
System.InvalidOperationException: 'Unable to resolve service for type 'Microsoft.Extensions.Logging.ILogger`1[Genbox.SimpleS3.Core.Internals.Authentication.SigningKeyBuilder]'
while attempting to activate 'Genbox.SimpleS3.Core.Internals.Authentication.SigningKeyBuilder'.'

Expected behavior
Theoretically, it should be possible to run with no logging available. Logging could be encapsulated in a new custom MyLogger which attempts to find the correct logger when instantiated. If no logger is available, NullLogger can be used.

I have TODO proposed solutions:
Create a NullLogFactory
NullLogFactory inherits from ILoggerFactory. Ctor takes in a nullable ILoggerFactory and saves the reference in a field.
In the CreateLogger(string categoryName) method from the interface, I redirect the call to the field if it is not null. If it is, I simply return a NullLogger.Instance.
public class NullLogFactory : ILoggerFactory
{
    private readonly ILoggerFactory? _factory;

    private NullLogFactory(ILoggerFactory? factory = null)
    {
        _factory = factory;
    }

    public void Dispose()
    {
        _factory?.Dispose();
        GC.SuppressFinalize(this);
    }

    public ILogger CreateLogger(string categoryName)
    {
        return _factory == null ? NullLogger.Instance : _factory.CreateLogger(categoryName);
    }

    public void AddProvider(ILoggerProvider provider)
    {
        _factory?.AddProvider(provider);
    }
}

The factory is registered with TryAddSingleton(), so in the case user has called AddLogging() before SimpleS3, the null logger won't be added to the service collection.
In the case the user calls AddLogging after SimpleS3, then logging won't be activated as AddLogging() from Microsoft.Extensions.Logging also calls TryAddSingleton on their ILoggerFactory service.
Change APIs to receive a ProxyLogger that inherits from ILogger
This requires a change to all APIs and would break backward compatibility. This is pretty much the same as changing all ILogger services to be optional around the code. It would make code readability worse.

Note: Your NullLogFactory doesn't need to take a ILoggerFactory - in case it exists already, you don't add the factory and hence you don't receive it.. If you add it before, you still don't need it, as there is nothing to receive.
Best option is probably to require the user to add ILogging features.

Yeah, it probably is. For the common usecase I'm going to call AddLogging() on the users behalf. In the advanced scenario like the code you have, I'm going to require that logging is already added. Otherwise, I have to depend on the concrete logging from Microsoft directly and I'd like to avoid that when possible.


(Task) Update Backend to Utilize the New Database Schema

References user story #31
Requires Task #32 to be completed first.
Update how the Rust backend interacts with the database to pull the information.
Additionally, update the BookType type and DBItem struct to store the new information.

Turso database has been updated.
New schema:

id
title
author
totalPages
pagesRead
synopsis
link
list
label

INT
VARCHAR
VARCHAR
INT
INT
VARCHAR
VARCHAR
VARCHAR
INT


Action Buttons and click event on a message

@raix hi!
Explain please. When sending a message, you need to specify what to do when clicking on the message. I understand this is implemented in the phonegap-plugin-push, but how can I achieve this here? Perhaps via Meteor.call or Push.on...  In this case, it is necessary that the parameters be transmitted - this is very necessary.

A simple opening of the application is not suitable.

Also this topic was touched on the forum meteor.

Hi @atomoc I've answered this question before (getting too old to remember where)
So there are two types of notifications:

one is when the app is in the background or closed
one is when the app is open.

Now if the app is closed thats the easy case cause the os will take care of things.
If the app is open if would be pretty bad UX if the native notifications interrupted the user - that's where you come in... You have to handle the notifications when the app is open in a nice user friendly way - there is no single solution to it.
If you want to actually trigger a native notification then use the local notification system - there is a cordova plugin for it

It is important that this works when the application is closed. Cordova plugin is not suitable, because js does not work when the application is closed.
It is necessary for Push to handle the events that occur when you click on the notification (for example), is it really unrealistic?
In the future, I will most likely transfer the application to the React Native..., I just do not believe that this plug-in is not capable of it.
Just say, is it capable or not? I'm just tired of beating my head against the wall )

Hi @raix ,
I am implementing Action Buttons, and yes you have referenced it in your previous threads such as this, but it doesn't seem to have been implemented yet. Thus I tried this approach forking raix:push and implementing action buttons, but how do I run this locally? I am unable to find your build steps either.


Add Note about IIS Not supporting Single File Deployments

I think it would be useful to note that IIS does not support single file deployments.
I read the docs, thought, yes, I will try this with my new website and so published a single file to IIS.  When I tried to start the site, it then noted that Single File Deployments are not supported by IIS.

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

ID: e1932751-7c2b-ce92-936e-e97f8581d5fa
Version Independent ID: de677d1f-386a-e4c3-fdd0-6806b3ef2c0e
Content: Single file application - .NET
Content Source: docs/core/deploying/single-file.md
Product: dotnet-fundamentals
GitHub Login: @LakshanF
Microsoft Alias: lakshanf

Ping @LakshanF

cc @VSadov
@VSadov, can you comment on this please? @tdykstra, sorry for the delay

ping @VSadov

ping @VSadov

I would suggest:
"Note: Single File Deployments are only supported by IIS when using the Out of Process hosting model"


Update localization docs for v3.3

+1, thanks Jason, please make sure you verify the rendering in Sphinx once it is built on docs

Thanks, typos fixed @lindy65


Option to use current savepath always

A setting(checkbox) that allows for auto download to default path. (No dialogs on magnet click just start downloading).

:+1:


[Bug]: The dynamic import dependency module has been elevated to the entrance

System Info
System:
OS: macOS 15.1.1
CPU: (8) arm64 Apple M1
Memory: 90.00 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.11.0 - ~/.nvm/versions/node/v22.11.0/bin/node
Yarn: 1.22.22 - ~/.nvm/versions/node/v22.11.0/bin/yarn
npm: 10.9.0 - ~/.nvm/versions/node/v22.11.0/bin/npm
pnpm: 9.15.0 - ~/.nvm/versions/node/v22.11.0/bin/pnpm
bun: 1.1.27 - ~/.bun/bin/bun
Browsers:
Safari: 18.1.1
npmPackages:
@rspack/cli: 1.1.6 => 1.1.6
@rspack/core: 1.1.6 => 1.1.6

[ ]

Details
rspack.config.js
export default {
    entry: './src/index.js',
    experiments: {
        outputModule: true
    },
    output: {
        chunkFormat: 'module',
        chunkLoading: 'import',
        module: true
    },
    externalsType: 'module-import',
    externals: ['vue', 'axios'],
    optimization: {
        minimize: false
    }
};

src/index.js

console.log('>>>>>>>>>>>>> start');
function start () {
    import('./app.js');
}
console.log('>>>>>>>>>>>>> end');
import('axios');

src/app.js
import { version } from 'vue';

console.log(version);

Reproduce link
https://github.com/lzxb/rspack-dynamic-import-to-top
Reproduce Steps
pnpm i
pnpm build

As a temp workaround, you could explicitly declare the external type of the dynamic imported request to import xx, e.g.
externals: { vue: 'import vue', axios: 'axios' },

I'll take a look into the source code.

The  import type will lose all exports

The  import type will lose all exports

What does it mean.

Compile into library mode, use import type, all exports will be deleted

Could you update the reproduction demo.

Is it adding an import  type demo?

Compile into library mode, use import type, all exports will be deleted

To explain what does this mean is enough.

I updated. in feat-import branch.

no have export


Update Translations for Stationary RNG

Refactor
Update Translations
Autosave user setting (languages & shiny charm)

Thank you :)


Add music and sounds

Since the kernel's user API for ALSA seems undocumented and alsa-lib is LGPL, the current plan is to proxy alsa-lib into its own process and use IPC to direct audio to be played.
This issue is low-priority until some sounds or music need to be added to the player.


Cannot overwrite default options

We cannot overwrite the default options. We want to save a diff image if there is a similar output.
Line 178 in index.js _mergeDefaultOptions handle custom options.
We think this code is better:
if (optionsB.hasOwnProperty(value)) {                 optionsA[value] = optionsB[value];             }

Thank you for your support.
Do you update version 2.0.0? What is the best and fastest way to fix it for everyone?

Hi @jvornkahl2222, the patch committed fixes your issue. However the build is failing for other reasons so when I have some free time to make the build green, I'll push a minor release.
In the meantime, you can update your package.json to point at this commit.

Released in 2.0.1


Understanding JSON in Android Studio

Topic Suggestion
Understanding JSON in Android Studio
Writing sample(s):
https://www.section.io/engineering-education/authors/meshack-koros/
Proposed title of article
Understanding JSON in Android Studio
Proposed article introduction
In order for an android application to interact with the database, the program in the xml files should be executed and read by the server. The server cannot recognize a xml file thus the file is converted to JSON.
JSON is a light weight and much human readable form.  In this article, we will discuss how the file is converted from xml to JSON format. Furthermore, we will discuss different classes of JSON and how we can manipulate them.
We will also discuss the two JSON structures which include a collection of keys and a list of values. Moreover, we will discuss the main JSON components which include JSON Objects(), JSON Array(),  key and value.
The user will also get to understand JSON parsing in Android and JSON parsing Methods.
Key takeaways
By the end of the article the user will be able to understand the following

JSON classes and structures
Main JSON components
JSON parsing in Android and JSON methods

References
N/A

Thank you for your response and we thank you for submitting your topic. After some careful consideration it struck us that this topic may be a bit over saturated throughout other blog sites and official documentations as previously mentioned on your topic form by our content moderator.
We typically refrain from publishing content that is covered widely on the net or other blogs. As we're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts.
We believe this is the best way for students to build a great portfolio (for potential employers) is by building what does not exist and what can provide the most value.
You are more than welcome to pursue another more in depth topic


Redeploy ClimSim with only 50 workers, due to caching errors

See discussion in #36.

The test Dataflow jobs deployed from this PR were correctly assigned max_num_workers=50 (based on the label here).

but I now realize that this label will not be discoverable (with the current implementation from #37) on push events... 🤔

Ok! The rewritten workflow logic successfully deployed the test jobs to dataflow with max_num_workers=50. I believe this logic should now work for push events as well, so going to merge this and hope we get the desired result (production runs of both recipes with only 50 workers each).


feat: 数据源级租户支持

PR 类型

[ ] 新 feature
[ ] Bug 修复
[x] 功能增强
[ ] 文档变更
[ ] 代码样式变更
[ ] 重构
[ ] 性能改进
[ ] 单元测试
[ ] CI/CD
[ ] 其他

PR 目的

解决方案

PR 测试

Changelog

模块
Changelog
Related issues

其他信息

提交前确认

[x] PR 代码经过了完整测试，并且通过了代码规范检查
[ ] 已经完整填写 Changelog，并链接到了相关 issues
[ ] PR 代码将要提交到 dev 分支

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.3 out of 5 committers have signed the CLA.:white_check_mark: xtanyu:white_check_mark: ppxb:white_check_mark: weirantongxue:x: AiMing317:x: Charles7cYou have signed the CLA already but the status is still pending? Let us recheck it.


Black flashing when using white theme

When using the extension with the white theme, the screen is flashing black shortly when loading the new tab page.
Maybe CSS for the black theme is applied on load and the white theme CSS is overwriting it later on?

Maybe CSS for the black theme is applied on load and the white theme CSS is overwriting it later on?

Actually, that's exactly what's happening! All the CSS is already embedded into the page but the dark theme is loaded by default. Once the JS loads we wait for chrome.storage.sync.get to get the users theme setting and apply a class to the body. That's why there's a flash of the dark theme.
I tried other techniques for loading the theme styles but this has been the fastest so far while still allowing the user to choose a theme. I'm keen to hear any suggestions about this though :smiley:
The logic is in src/loader.js if you're curious.
On lower powered machines or when there's a lot of open tabs etc. I've found the flash is more frequent. I have some ideas about how to reduce this but I'm not sure it can be eliminated altogether.

Thanks for the information!
Makes total sense and I'm not quite sure how to improve it.
You could argue that applying the bright theme by default is better because the usual browser background (eg. current webpage) is probably rather bright than dark and as a result the flash when loading the dark theme later on wouldn't be that "heavy". But I'm not sure whether that really makes sense 😊
On the other side: You're probably assuming that more people use the black theme, which is why loading that by default is preferable?

On lower powered machines or when there's a lot of open tabs etc. I've found the flash is more frequent.
Yep, you're right. I'm not always experiencing it, just sometimes.

It's been a while but even with the latest changes in the next branch, there hasn't been much improvement in theme loading speed. Although I did change settings storage from chrome.storage.sync to chrome.storage.local which saw a small performance improvement (which means settings will not be synchronised to a user's Google account).
There have been many performance improvements to speed up the initial page launch so hopefully flashes are less prominent. But due to the nature of the delay between loading the page before asynchronously getting the user theme setting and applying a class to the document body, it's probably going to remain an issue.
I did consider using a background script to handle settings data but messaging between the new tab page and the background script also has a delay which can result in a flash. Keeping even a blank persistent background script open does have the benefit of forcing Chrome to keep the extension's assets in memory (faster new tab open) but has the downside of chewing up memory so I decided against it.
About which theme should be the default, my thinking here is dark theme should remain the default. If you get a flash of dark before loading a light theme it's not a big deal. However, if it's the middle of the night and you get a flash of white before loading a dark theme it can be blinding! I have some ideas for better theme customisation in future but it's likely the default page colour will be dark to prevent blinding users :sun_with_face:
Going to close the issue for now but might revisit this in future!

So... after thinking more about the issue I was able to properly fix it!
For whatever reason I was stuck thinking I had to use the async chrome.storage API, but as it turns out using good old localStorage was the answer. Because localStorage is sync it blocks the page from rendering until it's done, so no more flash of default theme colour!
Since the background script idea was also on my mind, it's been added as an experiment so it can be used in more scenarios before making a decision whether to keep it or not. In my local testing memory consumption never went over about 80 Mb (after the browser's garbage collection has run) so maybe it's acceptable in return for the perceived performance boost.
Both these changes are available in https://github.com/maxmilton/new-tab/releases/tag/v0.16.3.


Why does the PSNR keeps decreasing when training ESRGAN?

Hello, first of all thank you for your open source project。
I encountered a problem when I tried to reproduce your results about ESRGAN。
Mydataset is DF2K

First I trained a RRDBNET_X4 model  from scratch;  After 220k iters, I get 27.0 PSNR-RGB(28.8 PSNR-Y) on set14 (Green Curve ).
Then I use that model to train ESRGAN, but the psnr keeps decreasing over time(Black Curve), this problem also happened on set5.

so there are some questions about this:

Is this situation normal？ Did i do something wrong？
the 28.99 PSNR-Y in your paper  is your RRDBNET's result or ESRGAN's result?
What's your  PSNR curve of ESRGAN like？ What's your final PSNR-Y of ESRGAN on set14?

Hi @lightfate

GAN-based models such as SRGAN, ESRGAN produces lower PSNR values. And PSNR is not a good metric (reflecting the visual quality) for GAN0-based models. So when you train ESRGAN, the PSNR will decrease.
In the paper, RRDB  indicates the model trained with L1/L2 loss, not the gan loss.
You can obtain ESRGAN training curves in https://wandb.ai/xintao/basicsr/runs/1qezt05j?workspace=user-xintao
note that the dataset is DIV2K

Thank you～


netdata: facilitate building netdata with cloud support

This PR adds a withCloud option to the netdata package. When enabled it allows the netdata agent to communicate with the netdata cloud.
Other than that, we unconditionally wrap the netdata-claim.sh script with a path to openssl and no longer remove the sbin output as it is required by the script.

Motivation for this change
The current netdata package does not support connecting to the netdata cloud.
There has been a packaging request for netdata with cloud support in #91549.
#92291 was merged in preparation to this PR.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
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 nixpkgs-review --run "nixpkgs-review wip"
[x] 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.

This PR also adds a new file for the custom version of mosquitto used by netdata. I was unsure if it makes sense for that package to have a meta section, so I have left it out of the initial PR.

@jtojnar I really don't want to pester you, but maybe it would be possible for you to review this PR, as you have already approved and merged #92291? Thank you for your hard work on the Nixpkgs project!

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 92782 run on x86_64-darwin 1

1 package built:

netdata

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 92782 run on x86_64-darwin 1

1 package built:

netdata

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 92782 run on x86_64-linux 1

1 package built:

netdata

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 92782 run on x86_64-linux 1

1 package built:

netdata

Hi guys, ACLK-NG has been merged and is present in current nightlies and will be present in the next Netdata release. Currently is a fallback for when ACLK LEgacy can't be built (e.g. missing dependency) or can be enabled by passing --aclk-ng parameter to the installer.

@leotaku the build is failing
@ofborg build

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 92782 run on x86_64-linux 1

1 package built:

netdata

The new Netdata release (1.30.0) already has ACLK-NG support. This means that this pull request is no longer relevant.