Error loading theme

https://github.com/Litarvan/lightdm-webkit-theme-litarvan/issues/37
I have this same issue that says there was a problem with the theme and that it needed to load the default. Im on manjaro and I installed through the aur

The official package should work fine.

you mean the non git from the aur? that is what I am using

There is no non git in the aur. The is a package in the official repos.
Please post the output of pacman -Qi lightdm-webkit-theme-litarvan.

yeah sorry I meant in the official repos
pacman -Qi lightdm-webkit-theme-litarvan ]   171/221   GB
Name            : lightdm-webkit-theme-litarvan       ▄▄█ ▄▄█ ▄▄█ ▄▄█ ▄▄█ ▄▄█ ▄▄█ ▄▄█
Version         : 3.1.0-1             Color palette   ██▀ ██▀ ██▀ ██▀ ██▀ ██▀ ██▀ ██▀
Description     : Modern and full-featured LightDM theme
Architecture    : any
URL             : https://github.com/Litarvan/lightdm-webkit-theme-litarvan
Licenses        : BSD
Groups          : None
Provides        : None
Depends On      : lightdm-webkit2-greeter
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 9.41 MiB
Packager        : Filipe Laíns<EMAIL_ADDRESS>Build Date      : Sat 21 Mar 2020 02:20:26 PM EDT
Install Date    : Sat 11 Apr 2020 07:24:20 PM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Okay, that is not from the aur, that is the official package. It works in Arch Linux so you either have LightDM misconfigured or Manjaro has a bug, in that case, please report the issue to them.

yeah I guess I mean the lightdm-slick-greeter works fine on my system

You need to change the greeter and configure it.
My configs:
/etc/lightdm/lightdm.conf
#
# General configuration
#
# start-default-seat = True to always start one seat if none are defined in the configuration
# greeter-user = User to run greeter as
# minimum-display-number = Minimum display number to use for X servers
# minimum-vt = First VT to run displays on
# lock-memory = True to prevent memory from being paged to disk
# user-authority-in-system-dir = True if session authority should be in the system location
# guest-account-script = Script to be run to setup guest account
# logind-check-graphical = True to on start seats that are marked as graphical by logind
# log-directory = Directory to log information to
# run-directory = Directory to put running state in
# cache-directory = Directory to cache to
# sessions-directory = Directory to find sessions
# remote-sessions-directory = Directory to find remote sessions
# greeters-directory = Directory to find greeters
# backup-logs = True to move add a .old suffix to old log files when opening new ones
# dbus-service = True if LightDM provides a D-Bus service to control it
#
[LightDM]
#start-default-seat=true
#greeter-user=lightdm
#minimum-display-number=0
#minimum-vt=7 # Setting this to a value < 7 implies security issues, see FS#46799
#lock-memory=true
#user-authority-in-system-dir=false
#guest-account-script=guest-account
#logind-check-graphical=false
log-directory=/var/log/lightdm
run-directory=/run/lightdm
#cache-directory=/var/cache/lightdm
#sessions-directory=/usr/share/lightdm/sessions:/usr/share/xsessions:/usr/share/wayland-sessions
#remote-sessions-directory=/usr/share/lightdm/remote-sessions
#greeters-directory=$XDG_DATA_DIRS/lightdm/greeters:$XDG_DATA_DIRS/xgreeters
#backup-logs=true
#dbus-service=true

#
# Seat configuration
#
# Seat configuration is matched against the seat name glob in the section, for example:
# [Seat:*] matches all seats and is applied first.
# [Seat:seat0] matches the seat named "seat0".
# [Seat:seat-thin-client*] matches all seats that have names that start with "seat-thin-client".
#
# type = Seat type (local, xremote, unity)
# pam-service = PAM service to use for login
# pam-autologin-service = PAM service to use for autologin
# pam-greeter-service = PAM service to use for greeters
# xserver-backend = X backend to use (mir)
# xserver-command = X server command to run (can also contain arguments e.g. X -special-option)
# xmir-command = Xmir server command to run (can also contain arguments e.g. Xmir -special-option)
# xserver-config = Config file to pass to X server
# xserver-layout = Layout to pass to X server
# xserver-allow-tcp = True if TCP/IP connections are allowed to this X server
# xserver-share = True if the X server is shared for both greeter and session
# xserver-hostname = Hostname of X server (only for type=xremote)
# xserver-display-number = Display number of X server (only for type=xremote)
# xdmcp-manager = XDMCP manager to connect to (implies xserver-allow-tcp=true)
# xdmcp-port = XDMCP UDP/IP port to communicate on
# xdmcp-key = Authentication key to use for XDM-AUTHENTICATION-1 (stored in keys.conf)
# unity-compositor-command = Unity compositor command to run (can also contain arguments e.g. unity-system-compositor -special-option)
# unity-compositor-timeout = Number of seconds to wait for compositor to start
# greeter-session = Session to load for greeter
# greeter-hide-users = True to hide the user list
# greeter-allow-guest = True if the greeter should show a guest login option
# greeter-show-manual-login = True if the greeter should offer a manual login option
# greeter-show-remote-login = True if the greeter should offer a remote login option
# user-session = Session to load for users
# allow-user-switching = True if allowed to switch users
# allow-guest = True if guest login is allowed
# guest-session = Session to load for guests (overrides user-session)
# session-wrapper = Wrapper script to run session with
# greeter-wrapper = Wrapper script to run greeter with
# guest-wrapper = Wrapper script to run guest sessions with
# display-setup-script = Script to run when starting a greeter session (runs as root)
# display-stopped-script = Script to run after stopping the display server (runs as root)
# greeter-setup-script = Script to run when starting a greeter (runs as root)
# session-setup-script = Script to run when starting a user session (runs as root)
# session-cleanup-script = Script to run when quitting a user session (runs as root)
# autologin-guest = True to log in as guest by default
# autologin-user = User to log in with by default (overrides autologin-guest)
# autologin-user-timeout = Number of seconds to wait before loading default user
# autologin-session = Session to load for automatic login (overrides user-session)
# autologin-in-background = True if autologin session should not be immediately activated
# exit-on-failure = True if the daemon should exit if this seat fails
#
[Seat:*]
#type=local
#pam-service=lightdm
#pam-autologin-service=lightdm-autologin
#pam-greeter-service=lightdm-greeter
#xserver-backend=
#xserver-command=X
#xmir-command=Xmir
#xserver-config=
#xserver-layout=
#xserver-allow-tcp=false
#xserver-share=true
#xserver-hostname=
#xserver-display-number=
#xdmcp-manager=
#xdmcp-port=177
#xdmcp-key=
#unity-compositor-command=unity-system-compositor
#unity-compositor-timeout=60
greeter-session=lightdm-webkit2-greeter
#greeter-hide-users=false
#greeter-allow-guest=true
#greeter-show-manual-login=false
#greeter-show-remote-login=true
#user-session=default
#allow-user-switching=true
#allow-guest=true
#guest-session=
session-wrapper=/etc/lightdm/Xsession
#greeter-wrapper=
#guest-wrapper=
#display-setup-script=
#display-stopped-script=
#greeter-setup-script=
#session-setup-script=
#session-cleanup-script=
#autologin-guest=false
#autologin-user=
#autologin-user-timeout=0
#autologin-in-background=false
#autologin-session=
#exit-on-failure=false

#
# XDMCP Server configuration
#
# enabled = True if XDMCP connections should be allowed
# port = UDP/IP port to listen for connections on
# listen-address = Host/address to listen for XDMCP connections (use all addresses if not present)
# key = Authentication key to use for XDM-AUTHENTICATION-1 or blank to not use authentication (stored in keys.conf)
# hostname = Hostname to report to XDMCP clients (defaults to system hostname if unset)
#
# The authentication key is a 56 bit DES key specified in hex as 0xnnnnnnnnnnnnnn.  Alternatively
# it can be a word and the first 7 characters are used as the key.
#
[XDMCPServer]
#enabled=false
#port=177
#listen-address=
#key=
#hostname=

#
# VNC Server configuration
#
# enabled = True if VNC connections should be allowed
# command = Command to run Xvnc server with
# port = TCP/IP port to listen for connections on
# listen-address = Host/address to listen for VNC connections (use all addresses if not present)
# width = Width of display to use
# height = Height of display to use
# depth = Color depth of display to use
#
[VNCServer]
#enabled=false
#command=Xvnc
#port=5900
#listen-address=
#width=1024
#height=768
#depth=8

/etc/lightdm/lightdm-webkit2-greeter.conf
#
# [greeter]
# debug_mode          = Greeter theme debug mode.
# detect_theme_errors = Provide an option to load a fallback theme when theme errors are detected.
# screensaver_timeout = Blank the screen after this many seconds of inactivity.
# secure_mode         = Don't allow themes to make remote http requests.
# time_format         = A moment.js format string so the greeter can generate localized time for display.
# time_language       = Language to use when displaying the time or "auto" to use the system's language.
# webkit_theme        = Webkit theme to use.
#
# NOTE: See moment.js documentation for format string options: http://momentjs.com/docs/#/displaying/format/
#

[greeter]
debug_mode          = false
detect_theme_errors = true
screensaver_timeout = 300
secure_mode         = true
time_format         = LT
time_language       = auto
webkit_theme        = litarvan

#
# [branding]
# background_images = Path to directory that contains background images for use by themes.
# logo              = Path to logo image for use by greeter themes.
# user_image        = Default user image/avatar. This is used by themes for users that have no .face image.
#
# NOTE: Paths must be accessible to the lightdm system user account (so they cannot be anywhere in /home)
#

[branding]
background_images = /usr/share/backgrounds
logo              = /usr/share/pixmaps/archlinux-logo.svg
user_image        = /usr/share/pixmaps/archlinux-user.svg

yeah thats how my configs look right now

The only thing I can think of that could cause this is the lightdm service not being active. Please report this to Manjaro.

yeah im doing that now

so im puting it here so that everyone can see it  but this is how my configs look
# General configuration
#
# start-default-seat = True to always start one seat if none are defined in the configuration
# greeter-user = User to run greeter as
# minimum-display-number = Minimum display number to use for X servers
# minimum-vt = First VT to run displays on
# lock-memory = True to prevent memory from being paged to disk
# user-authority-in-system-dir = True if session authority should be in the system location
# guest-account-script = Script to be run to setup guest account
# logind-check-graphical = True to on start seats that are marked as graphical by logind
# log-directory = Directory to log information to
# run-directory = Directory to put running state in
# cache-directory = Directory to cache to
# sessions-directory = Directory to find sessions
# remote-sessions-directory = Directory to find remote sessions
# greeters-directory = Directory to find greeters
# backup-logs = True to move add a .old suffix to old log files when opening new ones
# dbus-service = True if LightDM provides a D-Bus service to control it
#

