Cross compile to Windows from Linux gives error in pcap_windows.go for arpscan

Running:
GOOS=windows GOARCH=amd64 go build github.com/google/gopacket/examples/arpscan
Result:
src/github.com/google/gopacket/pcap/pcap_windows.go:14:10: undefined: Handle
What is the best resolution for this?

I don't have a resolution, but would like to mention that I am I'm trying to run the examples as well and am getting the same error.
I'm running windows/amd64
I'm not sure why it can't see Handle in pcap.go

Unfortunately, I don't have a windows machine, so debugging/fixing this is going to be difficult on my end... if anyone with a Windows box is able to step up and look into things, it'd be greatly appreciated.

@gconnell Welp, I managed to get the examples running by following https://stackoverflow.com/questions/38047858/compile-gopacket-on-windows-64bit
Which I found via issue #159. Honestly, I should have read pcap/doc.go.

Well crapola. I swear I searched and searched for an answer before I filed a bug. Thanks for tracking it down.


re-written FDSys scraper

Per #165 (bulk data), I basically rewrote fdsys.py.
It now can download bulk data files using the bulk data sitemaps, efficiently keeping them up to date by downloading only what's changed. It's also a bit cleaner / more maintainable code. And I dropped some code no one was using (unless someone chimes in on #169).
The command-line arguments have changed. I think I was the only one actually using this module though.
Before merging someone will probably say what about tests? I also need to update GovTrack to use the new command line arguments.

Why am I not using https://www.gpo.gov/smap/bulkdata/sitemapindex.xml? h/t @crdunwel


Crash when the blocknumber is not provided

It's supposed to use the latest block when no block number is provider.

Also the campaign does not end automatically when there is error. I have to cancel it myself to stop it running.

This is fixed in #9. Please use fuzzland/ityfuzz latest image.
docker pull fuzzland/ityfuzz:latest


[Bug]: Authenticated API not correctly attaching self-signed certificates

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Currently, when we have an API that requires authentication through self-signed certificates, even if we attach our PEM file, Appsmith is not able to read it and displays the following error:
org.springframework.web.reactive.function.client.WebClientRequestException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

Example video:
https://user-images.githubusercontent.com/114161539/226468450-24550d06-1107-422b-a0e2-ed270b90ce3f.mp4
Steps To Reproduce

Connect to a self-signed certificate API. You can use this Python script to generate the server with its PEM certificates.

from flask import Flask, request, jsonify
import ssl
import os
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography import x509
from cryptography.x509.oid import NameOID
from cryptography.hazmat.primitives import serialization
from datetime import datetime, timedelta
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.backends import default_backend

app = Flask(__name__)

cert_path = os.path.join(os.path.dirname(__file__), 'cert.pem')
key_path = os.path.join(os.path.dirname(__file__), 'key.pem')
if not os.path.exists(cert_path) or not os.path.exists(key_path):
   print("Generando certificado y clave...")

   private_key = rsa.generate_private_key(
       public_exponent=65537,
       key_size=2048
   )

   subject = issuer = x509.Name([
       x509.NameAttribute(NameOID.COMMON_NAME, u"localhost")
   ])
   cert = x509.CertificateBuilder().subject_name(
       subject
   ).issuer_name(
       issuer
   ).public_key(
       private_key.public_key()
   ).serial_number(
       x509.random_serial_number()
   ).not_valid_before(
       datetime.utcnow()
   ).not_valid_after(
       datetime.utcnow() + timedelta(days=365)
   ).add_extension(
       x509.SubjectAlternativeName([x509.DNSName(u"localhost")]),
       critical=False,
   ).sign(private_key, hashes.SHA256(), default_backend())

   with open(cert_path, 'wb') as f:
       f.write(cert.public_bytes(encoding=serialization.Encoding.PEM))
   with open(key_path, 'wb') as f:
       f.write(private_key.private_bytes(
           encoding=serialization.Encoding.PEM,
           format=serialization.PrivateFormat.TraditionalOpenSSL,
           encryption_algorithm=serialization.NoEncryption()
       ))
   print("Certificate and key generated at the following location:")
   print(cert_path)
   print(key_path)

context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain(cert_path, key_path)

users = [
   {"username": "user1", "password": "pass1"},
   {"username": "user2", "password": "pass2"}
]

def authenticate(username, password):
   for user in users:
       if user["username"] == username and user["password"] == password:
           return True
   return False

@app.route('/protected')
def protected():
   auth = request.authorization
   if not auth or not authenticate(auth.username, auth.password):
       return jsonify({'error': 'Unauthorized access'}), 401
   return jsonify({'message': 'Welcome to the protected area!'})

if __name__ == '__main__':
   app.run(ssl_context=context)

Note: install these libraries: pip install flask  &&  pip install cryptography
2. Run this curl command from the directory where you executed the Python code to verify a successful connection.
3. Expose port 5000 through Ngrok to connect to it from Appsmith.
4. Create your data source in Appsmith with an authenticated API.
5. In the URL field, put the URL that Ngrok gave you, plus this endpoint: /protected.
6. Attach the cert.pem certificate generated by the Python code.
Public Sample App
No response
Environment
Production
Issue video log
No response
Version
Appsmith v1.9.12-SNAPSHOT/ Cloud Appsmith Community v1.9.12

This issue does not seem valid with v1.9.19. To verify I have followed all the steps as provided in the description. I think there is a minor error in the way the test is described. Apart from attaching the self signed certificate we also need to provide the username and password info via the REST API header which turns out to be Authorization: Basic dXNlcjE6cGFzczE= , e.g. the curl request would look like:
curl --cacert cert.pem --header "Authorization: Basic dXNlcjE6cGFzczE=" https://localhost:5000/protected

The same works with Appsmith as well:

This issue does not seem valid with v1.9.19. To verify I have followed all the steps as provided in the description, except Appsmith instance was running on my local. I think there is a minor error in the way the test is described. Apart from attaching the self signed certificate we also need to provide the username and password info via the REST API header which turns out to be Authorization: Basic dXNlcjE6cGFzczE= , e.g. the curl request would look like:
curl --cacert cert.pem --header "Authorization: Basic dXNlcjE6cGFzczE=" https://localhost:5000/protected

Also, as per my understanding, we cannot use ngrok with the python server since ngrok would expose a different endpoint for which we don't have the self signed certificate (the Python script provided creates the self signed certificate for the localhost endpoint).
The same works with Appsmith as well:


Add Nibble/DSK Image support

Is your feature request related to a problem? Please describe.
Depends on how you define problem :) The problem is Apple2-IO-RPi does not currently support Nibble/DSK images which are useful for software which can't be easily loaded onto a ProDOS volume.
Describe the solution you'd like
Implement Nibble/DSK support for DOS 3.3 images, see suggestions on method below.
Additional context
I'm a bit naive with Apple II design...but I think this is doable with software/firmware only changes? Did some research and it looks like an approach similar to the open source Pseudo-Disk II would be possible. That project supports both a ProDOS and Nibble mode. The general approach to Nibble support is described as "Boot code identical to one found in a standard DISK II controller card is mapped into the Cx00-CxFF memory space. AVR interprets reads from the addresses responsible for disk operation. For example it notices attempts to position the head and adds a offset to the beginning of the image." In the case of the Apple2-IO-RPi it would seem that the Boot ROM could load the Disk II card code into memory, then a driver on the Pi side (instead of the AVR used by Pseudo-Disk II) could interpret the calls for disk operation and read/write from a Nibble (or DSK) file.

The Raspberry Pi running Linux is not particularly well suited for realtime. The Pseudo-Disk II concept really requires different hardware with a microcontroller. This request would be a good candidate for a Raspberry Pi Pico but I believe someone else is already working on a project for that. This project was designed for command and response, the Apple II sending commands and the Raspberry Pi responding. The focus going forward is to increase what those commands are from the existing ReadBlock, WriteBlock, Execute, Shell, LoadFile etc. and add on things like LoadImage, Compile, WGet, VNC, etc.

Moved to Discussions here: https://github.com/tjboldt/Apple2-IO-RPi/discussions/68


Avoid race conditions in GC_Example test

Pull Request Description
Re-enables https://github.com/enso-org/enso/pull/10602/files#r1690919173 - uses IO.println to allow us to see what the CI actually does.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] All code follows the
Scala,
Java,
[x] Unit tests are being analyzed

First run:

linux is fine
mac is fine
windows is fine

OK, let's try to schedule another run.

Another successful run:

correct on Linux
correct on Mac
correct on Windows

What's next?

We might hit the GC problem with Native Image tests:
DEBUG main_internal:Running process for the output.{command=Command:
	ENSO_DATA_DIRECTORY="/Users/runner/work/enso/enso/built-distribution/enso-engine-2024.3.1-dev-macos-amd64/enso-2024.3.1-dev" "/Users/runner/work/enso/enso/built-distribution/enso-engine-2024.3.1-dev-macos-amd64/enso-2024.3.1-dev/bin/enso" "--run" "/Users/runner/work/enso/enso/test/Base_Tests"
	with environment overrides:
		ENSO_DATA_DIRECTORY=/Users/runner/work/enso/enso/built-distribution/enso-engine-2024.3.1-dev-macos-amd64/enso-2024.3.1-dev}: ide_ci::program::command: Spawning.

I guess I should enable log output, at least.

All checks have passed including the native image run on Linux with output.

And we have a test failure on Linux:
 INFO ide_ci::program::command: enso ℹ Still 10418 resources to clean up...
 INFO ide_ci::program::command: enso ℹ Still 10418 resources to clean up...
 INFO ide_ci::program::command: enso ℹ Still 10418 resources to clean up...
 INFO ide_ci::program::command: enso ℹ Still 10418 resources to clean up...

I am inclined to believe the test is wrong...

Previous runs blocked by

#10695

let's hope we merge by end of this week


Generate Video from images

Can this library create a video from images?

this lib create a video from image.
https://github.com/MasayukiSuda/ImageToVideoAndroid

I tried using it.. it doesn't work for multiple images

I tried using it.. it doesn't work for multiple images


[Introduction] Smart Monkey - free recorder for puppeteer

Hi,
This is not an issue but I think it is worth to intro this tool here. If not, please close the issue.
I have added a functionality to Smart Money for exporting a project to Puppeteer code. Here is the video for demo: https://www.youtube.com/watch?v=eBzK85MOo-A
In the most of cases, you don't need to write any line of code for creating a test suite.
If you have any question, please comment!
Sincerely,
Thach

This is pretty cool indeed! I'll play around with this a bit once I have some free time :)


check pkg pr new

Description

Linked Issues

Additional Context

[!TIP]
The author of this PR can publish a preview release by commenting /publish below.

/publish


Terraform fails to update theme