[LightDM]
#start-default-seat=true
#greeter-user=lightdm
#minimum-display-number=0
#minimum-vt=7 # Setting this to a value < 7 implies security issues, see FS#46799
#lock-memory=true
#user-authority-in-system-dir=false
#guest-account-script=guest-account
#logind-check-graphical=false
#log-directory=/var/log/lightdm
run-directory=/run/lightdm
#cache-directory=/var/cache/lightdm
#sessions-directory=/usr/share/lightdm/sessions:/usr/share/xsessions:/usr/share/wayland-sessions
#remote-sessions-directory=/usr/share/lightdm/remote-sessions
#greeters-directory=$XDG_DATA_DIRS/lightdm/greeters:$XDG_DATA_DIRS/xgreeters
#backup-logs=true
#dbus-service=true

#
# Seat configuration
#
# Seat configuration is matched against the seat name glob in the section, for example:
# [Seat:*] matches all seats and is applied first.
# [Seat:seat0] matches the seat named "seat0".
# [Seat:seat-thin-client*] matches all seats that have names that start with "seat-thin-client".
#
# type = Seat type (local, xremote)
# pam-service = PAM service to use for login
# pam-autologin-service = PAM service to use for autologin
# pam-greeter-service = PAM service to use for greeters
# xserver-command = X server command to run (can also contain arguments e.g. X -special-option)
# xmir-command = Xmir server command to run (can also contain arguments e.g. Xmir -special-option)
# xserver-config = Config file to pass to X server
# xserver-layout = Layout to pass to X server
# xserver-allow-tcp = True if TCP/IP connections are allowed to this X server
# xserver-share = True if the X server is shared for both greeter and session
# xserver-hostname = Hostname of X server (only for type=xremote)
# xserver-display-number = Display number of X server (only for type=xremote)
# xdmcp-manager = XDMCP manager to connect to (implies xserver-allow-tcp=true)
# xdmcp-port = XDMCP UDP/IP port to communicate on
# xdmcp-key = Authentication key to use for XDM-AUTHENTICATION-1 (stored in keys.conf)
# greeter-session = lightdm-webkit2-greeter
# greeter-hide-users = True to hide the user list
# greeter-allow-guest = True if the greeter should show a guest login option
# greeter-show-manual-login = True if the greeter should offer a manual login option
# greeter-show-remote-login = True if the greeter should offer a remote login option
# user-session = Session to load for users
# allow-user-switching = True if allowed to switch users
# allow-guest = True if guest login is allowed
# guest-session = Session to load for guests (overrides user-session)
# session-wrapper = Wrapper script to run session with
# greeter-wrapper = Wrapper script to run greeter with
# guest-wrapper = Wrapper script to run guest sessions with
# display-setup-script = Script to run when starting a greeter session (runs as root)
# display-stopped-script = Script to run after stopping the display server (runs as root)
# greeter-setup-script = Script to run when starting a greeter (runs as root)
# session-setup-script = Script to run when starting a user session (runs as root)
# session-cleanup-script = Script to run when quitting a user session (runs as root)
# autologin-guest = True to log in as guest by default
# autologin-user = User to log in with by default (overrides autologin-guest)
# autologin-user-timeout = Number of seconds to wait before loading default user
# autologin-session = Session to load for automatic login (overrides user-session)
# autologin-in-background = True if autologin session should not be immediately activated
# exit-on-failure = True if the daemon should exit if this seat fails
#

[Seat:*]
#type=local
#pam-service=lightdm
#pam-autologin-service=lightdm-autologin
#pam-greeter-service=lightdm-greeter
#xserver-command=X
#xmir-command=Xmir
#xserver-config=
#xserver-layout=
#xserver-allow-tcp=false
#xserver-share=true
#xserver-hostname=
#xserver-display-number=
#xdmcp-manager=
#xdmcp-port=177
#xdmcp-key=
greeter-session = lightdm-slick-greeter
#greeter-hide-users=false
#greeter-allow-guest=true
#greeter-show-manual-login=false
#greeter-show-remote-login=true
#user-session=default
#allow-user-switching=true
#allow-guest=true
#guest-session=
session-wrapper=/etc/lightdm/Xsession
#greeter-wrapper=
#guest-wrapper=
#display-setup-script=
#display-stopped-script=
#greeter-setup-script=
#session-setup-script=
#session-cleanup-script=
#autologin-guest=false
#autologin-user=
#autologin-user-timeout=0
#autologin-in-background=false
#autologin-session=
#exit-on-failure=false

#
# XDMCP Server configuration
#
# enabled = True if XDMCP connections should be allowed
# port = UDP/IP port to listen for connections on
# listen-address = Host/address to listen for XDMCP connections (use all addresses if not present)
# key = Authentication key to use for XDM-AUTHENTICATION-1 or blank to not use authentication (stored in keys.conf)
# hostname = Hostname to report to XDMCP clients (defaults to system hostname if unset)
#
# The authentication key is a 56 bit DES key specified in hex as 0xnnnnnnnnnnnnnn.  Alternatively
# it can be a word and the first 7 characters are used as the key.
#
autologin-user=zany130

autologin-user-timeout=20

[XDMCPServer]
#enabled=false
#port=177
#listen-address=
#key=
#hostname=

#
# VNC Server configuration
#
# enabled = True if VNC connections should be allowed
# command = Command to run Xvnc server with
# port = TCP/IP port to listen for connections on
# listen-address = Host/address to listen for VNC connections (use all addresses if not present)
# width = Width of display to use
# height = Height of display to use
# depth = Color depth of display to use
#

[VNCServer]
#enabled=false
#command=Xvnc
#port=5900
#listen-address=
#width=1024
#height=768
#depth=8

[greeter]
debug_mode          = Greeter theme debug mode.
detect_theme_errors = Provide an option to load a fallback theme when theme errors are detected.
screensaver_timeout = Blank the screen after this many seconds of inactivity.
secure_mode         = Don't allow themes to make remote http requests.
time_format         = A moment.js format string so the greeter can generate localized time for display.
time_language       = Language to use when displaying the time or "auto" to use the system's language.
webkit_theme        = Webkit theme to use.

NOTE: See moment.js documentation for format string options: http://momentjs.com/docs/#/displaying/format/

[greeter]
debug_mode          = false
detect_theme_errors = true
screensaver_timeout = 300
secure_mode         = true
time_format         = LT
time_language       = auto
webkit_theme = litarvan

[branding]
background_images = Path to directory that contains background images for use by themes.
logo              = Path to logo image for use by greeter themes.
user_image        = Default user image/avatar. This is used by themes for users that have no .face image.

NOTE: Paths must be accessible to the lightdm system user account (so they cannot be anywhere in /home)

[branding]
background_images = /usr/share/backgrounds
logo              = /usr/share/pixmaps/archlinux-logo.svg
user_image        = /usr/share/pixmaps/archlinux-user.svg

I have exactly the same issue on the following versions:
[marek@marecki-pc ~]$ LANG=C pacman -Qi lightdm-webkit-theme-litarvan lightdm-webkit2-greeter
Name            : lightdm-webkit-theme-litarvan
Version         : 3.1.0-1
Description     : Modern and full-featured LightDM theme
Architecture    : any
URL             : https://github.com/Litarvan/lightdm-webkit-theme-litarvan
Licenses        : BSD
Groups          : None
Provides        : None
Depends On      : lightdm-webkit2-greeter
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 9.41 MiB
Packager        : Filipe La
Build Date      : Sat Mar 21 19:20:26 2020
Install Date    : Sun Apr 26 00:04:01 2020
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Name            : lightdm-webkit2-greeter
Version         : 2.2.5-2
Description     : LightDM greeter that uses WebKit2 for theming via HTML/JavaScript.
Architecture    : x86_64
URL             : https://github.com/antergos/web-greeter
Licenses        : GPL3
Groups          : None
Provides        : None
Depends On      : lightdm  webkit2gtk  accountsservice  gnome-backgrounds
Optional Deps   : None
Required By     : lightdm-webkit-theme-litarvan
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 2.78 MiB
Packager        : Filipe La
Build Date      : Sun Sep 16 23:03:25 2018
Install Date    : Sun Apr 26 00:04:00 2020
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

Specific error is undefined is not an object r.desktop.username
What's strange, issue doesn't occur if I start lightdm-webkit2-greeter from terminal on already logged in user.

I also have this issue and I was able to get it working.
Although it feels laggy, I don't know if that is how it should be.
First, lines 27 and 28 in the settings.js:
changed from
lightdm.users.forEach(u => settings.user.username === u.username && (settings.user = u));
lightdm.sessions.forEach(s => settings.desktop.username === s.key && (settings.desktop = s));

to
lightdm.users.forEach(u => lightdm.users[0].username === u.username && (settings.user = u));
lightdm.sessions.forEach(s => lightdm.sessions[0].username === s.key && (settings.desktop = s));

Then everything was more or less working but LightDM was popping up the fallback message all the time. Another TypeError in the icon selection.
Modified the code around line 28 in the SelectItem.vue file from:
                        let key = this.item.key.toLowerCase();

to
                    let key = 'i3';
                    if (typeof this.item.key !== 'undefined'){
                        let key = this.item.key.toLowerCase();
                    }

After that I build again the tar package and everything was more or less working.
It seems to me that some package update broke this code somehow as the package is "compiled" with the @babel/preset-env package among others.

Same issue on arch so it's not a Manjaro thing. @FFY00 Haven't tried @osalas88 suggestion yet

I am having the same problems with the latest version on the latest arch kernel. I have even tried reinstalling it once.

Same issue, can't load the theme at all.

I have no longer had the issue for a long time but may just be a coincidence.

I tried fixing this on 3.2.0, please let me know if it's working for you

I have build it directly from the git and now it is really smooth, nothing else to report.
Thanks!

I think I can close this then, if anyone is still having the same issue feel free to comment and I will reopen it.


Metal backend

New low-ish level graphics API from Apple:
https://developer.apple.com/metal/
Supports desktop macs and mobile iOS devices.
Complexity-wise, should be similar to DX12/Vulkan with simplified resource management.
Bindings can be found at https://github.com/fkaa/metal-rs

Mostly done by @fkaa 's awesome work in #969


chore(integration): submit Sales Prediction App using uAgents for Fetch.ai hackathon

Sales Prediction App
Overview
This repository contains a Sales Prediction Application that utilizes Flask for the backend, uAgents for agent-based operations, and a custom-developed machine learning model for predicting future sales based on historical data. The application is designed to provide businesses with actionable insights into future sales trends, helping them make informed decisions.
Features

Custom Sales Prediction Model: Developed using historical sales data, this model predicts future sales with high accuracy.
Flask Backend: Manages API requests, handles data processing, and serves the model predictions.
uAgents Integration: Uses uAgents for decentralized and scalable processing of sales data.
CSV Upload: Users can upload their sales data in CSV format for analysis and prediction.

Installation
Prerequisites
Ensure you have the following installed on your system:

Python 3.8 or higher
pip (Python package manager)
Flask
uAgents
(Any other dependencies, such as pandas, scikit-learn, etc.)

Setup Instructions

Clone the repository:
git clone https://github.com/your-username/sales-prediction-app.git
cd sales-prediction-app

Create a virtual environment:
python3 -m venv venv
source venv/bin/activate   # On Windows use `venv\Scripts\activate`

Install dependencies:
pip install -r requirements.txt

Run the Flask application:
   python app.py

uAgents Integration
This application uses uAgents for distributed processing, allowing it to handle large datasets and complex operations efficiently. The uAgents are configured to:
Receive and Process Data: Agents receive sales data from the Flask backend and preprocess it for prediction.
Model Execution: uAgents handle the execution of the custom prediction model, ensuring scalability and robustness.
Return Predictions: Processed predictions are sent back to the Flask backend for user access.
Usage

Uploading Data:

Navigate to the /upload endpoint to upload your CSV file containing historical sales data.
The CSV file should have columns like Date, Sales, Product_ID, etc., depending on the model's requirements.

Making Predictions:

After uploading the data, navigate to the /predict endpoint.
The model will process the data and return predictions for future sales.

Viewing Results:

Predictions can be viewed directly on the web interface or downloaded as a CSV file for further analysis.
Future Enhancements:

Real-time Prediction: Implementing real-time sales prediction using streaming data.
Advanced Visualization: Adding advanced data visualization features to the web interface.
User Authentication: Securing the app with user authentication and role management.

Hello @Shivaraj-Kolekar great idea but there are a lot of files here which we think could be reduced.
I am going to close this PR as it needs some refactoring, please do resubmit to https://github.com/fetchai/uAgent-Examples under /community folder.
Thanks!


C++: Minimal caching of the IR type system

(follow-up to #2008)
This was the minimal amount of predicates I could easily cache without introducing extra cached stages. The predicates that are not cached here, like CppType::getTypeSize and getCanonicalLanguageType, appear to be cheap.
I've tested that this avoids recomputation of the IR type system by running
grep -c 'Starting to evaluate predicate CppType::CppType::getIRType_dispred'

on the evaluator log for IRSanity.ql. It drops from 4 to 1. The pretty-printed DIL drops from 79,175 lines to 76,326 lines.

You should probably add similar caching on the C# side as well (CSharpType, CSharpType.getIRType()).

Done.


Disable autoplay timer when prop changes to false

This fixes the issue of the swiper transitioning one more time after setting autoplay to false.

👍 thanks


serious error configuring DeepChat with Svelte

Using the playground here:  https://stackblitz.com/edit/deep-chat-svelte?file=src%2FApp.svelte
I try adding config in the form of for example:
submitButtonStyles='{
   "submit": {
     "container": {
       "default": {
         "transform": "scale(1.21)",
         "marginBottom": "-3px",
         "marginRight": "0.4em"
       }
     }
   }
 }'

So now the example component is:

Deep Chat

  <deep-chat
    demo={true}
    textInput={{placeholder:{text: "Welcome to the demo!"}}}
    initialMessages={initialMessages}
    submitButtonStyles='{
    "submit": {
      "container": {
        "default": {
          "transform": "scale(1.21)",
          "marginBottom": "-3px",
          "marginRight": "0.4em"
        }
      }
    }
  }'
  />

We get a parse error telling us we are missing a '}' on the first line of any quoted struct .
I've tried this with projects setup for js and ts.  Same result.

Hi @jhancock.
The syntax you should be using for properties in Svelte is double curly braces - {{}}.
So relating to your example for submitButtonStyles, it should be as follows:
submitButtonStyles={{
  "submit": {
    "container": {
      "default": {
        "transform": "scale(1.21)",
        "marginBottom": "-3px",
        "marginRight": "0.4em"
      }
    }
  }
}}

To note, the double quotes for property names in the example above are optional.

Brilliant!  Thanks for the quick reply.  I went to bed last night thinking this must have something to do with Svelte.  Couldn't find example of how to encode the params this way.