When deploying an updated theme using terraform-provider-fusionauth, the following error occurs:
An argument named “account_delete_webauthn_passkey” is not expected here.
and other errors for missing WebAuthn related template files.
terraform-provider-fusionauth version:  0.1.54
terraform provider --> https://github.com/gpsinsight/terraform-provider-fusionauth
complete log with errors --> https://gist.github.com/chimericdream/f00180e066c99285994ee9f660d4d387
Additionally, the terraform plugin may required an update to support themes for versions 1.40.x. found here terraform-provider-fusionauth/fusionauth/resource_fusionauth_themes.go line 8
"github.com/hashicorp/terraform-plugin-sdk/v2/diag"

That plugin version is quite old... have you tried updating?

I updated to the latest 0.1.76 version of the plugin, but it still has the issue. The problem is that the theme resource in the provider has not been updated to include the six new WebAuthN related templates.


Update GatewayAPIHandler.cs

messageId is bigger then int32.

@kit230986 Thank you! The fix is released in v1.1.1


Formatting selection doesn't work

If I select some part of a php-document and run a format on that selection I get an error message.

Is this expected or an error? Is there any way to get partial formatting using this plugin? :)
Debug is checked but no output is shown in the debug console:

This extension does not implement a by selection formatter.

@valeryan Ok. Is it possible to implement or is it a limitation with phpcs?

I am sure it's possible. I am not sure when I will have the time to look into it.

@emil-nasso I have not had a chance to work on a format selection implementation yet. I have read back through your comments and I want to point out that the debug options use console.log so you will see all the information by opening help>Toggle Developer Tools. I am still curious why you have a format selection option on your context menu. I don't have that but it appears like it tries to use my extension to format. Do you have an extension adding that functionality?


segfault in changegroupactive

Hyprland Version
Hyprland, built from branch main at commit b10cae3010f5b1d853eb13f8a591ee10d67fe51e dirty (decos: groupbar mouse interaction (3102)). Tag: v0.29.0-7-gb10cae30
Bug or Regression?
Bug
Description
segfault
How to reproduce
I don't know. it happened randomly while doing nothing special.
Crash reports, logs, images, videos
Still can't attach the file.. pasting
--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Well this is awkward.

Hyprland received signal 11 (Segmentation fault)

Version: b10cae3010f5b1d853eb13f8a591ee10d67fe51e
Tag: v0.29.0-7-gb10cae30

System info:
	System name: Linux
	Node name: axion
	Release: 6.4.12-arch1-1
	Version: #1 SMP PREEMPT_DYNAMIC Thu, 24 Aug 2023 00:38:14 +0000

GPU:
	00:02.0 VGA compatible controller [0300]: Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])
	DeviceName: VGA compatible controller

os-release:
	NAME="Arch Linux"
	PRETTY_NAME="Arch Linux"
	ID=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://archlinux.org/"
	DOCUMENTATION_URL="https://wiki.archlinux.org/"
	SUPPORT_URL="https://bbs.archlinux.org/"
	BUG_REPORT_URL="https://bugs.archlinux.org/"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=archlinux-logo

Backtrace:
	#0 | Hyprland(_Z12getBacktracev+0x62) [0x55aa57be5db2]
		??
		??:0
	#1 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x791) [0x55aa57bb5f21]
		??
		??:0
	#2 | Hyprland(_Z25handleUnrecoverableSignali+0x44) [0x55aa57b47de4]
		??
		??:0
	#3 | /usr/lib/libc.so.6(+0x3e710) [0x7f83d3e3e710]
		??
		??:0
	#4 | /usr/lib/libwayland-server.so.0(wl_resource_instance_of+0x10) [0x7f83d489dd40]
		??
		??:0
	#5 | /usr/lib/libwlroots.so.12032(wlr_seat_keyboard_enter+0xdf) [0x7f83d495c92f]
		??
		??:0
	#6 | Hyprland(_ZN11CCompositor12focusSurfaceEP11wlr_surfaceP7CWindow+0xc8) [0x55aa57b4dc88]
		??
		??:0
	#7 | Hyprland(_ZN11CCompositor11focusWindowEP7CWindowP11wlr_surface+0x135) [0x55aa57b52665]
		??
		??:0
	#8 | Hyprland(_ZN7CWindow15setGroupCurrentEPS_+0x2b2) [0x55aa57b7c2d2]
		??
		??:0
	#9 | Hyprland(_ZNSt17_Function_handlerIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEPS6_E9_M_invokeERKSt9_Any_dataOS5_+0x63) [0x55aa57c2f3c3]
		??
		??:0
	#10 | Hyprland(_ZN15CKeybindManager14handleKeybindsERKjRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_RKibj+0xb5e) [0x55aa57c292ce]
		??
		??:0
	#11 | Hyprland(_ZN15CKeybindManager10onKeyEventEP22wlr_keyboard_key_eventP9SKeyboard+0x7b1) [0x55aa57c2df91]
		??
		??:0
	#12 | Hyprland(_ZN13CInputManager13onKeyboardKeyEP22wlr_keyboard_key_eventP9SKeyboard+0x9c) [0x55aa57c3eb3c]
		??
		??:0
	#13 | Hyprland(_Z13handleWrappedP11wl_listenerPv+0x40) [0x55aa57bf76b0]
		??
		??:0
	#14 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x7f83d489f01e]
		??
		??:0
	#15 | /usr/lib/libwlroots.so.12032(wlr_keyboard_notify_key+0x26) [0x7f83d49747b6]
		??
		??:0
	#16 | /usr/lib/libwlroots.so.12032(+0x5ace3) [0x7f83d4942ce3]
		??
		??:0
	#17 | /usr/lib/libwlroots.so.12032(+0x59d2c) [0x7f83d4941d2c]
		??
		??:0
	#18 | /usr/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x7f83d48a0ae2]
		??
		??:0
	#19 | /usr/lib/libwayland-server.so.0(wl_display_run+0x27) [0x7f83d48a12d7]
		??
		??:0
	#20 | Hyprland(main+0xac6) [0x55aa57b37346]
		??
		??:0
	#21 | /usr/lib/libc.so.6(+0x27cd0) [0x7f83d3e27cd0]
		??
		??:0
	#22 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f83d3e27d8a]
		??
		??:0
	#23 | Hyprland(_start+0x25) [0x55aa57b47c85]
		??
		??:0

Log tail:
[LOG] Registered signal for owner 55aa5ab1aac0: 55aa5ad15610 -> 55aa5ab1aba0 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 55aa5ab1aac0: 55aa5ad15650 -> 55aa5ab1ac08 (owner: SurfaceTreeNode)
[LOG] Added a new subsurface 55aa5ad0bc20
[LOG] Registered signal for owner 55aa5ad1c010: 55aa5ad18ee0 -> 55aa5ad1c028 (owner: Subsurface)
[LOG] Registered signal for owner 55aa5ad1c010: 55aa5ad18ef0 -> 55aa5ad1c090 (owner: Subsurface)
[LOG] Registered signal for owner 55aa5ad1c010: 55aa5ad0bca0 -> 55aa5ad1c0f8 (owner: Subsurface)
[LOG] Creating a surfaceTree Root! (pWindow: 55aa5a862480)
[LOG] XDG Popup got assigned a surfaceTreeNode 55aa5ab1aac0
[LOG] Subsurface 55aa5ad0bc20 mapped
[LOG] Registered signal for owner 55aa5ac14b48: 55aa5ad18f10 -> 55aa5ac14b50 (owner: CWLSurface)
[LOG] CWLSurface 55aa5ac14b48 called init()
[LOG] Registered signal for owner 55aa5ac14b40: 55aa5ad18f00 -> 55aa5ac14bb8 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 55aa5ac14b40: 55aa5ad18ed0 -> 55aa5ac14c20 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 55aa5ac14b40: 55aa5ad18f10 -> 55aa5ac14c88 (owner: SurfaceTreeNode)
[LOG] Creating a subsurface Node! (pWindow: 55aa5a862480)
[LOG] XDG Popup unmapped
[LOG] Callback 55aa5ac14c48 -> 55aa5ac14c40, SurfaceTreeNode removed.
[LOG] Callback 55aa5ac14cb0 -> 55aa5ac14ca8, SurfaceTreeNode removed.
[LOG] Callback 55aa5ac14be0 -> 55aa5ac14bd8, SurfaceTreeNode removed.
[LOG] Callback 55aa5ac14b78 -> 55aa5ac14b70, CWLSurface removed.
[LOG] CWLSurface 55aa5ac14b48 called destroy()
[LOG] SurfaceTree Node removed
[LOG] Callback 55aa5ad1c120 -> 55aa5ad1c118, Subsurface removed.
[LOG] Callback 55aa5ad1c050 -> 55aa5ad1c048, Subsurface removed.
[LOG] Callback 55aa5ad1c0b8 -> 55aa5ad1c0b0, Subsurface removed.
[LOG] Callback 55aa5ab1abc8 -> 55aa5ab1abc0, SurfaceTreeNode removed.
[LOG] Callback 55aa5ab1ac30 -> 55aa5ab1ac28, SurfaceTreeNode removed.
[LOG] Callback 55aa5ab1ab60 -> 55aa5ab1ab58, SurfaceTreeNode removed.
[LOG] SurfaceTree Node removed
[LOG] Callback 55aa5ad19390 -> 55aa5ad19388, CWLSurface removed.
[LOG] CWLSurface 55aa5ad19360 called destroy()
[LOG] Destroyed popup XDG 55aa59f5e430
[LOG] Callback 55aa59f5e688 -> 55aa59f5e680, HyprPopup removed.
[LOG] Callback 55aa59f5e620 -> 55aa59f5e618, HyprPopup removed.
[LOG] Callback 55aa59f5e5b8 -> 55aa59f5e5b0, HyprPopup removed.
[LOG] Callback 55aa59f5e550 -> 55aa59f5e548, HyprPopup removed.
[LOG] Callback 55aa59f5e4e8 -> 55aa59f5e4e0, HyprPopup removed.
[LOG] Callback 55aa59f5e480 -> 55aa59f5e478, HyprPopup removed.
[LOG] Searching for matching rules for firefox (title: Mozilla Firefox)
[LOG] Window rule minsize 800 600 -> firefox matched 55aa5a862480 [Mozilla Firefox]
[LOG] Window rule noblur -> firefox matched 55aa5a862480 [Mozilla Firefox]
[LOG] Window 55aa5a862480 set title to Mozilla Firefox
[LOG] Searching for matching rules for firefox (title: Roland - Backstage — Mozilla Firefox)
[LOG] Window rule minsize 800 600 -> firefox matched 55aa5a862480 [Roland - Backstage — Mozilla Firefox]
[LOG] Window rule noblur -> firefox matched 55aa5a862480 [Roland - Backstage — Mozilla Firefox]
[LOG] Window 55aa5a862480 set title to Roland - Backstage — Mozilla Firefox
[LOG] Starting a swipe from 1
[LOG] Set keyboard focus to surface 55aa5b532110, with window name: foot
[LOG] Ended swipe to the right
[LOG] Keybind triggered, calling dispatcher (64, , 93)

last log:
[LOG] Keybind triggered, calling dispatcher (64, , 93)

what dispatcher was that? either moveIntoGroup or changeGroupActive

it's bound to changegroupactive,b

can you repro this?
what windows were in the group?

Same thing here.

how is this happening?
I can't repro

But im using hyprland-nvidia patch, problems are kind off expected since it's not an official patch

likely not related?

can you repro this? what windows were in the group?
?

@MightyPlaza likely related to your MR, but I can't repro either.

I have no idea how to repro unfortunately

btw, the segfault i was facing was purely related hyprland-nvidia patch, solved it by downgrading to v0.28, nothing to do with this issue.

Probably caused by this assertion in wlroots
	assert(wl_resource_instance_of(resource, &wl_keyboard_interface,
		&keyboard_impl));

from
seat_client_from_keyboard_resource
wlr_seat_keyboard_enter
default_keyboard_enter
wlr_seat_keyboard_notify_enter
CCompositor::focusSurface(wlr_surface*, CWindow*)
CCompositor::focusWindow(CWindow*, wlr_surface*)
CWindow::setGroupCurrent(CWindow*)

to me sounds insane. As if memory got corrupted or a high energy cosmic particle hit your ram.

sounds like a data race. does nvidia patch do something majorly different than gbm?

Probably caused by this assertion in wlroots
	assert(wl_resource_instance_of(resource, &wl_keyboard_interface,
		&keyboard_impl));

from
seat_client_from_keyboard_resource
wlr_seat_keyboard_enter
default_keyboard_enter
wlr_seat_keyboard_notify_enter
CCompositor::focusSurface(wlr_surface*, CWindow*)
CCompositor::focusWindow(CWindow*, wlr_surface*)
CWindow::setGroupCurrent(CWindow*)

If wlroots is the culprit - shouldn't the issue be closed?


Checking convergence

Initial discussion on how to check convergence is here: https://github.com/srlanalytics/bdfm/commit/9d9d65c3604cf625bb593af7f8855b3bf0c44eb1
A formal and automated convergence would hugely beneficial, perhaps with the coda package, or with a simpler ad test? To be investigated.

move discussion from code
CHS
I would really like to have a formal test to tell me if convergence has reached or not!
If it is really necessary to look at this plots, we should have a function that makes all of the following functions
SETH
A few notes on this:
(1) Assessing convergence via a formal test isn't trivial: there is a nice overview here: http://www.mcmchandbook.net/HandbookChapter6.pdf. There is already an R package to do this --- the coda pacakge. We could introduce this as a dependency. However, I'm not inclined to make bdfm yet more complicated and draw out the project. Interested users should be albe to plug stored simulation values into coda functions to test convergence. However, looking at the trace plot works well, is simple, and obvious.
(2) There are a LOT of parameters that would need checking --- generating plots for all of them may not be very practical. For example, in a model with 20 observables, 2 factors and 3 lags we would have 40 loadings, 20 shocks to the observation equation (this matrix is diagonal), 12 transition equation parameters, and 4 shocks to the transition equation (this matrix is square) for a total of 76 parameters to check, and that's a pretty small model.
(3) A lot of convergence testing is used to update the mixing distribution in the Metropolis Hastings algorithm used to generate MCMC simulations. We just use Gibbs sampling, meaning the probability of accepting a draw is 1 and there is nothing to tweak. This is not necessarily the most efficient approach, but is simple, doesn’t require user input, and works well most of the time.
CHS
A lot of questions here: Why do things look good, how could I tell if they weren't, and mostly: how could I change the defaults to make them better
SETH
"Looking good" means sampling from a stationary distribution --- i.e. we're drawing values around a posterior mean. Not good would be something obviously non stationary, or with obvious breaks in the model jumping between 2 or more different mean parameter values. It's not always obvious to me how one might change defaults to make things look better --- good data is probably the biggest issue. Another time issues come up is when we use priors to force the model towards somewhere it doesn't want to be. Instead of gradually shifting towards the prior distribution, it is often the case that at a certain point the model will "jump" to a new distribution that satisfies the priors. If our priors put it right on edge, it might jump between models making our posterior estimates invalid. There's no obvious way to control for this that I'm aware of.. it's just guess and check with priors until you get somewhere where the model is "happy".

I played around a lot, and I think you can work easily without checking the convergence. So we can advertise the convergence plots as something slightly more advanced.
I dont' think we need coda support in the first CRAN version. Let's close this for now.


Anti-Aliasing option of Image is confusing

The Anti-Aliasing option of certain Image(wand)  affects globally to the Image(wand),
NOT just the Fonts.
BaseImage.font_antialias should be renamed to BaseImage.antialias.
MagickSetAntialias() and MagickGetAntialias() are effective to all operations applied on specfic Image(wand).

Thanks for suggestion!  I will make .font_antialias deprecated.

Renamed to BaseImage.antialias, and marked BaseImage.font_antialias as deprecated.


paper_icon_button_basic_test 'applies an icon specified by the icon attribute' failing

You can use the element in a polymer web app project and see the svg in the dom and query it via a querySelector.  The test below, however, fails.
expect(Polymer.dom(b1.$['icon'].jsElement['root']).querySelector('svg'),
          isNotNull);

passes now, probably due to polymer update


transform: scale(0); becomes transform: 0;

NPM version (npm -v): 4.0.5
Node version (node -v): 7.4.0
Node Process (node -p process.versions): { http_parser: '2.7.0',
node: '7.4.0',
v8: '5.4.500.45',
uv: '1.10.1',
zlib: '1.2.8',
ares: '1.10.1-DEV',
modules: '51',
openssl: '1.0.2j',
icu: '58.2',
unicode: '9.0',
cldr: '30.0.3',
tz: '2016j' }
Node Platform (node -p process.platform): darwin
Node architecture (node -p process.arch): x64
node-sass version (node -p "require('node-sass').info"):
node-sass       4.5.0   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]
npm node-sass versions (npm ls node-sass):
└─┬<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
When encountering a syntax, or compilation issue:

Open an issue on LibSass. You
may link it back here, but any change will be required there, not here.

Syntax issue, working in LibSass 3.5 and all other compilers using SassMeister.
Input:
transform: scale(0);

Becomes:
transform: 0;

If you delete this text without following it, your issue will be closed.

 I can't reproduce this locally or on Sassmiester. If you can please create a libsass bug since it is a compilation issue.

Only other CSS processing I'm using is autoprefixer, but have confirmed the issue is not with that. Can't reproduce the bug in Libsass, so I'm at a bit of loss !

Since this can't be reproduced using the plain node-sass on the commandline or libsass, the issue lies somewhere else in your build pipeline.
Aside: I'm assuming scale(0) and 0 are functionally identical and something is just optimizing it for you

Thanks for the help anyway @nschonni. I'll keep investigating.
FYI, from a CSS point of view, transform: scale(0), makes the element shrink, while transform: 0 does nothing at all.


Improve naming build operation names for task actions

Here is a spike for initial feedback (no functional tests were adjusted or added yet).
This gives meaningful names to task actions by making ContextAwareTaskAction a Describable and implementing getDisplayName() for all commonly used task action implementations.
The names are not necessarily unique anymore. As, for simplification, there is no counter on the doFirst {} and doLast {} closure actions, which do not have a name. I think it is not a very common case, and not a recommended one, to add several of these.
There is Execute unnamed task action fallback, where I am not yet sure if/when we would hit that.
Here is how it looks like in IDEA:

My 2 cents...
I like the idea of making it possible to describe an action (e.g., doLast("workaround some funny thing") { /* stuff */ }).
-1 on naming the "validate such-and-such input" or "create such-and-such output". We shouldn't show these individually because it's just noise.  Maybe we should show an overall "Validating task inputs" (and do all validation there), I don't have a strong opinion that we have to show something.

Very big improvement.
One thing to keep in mind is that we shouldn't be conflating operation demarcation and user visualisation. It just so happens right now in that tools visualise the entire operation tree, but it doesn't have to be this way. There has been discussion about adding some kind of concept of importance/audience to operations so that tools can make better decisions about what to show to humans. My point here is that at some point this is probably going to be necessary to reduce the information to just what is useful for humans and we should do that instead of artificially dropping operations in order to achieve it.

I like the idea of making it possible to describe an action (e.g., doLast("workaround some funny thing") { /* stuff */ }).

If this were there, scans could use it to improve the information we present in task input comparison. That's not saying “let's add it right now”.

Thanks for all the good feedback. I agree that naming the closure actions is a great idea. And I think it can be added without much effort.
I added it to the spike:

Regarding what we show:
We actually show only one "Validating task inputs". It was just named wrong, missing the s, which was confusing in the example. But I agree that this is noise, especially the individual create X output folder. But these were all displayed before already as Task action x/y, which is even worth.
So moving towards an implementation, I would suggest to split this up into naming the build operations we already have vs. reducing the number of build operations.

Naming: Turn this spike into an implementation of #1681 by adding the appropriate test coverage. I would include the new naming of doFirst/doLast actions here.

Reduce: To me it looks like a good approach would be to make certain things not-a-action, if we do not want them to show up. This would be gradle/task-output-cache#651.

I agree with Luke that this is a big improvement. I love how you show how this looks from a user perspective. Does this impact what one sees in the CLI at all?
@ldaley is right that we could make these events richer so IDEs (or we) can provide better visualizations. I would suggest we consider that a separate effort.
Aside, I think we ought to go further improving the IDE experience working with other orgs, and this isn't the lowest-hanging fruit.

Very nice improvement on the display. Also +1 on reducing the number of "infrastructure" actions.

@eriwen this is not influencing the CLI at the moment. Task actions are not displayed as far as I can tell.

Thanks everyone for comments and reviews of this PR so far. I intend to merge this into master. I added test coverage for the changes. Who could give this a final review?
CI Branch Stage: https://builds.gradle.org/viewQueued.html?itemId=7520694


FoundationEssentials: implement file operations

This adds an initial implementation for file operations on Windows. With this, FileManager should at least build on Windows, which unblocks future work as well as brings us closer to enabling FoundationEssentials on Windows.

@swift-ci please test

/build/swift-foundation/Sources/FoundationEssentials/FileManager/FileOperations.swift:845:159: error: cannot convert value of type 'UnsafeMutablePointer<CChar>' (aka 'UnsafeMutablePointer<Int8>') to expected argument type 'String'