Add new NUMBER option type (https://discord.com/developers/docs/int…

https://discord.com/developers/docs/interactions/slash-commands#application-command-object-application-command-option-type

Could you add it to the Slash command option deserializer

Done. Was trying to see where else it was used but my local project was slightly outdated and didn't contain this ;P


update documentation

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


small visual glitch creating action

Issues

If you're having trouble with Articulate we definitely want to help you. If you can provide a little bit of information it will make our troubleshooting job easier.
Small visual glitch when creating an action for the first time I just noticed: Seems to be Firefox issue, not reproducing on Chrome.

Did you download a release or pull from Master? Which release?
27.2
What operating system are you running?
10 pro
Are you running locally or in the cloud?
local
Which browser are you using?
FF

I asked @RussellSPG for a guide to replicate this one as I don't see the issue in my instance


Accept More Move Formats

Currently, you have to enter your move as two separate capitalized coords, e.g. A2 + B3.  This could be improved in several ways:

Make this case-insensitive (50 XP): A6 is the same as a6.
Make this order-independent (50 XP): A6 is the same as 6A.
Make this enterable as a single line (50 XP): A6 + B5 is the same as A6 B5.

That last one will probably be very helpful if you decide to do https://github.com/UCSB-CS56-Projects/cs56-games-checkers/issues/11...

Fixed in https://github.com/UCSB-CS56-Projects/cs56-games-checkers/pull/27.  Full 150 XP from this issue plus 50 bonus XP for reworking the parse function (see the PR comments).
I'll close this once I record your points.
+200 XP

Fixed in https://github.com/UCSB-CS56-Projects/cs56-games-checkers/pull/26.


UX improvements

As per customer suggestion:

in calendar view it would be handy if weekend are highlighted in
different colour or at least in bold text.

Weekends do have different backgound in current version 0.5.0
Nothing to do for this ticket.

As per comment above: closing.


Review and refactor Tessera CLI code

Future plans will expand the functionality of the admin cli.
The CLI code should be modularised up to make it easier to make changes to existing/add new CLIs in the future.

Resolved by #754


This makes the smear correction work

The secret to success was not assuming that the first science pixel column is 0, it is 12!

Thanks Dr. Barentsen!


Rewrite singleton data types

Currently we have patterns as follows:
type family ArgProtData (t :: ArgumentType) where
  ArgProtData 'IntWAT = Maybe WLEnum
  ArgProtData 'UIntWAT = Maybe WLEnum
  ArgProtData 'FixedWAT = ()
  ArgProtData 'StringWAT = ()
  ArgProtData 'ObjectWAT = Maybe WLInterface
  ArgProtData 'NewIdWAT = Maybe WLInterface
  ArgProtData 'ArrayWAT = ()
  ArgProtData 'FdWAT = ()
data ArgProtDataBox = forall t. ArgProtDataBox (SArgumentType t) (ArgProtData t)

type family WireArgument (t :: ArgumentType) where
  WireArgument 'IntWAT = Int32
  WireArgument 'UIntWAT = Word32
  WireArgument 'FixedWAT = Fixed23_8
  WireArgument 'StringWAT = B.ByteString
  WireArgument 'ObjectWAT = Word32
  WireArgument 'NewIdWAT = Word32
  WireArgument 'ArrayWAT = B.ByteString
  WireArgument 'FdWAT = ()
data WireArgBox = forall t. WireArgBox (SArgumentType t) (WireArgument t)

First of all, the constructor names are a bit long. Secondly, we can replace the box type definitions by something like this:
data ArgBox (f :: ArgumentType -> *) = forall t . (SArgumentType t) :=> (f t)
infixr 1 :=>

(here, I'm stealing syntax from dependent-sum)
And now we could obtain the original types as:
type ArgProtDataBox = ArgBox ArgProtData
type WireArgBox = ArgBox WireArgument

This will make a bunch of code more concise.
TODO: care about strictness?

As it turns out, this actually doesn't work because type families usually have to be used "completely evaluated". That means that the expression ArgProtData in the line
type ArgProtDataBox = ArgBox ArgProtData

is invalid. To fix it, you would need to introduce more data types, which is exactly what I thought we could avoid. So this scheme doesn't really help us.


Support a progress handler

Some Promise libraries support the addition of a progress handler. It is meant for communicating progress in long-running operations (some more discussion here).
What are your thoughts on implementing this handler in PromiseKit? I have a specific use case that I've seen other libraries deal with using progress handlers:

I have a network request (that returns a Promise) that may or may not hit a shared NSURLCache. In case it does, and if the user explicitly sets it (via a new NSURLRequestCachePolicy), the request serves the cached data and then fetches from the network anyway. This is so that the user gets potentially stale data immediately while fresh data is being fetched in the background.

I would possibly like to use progress to support this use case, serving the cached data through this handler and then the final, fresh, data through the normal fulfillment handler.
Other than using progress, do you see any potential way of supporting this behaviour using just the two currently supported handlers?
Thank you!

Looks like progress in URLSessionTask is lazy now. Currently NSURLSession+Promise hides task inside, so there is no way to access to task's progress to initiate its creation.
In mentioned below code parentProgress not changing:
    let parentProgress = Progress(totalUnitCount: 1)
    parentProgress.becomeCurrent(withPendingUnitCount: 1)
    let promise = URLSession.shared.dataTask(.promise, with: request)
    parentProgress.resignCurrent()

but, after adding _ = task.progress, it will work properly:
    public func dataTask(_: PMKNamespacer, with convertible: URLRequestConvertible) -> Promise<(data: Data, response: URLResponse)> {
        return Promise { seal in
            let task = dataTask(with: convertible.pmkRequest, completionHandler: adapter($0))
            _ = task.progress
            task.resume()
        }
    }

Ticket pls


nuttx/sched: semaphore and mqueue task list optimize

Summary
Add CONFIG_TASK_LIST_OPTIMIZE feature to improve sem and mqueue performance.

move waitingforsemaphore list to sem_s；
move waitingformqnotempty and waitingformqnotfull list to mqueue_inode_s;

depends on https://github.com/apache/incubator-nuttx/pull/7185
Impact
Code Size:
Before:
   text	   data	    bss	    dec	    hex	filename
 109692	    224	  24940	 134856	  20ec8	nuttx

After:
Disable CONFIG_TASK_LIST_OPTIMIZE
   text	   data	    bss	    dec	    hex	filename
 109732	    224	  24940	 134896	  20ef0	nuttx

Enable CONFIG_TASK_LIST_OPTIMIZE
   text	   data	    bss	    dec	    hex	filename
 109924	    312	  25144	 135380	  210d4	nuttx

Performance:
20 semaphore and 20 threads with different priorities.
sem_post -> sem_wait (cycle count):
before:
8179
after:
6988
Testing
sabre-6quad:nsh

let rebase the patch

@pkarashchenko the break is fixed here https://github.com/apache/incubator-nuttx-apps/pull/1321

@pkarashchenko please review the change where conflict with your priority inheritance change.

This approach goes in conflict with https://github.com/apache/incubator-nuttx/pull/6318 sched/semaphore/sem_holder.c line 436 that tries to find the task with highest priority that is waiting for the semaphore held by the task. I need some more time to think how to implement fix priority restoration in case we move the list to semaphore

Yeah, seems it becomes even easier with this change. I just need to pick the first waiter with priority inheritance enabled from each holder list and get the maximum priority among waiters. And execution time will be improved tremendously in such case as we switch search complexity from O(2) to O(1).

In file included from /github/workspace/sources/nuttx/include/nuttx/semaphore.h:31,
                 from /github/workspace/sources/nuttx/include/nuttx/mutex.h:32,
                 from /github/workspace/sources/nuttx/include/nuttx/fs/fs.h:38,
                 from /github/workspace/sources/nuttx/include/stdio.h:34,
                 from /github/workspace/sources/apps/system/libuv/libuv/include/uv.h:55,
                 from libuv/src/unix/core.c:21:
Error: /github/workspace/sources/nuttx/include/semaphore.h:106:3: error: unknown type name 'dq_queue_t'
  106 |   dq_queue_t waitlist;
      |   ^~~~~~~~~~
make[3]: *** [/github/workspace/sources/apps/Application.mk:148: core.c.github.workspace.sources.apps.system.libuv.o] Error 1

@xiaoxiang781216 probably libuv patches should be modified.

@pkarashchenko the break is fixed here https://github.com/apache/incubator-nuttx-apps/pull/1321

@xiaoxiang781216 let's better move include/queue.h to include/nuttx/queue.h

@zyfeier please rebase the patch to the last master.

LGTM.

Sure.

@zyfeier
In the PR comment, you wrote
Add CONFIG_TASK_LIST_OPTIMIZE feature to improve sem and mqueue performance.

However, I can not see the config.

@zyfeier In the PR comment, you wrote
Add CONFIG_TASK_LIST_OPTIMIZE feature to improve sem and mqueue performance.

However, I can not see the config in the commits.

CONFIG_TASK_LIST_OPTIMIZE has been removed，i'll update the PR comment.

@xiaoxiang781216 @zyfeier Let me try this PR later.

@masayuki2009 how about you test result?

@masayuki2009 how about you test result?

@xiaoxiang781216
I confirmed that all the tests passed.

Thanks very much to verify the change.


Name
Kestra
Website
https://kestra.io/
Logos
https://kestra.io/logo-white.svg
https://kestra.io/logo.svg
The Legal Stuff

[X] My organization consents to their logo being displayed on the Eclipse Temurin adopters page.

PR at https://gitlab.eclipse.org/eclipsefdn/it/api/eclipsefdn-project-adopters/-/merge_requests/219


OS versions out of date

should Windows 11 and Windows Server 2022 be included in the OS list?

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

ID: e526d827-05b8-8e9a-80f5-c43562c1e182
Version Independent ID: d8ea3163-5966-754a-0773-c4b40dd12654
Content: Introduction to Windows Machine Learning
Content Source: docs/windows-ml/index.md
Product: machine-learning
GitHub Login: @rosanevallim
Microsoft Alias: rovalli

This repo has changed significantly since this issue was first raised, and further changes are upcoming. As such, I'm going through and closing many of these stale issues which sat unassigned for a long while.


Crash on password protected zip

Prerequisites

[x] Did you read FAQ section?
[x] Did you test with the latest releases or commit ?
Used latest release. See version below

Description
Got error that zip file is encrypted and that an image can't be extracted.
Steps to Reproduce

Enable image verification in the config.ini
Download zip file that is encrypted with a password (f1 mode used, fanbox)

Expected behavior:
Zip file to remain intact, or images to be extracted. Download
Actual behavior:
Crashes as images inside the zip can't be accessed without a password.
Traceback (most recent call last):
  File "PixivUtil2.py", line 270, in download_image
  File "zipfile.pyc", line 901, in testzip
  File "zipfile.pyc", line 993, in open
RuntimeError: File cover.jpg is encrypted, password required for extraction
Error at download_image(): (<type 'exceptions.RuntimeError'>, RuntimeError('File cover.jpg is encrypted, password required for extraction',), <traceback object at 0x042BE030>) at [REDACTED link for privacy reasons] (9000)
Traceback (most recent call last):
  File "PixivUtil2.py", line 2369, in main
  File "PixivUtil2.py", line 2126, in main_loop
  File "PixivUtil2.py", line 1876, in menu_fanbox_download_supported_artist
  File "PixivUtil2.py", line 1925, in processFanboxArtist
  File "PixivUtil2.py", line 1978, in processFanboxImages
  File "PixivUtil2.py", line 270, in download_image
  File "zipfile.pyc", line 901, in testzip
  File "zipfile.pyc", line 993, in open
RuntimeError: File cover.jpg is encrypted, password required for extraction
press enter to exit.

Workaround
Disable verification of images.
Personally, i enabled the verificaiton just to be on the safe side. Either way, not a big deal for me. However, i wanted to report the error in case you just wanna catch the error and just print that verification is skipped in this case.
Versions
PixivDownloader2 version 20190919

do you have the post id that I can use to replicate just in case?


The RWX volumes are not available while adding a disk to a VM

Steps to reproduce:

Create a volume, setting its Access Mode as RWX
Edit a VM, add a disk from an existing volume

Result:
The RWX volumes are not available in the volume dropdown which does not make sense

Need more investigation


Fix #146

Fix issue #146

Changes on processTo have move some pixels on existing tests:

issue25
issue57b
issue72

Fixtures seem to be a bit tricky

Hello, committed a version without changes on tests:

issue25
issue57b
issue72

Thank you, @jesnault


Infinite loop from blocked request

Hi, when I try to access rescript-lang.org/ the page stays blank and my browser makes an infinite loop of requests.
Here's a screenshot of how it looks.

It seems like one request is being blocked (I'm using Firefox with uBlock Origin with 3rd party scripts blocked by default), and that seems to cause the issue.  It would be great if this could be handled more gracefully.
Thanks!

Related to #528


Update Python Client - c9bdc78

(This PR was generated by a GitHub action)

Thanks for finding the solution @samredai . @shangyian would you like to do the honors (of merging)?


[BUG] Make slice produce undefined values

Description
About slices in the manual:

At the example above, the s variable is 20 sized slices and all elements initialized with default value.

    let slice = make([]int, 6)
    outln(slice)
    // [94373079838218 0<PHONE_NUMBER>967900464<PHONE_NUMBER>052596788<PHONE_NUMBER>513079344 13618]

Expected behavior
I was expecting slice to be filled with "default values" and since its type is explicit as: Int that is 0 (Zero), instead it seem to produce undefined - garbage data
Current behavior
No response
Additional information
julec version beta 0.0.6 @master

This is absolutely unexpected behavior.
I'll investigate this.
Thanks.


Multi-Model Support + .env configuration file

Also added default so if no arguments are supplied to ingest, it just uses the .env DOCUMENTS_DIRECTORY
P.S. Must rename example.env to .env to use

thanks for the effort. i was on this right now too haha.
let me run a brief check and then up we go.

Got bored working on an auto convert script. I got it done, Ill send a PR if you want to look at it. Basically it uses the .env to look at your LLM model_path and checks the models type. If it is ggml, it converts it to ggjt. If its already ggjt, it does nothing and exits. Could probably call it from the ingest and/or startllm based on a .env CONVERT_OLD_MODEL=True or something. Just an idea.

Got bored working on an auto convert script. I got it done, Ill send a PR if you want to look at it. Basically it uses the .env to look at your LLM model_path and checks the models type. If it is ggml, it converts it to ggjt. If its already ggjt, it does nothing and exits. Could probably call it from the ingest and/or startllm based on a .env CONVERT_OLD_MODEL=True or something. Just an idea.

Testing something similiar by probing the binary itself with magicbytes. And auto-detecting if it has a gptj backend.
Glad your are so productive, I'd welcome such an addition. Just set a auto_convert variable inside .env. If true the convertion is done.


Updated Readme.md of the Quotes-Extension.

Added the new screenshots.

Great 👍

@AKD-01 added labels on PR #196

@AKD-01 what is your issue number, tag it here


Typo in permissions "\u003Call_urls>"

On the manifest.json the permission should be <all_urls>

Fair enough !


GCC 10 complains about  multiple definition of trace_flag

the project cant be built without -fcommon added to CFLAGS
See : https://gcc.gnu.org/gcc-10/porting_to.html

Global variables have been fixed and now DMRconfig compiles with GCC 10 and its default-fno-common
Fix in commit 1a69014

Global variables have been fixed and now DMRconfig compiles with GCC 10 and its default-fno-common
Fix in commit 1a69014


[CPU] Add support for pack ukernel preparation.

The pack ukernel only works for 2D cases. Similar to what's happening in
batch_mmt4d, The revision adds the support to convert 3D pack into 2D
pack.

The PR is on top of https://github.com/iree-org/iree/pull/17471, please review the last commit.


[Relay] Add TopPattern to nn.dropout

nn.dropout is usually simplified in inference, but not for training, so we need to make up this attribute to make sure the model with nn.dropout can pass all Relay passes.
cc @anijain2305

Was this related with https://discuss.tvm.apache.org/t/toppattern-has-not-been-registered-for-nn-dropout/11305?
@AndrewZhaoLuo mentioned that

Dropout isn’t really supported

But actually here is an registration.

Hey Lyken, this isn't really registering compute, instead it's registering an attribute saying this operator should not be fused with anything if I understand it correctly. Don't know the full context though.


Store states when they arrive

I reverted this PR, as it was not immediately compatible with Alex's work in https://github.com/statechannels/monorepo/pull/1009.
The PR also does a bit more than billed, making some non-trivial changes to the interface to the store. These changes aren't used anywhere in the PR, so I was hoping to understand more about why they were made. These include:

Changing the behaviour of createChannel, so it no-longer creates the initial state.

Are there any examples where we don't know the initial state at the time we create the channel?

Changing createChannel to return a ChannelStoreEntry, instead of the channelId.

The original intention was to try and keep the surface area of the new store small. I understand that we decided to make a ChannelStoreEntry object back initially, to help with existing protocols, but is it required here?

Splitting the existing addState method into two public methods: signState and addState.

It isn't clear why we need the other external method - it seems like we either add states from protocols (currently addState), or from external messsges (currently pushMessage).
I chose addState over signState originally, as I was concerned that signState didn't give any indication that state was being stored and synced, and it seemed more intuitive to understand that signing and syncing would happen automatically when adding a state to a channel. Some alternatives:  signAndSendState, addToChannel?

Happy for the PR to be resubmitted once it's been rebased onto the updated master.

I reverted this PR, as it was not immediately compatible with Alex's work in #1009.
The PR also does a bit more than billed, making some non-trivial changes to the interface to the store. These changes aren't used anywhere in the PR, so I was hoping to understand more about why they were made.

The point of this PR is that pushMessage does not store states. Prior, there was no way to actually do this: there were only two ways to get states into the store: addState and createChannel. Neither of these methods accept a signature, and internally, the store signs states with the user's private key.

These include:

Changing the behaviour of createChannel, so it no-longer creates the initial state.

Are there any examples where we don't know the initial state at the time we create the channel?

I don't know. But if my wallet receives a signed state for you, it can't store it if nothing exists at this.channels[channelId]. It's obviously unwise to blindly sign that state on arrival, so createChannel should not sign on the user's behalf.

Changing createChannel to return a ChannelStoreEntry, instead of the channelId.

The original intention was to try and keep the surface area of the new store small. I understand that we decided to make a ChannelStoreEntry object back initially, to help with existing protocols, but is it required here?
Given that ChannelStoreEntry exposes a channelId property, this is strictly an increase in functionality:
const channelId = createChannel(...) can be written as const { channelId } = createChannel(...)

Returning a ChannelStoreEntry means you can replace this with something like
const channelStorage = await this.getEntry(channelId) || await this.createChannel(state)

Splitting the existing addState method into two public methods: signState and addState.

It isn't clear why we need the other external method - it seems like we either add states from protocols (currently addState), or from external messsges (currently pushMessage).
I chose addState over signState originally, as I was concerned that signState didn't give any indication that state was being stored and synced, and it seemed more intuitive to understand that signing and syncing would happen automatically when adding a state to a channel. Some alternatives:  signAndSendState, addToChannel?

pushMessage currently does not add states to the store. This PR changes this, by having pushMessage call addState. It's more surprising to me that addState signs the state for me, than that signState stores the state for me. If I ever witness a signed state, I want to store it unless I have a good reason to discard it. This includes states that I sign.
It doesn't matter if it's called signState or signAndAdd state, but there needs to be some method with signature (signedState: SignedState) => any which stores signed states; it's just as well for signStateOrWhateverItsCalled to call that method.

You're right that, as it's currently written, pushMessage doesn't store states, and that that bit needs to be added. It doesn't seem like that necessarily means that the other methods should change though? The intention was that there would be three ways of getting a state into the store:

createChannel: called by the wallet owner's protocols, when they want to create a channel, and set the initial state
addState: called by the wallet owner's protocols, when they want to add a state to an existing channel
pushMessage: which unpacks messages from opponents, and adds the states, creating channels if necessary. Called directly from the messaging layer, and not by the wallet owner's protocols.

Regardless of what we call add/sign/signAndAddState, I don't believe we need to add an extra method to the external store interface?

Regardless of what we call add/sign/signAndAddState, I don't believe we need to add an extra method to the external store interface?

Hm, yes, so the simple thing to do is remove [addState](https://github.com/statechannels/monorepo/pull/1012/files#diff-550d8631da011300e059fa60a006db77R54) from the store API (and then rename as we wish.)

I think (?) addState is one of the things that is now in use after #1009, so it might be better to just rename.

I think (?) addState is one of the things that is now in use after #1009, so it might be better to just rename.

https://github.com/statechannels/monorepo/pull/1016/commits/f3e5a26f1f6967161ac9b5da7842dd6cf1de5602


feat: unify metrics ( cleanup and add missing metrics )

Resolves #2218
The PR aims to have unified metrics.
Currently we are exposing metrics for different sources/sinks(kafka, http etc) in addition to forwarder metrics.
Cleanup of such metrics as well as addition of any missing metrics

How have you tested it?

@KeranYang @kohlisid @yhl25 - please review.

You probably noticed that one of the e2e tests is failing. It's because the vertex processing rate calculation stopped working. This is because in numaflow, for each vertex, we use forwarder_data_read_total metric to calculate processing rate. See here. Please make sure that we don't change this name for ALL type of vertices. @adarsh0728

Thanks, checking

@adarsh0728 please take a look at https://github.com/numaproj/numaflow/blob/main/pkg/daemon/server/service/rater/rater_test.go#L63 to understand how the metric is used to calculate data processing rate and see if your PR somehow breaks the contract.

@KeranYang @whynowy: I think I got the issue.

TestUserDefinedSourceSuite test case is failing which involves testing testSimpleSource. To calculate processing rates, client.GetVertexMetrics(context.Background(), pipelineName, vertexName) is called here

Here, in GetVertexMetrics function we are assuming source to have single partition (vertex name itself) and subsequently calling getRates for this partition.

With PR changes, we have changed source's partition name to 'source-partition-[partitionIdx]' which is causing the issue.

What should be the best possible way out here? Should I introduce a new label for partition idx as suggested by Keran before.

@adarsh0728 thank you for diving deep into the issue. The problem is introduced because we move Kafka per-partition metrics to source forwarder. I think we can simplify it by keeping Kafka per-partition metric in Kafka source and continue using vertex name as source partition name. cc: @whynowy

@adarsh0728 thank you for diving deep into the issue. The problem is introduced because we move Kafka per-partition metrics to source forwarder. I think we can simplify it by keeping Kafka per-partition metric in Kafka source and continue using vertex name as source partition name. cc: @whynowy

sounds good to me.

thanks @whynowy and @KeranYang . Will do the necessary changes and update.


there is a virus oh no

          there is a virus oh no

Originally posted by @changcheng967 in https://github.com/changcheng967/Kata_speed/pull/50#pullrequestreview-2149055831

crasher.bat removal

fine fine fine


To do: Handle inter-entity cascades

The current solution for inter-entity cascades (where a cursed magic item appears in the box inside your backpack, which increases the weight of the box, which increases the weight of the backpack, which increases your encumbrance) is fragile. It can break down if the cascade branches and then rejoins.
Figure out a way to make this reliable. The simplest fix is a) to forbid multiple hops in formulas (you can only look at entities directly linked to you), and then ensure that cascades are resolved breadth-first. Right now they go depth-first. Breadth-first should ensure that branches and rejoins do not cause trouble.
A really fancy solution would involve yet another dependency graph, but I ain't doing that unless I have to.

Changed cascades to breadth-first, albeit in a very messy way that could probably be much cleaner.

Write a test that verifies breadth-first behavior.
Enforce no double hops.
Clean up the mess.


GUI to report at real time all the daemons running/stopped/delayed by all Gradles instances

Expected Behavior

Through a tool based on GUI show at real time all the daemons running (and stopped/delayed) by all the Gradle versions working. And showing what app is involved behind the scenes.
For example the tool would show:

daemon X being running by Gradle 6.6 by terminal/console
daemon Y being running by Gradle 6.7 by terminal/console
daemon Z being running by IntelliJ Idea
daemon W being running by STS (Spring Tool Suite)

And give the option to stop it.
Current Behavior

Run each time the gradle --status for each Gradle release to see the current status.
Context

Detect quickly where and who is causing a lock about daemons.

Thank you for the suggestion!
We are thinking about potential improvements in this area but having a GUI for daemon statuses is unlikely.


Rails 5

Attempting to upgrade to Rails 5. Still a work in progress.
Fix #50

While this is passing with Travis, it's throwing a ton of deprecation warnings, which I'd like to handle before merging.

I'm going to deploy this to staging first to ensure that it works in my server setup.

Working well on staging. Headed to master!


ENH: add multilinux2010

Now that multilinux2010 has been released, update the demo to use it
~And as an extra, replace nose with pytest~
Edit: do not change from nose

xref pypa/manylinux#179

I think you opened this before the manylinux2010 image had finished building; that should clear up next time the tests run.
You also seem to have a problem running pytest - I think possibly you need the --pyargs option. Or leave it as nose for now and work on that in another PR.

removed the nose -> pytest changes

This now passes, but the wheels built on the manylinux2010 image appear to get a manylinux1 tag instead of manylinux2010. We'll need to investigate whether we're doing something wrong here, or in the build image, or in auditwheel.

That looks good to me. :-)
We could get rid of the DOCKER_IMAGE variable by using quay.io/pypa/$PLAT - I don't know if it's clearer to be more concise, or to spell out the image names separately. :-)

Since this is a demo, I would prefer to be as explicit as possible.
Interesting that auditwheel says "INFO:auditwheel.main_repair:Wheel is eligible for a higher priority tag. You requested manylinux2010_x86_64 but I have found this wheel is eligible for manylinux1_x86_64." and then goes and make both wheels, manylinux1 and manylinux2010

OK, explicit is fine by me.
Yes, I think I would have made auditwheel show the message but only add the requested tag, even if another one is valid. What it's doing is reasonable enough, though.

anything else I need to do?

This looks good to me, and I've now been granted the power to merge it :slightly_smiling_face:


Add ability for restart of graphhopper instance remotely for unattended graph updates on servers

To help with periodic updates of the graph, it would be very useful to be able to trigger a restart of graphhopper by writing a semaphore file or via the api using curl or similar.
Use case would be in unattended graph updating on servers. Rather than bring graphhopper down and waiting wile the new graph was built, the rebuilding could be done in another Instance of graphhopper. When the graph creation was complete, the main instance could be brought down, the config file changed to point to the directory with the new graph and then the main instance could be restarted. resulting in minimal downtime on the service.
See also issue #112 re running multiple instances of Graphhopper

Can the following be implemented?
http://www.randomactsofsentience.com/2012/01/stopping-andor-restarting-embedded.html
It uses the jetty infrastructure and the code is relatively simple.
I can submit a pull request if needed, but I think someone who know this area better and the jetty infra should do it as I have no means to understand if the code I linked to is any good...

It seems to me that this should be done from the outside. Or from the inside. But not on that level.
I mean, either GraphHopper gets a service API with which you can tell it to reload its Graph.
Or you stop and restart the GraphHopper executable, i.e. the JVM, with outside infrastructure (a container, a thing which controls daemons, etc.).
This here seems strangely in-between to me.

I can't argue with your logic, however consider my case:
I'm running GH as a Windows service, the only interaction I have with this service is through http requests.
In order to restart the server I'll need to restart the Windows service which requires elevated permission, which I rather give of possible.
So I need a http command to restart the server in order to use the new cache I created.

@HarelM if we would implement this (at all) I agree with @michaz and this way seems to be too jetty specific and not useful if used elsewhere. Also why can't you create a crontab-alike entry which checks if a new graph is available and then restart the GH service? No external access would be necessary or how are you triggering the creation of the new graph cache?

Currently, I'm using a command line java process to create a new cache in a new folder:
java -cp \"*\" com.graphhopper.tools.Import config=config-example.properties datareader.file={osmFileFullPath} graph.location={GH_NEW_CACHE_FOLDER}
Then I stop the GH server, switch between the cache folders and load the GH server again.
However, this requires admin permissions since the GH server java process is hosted as a windows service, which as I said I would like to avoid.
If you have a better method of doing so I open to suggestions.
This is currently the best approach we found to reduce the time the GH server is down for updates.
Note that this is a windows server and I'm writing code in C# and not in java (hence the need for external http requests)...

Well, a better approach for me would be to send an http request to create a new cache, recive the new cache id and send another http request to switch between graphs/caches.
And the delete the old cache, again from http. This way I won't need to run any java process besides loading the server once.
This also requires the ability to get current graphs/caches so when the server is running I can query which graph is the "current" one.

I think I'm over complicating this.
When loading the GH server I'm giving a file name for OSM database as a parameter.
My use case is that when this file changes, I need the GH server to update with minimal downtime.
One possible solution would be to use a file watcher and when this file changes create a new graph and delete the current graph once the operation is finished (although this leaves the cache parameter weird since the new graph won't know where to write its cache).
A second possible solution will be to call a HTTP method to signal the server the pbf file changes (similar to the above but doesn't require a file watcher, same issue with cache parameter).
I'll have some free times on my hands next week if you want to direct me to the location in the code assuming we agree on the approach I'll be able to contribute.

Every new feature deserves maintenance from us. Also it introduces security related concerns that needs thoughts. Also this restart often is coupled to trigger a change in the config of the load balancer (to reduce downtime to 0) and so forth. I'm currently more convinced to have this in a separate repo and we would be happy to link to it.

I think this is very basic, I'm not sure I understand how this was not implemented already as I can't image a production server that doesn't need this. I don't think it has a place in another repository/code base.
It's true that you'll need to maintain this, but I don't think it should be a big effort.

The current design is that the graph is loaded at startup time. I think that's a defendable decision. Everything needs to be assigned some scope, and the most common ones are Singleton, Session and Request. This here is Singleton.
So if one requires a new graph, they can restart. For restarting a service, use whatever your environment provides. I don't know Windows well, but there should be tools for that. The permission thing is really an administrative issue and should not directly lead to code changes.

@michaz I understand your point in general.
My perspective is different, If you'd offer your code as a jar file that you can only use with Java and you'd need to write the service around it to support requests I would have no case.
But you decided not to.
When you decided to facilitate for HTTP requests it means that who ever uses this code doesn't need to write anything in Java theoretically, all a client needs to do is be able to send HTTP requests, which I think is a great solution to cross platform and cross languages (since every language has an http client).
My reference here which I also need in my production server and feel like they nailed the subject is Elastic Search.
Their API fully supports HTTP, including everything.
Since I use both I can compare and there was no need for me to open an issue there since they support everything I need from HTTP without writing a single line of Java code. They are hosted as a window service much like I host graph hopper and I don't need permissions since I don't need to bring it down.
P.S. The equivalent of a windows service in Linux is a daemon as far as I can tell, and in order to restart it you'll need elevated permissions (Don't take my word for it since I'm not a Linux expert) but if I'm correct this problem is not windows specific... The reason for creating a daemon is so that if the server restarts for some reason GH service will be available.

Their API fully supports HTTP, including everything.

Their API also supports distributed requests, load balancing and much more and btw: they have hundreds of engineers ... so in theory it is nice to compare this to GH but in praxis we have to cut features somehow to concentrate maintenance on the important parts.
We are happy to link to your proposed changes from the docs and/or here. BTW: it is quite easy to embed the GHServer class in customized java code.

Since I use both I can compare

We are happy ES users too and we can compare too ;)

Setting up periodic updates with bash scripts, crontab, etc might work well enough for Linux, but I can understand that this is seriously painful to do for Windows. So I understand why you are looking for an easy way to manage your instance on Windows @HarelM.

1.) either GraphHopper gets a service API with which you can tell it to reload its Graph.

Actually I kind of like this idea. So we could provide an /admin endpoint for this, that has to be protected somehow (password, IP Blacklist, JWT, ...). The endpoint would allow to perform certain management tasks, like loading a new graph file from the file system. This would make orchestrating a couple of graphhopper instances easy.
For loading a new graph file I would think that we might need to re-run parts of the DefaultModule#configure() method. This would allow reloading the graph file with (almost?) zero downtime.
So from my point of view, we need a couple of good use-cases here to justify the development of something like this. But this is not really part of this issue, anyway :).
The biggest benefit I see is when managing a lot of GH instances. You might have a load balancer. You might have lots of services around it. Here a couple of ideas, what you could do:

Reloading graph files from the load balancer, so the load balancer could disable a routing server, reload the graph file and re-enable the routing server (not sure if this should be the responsibility of the load balancer)
Fixing a broken routing server. So for some reason a server hung up, the load balancer marks it as unhealthy. Now the load balancer could simply restart the unhealthy server.
Managing the config of a server from the load balancer. So maybe you want to remotely change the config of the routing server, you could simply do this from the load balancer (I have no idea, why I would want to do this, but, why not).

Actually I kind of like this idea.

Again, I like the idea as well, but we should first of all concentrate on the many more important non-service features that we have already on the list for years. And this feature is not just adding a new endpoint, security-wise I don't like to have without proper thoughts and testing.

Again, I like the idea as well, but we should first of all concentrate on the many more important non-service features that we have already on the list for years.

I am 100% with you on this :) I was just thinking about the possibilities.

I'm revisiting this topic again as I'm working on improving the downtime of the OSM updates on my server.
Here's another thought which might require less code and be more in-sync with how it's built right now:

Allow creating the GH server without a file (just loading it so it can wait for requests)
Add a HTTP API call to send an OSM file to the server - once the file is received a temporary cache/graph is created. when the creation is complete and graphs are switched.
This way the server is always up - no restart, no jetty specific code, what do you think?
I can work on it and create a pull request, I just need some guidance where to start.