These build failures do look related - it looks like this change breaks the macOS/linux build. Let me know if you need any assistance addressing that before we merge this

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

Going to merge this for now - if there are any more comments, happy to address them in a follow up. This should allow us to get to the file diffing changes.


Update README.md

Adds some clearer readme instructions

Closing as this will be replaced by the work in this pr


vendor ruby 2.0

Add install-vendor command to install vendor ruby/git
vendor tools will be installed to Library/Homebrew/vendor/<name>/<version> with a Library/Homebrew/vendor/<name>/opt symlink to point to current version. This enables us to push updates in the future by simply update the symlink.
It is important to notice that for most of users they will continue to use system ruby/git. vendor version is only used for old systems.

If that's not asking too much, I'd like to read a (short) high level overview of how this is supposed to work and to what extent these things will be automatic or require user intervention. I'd like to know that before I start commenting on the implementation. (Note that I'm fine waiting for that overview, as this code is still work in progress—and maybe the exact idea how this is supposed to work also isn't finalized yet.)

@xu-cheng Can we pull this into PR comments? It's hard to "find" these comments now. Assuming there has been a git --version check before the initial opt symlink is set I think that code is fine: a symlink there means we know it's been setup correctly. I also think it's worth worrying about Git issues in a future PR; I'm still not convinced using install-vendor is necessarily the best approach for Git when we have bottles and the ability to install using the formula directly.

I pull the comment here for better visibility.

Assuming there has been a git --version check before the initial opt symlink is set I think that code is fine: a symlink there means we know it's been setup correctly.

But we don't know whether the git is outdated, especially for security updates.

I also think it's worth worrying about Git issues in a future PR;

Unfortunately, we have to make sure install-vendor works for git now, because we won't be able to largely change the workflow of install-vendor in the future.

I'm still not convinced using install-vendor is necessarily the best approach for Git when we have bottles and the ability to install using the formula directly.

If you have done some extensive test, you will find there are several obstacles:

The first one is the bootstrap problem. And brew install url has many its own problem.
Tap#private? which will be called by brew install requires git. We probably need to fix it in another PR.
The use experience from Linuxbrew has shown me that using formula installation as homebrew's runtime deps is quiet fragile.
And vendor git can solve all of them in quite simple and robust way.

I pull the comment here for better visibility.

Thanks!

But we don't know whether the git is outdated, especially for security updates.

We should continue to use the old Git until the new one is working. This is the same as we do with Homebrew's security updates and linking.

Unfortunately, we have to make sure install-vendor works for git now, because we won't be able to largely change the workflow of install-vendor in the future.

Why not?

The first one is the bootstrap problem. And brew install url has many its own problem.

Can you elaborate on these problems?

Tap#private? which will be called by brew install requires git. We probably need to fix it in another PR.

Yeh, that seems like another PR that can go in before this one.

The use experience from Linuxbrew has shown me that using formula installation as homebrew's runtime deps is quiet fragile.

I don't know if this applies to Homebrew. Also, I'd rather improve this situation rather than rely on another script which will have its own edge cases, issues and bugs. We have to use Bash to install Ruby so we can run most of Homebrew; this does not apply to Git or even Curl which could both be installed using pure Ruby and HTTP.

We should continue to use the old Git until the new one is working. This is the same as we do with Homebrew's security updates and linking.

The reality is with your proposed way is we want able to know whether the new one is working. It may work for git --version, but fail for another issues. And git will never know there is a revision here. As for security, it is extremely bad idea to use an vulnerable version when there is a fix. Not mention, your propose solution would easily allow an attacker to introduce downgrade attack as attacking vector.

Why not?

We cannot know make symlink create by scripts for now, and fallback to control by git in the later. It will introduce  git conflict.

Can you elaborate on these problems?

Even without mentioning the possible dep issues, installing by url will tag the tap to nil. And it could cause many problem in formula resolution process and stopping bottle to be fetched.

I don't know if this applies to Homebrew. Also, I'd rather improve this situation rather than rely on another script which will have its own edge cases, issues and bugs. We have to use Bash to install Ruby so we can run most of Homebrew; this does not apply to Git or even Curl which could both be installed using pure Ruby and HTTP.

These problems are all applied to Homebrew. Linuxbrew or tigerbrew just happens to revel the problem more easily. Using formulae as homebrew's runtime deps will cause nightmare for brew reinstall/upgrade/unlink. Trust me, decoupling the deps issue is the right way and most simple and robust solution.

even Curl which could both be installed using pure Ruby and HTTP.

But how do you install ruby? You will need curl. Again, the bootstrap problem .

The reality is with your proposed way is we won't be able to know whether the new one is working. It may work for git --version, but fail for another issues. And git will never know there is a revision here. As for security, it is extremely bad idea to use an vulnerable version when there is a fix. Not mention, your propose solution would easily allow an attacker to introduce downgrade attack as attacking vector.

I think you've misunderstood my solution: I'm saying we should always upgrade unless the upgrade fails.

We cannot make symlink created by scripts for now, and fallback to control by git in the later. It will introduce git conflict.

Please elaborate on this (and length); I don't understand.

Even without mentioning the possible dep issues, installing by url will tag the tap to nil. And it could cause many problem in formula resolution process and stopping bottle to be fetched.

It could cause problems but does it? We could easily fix that installing by URL issue if we detect we're installing from a tap's URL.

These problems are all applied to Homebrew. Linuxbrew or tigerbrew just happens to revel the problem more easily. Using formulae as homebrew's runtime deps will cause nightmare for brew reinstall/upgrade/unlink. Trust me, decoupling the deps issue is the right way and most simple and robust solution.

Well we've been doing this for earlier versions of Homebrew for a long time with curl and git and not experienced problems.

But how do you install ruby? You will need curl. Again, the bootstrap problem .

Sure; I'm arguing this is why a install-vendor doesn't need to install Curl so we agree. My point was that if you really needed to you can do HTTP transfers using Ruby itself.

I think you've misunderstood my solution: I'm saying we should always upgrade unless the upgrade fails.

My major problem is how do you know there is a git update. If you don't store such information in symlink.

Please elaborate on this (and length); I don't understand.

Basically, there are two proposed solutions here.

One is my current PR, i.e. the symlink is maintained by git repo. For every update, we update the symlink in git commit.
The next is yours. i.e. the symlink should be created by install-vendor based on the outcome whether it is success. i.e. the symlink is ignored by git.

We could move my solution to yours. But not in reverse, because it will cause git conflict in update.

Well we've been doing this for earlier versions of Homebrew for a long time with curl and git and not experienced problems.

Try to upgrade or reinstall them. This is what you got https://gist.github.com/anonymous/158e41f6ca542c348796ae380da56a0f
The current solution is to manually do  brew fetch; brew install

My major problem is how do you know there is a git update. If you don't store such information in symlink.

Have a vendor/git-version file.

Try to upgrade or reinstall them. This is what you got https://gist.github.com/anonymous/158e41f6ca542c348796ae380da56a0f

That can be improved by not using HTTPS and relying on checksum security instead. We can also quieten some of those warnings. Doesn't seem insurmountable and doesn't apply to git.

Have a vendor/git-version file.

The next question is how to check the git-version file. Supporting we have the logic mentioned in https://github.com/Homebrew/brew/pull/195#discussion_r63005898 in ENV/scm/git.

That can be improved by not using HTTPS and relying on checksum security instead. We can also quieten some of those warnings.

There are certainly some hack we can use to mitigate the issue. But why not using a simple and robust vendor approach? It can solve all of them and doesn't require human interaction in edge cases.

Doesn't seem insurmountable and doesn't apply to git.

It applies to git, if there is openssl update. And git depends on curl on old system. Basically, we have git curl and openssl formulae depend on each other. A reinstall or upgrade on any of them requires manually fix the bootstrap problem.

The next question is how to check the git-version file. Supporting we have the logic mentioned in #195 (comment) in ENV/scm/git.

I don't think we need to. I think we just use opt and then we install the latest versions at update time or something?

It applies to git, if there is openssl update. And git depends on curl on old system. Basically, we have git curl and openssl formulae depend on each other. A reinstall or upgrade on any of them requires manually fix the bootstrap problem.

There are certainly some hack we can use to mitigate the issue. But why not using a simple and robust vendor approach? It can solve all of them and doesn't require human interaction in edge cases.