After further looking in the code here's what I came up with (Inputs are very welcome):

Allow the possibility to create the graph lazily:
1.1 Add a configuration flag: graph.lazy_load, false by default, to facilitate for such option.
1.2 The server is assuming there's a ready graph storage (BTW this is not an interface which makes things harder) - solution: create an interface for Graph and GraphStorage and create a class EmptyStorage which doesn't do much except facilitate for lazy loading (This is not my preferred solution but the code assumes the storage can't be null due to injection).
Add RebuildServlet for the address of /rebuild which accepts an OSM file in the payload, will load and import using the original command line arguments, once the storage is created use setGraphHopperStorage to update it on the original instance.
Am I in the right direction?
I thought about adding a method to GraphHopper to facilitate for rebuild but I saw that the state is in a private member called fullyLoaded and I'll have a hard time changing that logic, I think...

Added a discussion on this issue in the forum to get some help with the existing code:
https://discuss.graphhopper.com/t/rebuildservlet-design-review-and-code-queries/2009

@karussell I would love your input on this, I'm at the final stages of implementation and it just doesn't feel 100% right.
What I've done so far:
RebuildServlet is calling GraphHopper newly written rebuild function which receives a graph that was created in a different location, closes the current graph and uses the new location instead.
The code is basically doing what it should, it just feels a bit hacky. I'll try and write some tests and see if I can make sure everything is covered. Should I commit and create a pull request for review?
I really need a feedback here...

I still do not understand why we need to change the core functionality to just reload the graph. IMO you could easily add a servlet, create a custom server to include this servlet (see eg. the map matching web module where we customize the GHServer) and then do the graph reload. This way we avoid to have to maintain it in the core (I think we are not yet there to include service functionality that introduce security questions and much more complexity) and it should be still easy on your side

I can't seem to be making my point I guess.
The fact is - not everyone is writing in Java (Imperfect world, I know...).
I have a server which hosts GraphHopper as a process, the rest of the code is written in C#.
I do not want to write proprietary Java code only for this feature (Graph rebuild) since I believe it should be a part of GraphHopper capabilities - I think everyone that uses a system that updates and is not static would probably need this at some point.
Writing the code anywhere else beside in GH requires to know the internals of how GH works and creates an unhealthy coupling, IMHO. I tried to do it implement it a few times in other places and it just felt wrong.
The only functionality which I currently think is missing is this rebuild and facilitate it though HTTP is the only true cross-language solution.
The code I added is mainly focused in the RebuildGraphServlet but requires some minor changes in the core.
I haven't changed any tests and they all pass which might indicate the changes are truly minor also in terms of maintenance.
I really think others may find this piece of code helpful and I'll gladly spend a few more hours improving this so it can be merged here.

Here's the relevant commit BTW:
https://github.com/IsraelHikingMap/graphhopper/commit/60683a6908a8879ca3e529daeda7d975e2990dab
The only thing that I'm not OK with is the public LocationIndex getLocationIndex() method which is used with injection to NearestServlet and does not allow null.
I believe a better solution for this will be to add LocationIndex to GraphHopperAPI as a property so that it can be changed after the graph is loaded the first time and there will be no need to inject it.
This is currently the only issue I see with the current implementation, but I'm very new to this code base so I might be way off. thoughts are very very welcome :-).

My new thoughts are still my old thoughts:
The current architecture is (mostly) based on the assumption that the Graph is immutable. If you want a new Graph, stop and restart the service. It's what we do on graphhopper.com! If you can't do this merely because you don't have admin access to the machine, I suggest you find some way to virtualize the server, run it in a container, or something.

I believe a better solution for this will be to add LocationIndex to GraphHopperAPI as a property so that it can be changed after the graph is loaded the first time and there will be no need to inject it.

No. We're moving into exactly the opposite direction, where dependecies are injected at creation and are final from then on. When X depends on Y (or even creates it like in this case), and you need an X with a new Y, the least-messy solution is to create a new X with a new Y, not change the Y under the X's feet. Except when X and Y were designed from the beginning to be like that, and there are naturally many Ys within the life-cycle of the X. This isn't the case here.
Work-arounds for the administrative problem of not being able to restart a server do not belong into the code-base.

@michaz Thanks for your response.
It's very hard to convey an architecture discussion over a thread and not in person but I'll try to make my point never-the-less.
I have written such administrative service which shuts-down GH server and does the update. In the middle of writing it I noticed how deeply I'm coupled with how GH work (cache location, file location, can't do it from remote, etc...) and the more code I wrote the less right the solution felt.
I then stopped for a second and tried to solve this without assuming anything and the solution I ended up is what I committed. I believe this is the correct solution to the problem in terms of coupling and the way I perceive a client-server architecture when the server is always up.
Regarding what you wrote:

GraphHopper the class in terms of API is far from being immutable as it has public methods such as change location, set graphhopper storage, load, loar or import, etc... which makes it mutable, although some methods have checks in them, the API itself is not by definition an API for immutable class.
The Servlet API exposes changes method, this is not drastically different in term of API (I know it's different in term of the actual code though but I don't think it should guide this decision).
LocationIndex is a part of the graph and shouldn't really exists on its own if I understand its creation flow, I might be missing something though, therefore I thought that adding it to the GraghHopperAPI interface would be more correct - meaning when you want to use location index you have to have an instance of a graph and you ask it for a location and not separate its existence by injecting it on its own.

I hope I'm making some sense, feel free to look at the code changes I made and let me know if this truly moves the code in what you define as the "wrong direction".

You probably won't like the changes I made, but I didn't like the casting that I added and the one that was already there.
I added a few methods to GraphHopperAPI to support the required changes (and also to remove the casting).
All tests pass including the test I added.
Let me know if you are interested in pulling this in and I'll create a pull request.

Unfortunately I spoken too soon. after rebuild I'm getting the following error when sending a route request, any thought where to look for the issue? it's probably a variable that wasn't initialized because if I close the process and open it again the graph is working as expected.
2017-06-11 21:39:15,436 [qtp510063093-43] ERROR com.graphhopper.storage.RAMDataAccess - nodes_ch_fastest_foot, segments:0, bufIndex:1, bytePos:1697720, segPower:20
2017-06-11 21:39:15,442 [qtp510063093-43] WARN  org.eclipse.jetty.server.HttpChannel - /route
java.lang.ArrayIndexOutOfBoundsException: 1
        at com.graphhopper.storage.RAMDataAccess.getInt(RAMDataAccess.java:208)
        at com.graphhopper.storage.CHGraphImpl.getLevel(CHGraphImpl.java:144)
        at com.graphhopper.routing.util.LevelEdgeFilter.accept(LevelEdgeFilter.java:51)
        at com.graphhopper.routing.AbstractRoutingAlgorithm.accept(AbstractRoutingAlgorithm.java:79)
        at com.graphhopper.routing.DijkstraBidirectionRef.fillEdges(DijkstraBidirectionRef.java:164)
        at com.graphhopper.routing.DijkstraBidirectionRef.fillEdgesFrom(DijkstraBidirectionRef.java:132)
        at com.graphhopper.routing.AbstractBidirAlgo.runAlgo(AbstractBidirAlgo.java:68)
        at com.graphhopper.routing.AbstractBidirAlgo.calcPath(AbstractBidirAlgo.java:61)
        at com.graphhopper.routing.AbstractRoutingAlgorithm.calcPaths(AbstractRoutingAlgorithm.java:116)
        at com.graphhopper.routing.template.ViaRoutingTemplate.calcPaths(ViaRoutingTemplate.java:115)
        at com.graphhopper.GraphHopper.calcPaths(GraphHopper.java:1054)
        at com.graphhopper.GraphHopper.route(GraphHopper.java:939)
        at com.graphhopper.http.GraphHopperServlet.doGet(GraphHopperServlet.java:142)

OK, diving deeper... The instance of PrepareContractionHierarchies should not have been used.
This is due to the fact that CHAlgoFactoryDecorator is keeping a list of PrepareContractionHierarchies.
IMHO I don't think a factory should have a state, but clearing the list when calling close on GraphHopper solves the issue and rebuild is now working without exceptions (At least the tests I made).