I think this is a problem that we can solve (but don't need to for this PR) and I'm not yet convinced that the vendor approach is more simple or robust. It's not clear to me how I build a new vendor version, how I upload it, how I distribute it or test it. We know how to do this for formulae and git is a formula that updates pretty regularly whereas ruby is something we cannot use a dedicated formula for this and will not be updated more often than OS X releases.

I don't think we need to. I think we just use opt and then we install the latest versions at update time or something?

That's my whole point. It will never be checked. Noted, there are not much difference between brew update and Utils.git_available?.

I think this is a problem that we can solve (but don't need to for this PR)

No, you cannot. There are hard deps on git for old systems, which it's enough to make brew install url unappliable.

It's not clear to me how I build a new vendor version, how I upload it, how I distribute it or test it. We know how to do this for formulae

You can read readme at https://github.com/xu-cheng/homebrew-portable for how. Short story is it is almost identical to normal formula. I can add more document if it's requested. But please not just reject something because it is new to you.

and git is a formula that updates pretty regularly

For vendor git, we don't need to follow the latest git. We can only update if it's required or follow apple's git.

That's my whole point. It will never be checked. Noted, there are not much difference between brew update and Utils.git_available?.

It could be, though, there's no technical reason preventing it.

No, you cannot. There are hard deps on git for old systems, which it's enough to make brew install url unappliable.

brew install from a URL does not require Git so I don't know what your point is here.

You can read readme at https://github.com/xu-cheng/homebrew-portable for how. Short story is it is almost identical to normal formula. I can add more document if it's requested.

That's completely different to the process of how we build, upload and release to users a new version of a formula.

But please not just reject something because it is new to you.

I'm not and I don't really appreciate the insinuation. It's not clear you've thought through all the edge-cases of what will happen if e.g. the installation fails. Old code has known bugs and edge cases. New code will have bugs and edge cases (perhaps far fewer, perhaps almost none) but they are currently unknown, undocumented and only the work of a single maintainer. This is concerning for something we're going to introduce as a mandatory requirement to all Homebrew users on old versions.

For vendor git, we don't need to follow the latest git. We can only update if it's required or follow apple's git.

Between Git, OpenSSL and Curl there's a lot more regular security updates to be done than Ruby 2.0.x.
I've said before: I don't think this PR needs to be blocked on figuring out how we're going to handle Git and/or Curl and I don't think we need to talk about them here as there's more discussion needed about the merits of different approaches.
--
Anyway, what does need to be done before this PR is merged (or at least before it is enabled by default rather than guarded behind an environment option temporarily) is the following things:

Allow Homebrew users to be able to run brew update and then go without internet and still have a ruby that works.
Ensure that the 32-bit Ruby still works on a 64-bit 10.8 (ideally 64-bit 10.11)
Provide a script and ideally a CI job so any Homebrew maintainer can upgrade this Ruby if there's an urgent security vulnerability and you're unavailable (and I think this means it'd be sensible to rely on existing infrastructure such as Bintray, Jenkins and a Homebrew organisation repository but that's up-to-you)

It could be, though, there's no technical reason preventing it.

But we need to figure it out before merging this, as I said that we won't be able to change it in the future

brew install from a URL does not require Git so I don't know what your point is here.

To install Homebrew core tap, you will need git. And I mean you cannot use brew install url as approach to bootstrap Homebrew on old system.

That's completely different to the process of how we build, upload and release to users a new version of a formula.

Is it? The only different is that we don't need to bottle them but just package the build binary.

I'm not and I don't really appreciate the insinuation. It's not clear you've thought through all the edge-cases of what will happen if e.g. the installation fails. Old code has known bugs and edge cases. New code will have bugs and edge cases (perhaps far fewer, perhaps almost none) but they are currently unknown, undocumented and only the work of a single maintainer. This is concerning for something we're going to introduce as a mandatory requirement to all Homebrew users on old versions.

I will apologize if there is any insinuation. Please you do need to keep a open mind on new solution. Because it indeed solved certain issue that old system cannot. Let's please not take away from technical reality.

Between Git, OpenSSL and Curl there's a lot more regular security updates to be done than Ruby 2.0.x.

OpenSSL's update is appiled to ruby as well. I don't see there is too much difference.

I've said before: I don't think this PR needs to be blocked on figuring out how we're going to handle Git and/or Curl and I don't think we need to talk about them here as there's more discussion needed about the merits of different approaches.

As I said, we need to figure out how to manage the opt symlink as it cannot be changed in the future.

Allow Homebrew users to be able to run brew update and then go without internet and still have a ruby that works.

I'm open to solution, but it need be discussed thoroughly in this PR.

Ensure that the 32-bit Ruby still works on a 64-bit 10.8 (ideally 64-bit 10.11)

This is already done. You can test this PR now with the vendor ruby.

Provide a script and ideally a CI job so any Homebrew maintainer can upgrade this Ruby if there's an urgent security vulnerability and you're unavailable (and I think this means it'd be sensible to rely on existing infrastructure such as Bintray, Jenkins and a Homebrew organisation repository but that's up-to-you)

We could add CI job if we add Leopard VM. This final binary will definitely go to bintary, so it is the repo. Current build is only for test purpose only.
Anyway, it's late on my TZ. I will let other maintainers to join the discussion.

But we need to figure it out before merging this, as I said that we won't be able to change it in the future

Sure, I think that's revealing a limitation in the current approach that would be solved with a vendor/git-version approach, as mentioned before.

To install Homebrew core tap, you will need git. And I mean you cannot use brew install url as approach to bootstrap Homebrew on old system.

We can, you just don't think we should. I think improving that flow would solve a lot of problems. Regardless, that doesn't need to be decided in this PR: we just need to decide how to use the symlink.

Is it? The only different is that we don't need to bottle them but just package the build binary.

That's pretty different, to me. It's much more like how we used to do packaging before CI (which was a pain).

I will apologize if there is any insinuation. Please you do need to keep a open mind on new solution. Because it indeed solved certain issue that old system cannot. Let's please not take away from technical reality.

I'm definitely keeping an open mind. I'm 👍 on this general solution. The only things I think need tweaked are mentioned above but it's 95% of the way there already.

I will apologize if there is any insinuation.

Thanks 🙇

Please you do need to keep a open mind on new solution. Because it indeed solved certain issue that old system cannot. Let's please not take away from technical reality.

I think this does solve some problems and introduces some new ones but, as said, it only needs a few tweaks to address them.

This is already done. You can test this PR now with the vendor ruby.

Ok, 🆒, I wasn't sure.

We could add CI job if we add Leopard VM. This final binary will definitely go to bintary, so it is the repo. Current build is only for test purpose only.

Yeh, we can add a 10.5 VM. I'd be interested if it's possible to build this on a new version in 32-bit mode and have it work on an old version, though. With or without CI that would make uploading/testing new versions much easier.

Anyway, it's late on my TZ. I will let other maintainers to join the discussion.

👍 Thanks for all your hard work here @xu-cheng. I do appreciate it, I'm just trying to make sure we end up with a robust, maintainable, understood solution.


Support PermanentURI Contract Events for OpenSea Frozen Metadata

The contract should support indicating that the metadata is frozen:
https://docs.opensea.io/docs/metadata-standards#freezing-metadata
It's not entirely clear how this is enforced, since emitting such an event has no bearing on whether the baseURI can be changed. I believe that it's "enforced" by OpenSea just never allowing the metadata to change on their marketplace, but this has no bearing on other marketplaces.
We should also add support for Arweave and Filecoin moving forward and allow users to set a provenance hash. Provenance hashing was included in an earlier unreleased version of the contract but removed since beginners have no easy way of generating a provenance hash, and many projects seem to disregard it's importance or aren't interested in including it.
event PermanentURI(string _value, uint256 indexed _id);
You can clearly see that the event they instruct users' contracts to emit takes the tokenId as a parameter. In my personal opinion, the entire collection should be marked as permanent. It doesn't make sense for some of the user's tokens to be marked as permanent while others are not. It may also be very expensive in terms of gas to emit this event for every token in the collection.
OpenSea says to contact them to mark an entire collection as frozen, which seems a terrible way to handle things.

I believe only an entire collection should be marked as frozen, and the gas costs to emit this event for a large collection (10,000 tokens or similar) just doesn't make sense.
If users want to make their metadata more "permanent" we should just use Arweave.


More code examples in Javadoc for TupleConstructor and ToString

Based on discussion on the dev mailing list on how to include code example from the MrHaki Groovy Goodness blog series. Instead of external link the code samples from the blog posts are included in the Javadoc comments.
See also:

http://groovy.329449.n5.nabble.com/Re-GitHub-groovy-pull-request-Link-to-MrHaki-s-blog-in-TupleConstructor-jav-tp5731382.html

Thank you! oh.. and +1 ;)

Thanks!


How to use topk?

I am trying to use topk to implement X-LoRA in Candle, and want to perform topk in the last dimension. Specifically, I need the indices return value (as returned by torch.topk).
These indices will either be used to creaste a mask to zero out all the values which are not in the topk, and/or used to apply scalings on the nonzero values. This is a may be hard to understand, as such please see this snippet from our X-LoRA library.
Is there a way to implement this with the current Candle functions, or is this planned to be implemented as a function?

After looking at the Mixtral MoE selection implementation, I cannot really understand it:

https://github.com/huggingface/candle/blob/3144150b8d1b80b2c6b469dcab5b717598f0a458/candle-transformers/src/models/mixtral.rs#L302-L323

How does this work? Thanks!

@gregszumel, thanks for the explanation. I would love to see this added to Candle. If you want to contribute this to mistral.rs please feel free!

It's certainly not an efficient top_k as indeed we fully sort the array, but the worst part is more that the operation takes place on the cpu so this triggers some synchronization point. I'm putting together #2132 that should help doing this fully on the gpu, it will still sort the whole array but actually on gpus it's not necessarily that slower than a topk as the sort is done in parallel (also the number of experts is very small, 8, so this wouldn't be much of an issue even on the cpu).

@LaurentMazare, thanks! I saw that PR and am very excited for it to be merged.

@EricLBuehler Looks like it got merged - thanks at @LaurentMazare!
I hope to find some time this week to implement top-k; I'm thinking it's home is probably in either in mistral.rs or candle-ext, but the argsort is probably a great workaround for now.

@gregszumel, that sounds great! If you decide to contribute it to mistral.rs, that would be much appreciated.

For future reference, here's the implementation: https://github.com/EricLBuehler/mistral.rs/blob/6aec940499be1cf72c628f7ddaa8b3e59bcb4fda/mistralrs-core/src/ops.rs#L482-L504


Use Factory Pattern for public API

Is your feature request related to a problem? Please describe.
Extending features will explode parameters for many/most functions.
Describe the solution you'd like
Factory pattern: Work on a factory object to hold all settings and configuration variables. This keeps function signatures at more constant length over time.
Describe alternatives you've considered
Insanely long function signatures are needed for all parent functions when adding a new parameter to a low-level function.

You mean argument list passed to run, run_local etc?

yes. Extending DeployHost with more features will become quite ugly IMHO.
https://github.com/pogobanane/deploykit/commit/3270cc5af31af645925cb8a85337bb0005ecebb2

Is this possible while maintaining type checks?


[Feature] Replace all custom env. var. expansion logic for configuration files with a8m/envsubst

Description
graph-node supports env. var. expansion in certain sections of the configuration files, and we also ship envsubst in the official Docker image for more complex use cases. I'd argue it makes most sense to drop our custom env. var. expansion logic and automatically invoke envsubst in the start script. This benefits us in three ways:

Less code – yay, always a win.
We enable env. var. expansion in all sections of the configuration files, as opposed to just some of them.
We get support for default values and other advanced features of envsubst, like custom evaluation expressions.

Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
No response
Some information to help us out

[ ] Tick this box if you plan on implementing this feature yourself.
[X] I have searched the issue tracker to make sure this issue is not a duplicate.

I'd like to keep env expansion built in at least for those already existing. I used that feature for development in different places. Yes I could switch to wrap my graph-node invocation with envsubst, but I still raise the point that it's used today.
Some from Semiotic looked at having env expansion deeper in the deserialization engine to that the full config could use env expansion, not sure what have been the state/conclusion of that.

The Figment crate enables layered configuration. Looks very cool really, it's not exactly envsubst but it's an interesting approach to overriding from the environment. The key to be substituted can be entirely omitted in the toml. The env var must have a specified prefix and path format. And it can support other use cases such as overriding TOML with another TOML or a JSON.


[Feature] 血缘解析功能

Describe the feature (描述一下需求)
No response
Related suggestions (相关建议)
No response

合并到 #854


Fix bug where currently playing opens Music app

Description
In recent change (#15728), I introduced a small issue. All information about songs is obtained using Apple Scripts. In the previous implementation, running the command with background refresh caused the Music app to open constantly. The updated implementation checks whether the Music app is open before executing the Apple Script query to obtain the information.
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

LGTM!


HTTP POST method naming based on isTargetCollection

I am trying to understand why NamingHelper is making a decision about POST method name based on whether the tail is singular or plural.
It's very easy to fix, so I'll gladly do it if it's Ok.
As a result of this issue what we have is:
    @RequestMapping(value = "/{bookingRef}/ogoneIframe", method = RequestMethod.POST)
    public ResponseEntity<OgoneIframeResponseDto> updateOgoneIframe(...)

even though POST should normally be used for creation.
I would understand it if the decision would have been made based on whether the id is present in the url, but it's not the case.
@stojsavljevic , can you take a look and come up with a suggestion?

Hi.
This is done on purpose.
The reasoning behind this is that endpoints names should be in plural.
In case of singular name we consider that the resource can be only one. So in that case we don't generate method for creating new resource but to update the existing one.

Continuing the discussion form the PR...
This feature was point of confusion for a number of times.
And I tend to agree with you that we need more flexibility to cover different use cases and different approaches to model REST API.
Before we continue on this let's first finish #212 since there are changes in NamingHelper in both PRs.

@stojsavljevic , please check the PR now.


Develop

Codecov Report

Merging #299 (da37b2e) into master (bbd8e7c) will decrease coverage by 1.36%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #299      +/-   ##
==========================================
- Coverage   97.23%   95.86%   -1.37%
==========================================
  Files          82       86       +4
  Lines        2998     3073      +75
==========================================
+ Hits         2915     2946      +31
- Misses         83      127      +44

Impacted Files
Coverage Δ

glasses/__init__.py
100.00% <ø> (ø)

glasses/models/AutoModel.py
89.79% <ø> (+11.07%)
:arrow_up:

glasses/models/AutoTransform.py
100.00% <ø> (ø)

glasses/models/base/__init__.py
100.00% <ø> (ø)

glasses/models/base/protocols.py
100.00% <ø> (ø)

glasses/models/classification/deit/__init__.py
100.00% <ø> (ø)

glasses/models/classification/densenet/__init__.py
100.00% <ø> (ø)

...ses/models/classification/efficientnet/__init__.py
99.31% <ø> (+0.06%)
:arrow_up:

...lasses/models/classification/mobilenet/__init__.py
100.00% <ø> (ø)

glasses/models/classification/regnet/__init__.py
80.00% <ø> (-0.15%)
:arrow_down:

... and 104 more

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 3bb4ded...da37b2e. Read the comment docs.


Developer role should be sufficient

iTunesConnect says when adding a user with the Developer role that they are able to:

Manage TestFlight Testers

But if I use a user with that role for boarding I get the following message:

Something went wrong, please contact the application owner: Account<EMAIL_ADDRESS>doesn't have a role that is allowed to administer app testers, current roles: ["developer"]

Hey @kdawgwilk - could you confirm what version of fastlane is in your Gemfile.lock for your boarding instance? I know some work has been done to fix this type of issue, so I'm wondering if that is checked out to an older version maybe?

I updated to the latest before trying this, I believe the issue is here
https://github.com/fastlane/boarding/blob/203d60280b6f49dba20a9b4bce5581dd02b8ff16/app/services/boarding_service.rb#L116

It looks like Developer role can only manage internal testers but not external because they are read-only?  Does that sound right?

I am having the same issue, no idea where to start with this one. On ITC I have full permissions to manager testers, but am getting this error when I try Pilot.

Hey @jmacwhyte, could you share the output from your command line when you try to add a tester? Would be helpful to see the stack trace. Thanks! 🚀


Don't use last component group id for "other" section on subscription page

Otherwise this breaks then there aren't any component groups as it
cannot use the last value the var was assigned as it never happened. #8

Codecov Report

Merging #16 (2df9220) into 2.5 (3947f0d) will increase coverage by 0.93%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##                2.5      #16      +/-   ##
============================================
+ Coverage     53.09%   54.03%   +0.93%
  Complexity     1264     1264
============================================
  Files           275      275
  Lines          4799     4799
============================================
+ Hits           2548     2593      +45
+ Misses         2251     2206      -45

Impacted Files
Coverage Δ
Complexity Δ

app/Http/Controllers/SubscribeController.php
52.11% <100.00%> (+49.29%)
20.00 <0.00> (ø)

app/Integrations/Core/System.php
92.30% <0.00%> (+5.12%)
13.00% <0.00%> (ø%)

app/Models/Subscriber.php
100.00% <0.00%> (+8.00%)
11.00% <0.00%> (ø%)

...ions/Subscriber/ManageSubscriptionNotification.php
22.22% <0.00%> (+22.22%)
2.00% <0.00%> (ø%)

app/Http/Middleware/SubscribersConfigured.php
100.00% <0.00%> (+100.00%)
2.00% <0.00%> (ø%)

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 3947f0d...2df9220. Read the comment docs.

Codecov Report

Merging #16 (2df9220) into 2.5 (3947f0d) will increase coverage by 0.93%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##                2.5      #16      +/-   ##
============================================
+ Coverage     53.09%   54.03%   +0.93%
  Complexity     1264     1264
============================================
  Files           275      275
  Lines          4799     4799
============================================
+ Hits           2548     2593      +45
+ Misses         2251     2206      -45

Impacted Files
Coverage Δ
Complexity Δ

app/Http/Controllers/SubscribeController.php
52.11% <100.00%> (+49.29%)
20.00 <0.00> (ø)

app/Integrations/Core/System.php
92.30% <0.00%> (+5.12%)
13.00% <0.00%> (ø%)

app/Models/Subscriber.php
100.00% <0.00%> (+8.00%)
11.00% <0.00%> (ø%)

...ions/Subscriber/ManageSubscriptionNotification.php
22.22% <0.00%> (+22.22%)
2.00% <0.00%> (ø%)

app/Http/Middleware/SubscribersConfigured.php
100.00% <0.00%> (+100.00%)
2.00% <0.00%> (ø%)

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 3947f0d...2df9220. Read the comment docs.


VS Code crashes with error 132

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.78.2
OS Version: Ubantu 18.04.6

Steps to Reproduce:
### Tasks
- [ ] Add a draft title or issue reference here

Use VScode to Open a file over 100M with extension .txt
Wait a couple of seconds, VS Code shows a window "The window has crashed. Reason: 'crashed' code: 132"

Can you attach the crash logs following the steps at https://github.com/microsoft/vscode/wiki/Native-Crash-Issues#creating-a-crash-report, if possible can you also attach an example file that was used to trigger the crash. Thanks!

bugreport-alioth-TKQ1.220829.002-2023-06-12-09-41-30.zip
code --crash-reporter-directory :
After using this command, and Take the steps that lead to the crash. the issue cannot be reproduced，But still have the same problem in normal use，I tried the same with version 1.77.3

@CodeLi1415 the argument should be of the form code --crash-reporter-directory /tmp/vscode-crash and once the crash reproduces you will see crash logs generated under /tmp/vscode-crash/pending

CrashLog.zip
I reproduced the problem using version 1.77.3 and upload the crash dump.

DUMP_1.79.2.zip
this is the dump for 1.79.2

I tried symbolicating the files. One of them has to do with watcher.node, and I don't know whether we have symbols for it. The other one seems to involve Mojo and PlatformSharedMemoryRegion.
symbolicated-93.log
symbolicated-bc.log

@CodeLi1415 crash seems to happen when trying to validate share memory file handle, can you try the following next steps

Does the crash repro when you launch with --disable-dev-shm-usage
Can you attach the output of code --verbose for the crash scenario

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


[Crazy idea] Firefox support

Hi guys!
It would be really cool to have support for Firefox in order to scrobble the songs I listen to on Bandcamp.
Is there any chance it will happen? Would it be technically feasible?

You'll be better pushed working on Firefox for Android extension for this functionality.
https://github.com/david-sabata/web-scrobbler was working on porting to FF for desktop. Perhaps raising a ticket for looking into the mobile extension development too.

Thanks!


Support for multiple response variables

The mvbrmsformula function in brms provides support for multiple formulas with shared inputs:
xf <- bf(x ~ z + 1)
yf <- bf(y ~ x + z + 1)
formula <- mvbf(yf, xf, ...)
fitted_model <- brm(formula, ...)

It would be nice if brmp supported this behavior as well.  I believe that in code generation this would just correspond to generating a single model with multiple response sample statements.
Additional question for discussion: would this require implementing brms's (expr | ID | group) grouping syntax as well?

@null-a what do you think about the feasibility of this?  Are there any major stumbling blocks you're aware of?

what do you think about the feasibility of this? Are there any major stumbling blocks you're aware of?

@eb8680: To the extent that I'm familiar with this feature, it seems perfectly feasible to me -- I see no major stumbling blocks.

I believe that in code generation this would just correspond to generating a single model with multiple response sample statements.

Yes, that's my understanding too. When multiple responses share the same family this could also be a single sample statement from a multivariate distribution? It seems that when the reponse is either multivariate normal or student's-t, brms models residual correlations by default. (In particular, the response distribution is parameterised by standard deviations and a correlation matrix.)

would this require implementing brms's (expr | ID | group) grouping syntax as well?

My understanding is that it is possible implement multivariate responses without this, but that once we do so this would be a useful extension to add? (Because it allows for group level terms
in different formulas to be modeled as correlated.)
Some further thoughts, noted for future reference:

Would be want to support models in which response variables have different response families? (e.g. y1 comes from a normal and y2 from a Bernoulli.) I don't see how to do this in brms, but it wouldn't surprise me if it's possible; it's very flexible.

There's perhaps some overlap here with models with a categorical response, as they also result in models in which mu is a vector rather than a scalar. "Distributional models" are also similar (though perhaps only superficially), since they too are specified with multiple formulas.

It seems most of the work would be in extending code generation. The mechanism used to specify priors would need to be extended so that parameters from individual formulas can be picked out. (brms appears to do this using the name of the response variable.) fitted would return an array with an extra dimension. Formula parsing and design matrix coding would be unchanged I guess.

The mvbind notation for setting up a multivariate model (in which each element of the response uses the same formula) seems like it would be useful eventually. Perhaps that could also be written as e.g. [y1,y2] ~ 1 + x. Perhaps for high-dimensional data there's a way to specify a range of columns, e.g. have y[0:2] ~ 1 + x be eqv. to [y0,y1,y2] ~ 1 + x.

Would be want to support models in which response variables have different response families?

I think a first version supporting only Normal responses with uncorrelated residuals would be fine, but in general we should be able to support all response families in the case where responses are fully observed, and at least Normal and Categorical/Bernoulli when responses are missing (#43, #44).  Support for the general case might involve doing relatively naive code generation in brmp and expecting the Pyro backend to be smarter about simplifying the resulting model.
Modelling correlations in residuals across arbitrary families seems more difficult, we can punt on that for now.

There's perhaps some overlap here with models with a categorical response, as they also result in models in which mu is a vector rather than a scalar ...

I wonder if we might want to draw a distinction between multiple variables and vector/tensor-valued variables or means, in the same way that Pyro allows tensor-valued sample statements via Distribution.to_event.  That way brmp could support non-scalar responses of different shapes, families, etc, and we could naturally support mvbind and generalizations.  That's sort of what I was thinking when I opened #46 although I don't have a fully formed proposal for that.
I would also like to see categorical responses supported eventually, since one of my motivating examples for this series of issues is a hierarchical HMM where the transition and emission distributions can each be written as GLMMs.

It seems most of the work would be in extending code generation

Yeah, that sounds right.  Maybe a good starting point would be to collect some examples that brms handles?


Fix SBML_INCLUDE_DIR

Fix CMakeLists.txt by including SBML_INCLUDE_DIR

It is fine to use this workaround for the time being on Mac.
Eventually, we need to figure out why the property of the imported target from another scope does not propagate to the final executable.


Color for element list boxes and attribute zebra-striping

In the list of elements:
http://music-encoding.org/guidelines/v3/elements.html

And on element documentation pages:
http://music-encoding.org/guidelines/v3/elements/desc.html
The alternating gray background and element tag backgrounds in the element lists are too dark to the point of being distracting and reducing the readability of the text.
It would be useful for the gray of such regions match that of the ODD sample code at the bottom of the element reference pages:

The gray color is currently #e5e5e5, but should be lightened to #f5f5f5.

Please make a PR

@ahankinson Here is a last one that should be transfered to the guidelines repo. Thx in advance.


Benchmarking

so to benchmark llm's with huge number of parameters we need to have the file locally so as to pass it as hostfile.
Is there any other way so it can fetch automatically from hugging face and give predict the latency?

For a rough estimation, one could calculate the FLOP-seconds required to calculate a forward pass of the target HF model, then divide by the FLOPs your local GPU can realistically achieve with the target inference framework.
We don't have functionality to provide realistic GPU FLOPs heuristics so I recommend just using https://github.com/EleutherAI/cookbook/blob/main/calc/calc_transformer_flops.py for the forward pass FLOPs and going from there.


Update repositories.txt

Hi @wxzed. I see this pull request removes https://github.com/DFRobot/DFRobot_GDL from the list. As explained by the bot, the automated system only handles submissions. But I'm here to help out with all other request types. Please tell me exactly what you are requesting to be done and I will get that process started right away.

Please remove the DFRobot GDL library

Although anyone is welcome to submit any library for inclusion in the Arduino Library Manager index, removals may only be done with the authorization of a maintainer of the library. Unfortunately, I was unable to verify that this request to remove https://github.com/DFRobot/DFRobot_GDL was authorized.
Please provide proof that this request is authorized. Thanks!

What kind of authorization certificate needs to be provided. This library was submitted by me. Is this ok?https://github.com/arduino/library-registry/pull/481

This library was submitted by me. Is this ok?

No. Even though anyone is permitted to submit a library, that does not give them authorization to later remove it.
However, I can see from the commit history of https://github.com/DFRobot/DFRobot_GDL that you have write permissions in the repository, which is sufficient.

The requested change is now in progress.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests and closes those issues/PRs when that is done. If you are subscribed to the linked PR, you'll get a notification at that time: https://github.com/arduino/library-registry/pull/491
After that, you can monitor the indexing of the library via its dedicated logs web page.
Information about that here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#can-i-check-on-library-releases-being-added-to-library-manager


Fixed builtin ordering in builder.

Stack:

#6710
#6726 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is


Pausing a timer causes all sensors to go to "unavailable"

Describe the bug
Pausing a timer causes all sensors, that are part of this integration, to go to "unavailable"
Once the timer is un-paused all sensors start to work again

Version of the integration
If you are unsure about the version check the github release here.

v1.4.1
master (46bcfc1)

Logs

2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Fetching data from Google Home device Living room speaker - https://<IP_ADDRESS>:8443/setup/assistant/alarms
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Fetching data from Google Home device SHIELD - https://<IP_ADDRESS>:8443/setup/assistant/alarms
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Fetching data from Google Home device Office clock - https://<IP_ADDRESS>:8443/setup/assistant/alarms
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Fetching data from Google Home device Kitchen home - https://<IP_ADDRESS>:8443/setup/assistant/alarms
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Fetching data from Google Home device Living Room display - https://<IP_ADDRESS>:8443/setup/assistant/alarms
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Failed to fetch data from Living room speaker, API returned 404. The device(hardware='Chromecast Audio') is possibly not Google Home compatible and has no alarms/timers. Will retry later.
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Getting Do Not Disturb setting from Google Home device Living room speaker
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Requesting endpoint setup/assistant/notifications for Google Home device Living room speaker - https://<IP_ADDRESS>:8443/setup/assistant/notifications
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Failed to fetch data from SHIELD, API returned 404. The device(hardware='SHIELD Android TV') is possibly not Google Home compatible and has no alarms/timers. Will retry later.
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Getting Do Not Disturb setting from Google Home device SHIELD
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Requesting endpoint setup/assistant/notifications for Google Home device SHIELD - https://<IP_ADDRESS>:8443/setup/assistant/notifications
2021-04-12 20:56:41 ERROR (MainThread) [custom_components.google_home] Unexpected error fetching sensor data: 'fire_time'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 173, in _async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 143, in _async_update_data
return await self.update_method()
File "/config/custom_components/google_home/api.py", line 246, in update_google_devices_information
coordinator_data = await asyncio.gather(
File "/config/custom_components/google_home/api.py", line 220, in collect_data_from_endpoints
device = await self.get_alarms_and_timers(device, ip_address, auth_token)
File "/config/custom_components/google_home/api.py", line 138, in get_alarms_and_timers
device.set_timers(resp.get(JSON_TIMER))
File "/config/custom_components/google_home/models.py", line 59, in set_timers
self._timers = [
File "/config/custom_components/google_home/models.py", line 62, in <listcomp>
fire_time=timer["fire_time"],
KeyError: 'fire_time'
2021-04-12 20:56:41 DEBUG (MainThread) [custom_components.google_home] Finished fetching sensor data in 0.038 seconds
2021-04-12 20:56:41 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.bedroom_clock_device, old_state=<state sensor.bedroom_clock_device=TOKEN; device_name=Bedroom clock, auth_token=TOKEN, ip_address=<IP_ADDRESS>, hardware=Lenovo Smart Clock, available=True, integration=google_home, friendly_name=Bedroom clock device, icon=mdi:form-textbox-password @ 2021-04-12T20:50:27.473474+01:00>, new_state=<state sensor.bedroom_clock_device=unavailable; friendly_name=Bedroom clock device, icon=mdi:form-textbox-password @ 2021-04-12T20:56:41.044334+01:00>>
2021-04-12 20:56:41 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.bedroom_clock_alarms, old_state=<state sensor.bedroom_clock_alarms=2021-04-13T06:30:00+01:00; next_alarm_status=inactive, alarms=[{'alarm_id': 'alarm/470f9193-9d44-43b6-bda6-63ee8586bd35', 'fire_time':<PHONE_NUMBER>, 'status': 'inactive', 'label': None, 'recurrence': None}, {'alarm_id': 'alarm/b20f9db8-0b46-4d0a-9633-dbbf551c243d', 'fire_time':<PHONE_NUMBER>, 'status': 'set', 'label': None, 'recurrence': [1, 2, 3, 4, 5]}], integration=google_home, friendly_name=Bedroom clock alarms, icon=mdi:alarm-multiple, device_class=timestamp @ 2021-04-12T20:50:27.475323+01:00>, new_state=<state sensor.bedroom_clock_alarms=unavailable; friendly_name=Bedroom clock alarms, icon=mdi:alarm-multiple, device_class=timestamp @ 2021-04-12T20:56:41.045833+01:00>>

Suspect this is caused because there is no "fire_time" attribute when the timer is paused
When Paused:
{"alarm":[{"date_pattern":{"day":13,"month":4,"year":2021},"fire_time":1.6182918e+12,"id":"alarm/470f9193-9d44-43b6-bda6-63ee8586bd35","status":4,"time_pattern":{"hour":6,"minute":30,"second":0}},{"fire_time":1.618296e+12,"id":"alarm/b20f9db8-0b46-4d0a-9633-dbbf551c243d","recurrence":[1,2,3,4,5],"status":1,"time_pattern":{"hour":7,"minute":40,"second":0}}],"timer":[{"id":"timer/f34ab61a-98cc-e4e7-37bc-a3b28b70a5ec","original_duration":60000.0,"remaining_duration":53409.0,"status":2}]}

When timer running:
{"alarm":[{"date_pattern":{"day":13,"month":4,"year":2021},"fire_time":1.6182918e+12,"id":"alarm/470f9193-9d44-43b6-bda6-63ee8586bd35","status":4,"time_pattern":{"hour":6,"minute":30,"second":0}},{"fire_time":1.618296e+12,"id":"alarm/b20f9db8-0b46-4d0a-9633-dbbf551c243d","recurrence":[1,2,3,4,5],"status":1,"time_pattern":{"hour":7,"minute":40,"second":0}}],"timer":[{"fire_time":1.618258941e+12,"id":"timer/f34ab61a-98cc-e4e7-37bc-a3b28b70a5ec","original_duration":60000.0,"status":1}]}

That's right, I'll fix it.

Let's get that release going 🔥

@whitehead-aa please try 1.4.2.

When paused "Next timer Status" reports paused.  on UI

Other sensors remain working.
tested on v1.4.2
Note: The State when timer paused is still "unavailable"  but I think that's intentional.


tonic fails to build on Starfive VisionFive 2 risc-v SBC

Here's my environment:

cargo --version --verbose --verbose
cargo 1.69.0-nightly (9880b408a 2023-02-28)
release: 1.69.0-nightly
commit-hash: 9880b408a3af50c08fab3dbf4aa2a972df71e951
commit-date: 2023-02-28
host: riscv64gc-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Fedora 38.0.0 [64-bit]

Here are the steps to reproduced on the VF2:

SCCACHE can't be installed on the VF2 for the very same error as well. LOL.  To circumvent that I did the following to prevent from using SCCACHE:

export RUSTC_WRAPPER=

The usual steps to build:

git clone https://github.com/hyperium/tonic.git
cd tonic/
RUSTFLAGS=-Awarnings cargo +nightly build --release

Here's there error:
  process didn't exit successfully: `/home/davidm/tonic/target/release/build/ring-5f8495bbdf7f7ee0/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/davidm/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/build.rs:358:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think it has been resolved here: https://github.com/briansmith/ring/pull/1574
but it hasn't been reviewed and merged yet.
There was another alternative, that might be used but it also hasn't been reviewed nor merged.

If you don't enable TLS then you shouldn't be building ring and it should work?

via the feature flags that is

I just wanted to report successfully building tonic on Starfive VisionFive 2 riscv64 SBC using Fedora OS 41 and a specific nightly version.
riscv@f40-vf2-saratoga:~/tonic/examples$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="41 (Server Edition Prerelease)"
ID=fedora
VERSION_ID=41
VERSION_CODENAME=""
PLATFORM_ID="platform:f41"
PRETTY_NAME="Fedora Linux 41 (Server Edition Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:41"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
SUPPORT_END=2025-05-13
VARIANT="Server Edition"
VARIANT_ID=server
riscv@f40-vf2-saratoga:~/tonic/examples$ uname -a
Linux f40-vf2-saratoga 6.11.0-0.rc7.56.0.riscv64.fc41.riscv64 #1 SMP PREEMPT_DYNAMIC Mon Sep  9 12:03:16 EDT 2024 riscv64 GNU/Linux
riscv@f40-vf2-saratoga:~/tonic/examples$

riscv@f40-vf2-saratoga:~/tonic/examples$ rustc --version --verbose
rustc 1.82.0-nightly (506052d49 2024-08-16)
binary: rustc
commit-hash: 506052d49d3903ea554e4ce760cc53610cff4ef5
commit-date: 2024-08-16
host: riscv64gc-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0
riscv@f40-vf2-saratoga:~/tonic/examples$ cargo --version --verbose
cargo 1.82.0-nightly (2f738d617 2024-08-13)
release: 1.82.0-nightly
commit-hash: 2f738d617c6ead388f899802dd1a7fd66858a691
commit-date: 2024-08-13
host: riscv64gc-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Fedora 41.0.0 [64-bit]

root@f40-vf2-saratoga:/home/riscv/tonic/examples# history|grep dnf
dnf install git
dnf install @"C Development Tools and Libraries"
dnf install clang clang-tools-extra
dnf install lld
dnf install emacs-nox
dnf install glib-devel
dnf install glib-devel
dnf install glib2-devel
dnf install gdk-pixbuf2-devel
dnf install pango-devel
dnf install cairo-gobject-devel
dnf install gtk4-devel
dnf install screen
dnf install sqlite-devel
time dnf upgrade --best --allowerasing
dnf install protobuf-devel

time cargo +nightly build --bin routeguide-server --release --verbose


docs: fix link to analysis example

This should fix the currently failing markdown check

I'll close mine #2918


Right-to-left text renders badly

This project is incredible. I was wondering whether why right-to-left rendering fails.  Currently, all text appears as if it were in visual order (in practice: reversed), and shaping does not work at all.
The first order of things should be to fix ordering. One could hack the order by piping relevant RTL strings through fribidi, but Chrome already has icu library. I wonder why that does not work. The output renderer doesn't seem to have a notion of direction, yet it receives logical order strings?

Ah, that's an interesting one! It's because RTL text is sent in the LTR order with a flag saying it's RTL. I have an idea to ship a fix this week-end (reverse the string if RTL flag is on), but I'm not sure how to handle shaping. I never had to read Arabic in a terminal, but I know that no shaping makes it hard to read (f e e l s a b i t l i k e t h i s). I'm not sure if it'll be as much of a problem with Hebrew.
Do you use RTL languages on the terminal, and if yes does it get shaped properly?

I occasionally have some RTL filenames and such. I don't use terminal browsers with RTL because none of them work well - their failures have less to do with the text (most of them at least invert) but they don't understand RTL element positioning. Carbonyl gets that for free.
Ordering: Hebrew doesn't need shaping. If you want to start with just fixing the order, you can just visually compare Google itself: Google Hebrew
We can see that inverting the strings will work most of the time, but will somewhat fail on the right-most button (it's still understandable but not the intended result per the BiDi algorhytm).
Shaping, the best (AFAIK only) OSS solution is harfbuzz. It's difficult and has enough corner cases that I suggest finding a way to link it in if that's at all possible  Skia itself uses harfbuzz.


Filtering for locked page report

Allow the locked pages report to be filtered by 'locked at', 'locked by' and 'is live'.
Split out from #5940, to cover the parts of report filtering that do not depend on the workflow branch. Incorporates #5954.

Test added in 3c9c75817da34b1c6536336c92b07578d3bdfd2c.


Some revisions of the paper

Thanks for the additions and corrections.  You didn't ask, but I did want to mention that the author order is based on my evaluation of contributions, which are not completely reflected in the commit logs.

You didn't ask, but I did want to mention that the author order is based on my evaluation of contributions, which are not completely reflected in the commit logs.

That's totally fine for me. I just took the order of contributors shown by GitHub for the preliminary draft of the .zenodo.json.


Gulp-JSHint throws an "Invalid Reporter" error whenever the code for Reporter is updated

Hi,
I have created a reporter for JSHint that worked fine in the initial draft. The reporter mainly exports the log reports as an HTML file. However when I updated the codebase to include CSS support, the gulp task started throwing an error for "Invalid Reporter". The code for the reporter doesn't contain any error and I have included the module as a dev dependency in my package.json

Can you link to the code please?

Looks like there must be some other issue with the way you are consuming gulp-html-log. See my attempt to reproduce here: https://github.com/spalger/reproduce-gulp-jshint-136

Can you share your entire gulpfile in a gist or something?

Hi! Apologies for the delay in reply, you can find my codebase here -->
https://github.com/subzworld/gulp-html-log
Thanks,
Subroto.
On Mon, Feb 1, 2016 at 11:09 PM, Spencer<EMAIL_ADDRESS>wrote:

Can you share your entire gulpfile in a gist or something?
—
Reply to this email directly or view it on GitHub
https://github.com/spalger/gulp-jshint/issues/136#issuecomment-178089397
.

Closes #123


GUI for tangram-es desktop applications and deployment to s3 for internal usage

It will be good to have some gui elements for tangram-es desktop applications (OSX, Linux).
Some good C++ Opengl based UI libraries are: https://github.com/ocornut/imgui, https://github.com/wjakob/nanogui
Things to get done for this:

[ ] Debugging menu to toggle different debug options we have hidden in the demo apps
[ ] Ability to take a screen crab so that we can test out the "view ready" functionality.
[ ] Deployment of an osx app to s3 for internal consumption (usage).

Updated this Issue to have some more defined tasks. Feel free to add any thing I missed.

IMGUI has been integrated in the desktop demo app now, and it doesn't seem like we've had a very serious need to deploy the desktop build artifacts. I'll go ahead and close this.


Call to virtual function is being decompiled ignoring specified calling convention.

Submitting this as a question, as I have a feeling that it's not a bug, but rather my missunderstanding of Ghidra api.
Describe the question
I've a problem with how a call to virtual function is being decompiled.
To Reproduce
I've defined vtable for packet_t structure as follows.
Note that below is just a clike representation which was actually defined by using GUI interface (new->structure/new->function definition).
// function definition
[...]
undefined4 __thiscall packet_func1(packet_t*);
[...]

// virtual table definition
struct vtable_packet_t {
    [...]
    packet_func1* func1;
    [...]
};

struct packet_t {
    vtable_packet_t* vtable;
    [...]
};

Now sample foo function with a call to packet->vtable->func1:
                        **************************************************************
                        *                          FUNCTION                          *
                        **************************************************************
                        void __thiscall foo(packet_t * this, undefined4 param_2, undefined4 param_3)
                        assume FS_OFFSET = 0xffdff000
        void              <VOID>         <RETURN>
        packet_t *        ECX:4          this
        undefined4        Stack[0x4]:4   param_2
        int               Stack[0x8]:4   param_3
                        packet::foo
PUSH       ESI
MOV        ESI,this
MOV        EAX,dword ptr [ESI]
MOV        EDX,dword ptr [EAX + 0x4]
CALL       EDX

gets decompiled like this:
void __thiscall packet::foo(packet_t *this, undefined4 param_2, int param_3)
{
    undefined4 uVar1;
    uint uVar2;
    short *psVar3;
    packet_t *unaff_EBX;
    packet_t *unaff_ESI;
    int in_stack_0000000c;

    uVar1 = (*this->vtable->func1)(unaff_ESI);
    [...]

Expected behavior
I would expect it to use ecx register instead of esi register (as this is x86:LE:32:default windows architecture).
void __thiscall packet::foo(packet_t *this, undefined4 param_2, int param_3)
{
    undefined4 uVar1;
    uint uVar2;
    short *psVar3;
    packet_t *unaff_EBX;
    packet_t *unaff_ESI;
    int in_stack_0000000c;

    uVar1 = (*this->vtable->func1)(this);
    [...]

Environment
OS: Windows 11
Java Version: openjdk 17.0.5
Ghidra Version: 10.2.2
Ghidra Origin: official GitHub distro

I have run into a similar issue where I select the fastcall calling convention

But the resulting function call is being misinterpreted:

(where param_1 is in ECX and param_2 is in EDX)
I would expect it to generate
(*param_2->vptr->WriteInt)(param_2, &s_pack, 0x1)

instead. Changing the calling convention back and forth doesn't change anything either.

Don't quote me on this but I think the same problem arises when overriding a variadic function signature.

@kscieslinski Try creating a structure with the name of your class packet and putting as the first element in the structure a pointer to your vftable structure. Your function definitions should not include the this param in the definition, only the other params in the function.  When you put a function into a class, the decompiler should assign the same named structure to the this. It can get confused if there are more than one of the same name and may use the wrong one. I think it gets the first one it finds unless you set an option for the preferred location to look.

Hi. Sorry for late reply, but I missed the notification. Unfortunately the proposed solution did not worked.
Moreover wouldn't it work only for a functions usingthis calling convention? As noted by the other users, this seems to be a more general problem (as other calling conventions also do not work).

@kscieslinski @lmichaelis @astrelsky One of our developers was able to recreate an example that caused this scenario in 10.2.2. In their example it is no longer happening in 10.2.3. Would you try 10.2.3 and let us know if you are still seeing the issue or not? Thanks!

I don't have a sample on hand that demonstrates the problem. Just didn't want to leave you hanging without any response.

@kscieslinski @lmichaelis @astrelsky One of our developers was able to recreate an example that caused this scenario in 10.2.2. In their example it is no longer happening in 10.2.3. Would you try 10.2.3 and let us know if you are still seeing the issue or not? Thanks!

Thanks, I can verify that my original example does now decompile properly. I can also confirm that calling conventions other than __thiscall work correctly as well.
I should probably mention that I am using a file I've upgraded from Ghidra 10.1.2, though I have changed and re-assigned the calling conventions as well as auto-analyzed the entire binary again.