I still believe a routing server should always be up and should handle updates without the need to be restarted or swapped.
Having said that, I was unable to convince this respectful forum that what I wrote should be pulled in and now my code had diverged from this code base. :-(
Below is my new solution that uses docker, extremely hackish in my point of view, but I guess this is what is the advised to do...

A docker container and code that creates the graph called docker-compose-gh-rebuild.yml:

version: '3.4'

services:
  graphhopper-rebuild:
    image: graphhopper/graphhopper
    container_name: graphhopper-rebuild
    volumes:
      - ./data:/data:rw
      - ./gh-config.yml:/data/gh-config.yml
    entrypoint: ./graphhopper.sh
    command: import asia_israel-and-palestine.pbf -c /data/gh-config.yml -fd -o /data/default-gh/

a container that is almost always running for the web api at port 8989:

version: '3.4'

services:
  graphhopper:
    image: graphhopper/graphhopper
    container_name: graphhopper
    volumes:
      - ghdata:/data:rw
      - ./gh-config.yml:/data/gh-config.yml
    ports:
      - 8989:8989
    command: -i - -c /data/gh-config.yml -o /data/default-gh/
    restart: always
volumes:
  ghdata:
    driver: local

A script to swap the cache (the name of the volume is generated according to current dir, but can be assigned before starting this procedure):

docker rm graphhopper-rebuild
rmdir -force data/default-gh
docker-compose -f ./docker-compose-gh-rebuild.yml up
docker container create --name dummy -v ghdata:/root hello-world
docker-compose stop graphhopper
docker cp ./data/default-gh/ dummy:/root/default-gh/
docker rm dummy
docker-compose start graphhopper

Feel free to close this issue, no need to keep it open...


Fixed Broken Support Link

Fixed Broken Support Link

Thanks for the update @esivakumar18. This is now merged.


Add the ability to have numbers in the issue key

We like to use Jira issue keys with numbers in them. This PR adds the ability to have numbers.
For example:
Ab1-1 Initialize Project
a2b-1 Initialize Project
3AB 1 Initialize Project

Thanks


Get properly issued SSL certificate and start running HTTPS server

I need to get a non-self-issued SSL certificate for forms.polydaic.com so I can run an HTTPS server.

To get this to work on Heroku we have to purchase and setup a SSL endpoint. Will talk to Jeremy about this.

This has be

This has been fixed. See http://stage.tellform.com for an example


Add support for local storage

Partial implementation of #14

Implements storage of image tabs with all user-provided configuration.
Converted image must be recomputed to save space.
Saves the resized image if the original image is larger than 1MB in its base64 encoding.
Added save button to save to local storage after successful conversion.
Resetting a saved tab reverts to the saved state.
Added a simple dirty state marker to tab header.
Removing a tab also removes local storage for it.

Thank you for the code! I'll read through it as soon as I get the time, I didn't expect a PR so soon after I commented on #14, even in spite of the existing poor-readability JS!

The functionality looks great! Thank you!
I've just made a few small edits I thought would be nice...
If you are able to, could you please add some inline documentation for the new functions you've added?
I've done so for the rest of the existing code in 50f666a, so this'll also be consistent when I eventually merge that branch later on.
Otherwise this looks good to merge now

Added JSDoc for the new functions, and rebased on current main.


Docs added for dark theme

Description
This PR fixes #922
Notes for Reviewers
This PR adds the documentation for new contributers to understand how they can contribute to Meshery.io website based on light and dark theme features on the website.
Signed commits

[x] Yes, I signed my commits.

A spelling error

Corrected. @GaganpreetKaurKalsi

@leecalcote I think this PR is all set to be merged.

Good deal. 👏


[move source lang] Don't type check dependencies

Motivation

For efficiency, dependencies now have all of their structs and functions marked as native
The signatures will still be checked, but the bodies will be affectively skipped

Test Plan

cargo test

@bors-libra r=sblackshear

:pushpin: Commit 417029a has been approved by sblackshear

:hourglass: Testing commit 417029ad0ec77aa7280ac26d3ccb35032569b200 with merge 370375ad6b39e4cf0c75b434e6ebe54eb304ab35...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: sblackshear
Pushing 370375ad6b39e4cf0c75b434e6ebe54eb304ab35 to master...


⚠ Fortnite has degraded performance

In 7b28ee5, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1470 ms

Resolved: Fortnite performance has improved in 2153790.


use Apache Pekko instead of Akka

Most of the Apache Pekko jars are now released. A decent number of 3rd party libs now also support Pekko.
https://www.lightbend.com/akka/license-faq

I'll likely be the one that ends up tackling this once I have bandwidth. The hard part is new clusters will have to be formed so it's technically going to be a breaking changed. We've been planning a 2.0 release for a while with our new scheduling algorithm, we should probably revisit that.

I am also interested in this issue.
@bdoyle0182 Do you mean we have to release the openwhisk 2.0 before migrating to Pekko?

The build dependencies in the OpenWhisk are quite dated.

https://github.com/apache/openwhisk/blob/master/settings.gradle
https://github.com/apache/openwhisk/blob/master/common/scala/build.gradle

Pekko is based off newer versions of the Akka libs. Also libs like Kamon have added Pekko support but only in more recent versions.
I think it would be a good idea to upgrade the existing dependencies to newer versions before trying to switch to Pekko. With Akka libs, I am suggesting latest Apache licensed versions - not the more recent versions that have Category X licenses.

Akka 2.6.21 (due to CVEs)
Akka HTTP 10.2.10 (due to CVEs)
Akka Management 1.1.4
Alpakka 4.0.0
Kamon 2.7.2
spray-json 1.3.6
logback 1.2.14 (due to CVEs)
httpclient 4.5.14 (due to CVEs)
netty 4.1.110.Final (due to CVEs)


msys2.msys2 version 4.0.1

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

dont know how to add a silent switch, i do know that you can pass "in --confirm-command --accept-messages --root C:/msys64" to the msys installer for a silent install

@Schatteneis the wingetcreate tool is very "preview" right now. I see it doesn't prompt for the switches with this particular installer. You might be better off creating a "Package Request" issue. You would need to be familiar with modifying the manifest to add the switches and potentially some of the other meta-data in the schema.

If you are willing to "hand edit", you could search for "Silent" in other PRs or in the source. That should show several examples of how the switches are added to manifests.


feat: update to eye v3.27.0

feat: update to eye v3.27.0

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

npm package (@latest dist-tag)
GitHub release
v4.27.0

Your semantic-release bot :package::rocket:


Restructuring psibase macros

This PR restructures the psibase_macros into a 3-project workspace for easier dev/testing.
In addition to the 3-project structure, it also splits service_macro.rs into separate files for better readability/maintainability.
There are a couple of TODOs but only in the test files and are notes for tests I can add; nothing functionally missing from this PR.
All files in the rust/psibase_macros/psibase-macros-lib/src/service_macro/ dir is unmodified code simply spilt out from the single formerly rust/psibase_macros/psibase-macros-lib/src/service_macro.rs into more bite-sized chunks.

You can also add your unit tests to CI/CD in rust/CMakeLists.txt if they belong

Was this addressed?

You can also add your unit tests to CI/CD in rust/CMakeLists.txt if they belong

Was this addressed?

It is now.


Csv delimiter change

Space-delimiter changed to standard comma-delimiter
Also added an additional test to cruncher

Thanks for the contribution @reidmcl! The new code looks great.
For the documentation:

Could you please restart the kernel and rerun the code in example_multi.ipynb so that the cells read 1, 2, 3 etc.?
It might be interesting to have greater variation in example_input.csv, especially in terms of income and dependents, so users can see the calculation of various credits.

Thanks for the contribution @reidmcl! Merging.


feat: add a symbolic parameter [WIP fix #112]

Add a class SymbolicParameter which inherits from symbolics.Symbol.
Integrate the new symbolic parameter with the lower and upper bounds of
Variable and Constraint.

I'm fairly happy with the current design although there are certainly still a number of decisions to be made. First of all, do symbolic expressions on variable and constraint bounds cover all the use cases? I guess, at least the objective should also be possible. Should the expressions of constraints themselves be able to contain symbolic parameters?
In the SymbolicParameter class I provide a method unregister which should be integrated with the variables and constraints. Maybe Variable and Constraint should get a memory for all the SymbolicParameters that they depend on and then we can call unregister in their __del__ method?

Cool! I will take a look at it tomorrow.
I think the ME-model formulation also requires some constraint linear coefficients to be symbolic.
I don't think ME-models require symbolic objectives, but eventually it would be nice to have for completeness.
Colton, correct me if I'm wrong about this :)

Yes, the ME-model also uses symbolic constraint coefficients, but this is a great start! I don't think there is anything planned in the near future that would require symbolic objective so there's no hurry there.
I will test this PR with the ME-model sometime early next week and get back to you, though I don't see anything that looks like it would be an issue.
Thanks!

Hey @Midnighter @KristianJensen,
Finally had an opportunity to test the ME-model building with the PR and it worked great! The only incompatibility that remained when using just the high-level interface was that I caught the NotImpolementedError  exception in the set_linear_coefficients  method in the Objective class. Creating a simple me_model_interface to override this method corrected the issue.
Thanks again for your help. Is there anything I can do to help get this PR ready to go?

Hi Colton, I'm glad you like it! Kristian and I talked about a few improvements that are currently still in the works on my side. I just need to get it done. So other than testing the new implementation once it's ready there's not much for you to do I'm afraid.


arm: 96boards: Add Chardev support for relevant boards

As of now both Dragonboard410c and Hikey boards run latest LTS kernel.
Hence, adding chardev support for those.
Along with this support, clang-format has been executed for the source file.
Signed-off-by: Manivannan Sadhasivam<EMAIL_ADDRESS>

@arfoll Can you please review and merge this PR? I still have many PR's in queue for 96Boards.

Thanks! LGTM now, :+1: from me for merging.

Merged, Thanks!


Unpkg don't redirect to latest version

I've published a package an hour ago and unpkg redirect:
https://unpkg.com/jquery.terminal -><EMAIL_ADDRESS>but last version is 2.1.2. When I type that version in, I've got new file but it don't redirect to 2.1.2.
This is not local cache issue because it also redirect to 2.1.1 from incognito mode.

It works now.

I have similar error for this url:
https://unpkg.com/jquery.terminal/js/emoji.js
it shows:
Found. Redirecting to<EMAIL_ADDRESS>
but it don't redirect, emoji is new file added in 2.1.0
Opening<EMAIL_ADDRESS>works.

For some reason this behaviour is consistent between Safari and Chrome for me and the only solid workaround at this point looks like this:
Last Week
  const defaults = { fetch: { mode: 'cors', referrer: 'no-referrer' } };

  const loadFromURL = async specifier => {
    let returned;
    const url = `${new URL(specifier, location)}`;
    const source = {specifier, url};
    try {
      source.response = await fetch(url, defaults.fetch);
      source.sourceText = await source.response.text();
      return (returned = source);
    } finally {
      returned || console.warn('Failed to load source from "%s" — %o', specifier, source);
    }
  };

This Week
  const defaults = { fetch: { mode: 'cors', referrer: 'no-referrer', redirect: 'follow' } };

  const fetchSource = async (source, options) => (
    (source.sourceText = ''),
    (source.response = await fetch(source.redirect || source.url, options)),
    (source.sourceText = await source.response.text()),
    // TODO: Revert once odd behaviour of response.redirected is resolved
    source.response.redirected && source.sourceText.startsWith('Found. Redirecting to')
      ? ((source.redirect = `${new URL(source.sourceText.slice(source.sourceText.indexOf('/')), source.url)}`),
        fetchSource(source, options))
      : source
  );

  const loadFromURL = async specifier => {
    let returned;
    const url = `${new URL(specifier, location)}`;
    const source = {specifier, url};
    try {
      await fetchSource(source, defaults.fetch);
      return (returned = source);
    } finally {
      returned || console.warn('Failed to load source from "%s" — %o', specifier, source);
    }
  };

Today I've checked and I'm not in VPN and have 500 error for https://unpkg.com/favloader/parseGIF.js that file was also added recently. Main file works fine.

I've just published version 0.4.2 of favloader and it now return 500 error randomly for any url, it load longer then usual and then crash. Maybe it's some dependency timeout.

This should be fixed now.

New issue, version 2.2.0 of jQuery Terminal released on February
https://unpkg.com/jquery.terminal/js/jquery.terminal.min.js
text: "Found. Redirecting to<EMAIL_ADDRESS>with error 500
destination exists<EMAIL_ADDRESS>

it works on other https://unpkg.com/handlebars/dist/handlebars.min.js

It seems it works today, maybe it was some temporary glitch or you fixed it.


Cannot query using tags__name__in

Django Version: 4.2.9
Taggit Version:  5.0.1
Hello, I have been beating my head against this and cannot figure it out. I am using the through parameter to point to a UUID tag class.   Here is my setup:
import uuid

from django.db import models
from django.utils.translation import gettext_lazy as _
from django.contrib.auth import get_user_model

from taggit.managers import TaggableManager
from taggit.models import GenericUUIDTaggedItemBase, TagBase

class AssetTag(TagBase):
    user = models.ForeignKey(
        get_user_model(),
        related_name="assettag",
        on_delete=models.CASCADE
    )
    class Meta:
        verbose_name = _("Tag")
        verbose_name_plural = _("Tags")

class AssetTaggedItem(GenericUUIDTaggedItemBase):
    tag = models.ForeignKey(
        AssetTag,
        related_name="assettaggeditem",
        on_delete=models.CASCADE
    )
    class Meta:
        verbose_name = _("Tag")
        verbose_name_plural = _("Tags")

class Asset(models.Model):
    id = models.CharField(primary_key=True, max_length=36, default=uuid.uuid4, editable=False, db_index=True)
    user_id = models.ForeignKey(
        get_user_model(),
        on_delete=models.CASCADE,
    )
    tags = TaggableManager(through=AssetTaggedItem)

I will create an asset and tag it with some_tag ... then I try to query assets with the tag like this:
_t = AssetTag.objects.filter(name='some_tag').values_list('name', flat=True)
assets = Asset.objects.filter(tags__name__in=_t).distinct()

or
assets = Asset.objects.filter(tags__name__in=["some_tag"]).distinct()
Both return no results. I cannot figure out whats going on.

First question: If you do AssetTag.objects.all(), do you see the tag you are expecting to find? Like you're sure the tag is saved? I'm assuming that this database is pretty small.
Second question: if you have a specific asset, does asset.tags.objects.all() give you the tags you're expecting in general?
Sometimes it is helpful to do things like:
print(Asset.objects.filter(tags__name__in=["some_tag"]).query)
This should help you see what exactly your system is doing.


Request to make attributes old-release-address , old-release-protocol, old-release-port optional for service /v1/embed-yourself.

Problem Description:
To test the software upgrade test suite , OldRelease,NewRelease tcp-c details are set through fake ip script before start of the application.
After that when the application is started it will trigger automatic register-yourself with no request body in application  . This is will trigger callback register-application to RO as mentioned below :
-> register-application to RO with request body
{"application-name":"AdministratorAdministration","release-number":"2.0.1","embedding-operation":"/v1/embed-yourself","client-update-operation":"/v1/update-client","operation-client-update-operation":"/v1/update-operation-client","tcp-server-list":[{"protocol":"HTTP","port":3004,"address":{"ip-address":{"ipv-4-address":"<IP_ADDRESS>"}}}
As application is already approved ,
-> embed-yourself is sent by RO to application with request body
{"registry-office-application":"RegistryOffice","registry-office-application-release-number":"2.0.1","relay-server-replacement-operation":"/v1/relay-server-replacement","relay-operation-update-operation":"/v1/relay-operation-update","deregistration-operation":"/v1/deregister-application","registry-office-address":{"ip-address":{"ipv-4-address":"<IP_ADDRESS>"}},"registry-office-port":3008,"registry-office-protocol":"HTTP","old-release-protocol":"HTTP","old-release-address":{"ip-address":{"ipv-4-address":"<IP_ADDRESS>","old-release-port":3004}
Note : For above examples the example application taken is AA running in port 3004 .
Once the embed-yourself is executed in the application OldRelease port that is set by fake ip script is replaced with the old-release-port that is sent in the request body of embed yourself which is current server details as preceeding application details are not provided.
Proposal :
Currently . as per OAS the below mentioned properties are required request body properties for service /v1/embed-yourself.
  required:
      - registry-office-application
      - registry-office-application-release-number
      - relay-server-replacement-operation
      - relay-operation-update-operation
      - deregistration-operation
      - registry-office-protocol
      - registry-office-address
      - registry-office-port
      - old-release-protocol
      - old-release-address
      - old-release-port

As , callback bequeath-your-data-and-die for embed-yourself service is only trrigered when oldRelease
application-name != "OldRelease" . Can we make below mentioned properties as optional properties of request body for the service /v1/embed-yourself.
- old-release-protocol
- old-release-address
- old-release-port

I understood that

the new applications gets instantiated with proper info about the OldRelease.
as new application -> RO://v1/register-application does not contain info about the OldRelease,
consequent RO -> new application://v1/embed-yourself does definitively not contain useful info.

Further on, I assume that the info about the OldRelease shall remain in /v1/embed-yourself for being able to trigger the embedding either manually or with tools different from RO.

Hi Thorsten , I would like to apologize that we couldn't discuss the issue . We had a plan to discuss this in the upcoming call .
Thank you for accepting the proposal.