🐛 ReactNative | V0.76.0 react-native-vision-camera not getting autlinked

What's happening?
I have upgraded the RN version to latest(0.76.0) to enable the RN NewArchitecture.
The React-native-vision-camera not package not seems to be autolinked.Getting getting error in the getcameradevices hooks.

Reproduceable Code
GitHub Repo:https://github.com/sandeep36butte/RNBrownFeldApp

This is the brownfield Application.Just clone and run the app with yarn start and run on android.

Relevant log output
ERROR  Warning: TypeError: Cannot read property 'CameraDevices' of undefined

This error is located at:
    in App
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer
    in ReactNativeBrownFieldApp(RootComponent), js engine: hermes
 ERROR  Warning: TypeError: Cannot read property 'CameraDevices' of undefined

This error is located at:
    in App
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer
    in ReactNativeBrownFieldApp(RootComponent), js engine: hermes

Camera Device
Null

Device
pixel 8
VisionCamera Version
4.6.0
Can you reproduce this issue in the VisionCamera Example app?
I didn't try (⚠ your issue might get ignored & closed if you don't try this)
Additional information

[ ] I am using Expo
[X] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Heyo - thanks for reporting! I investigated this and just created a fix for this here: https://github.com/mrousavy/react-native-vision-camera/pull/3281 :)

I'd appreciate a GitHub sponsor donation if you feel like this package and fix has helped you. :)

@mrousavy
This is working fine now.The issue is with the project directory structure.
autolinkLibrariesFromCommand needs to know where to run the config command from. In this case. By default would be .. but in your case, your package.json is in ../ReactNative.
Can refer here for solution
https://github.com/facebook/react-native/issues/47406


Throws errors on null geometries

In postgis-preview, when I execute SQL that does not have any geometry column, dbgeo throws an error.  I would still like to return geometry-less topojson to the client for the sake of consistency.

Did a quick fix in 8c255623911b401c0e917db56dd1b668174104f4, adding null island coordinates (0,0)  if no geom exists.  I think a real fix would involve allowing dbgeo to handle null geometries.

Per the GeoJSON spec (first bullet point) a null geometry is indeed allowed, so I think it would be best to return the following:
`{
"type": "Feature",
"properties": {
"key": "value"
},
}`

I implemented a fix in c4cb2f109025aeea832126297bced9913d7d2520. If you could please check it out and verify that it will indeed fix your problem I will publish a new version of the package.
Thanks!

Sorry for delay, will check this out asap and see if it works for postgis-preview

This is resolved in 1.0

Hey, following up on this, I just updated postgis-preview to use the newest version of dbgeo and it is handling null geometries just fine.  Thanks!


Opening account menu is async

Start VS Code
As things "warm up", click the account menu to open it

🐛 A few of those times you try to open it, there's a delay to it. Opening menus should always be a sync operation.

@sandy081 Unsure who's making this operation async, please forward accordingly.

/duplicate https://github.com/microsoft/vscode/issues/111398

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


ESP32 wemos with hand soldered lora module

Hey, First of all, awesome work you did here!
I am not sure what is going on cause i can't seem to really debug it well.
Soldered a little gateway together by hand using the wiring of the sparkfuns lora 1ch gateway schemetics, only leaving out the RST pin since there is no need for it. Checked the wiring 3 times but can't seem to get it working, maybe i am missing something but i keep getting a abort, here is the output from the Serial:
entry 0x400806ac
SPIFFS begin
Format SPIFFS Filesystem Done
Do Asserts
readConfig ERR:: file=/gwayConfig.txt does not exist ..
readConfig:: Error reading config file
setup:: readGwayCfg: ERROR readCfgCfg Failed
MAC: 30:ae:a4:37:e6:1c, len=17
0:0:1. WlanConnect SSID=Boogmakerstraat 45
WlanStatus:: NO SSID
..1:0:1. WlanConnect SSID=Boogmakerstraat 45
WlanStatus:: CONNECTED ssid=Boogmakerstraat 45
Host=esp32-37e61c WiFi Connected to Boogmakerstraat 45 on IP=<IP_ADDRESS>
Local UDP port=1700
UDP Connection successful
Gateway ID: 30aea4ffff37e61c, Listening at SF9 on 868.10 MHz.
resolveHost:: OK=nl.pool.ntp.org IP=<IP_ADDRESS>
Time set=Sunday 8-3-2020 17:39:53
resolveHost:: OK=router.eu.thethings.network IP=<IP_ADDRESS>
setupOta:: Started
Ready IP address: <IP_ADDRESS>
WARNING:: readSeen, history file not exists /gwayNum.txt
WWW Server started on port 80
Unknown transceiver=0, pins.rst =14, pins.ss  =18, pins.dio0 =26, pins.dio1 =33, pins.dio2 =32
abort() was called at PC 0x400dea6c on core 1
Backtrace: 0x4008c468:0x3ffb1e40 0x4008c699:0x3ffb1e60 0x400dea6c:0x3ffb1e80 0x400dec15:0x3ffb1eb0 0x400e2dfd:0x3ffb1ee0 0x400ecd97:0x3ffb1fb0 0x40088bb1:0x3ffb1fd0
Rebooting...
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
SPIFFS begin
Format SPIFFS Filesystem Done
Do Asserts
readConfig ERR:: file=/gwayConfig.txt does not exist ..
If you need any more info please let me know, would really like this to work!
Kind regards,
Daniël

Can you post a picture of the pin-out? Based on the output your board is not recognized by the software. You use _PIN_OUT==4 which is standard for ESP32 boards. Is it also standard for your board?
Unknown transceiver=0, pins.rst =14, pins.ss =18, pins.dio0 =26, pins.dio1 =33, pins.dio2 =32
The Sparfun node may be different.
Maarten

It would be easier to write them all down:
DIO2:32
Dio1:33
Dio0:26
Vdd:3v
Dio4:NC
Dio3:NC
Gnd:NC
Ant: connected to the wire
Then the second row
Gnd:NC
Miso:miso/19
Mosi:mosi/23
Sck:18
Nss:16
RST:NC
Dio5:NC
Gnd:gnd
Maybe I am missing something but that is the pinout as well as specified right or do I have to connect rst or maybe I messed up nss and sck that nss should the ss pin so change the software to 16 instead of 18? Will check that out the next day, don't have my laptop at hand atm

Changed the FW now too, but it didn't change anything expect the pinout is now
Unknown transceiver=0, pins.rst =27, pins.ss  =16, pins.dio0 =26, pins.dio1 =33, pins.dio2 =32

I see now that the software thinks that rst is 27. Did you change the software to be in line with your hardware?
Make sure that you change the software in loraModem.h (and pin definition in configGway.h) so that these are the same as the hardware.
Maarten

Yea that is right, but i didn't connect rst to anything now, so it is not a pin used, other then that i just set everything to esp32 as far as i know, turned off the oled and all that kind of stuff, so i am really scratching my head what is going on, any suggestion on how i could see why it is failing?
Daniël

I will have  last look. but since all of my Gateway work, I am not sure what is the problem with yours.

Perhaps send me a version of your configNode.h and configGway.h fil together with a picyure of your pin-out of the node.
Maarten

Yea ofc no bother at all,  here you go:

// 1-channel LoRa Gateway for ESP32 and ESP8266
// Copyright (c) Maarten Westenberg 2016-2020

#define VERSION "V.6.2.3.E.EU868; PlatformIO 200223a"
//
// Based on work done by Thomas Telkamp for Raspberry PI 1ch gateway and many others.
//
// All rights reserved. This program and the accompanying materials
// are made available under the terms of the MIT License
// which accompanies this distribution, and is available at
// https://opensource.org/licenses/mit-license.php
//
// NO WARRANTY OF ANY KIND IS PROVIDED
//
// Author: Maarten Westenberg<EMAIL_ADDRESS>//
// This file contains a number of compile-time settings that can be set on (=1) or off (=0)
// The disadvantage of compile time is minor compared to the memory gain of not having
// too much code compiled and loaded on your ESP device.
//
// NOTE:
// If version is for ESP32 Heltec board, compile with ESP32 setting and board
// "ESP32 Dev Module" or "Heltec WiFi Lora 32"
//
// For ESP8266 Wemos: compile with "Wemos R1 D1" and choose
// the right _PIN_OUT below. Selecting OLED while that is not connected does not
// really matter (so you can leave that in).
//
// The source has been optimized for PlatformIO usage. Than means the some variables
// can be define in the .platformio.ini file. Pleas look at the example file to see
// how to set these #defines
//
// ========================================================================================

// Define whether we should do a formatting of SPIFFS when starting the gateway
// This is usually a good idea if the webserver is interrupted halfway a writing
// operation. Also to be used when software is upgraded
// Normally, value 0 is a good default and should not be changed.
#if !defined _SPIFFS_FORMAT
#define _SPIFFS_FORMAT 1
#endif

// Allows configuration through WifiManager AP setup. Must be 0 or 1
#if !defined _WIFIMANAGER
#define _WIFIMANAGER 0
#endif

// Debug message will be put on Serial is this one is set.
// If set to 0, no printing to USB devices is done.
// Set to 1 it will print all user level messages (with correct debug set)
// If set to 2 it will also print interrupt messages (not recommended)
#if !defined _DUSB
#define _DUSB 2
#endif

// Define the monitor screen. When it is greater than 0 then logging is displayed in
// the special screen at the GUI.
// If _DUSB is also set to 1 then most messages will also be copied to USB devices.
#define _MONITOR 1

// Gather statistics on sensor and Wifi status
// 0= No statistics
// 1= Keep track of messages statistics, number determined by _MAXSTAT
// 2= Option 1 + Keep track of messages received PER each SF (default)
// 3= See Option 2, but with extra channel info (Not used when Hopping is not selected)
#define _STATISTICS 3

// Define the frequency band the gateway will listen on. Valid options are
// EU863_870	Europe
// US902_928	North America
// AU925_928	Australia
// CN470_510	China
// IN865_867	India
// CN779-787	(Not Used!)
// EU433		Europe
// AS923		(Not Used)
// You can find the definitions in "loraModem.h" and frequencies in
// See https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html
#define EU863_870 1

// Define the CLASS mode of the gateway
// A: Baseline Class
// B: Beacon/Battery Class
// C: Continuous Listen Class
#define _CLASS "A"

// Define whether to use the old Semtech gateway API, which is still supported by TTN,
// but is more lightweight than the new TTN tcp based protocol.
// NOTE: Only one of the two should be defined! TTN Router project has stopped
//
#define _UDPROUTER 1
//#define _TTNROUTER 1

// The spreading factor is the most important parameter to set for a single channel
// gateway. It specifies the speed/datarate in which the gateway and node communicate.
// As the name says, in principle the single channel gateway listens to one channel/frequency
// and to one spreading factor only.
// This parameters contains the default value of SF, the actual version can be set with
// the webserver and it will be stored in SPIFF
// NOTE: The frequency is set in the loraModem.h file and is default 868.100000 MHz.
#define _SPREADING SF9

// Channel Activity Detection
// This function will scan for valid LoRa headers and determine the Spreading
// factor accordingly. If set to 1 we will use this function which means the
// 1-channel gateway will become even more versatile. If set to 0 we will use the
// continuous listen mode.
// Using this function means that we HAVE to use more dio pins on the RFM95/sx1276
// device and also connect enable dio1 to detect this state.
#define _CAD 1

// CRCCHECK
// Defines whether we should check on the CRC of RXDONE messages (see stateMachine.ino)
// This should prevent us from getting a lot os stranges messgages of unknown nodes.
// Note: DIO3 must be connected for this to work (Heltec and later Wemos gateways).
#define _CRCCHECK 1

// Definitions for the admin webserver.
// A_SERVER determines whether or not the admin webpage is included in the sketch.
// Normally, leave it in!
#define A_SERVER 1       // Define local WebServer only if this define is set
#define A_REFRESH 1      // Allow the webserver refresh or not?
#define A_SERVERPORT 80  // Local webserver port (normally 80)
#define A_MAXBUFSIZE 192 // Must be larger than 128, but small enough to work

// Definitions for over the air updates. At the moment we support OTA with IDE
// Make sure that tou have installed Python version 2.7 and have Bonjour in your network.
// Bonjour is included in iTunes (which is free) and OTA is recommended to install
// the firmware on your router witout having to be really close to the gateway and
// connect with USB.
#define A_OTA 1

// We support a few pin-out configurations out-of-the-box: HALLARD, COMPRESULT and TTGO ESP32.
// If you use one of these two, just set the parameter to the right value.
// If your pin definitions are different, update the loraModem.h file to reflect these settings.
//	1: HALLARD
//	2: COMRESULT pin out
//	3: ESP32, Wemos pin out (Not used)
//	4: ESP32, Heltec and TTGO pin out (should work for Heltec, 433 and OLED too).
//	5: Other, define your own in loraModem.h (does not include GPS Code)
#if !defined _PIN_OUT
#define _PIN_OUT 5
#endif

// Single channel gateways if they behave strict should only use one frequency
// channel and one, or in case _CAD all, spreading factors.
// The TTN backend replies on RX1 timeslot for spreading factors SF9-SF12.
// If the 1ch gateway is working in and for nodes that ONLY transmit and receive on the set
// and agreed frequency and spreading factor. make sure to set STRICT to 1.
// In this case, the frequency and spreading factor for downlink messages is adapted by this
// gateway
// NOTE: If your node has only one frequency enabled and one SF, you must set this to 1
//		in order to receive downlink messages. This is the default mode.
// NOTE: In all other cases, value 0 works for most gateways with CAD enabled
#define _STRICT_1CH 1

//
// Also, normally the server will respond with SF12 in the RX2 timeslot.
// For TTN, thr RX2 timeslot is SF9, and we should use that one for TTN
#define _RX2_SF 9

// This section defines whether we use the gateway as a repeater
// For his, we use another output channel as the channel (default==0) we are
// receiving the messages on.
#define _REPEATER 0

// Will we use Mutex or not?
// +SPI is input for SPI, SPO is output for SPI
#define _MUTEX 0

// Define if OLED Display is connected to I2C bus. Note that defining an OLED display does not
// impact performance negatively, certainly if no OLED is connected. Wrong OLED will not show
// sensible results on the OLED display
// OLED==0; No OLED display connected
// OLED==1; 0.9" Oled Screen based on SSD1306
// OLED==2;	1.3" Oled screens for Wemos, 128x64 SH1106
#if !defined OLED
#define OLED 0
#endif

// Define whether we want to manage the gateway over UDP (next to management
// thru webinterface).
// This will allow us to send messages over the UDP connection to manage the gateway
// and its parameters. Sometimes the gateway is not accesible from remote,
// in this case we would allow it to use the SERVER UDP connection to receive
// messages as well.
// NOTE: Be aware that these messages are NOT LoRa and NOT LoRa Gateway spec compliant.
//	However that should not interfere with regular gateway operation but instead offer
//	functions to set/reset certain parameters from remote.
#define _GATEWAYMGT 0

// Do extensive logging
// Use the ESP8266 SPIFS filesystem to do extensive logging.
// We must take care that the filesystem never(!) is full, and for that purpose we
// rather have new records/line of statistics than very old.
// Of course we must store enough records to make the filesystem work
#define _STAT_LOG 1

// Set the Server Settings (IMPORTANT)
#define _LOCUDPPORT 1700 // UDP port of gateway! Often 1700 or 1701 is used for upstream comms

// Timing
#define _MSG_INTERVAL 15   // Reset timer in seconds
#define _PULL_INTERVAL 55  // PULL_DATA messages to server to get downstream in milliseconds
#define _STAT_INTERVAL 120 // Send a 'stat' message to server
#define _NTP_INTERVAL 3600 // How often do we want time NTP synchronization
#define _WWW_INTERVAL 60   // Number of seconds before we refresh the WWW page

// This defines whether or not we would use the gateway as
// as sort of backend decoding system for local sensors which decodes
// 1: _LOCALSERVER is used
// 0: Do not use _LOCALSERVER
#define _LOCALSERVER 1 // See server definitions for decodes

// Gateway Ident definitions. Where is the gateway located?
#define _DESCRIPTION "just another gateway" // Name of the gateway
#define _EMAIL<EMAIL_ADDRESS>   // Owner
#define _PLATFORM "ESP32"
#define _LAT 52.53293386
#define _LON 6.06787673
#define _ALT 14 // Altitude

// ntp
// Please add daylight saving time to NTP_TIMEZONES when desired
#define NTP_TIMESERVER "nl.pool.ntp.org" // Country and region specific
#define NTP_TIMEZONES 1                  // How far is our Timezone from UTC (excl daylight saving/summer time)
#define SECS_IN_HOUR 3600
#define NTP_INTR 0 // Do NTP processing with interrupts or in loop();

// lora sensor code definitions
// Defines whether the gateway will also report sensor/status value on MQTT
// (such as battery and GPS)
// after all, a gateway can be a node to the system as well. Some sensors like GPS can be
// sent to the backend as a parameter, some (like humidity for example) can only be sent
// as a regular sensor value.
// Set its LoRa address and key below in this file, See spec. para 4.3.2
// NOTE: The node is switched off by default. Switch it on in the GUI
#define _GATEWAYNODE 0

// We can put the gateway in such a mode that it will (only) recognize
// nodes that are put in a list of trusted nodes
// Values:
// 0: Do not use names for trusted Nodes
// 1: Use the nodes as a translation table for hex codes to names (in TLN)
// 2: Same as 1, but is nodes NOT in the nodes list below they are NOT shown
// NOTE: We probably will make this list dynamic!
#define _TRUSTED_NODES 1
#define _TRUSTED_DECODE 1

// ========================================================================
// DO NOT CHANGE BELOW THIS LINE
// Probably do not change items below this line, only if lists or
// configurations on configNode.h are not large enough for example.
// ========================================================================

// Maximum number of Message History statistics records gathered. 20 is a good maximum
// (memory intensive). For ESP32 maybe 30 could be used as well
#define _MAXSTAT 20

// Define the maximum amount of itemas we monitor on the screen
#define _MAXMONITOR 20

// We will log a list of LoRa nodes that was forwarded using this gateway.
// For eacht node we record:
//	- node Number, or known node name
//	- Last seen 'seconds since 1/1/1970'
//	- SF seen (8-bit integer with SF per bit)
// The initial version _NUMMAX stores max this many nodes, please make
// _MAXSEEN==0 when not used
#define _MAXSEEN 20
#define _SEENFILE "/gwayNum.txt"

// Name of he configfile in SPIFFs	filesystem
// In this file we store the configuration and other relevant info that should
// survive a reboot of the gateway
#define CONFIGFILE "/gwayConfig.txt"

// Define the correct radio type that you are using
#define CFG_sx1276_radio
//#define CFG_sx1272_radio

// Serial Port speed
#define _BAUDRATE 115200 // Works for debug messages to serial momitor

// MQTT definitions, these settings should be standard for TTN
// and need no changing
#define _TTNSERVER "router.eu.thethings.network"
#define _TTNPORT 1700 // Standard port for TTN

// sensor.h; 1-channel LoRa Gateway for ESP8266
// Copyright (c) 2016-2020 Maarten Westenberg version for ESP8266
//
// based on work done by Thomas Telkamp for Raspberry PI 1ch gateway
// and many other contributors.
//
// All rights reserved. This program and the accompanying materials
// are made available under the terms of the MIT License
// which accompanies this distribution, and is available at
// https://opensource.org/licenses/mit-license.php
//
// NO WARRANTY OF ANY KIND IS PROVIDED
//
// Author: Maarten Westenberg<EMAIL_ADDRESS>
//
// This file contains a number of compile-time settings and declarations that are'
// specific to the LoRa rfm95, sx1276, sx1272 radio of the gateway.
//
//
// ------------------------------------------------------------------------------------

// It is possible to use the gateway as a normal sensor node also. In this case,
// substitute the node info below.
#if _GATEWAYNODE == 1

// Valid coding for internal sensors are LCODE and RAW.
// Make sure to only select one.
//#define _LCODE 1
#define _RAW 1
#define _CHECK_MIC 1
#define _SENSOR_INTERVAL 300

#define _DEVADDR               \
	{                          \
		0xAA, 0xAA, 0xAA, 0xAA \
	}
#define _APPSKEY                                                                                \
	{                                                                                \
		0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB \
	}
#define _NWKSKEY                                                                                \
	{                                                                                \
		0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC \
	}
#define _SENSOR_INTERVAL 300
// For ESP32 based T_BEAM/TTGO boards these two are normally included
// If included make value 1, else if not, make them 0
#define _GPS 1
#define _BATTERY 1

#endif //_GATEWAYNODE

#if _TRUSTED_NODES >= 1
struct nodex
{
	uint32_t id; // This is the LoRa ID (coded in 4 bytes uint32_t
	char nm[32]; // Name of the node
};

// Add all your named and trusted nodes to this list
nodex nodes[] = {
	{0x260116BD, "lora-34 PIR node"},		  // F=0
	{0x26011152, "lora-35 temp+humi node"},   // F=0
	{0x2601148C, "lora-36 test node"},		  // F=0
	{0x00000000, "lora-00 well known sensor"} // F=0
};

#endif //_TRUSTED_NODES

// In some cases we like to decode the lora message at the single channel gateway.
// In thisase, we need the NkwSKey and the AppsSKey of the node so that we can decode
// its messages.
// Although this is probably overkill in normal gateway situations, it greatly helps
// in debugging the node messages before they reach the TTN severs.
//
#if _LOCALSERVER == 1
struct codex
{
	uint32_t id;		  // This is the device ID (coded in 4 bytes uint32_t
	unsigned char nm[32]; // A name string which is free to choose
	uint8_t nwkKey[16];   // The Network Session Key of 16 bytes
	uint8_t appKey[16];   // The Application Session Key of 16 bytes
};

// Sometimes we want to decode the sensor completely as we do in the TTN server
// This means that for all nodes we want to view the data of, we need to provide
// the AppsSKey and the NwkSKey

// Definition of all nodes that we want to decode locally on the gateway.
//
codex decodes[] = {
	{0xAAAAAAAA, "lora-EE", // F=0
	 {0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB},
	 {0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC}},
	{0xBBBBBBBB, "lora-FF", // F=0
	 {0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB},
	 {0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC}},
	{0x00000000, "lora-00", // F=0
	 {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
	 {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}}};
#endif //_LOCALSERVER

// If you have a second back-end server defined such as Semtech or loriot.io
// your can define _THINGPORT and _THINGSERVER with your own value.
// If not, make sure that you do not define these, which will save CPU time
// Port is UDP port in this program
//
// Default for testing: Switched off
// #define _THINGSERVER "your.extra.server"		// Server URL of the LoRa-udp.js handler
// #define _THINGPORT 1700						// Port 1700 is old compatibility

// Wifi definitions
// WPA is an array with SSID and password records. Set WPA size to number of entries in array
// When using the WiFiManager, we will overwrite the first entry with the
// accesspoint we last connected to with WifiManager
// NOTE: Structure needs at least one (empty) entry.
//		So WPASIZE must be >= 1
struct wpas
{
	char login[32]; // Maximum Buffer Size (and allocated memory)
	char passw[64];
};

// Please fill in at least ONE valid SSID and password from your own WiFI network
// below. This is needed to get the gateway working
//
wpas wpa[] = {
	{"Boogmakerstraat 45", "danielandclaire"}};

// Define the name of the accesspoint if the gateway is in accesspoint mode (is
// getting WiFi SSID and password using WiFiManager)
#define AP_NAME "ESP32-Gway-Things4U"
#define AP_PASSWD "0297282242"

// For asserting and testing the following defines are used.
//
#if !defined(CFG_noassert)
#define ASSERT(cond) \
	if (!(cond))     \
	gway_failed(__FILE__, __LINE__)
#else
#define ASSERT(cond) /**/
#endif

Thanks in advance for helping me out with this, if this doesn't work i give up with a handmade one and will just order a prefab

I cannot find anything wrong with it. Can you send the loraModem.h file as well, I like to see your definitions of _PIN_OUT == 5.

I am really a big idiot, i changed the pins but not the defines eg:
#define SCK 18
#define MISO 19
#define MOSI 23
#define SS 16
#define DIO0 26
Is the correct one, but i had the old one from pinout 4, left in place, that obviously doesn't work!
thank you so so much for all your help with this! now i can get started with automating my community garden!


Metriq Twitter bot

We will create a Metriq Twitter account bot that tweets when content is added to Metriq or edited. (This will probably require multiple sub-tasks with user stories, to implement. Please discuss design with us, before implementing.)

Referencing this issue to #413. Adding this also to the API milestone.


const fn and generics

Now that I came to like const soundness, of course I had to start thinking about how to achieve const soundness in the presence of generics. The problem is that in a const fn foo<T: Trait>, when we call T::method, how can we know if that method is safe to call in const context? When type-checking the method body, we cannot know if that will later resolve to a const fn or not.
There was plenty of discussion on this that I did not follow closely, but it seems it mostly happened in chat so I don't know of a good summary. @Centril was involved, probably @eddyb and @oli-obk and I am not sure who else?
I propose to discuss this further here so that we have a place to look at. I see two fundamental approaches:

Find some way to solve this and obtain a const sound generic type system, i.e., obtain a static guarantee that (safe) const code will not even attempt to call a non-const fn. (By "static" I mean that we detect this before even starting CTFE, just on the type system level. In our context here, "dynamic" means "during CTFE evaluation", i.e. when miri runs).
Punt on this. We will detect this a CTFE evaluation time. Our type system would only be const sound for non-generic code. Not very satisfying, but it's worth keeping in mind that this is not a horrible alternative, which puts an upper bound on the amount of complexity we should pile up to avoid this outcome. :D

(I understand there are other open questions around const fn, like avoiding having to manually mark every single function as const. Things like const mod have been proposed. Feel free to open a separate issue for those concerns, but I consider such discussion to be off-topic in this issue.)

Here is the simplest possible thing I could come up with, and I hope @centril et al will tell me why that is not sufficient. ;)
I propose that we have const impl Trait for Foo where all methods are checked in const context; and that, whenever we perform trait resolution in const context, we only consider const impl. We also freely allow using trait bounds that were introduced by where clauses, relying on the fact that whoever is satisfying those where clauses will take care to only use const impl. And I think that's already it.
So, for example, in
const fn ptr_eq<T>(x: &T, y: &T) -> bool {
    unsafe { x as *const _ == y as *const _ }
}

we check that we have a const impl PartialEq for *const T.
In
const fn foo<T: PartialOrd>(x: &T, y: &T) -> bool {
    x < y || y < x
}

we don't actually check anything locally, because the where clause is sufficient. We rely on the fact that when foo is called in const context, the caller will only use const impl to satisfy our where clause. That way, we should have an invariant that when a trait method is executed in const context, it always comes from a const impl.

I just realized one complication with this is default implementations and specialization. I suppose that we could let you write const fn when providing a default method, and when a const impl relies on a default method (by not overwriting that method), then the default method must be marked const. As for specialization; a const impl can only be specialized by a const impl.
What I am trying to avoid here is requiring annotations like where T: const PartialOrd, which directly lead us to const polymorphism and a whole bag of complexity that does not seem proportional to the problem we are solving. Essentially, we have implicit const polymorphism: const fn foo<T: Trait> is useable at run-time with all T: Trait, but in const context it requires T: const Trait. Similar, const impl<T> Trait for Foo<T> where T: Something is implicitly const polymorphic so that the resulting impl is const safe if we have T: const Something. This is not as powerful, but vastly simpler and requires hardly any new syntax.
Has such an idea already been discussed? Is there any reason why this does not work?

cc @alercah, @rpjohnst
Dumping stuff:

Start here... https://github.com/rust-lang/rfcs/pull/2237
https://github.com/Centril/rfcs/blob/rfc/const-everywhere/text/0000-const-everywhere.md
https://github.com/Centril/rfc-effects

First, I infer from your setup that we have the following typing rule:
Δ ⊢ TheTrait trait
Δ ⊢ TheType type
Δ ⊢ Implemented(TheType, const TheTrait)
----------------------------------------
Δ ⊢ Implemented(TheType, TheTrait)

is that accurate? If not, the system is pretty unusable.
Our primary goal with const impl or impl const or whatever should be code reuse.
As such, I think it is important that you can let something be const if the dependents are const.
I also think that whatever we come up with should scale to other forms of restrictions such as statically preventing panics, etc.
The idea of implicitly bounding traits as const is not bad, and can hopefully be retrofitted onto various designs. But I think inventing ergonomic syntax is starting at the wrong end of things. At the moment, I'm less interested about surface syntax and more about core semantics, inference, coherence and the consequences for reuse. For example, consider the following trait in the standard library which we would like to retrofit for const contexts (also Iterator, ..):
pub trait Hash {
    fn hash<H>(&self, state: &mut H)
    where H: Hasher; // As defined today...
}

If we accept the typing rule above, then a const impl must be:
const impl Hash for Foo {
    fn hash<H>(&self, state: &mut H)
    where H: Hasher // this is **NOT** `H: const Hasher`
    {
        // can't use any methods of `H`!
    }
}

We can't write:
const impl Hash for Foo {
    const fn hash<H>(&self, state: &mut H)
    where H: const Hasher
    {
        ...
    }
}

If we did, then either the typing rule above can't hold, or it does hold and if we allow the impl, the system is unsound. It is unsound because we can write something like this:
trait Bar {
    fn bar() -> usize;
}

trait Foo {
    fn foo<T: Bar>() -> usize;
}

struct Wibble;
struct Wobble;

impl Bar for Wibble {
    fn bar() -> usize {
        read_usize_from_file()
    }
}

const impl Foo for Wobble {
    const fn foo<T: const Bar>() -> usize {
        T::bar()
    }
}

const ITEM: usize = Foo::foo::<Bar>();

So the contravariant position of type parameters is causing problems for us if we wish to support existing code.
Instead, if we encode things as (this is not the surface syntax, but rather a language we can desugar to...):
trait Hash<effect E = io> {
    E fn hash<H: E Hasher>(&self, state: &mut H);
}

then the definition is backwards compatible. Here, E is a parametric effect variable.
If we want a const version of Hash, we can then write T: Hash<const>.
We can then try to make the surface syntax more ergonomic by adding elision, various shorthands, etc.
...to be continued...

https://github.com/Centril/rfcs/blob/rfc/const-everywhere/text/0000-const-everywhere.md
https://github.com/Centril/rfc-effects

Ah, that's where all that stuff is. :)
TBH I feel this is beyond the level of complexity that is worth throwing at this problem...

First, I infer from your setup that we have the following typing rule:

I can only guess what exactly that means, but every const impl also acts as a normal impl if that's what you mean?

The idea of implicitly bounding traits as const is not bad, and can hopefully be retrofitted onto various designs. But I think inventing ergonomic syntax is starting at the wrong end of things. At the moment, I'm less interested about surface syntax and more about core semantics, inference, coherence and the consequences for reuse.

I think restricting the type system to just what I described makes this discussion just so much simpler.
const impl Hash for Foo {
    fn hash<H>(&self, state: &mut H)
    where H: Hasher // this is **NOT** `H: const Hasher`
    {
        // can't use any methods of `H`!
    }
}

Under my proposal, this can use the methods of H because they come from a where clause.
I can try to express this using fancy syntax as well: Let's say we have "const mode variables \c" that we can quantify over, that can be either const or not. Then the above impl Hash would translate to something like
for<\c> \c impl Hash for Foo {
    fn hash<H>(&self, state: &mut H)
    where H: \c Hasher
    {
        // *can* use all methods of `H`!
    }
}

One thing I should may more explicit: I claim that every program accepted by the const type system would also be accepted by the "normal" type system. This is interesting because const-safety of a function does not imply safety (because const-safety only talks about what happens when you use the function with const-valid inputs).
So, we only have to typecheck the const impl Hash with the const type system (effectively typechecking the variant where \c is const) and will automatically know that the normal type system would also accept it (the variant where \c is runtime).

Reading over https://github.com/Centril/rfcs/blob/rfc/const-everywhere/text/0000-const-everywhere.md, I realized I did not talk about what to do with fn pointers. I think we can carry over the same idea:
const fn iter<T>(x: usize, f: fn(T) -> T) -> T

Can be called with any const fn in const context, but called with any fn at run-time. Just like we only allow const impl in const context (and probably need an invariant that all trait objects have a vtable which is a const impl), we also only allow using const fn pointers.
IOW, it is sugar for
for<\c> \c fn iter<T>(x: usize, f: \c fn(T) -> T) -> T

which I think you would write
?const fn iter<T>(x: usize, f: ?const fn(T) -> T) -> T

but I think this lacks the crucial information that the two ?const are tied together.
The trouble with this is that we already allow creating fn pointers on stable... :/

TBH I feel this is beyond the level of complexity that is worth throwing at this problem... so really hope we can have something simpler that's getting us most of the way.

I want to reuse the same mechanism for other forms of restrictions such as "this can't panic" and "this will always terminate" as well as adding more abilities such as "this can use RandomIntelExtension" or "this can use async", so I'd like a system that is composable, flexible, expressive, and ergonomic to use.

I can only guess what exactly that means, but every const impl also acts as a normal impl if that's what you mean?

The rule says that if T: const Trait holds, then T: Trait also holds, so it is a subtyping rule.

I think restricting the type system to just what I described makes this discussion just so much simpler.

Sure, but then you lose out on a bunch of interesting things you might want to encode :)
For example, it is not possible in your system to encode the following:
fn foo<F: const Fn() -> usize>(fun: F) {
    write_to_file("bar", fun()); // `fun` may not cause side-effects.
}

for<\c> \c impl Hash for Foo {
    fn hash<H>(&self, state: &mut H)
    where H: \c Hasher
    {
        // *can* use all methods of `H`!
    }
}

So, when you need a const impl you get one where the bound is const Hasher, but when you need a normal impl you just get a normal bound.

Yeah, this is much clearer wrt. what you mean, which is totally different from what I inferred (subtyping) at first :)
Being even more clear about what this means, I'd write:
for<effect C> C impl Hash for Foo {
    fn hash<H>(&self, state: &mut H) where H: C Hasher {
        ...
    }
}

where the possible effect is io (what we have today) as well as the absence of it. However, it seems to me that \c or C is possibly unconstrained because it is not mentioned by either Hash or Foo.
Also note that if you have some existing trait (as defined today) with provided methods where their definitions have side effects, then you'd need to require the const impl to redefine those methods.

EDIT: Looking at some of your work, it seems you would write that using ?const instead of \c. However, one important point is that it must be the same constness in both places, which ?const cannot express.

Well, you could use ?const for "possibly const" the way you've used const in your syntax and const for "must be const". Speaking of which, with the setup of having const mean "possibly const", then there's no way to use type parameter T with T: Foo where Foo has some function bar as T::bar() in a const generics context because we can't know before T is instantiated whether it is safe to use it in such a context.

IOW, I am not taking an effect system point-of-view here. Instead I think of there being two separate type systems, but they have this useful relationship. I think that means we can avoid all the usual complexity that effect systems bring.

Right; but it amounts to an effect-polymorphic system, albeit a limited and implicit one.
I also don't think it scales well to take that POV when you want to add more effects / restrictions.
In particular, I'd like to encode:
pub fn replace_with<T, F>(val: &mut T, closure: F)
where
    F: no_panic FnOnce(T) -> T
{
    unsafe {
        let old = ptr::read(val);
        let new = closure(old);
        ptr::write(val, new);
    }
}

Since we've guaranteed that closure(old) can't panic, it's safe. But if we let no_panic be "maybe don't panic", it doesn't work.

Just like we only allow const impl in const context (and probably need an invariant that all trait objects have a vtable which is a const impl), we also only allow using const fn pointers.

Yes; this is one of the major problems with the "exposed body" approach.
In my first system, I had contemplated Box<dyn const Foo> and impl const Foo as saying explicitly that existentials. If you don't have such an annotation, then Box<dyn Foo> or impl Foo need to be different types in an fn context and in a const fn context. I'm concerned that this could be hard to understand for users.
So what am I currently contemplating instead?
We can use lightweight quantification:
pub trait Hash<#E = io> { // #E  denotes an effect variable... We could possibly elide `io` here
    fn hash<H>(&self, state: &mut H)
    where H: #E Hasher; // As defined today...
}

(We can totally bikeshed the sigil #, multicore OCaml uses ! instead)
We can use implicit quantification on functions:
pub trait Iterator<#A> { // = io elided
    type Item;

    #A fn next(&mut self) -> Option<Self::Item>;

    ...

    #A fn chain<U>(self, other: U) -> Chain<Self, <U as IntoIterator<#B>>::IntoIter>
    where U: IntoIterator<#B, Item = Self::Item>,
    { ... }

    #A fn zip<U>(self, other: U) -> Zip<Self, <U as IntoIterator<#B>>::IntoIter>
    where U: IntoIterator<#B>,
    { ... }

    #A fn map<B, F: FnMut<#C>(Self::Item) -> B>(self, f: F) -> Map<Self, F> { ... }

    #A #B fn for_each<F: FnMut<#B>(Self::Item)>(self, f: F) { ... }

    #A fn filter<P>(self, predicate: P) -> Filter<Self, P>
    where P: FnMut<#B>(&Self::Item) -> bool,
    { ... }

    #A fn filter_map<B, F>(self, f: F) -> FilterMap<Self, F>
    where F: FnMut<#B>(Self::Item) -> Option<B>,
    { ... }

    ...

    #A fn flat_map<U, F>(self, f: F) -> FlatMap<Self, U, F>
    where
        F: FnMut<#B>(Self::Item) -> U,
        U: IntoIterator<#C>,
    { ... }

    #A fn flatten(self) -> Flatten<Self> where Self::Item: IntoIterator<#B> { ... }
    // Same as:
    #A fn flatten<#B>(self) -> Flatten<Self> where Self::Item: IntoIterator<#B> { ... }

    ...

    #A #C #D fn try_fold<B, F, R>(&mut self, init: B, f: F) -> R
    where
        F: FnMut<#C>(B, Self::Item) -> R,
        R: Try<#D, Ok = B>,
    { ... }

    ...
}

I don't think this is too bad. It is backwards compatible and also scales to more effects and restrictions.
The trait is also fully in on it, so all provided definitions in the trait are also as a consequence.
We can regain the syntax T: const Trait by saying that #E Trait means "find all quantified effect variables in the trait and require that they are #E".
If writing #A becomes repetitive, we can have some sort of syntax for "apply the variable to all functions" or something.
Of course, all of this is more complex, but also more flexible and expressive.
I also think it is understandable, because we already have 2 different things we can quantify over today:

lifetimes
types

with one more on the way:

const values

so people will already be used to quantify over a bunch of stuff.
@alercah had more ideas so I'll let them fill in...

I had also thought about some level of inference: e.g. by default, traits are considered to be fully effect-polymorphic (by adding an implicit effect parameter and applying it to all functions). This would only be done where it was safe (e.g. no higher-order functions involved? or perhaps only in limited cases of higher-order functions), but would help make effect-polymorphism usable on existing traits without having to add it explicitly, creating a giant migration headache.

It seems to me that @RalfJung's syntax is both forward-compatible with an effect system, and eminently reasonable as an actual syntax. Even if we ever get an effect system, I strongly suspect we would want such a shorthand anyway.
It also seems to me that the sorts of things @Centril wants to add are... well beyond the complexity budget. Fun to think about, perhaps useful as a tool to make const sound and usable, but not a real argument against considering @RalfJung's model, especially if it really is forward-compatible.

Sure, but then you lose out on a bunch of interesting things you might want to encode :)
For example, it is not possible in your system to encode the following:
fn foo<F: const Fn() -> usize>(fun: F) {
    write_to_file("bar", fun()); // `fun` may not cause side-effects.
}

Notice that const, a priori, has nothing to do with side-effects. const is about const-safety. I think const-safety is a term where we can all agree on what it means, whereas side-effects are much harder to define.
Yes, my system is deliberately restricted. I don't see Rust getting a full effect system any time soon, and I wouldn't want to wait with const fn until we found a design that's both expressive and ergonomic (probably that would be the first such effect system ever?). As you know, Rust used to have an effect system and it got removed (from what I read), amongst other reasons, because the complexity budget of the language is already "used by" by lifetimes and borrowing.
I agree, though, that terminology from a power powerful system can be useful in this discussion.

the possible effect is io (what we have today) as well as the absence of it.

Again, I'd like to separate const from "not io". Saying that io is the effect we have currently is rather arbitrary, i.e. we also have non-termination and panics -- and it may be useful to split io into different effects. (Memory and file system are a priory unrelated effects, for example. Just Haskell decided to lump it all together...)

Also note that if you have some existing trait (as defined today) with provided methods where their definitions have side effects, then you'd need to require the const impl to redefine those methods.

I do not understand what you are saying here.

Well, you could use ?const for "possibly const" the way you've used const in your syntax and const for "must be const". Speaking of which, with the setup of having const mean "possibly const", then there's no way to use type parameter T with T: Foo where Foo has some function bar as T::bar() in a const generics context because we can't know before T is instantiated whether it is safe to use it in such a context.

The key difference between your ?const and my const is that I am expressing "this function is const if you are using const impl to satisfy trait bounds".

Essentially, the type const fn is only different from fn when are are in const-context, and is otherwise considered the same type.

What meaningful work could a const fn do with a non-const function argument? I'm not sure we need the extra const and its typing implications for function arguments.

@lxrec I have an example in my post

for function pointers one can think e.g. of a function that initializes a data structure, and just puts a function pointer into it without ever calling that function -- that's perfectly safe to do in const context even when the function is not const-safe.

Summarizing today's discussion of @oli-obk, @Centril and me on Discord:
We all agreed that whatever proposal we come up with should be able to desugar into a full-blown effect system. That helps for discussion, for future addition of such a system (if that ever happens), and to check the design. The first implementation will likely not use that desugaring though but implement the rules directly, as that is much simpler.
@Centril's main point of contention with my proposal are (1) handling of provided methods in traits (i.e. those where the trait definition provides a default implementation), and (2) uniformity issues around explicit const dyn/const fn types, but implicit const Trait bounds. (And something about parametricity that I did not understand.^^)
As for (2), we can easily decide to make people write const Trait bounds in const fn. I do not think that that is worth it, but it'd be an okay outcome -- so I propose we experiment with that during stabilization.
For (1), we realized that my proposal had a problem: I imagined that when you write const impl, if the provided method was not a const fn, you habe to implement it yourself. That would work, however, it makes adding a non-const provided method to a trait a breaking change! If we do not want that, we can alternative say that traits must be marked as const trait if they want to permit a const impl. Then all provided methods would implicitly be const fn. Personally I am not decided yet which of these two is preferrable; @oli-obk and @Centril are tending towards const trait.
I think that's it? Please amend if I missed anything.

@RalfJung I'm undecided on the last point too, but I think it's quite permissible to leave that as an unresolved question for now. Do you feel we're at a point an RFC can be written for all this now?

Maybe?
I plan to submit something on const safety and promotion to this repo within this month. I'd be happy for someone else to write up the generics stuff :D

@RalfJung I think promotion is already sorted... I did that in a PR a few months back.

I am not talking about implementation, but about https://github.com/rust-rfcs/const-eval/blob/master/promotion.md

@RalfJung I thought point 2 was already disallowed, but it seems someone added a const_raw_ptr_to_usize_cast feature (why??).

Why should unsafe const code not be able to do that?
It is needed, for example, to eventually make HashMap const-compatible.

Because it causes non-determinism (and thus non-referential transparency)... I don't see why HashMap needs it.

Because it causes non-determinism

Wrong.
Casting a pointer to a usize in miri does not actually create an integer. It keeps a pointer value at integer type. See this blog post and the definition of Scalar in the miri engine.

I don't see why HashMap needs it.

It stores a pointer and a boolean together in a single usize, exploiting the fact that the pointer is aligned and hence some bits at the end are always 0.

struct Foo<T> {
  x: usize,
  f: const fn(T) -> T,
}
const fn twice<T>(arg: T, fun: Foo<T>) -> T {
    fun.f(fun.f(arg)) // OK. We know that `fun` respects the rules of `const`.
}

Does this mean
fn foo<T>(t: T) -> T { t }
let x = Foo { x: 42, f: foo };

is not legal because foo is not const fn? Even in runtime code where the constness is irrelevant?

Does this mean
fn foo<T>(t: T) -> T { t }
let x = Foo { x: 42, f: foo };

is not legal because foo is not const fn? Even in runtime code where the constness is irrelevant?

No; const fn and fn are the same type when typechecking runtime code.
I think of Rust as having two typesystems at this point, one used for typechecking code in const context and one for the rest. They are related by the fact that const-well-typed code is also runtime-well-typed. The const type system is the only one making any distinctions based on const fn vs. fn.
In https://github.com/rust-lang/rust/issues/53972, you suggested almost the same scheme, except you planned to also allow const as qualifier in front of any type. I am a bit worried about what exactly that is even supposed to mean... in any case, I disagree with
struct Bar(const fn());
const fn bar(f: Bar) {
    (f.0)() // not allowed
}

This should be allowed, we said const fn explicitly after all!

@glaebhoerl I do see a formulation in terms of validity/safety though -- in const context, a fn() is safe when it points to any function, but a const fn() is safe only when it points to a const-callable function. const fn() could still be valid when pointing to a non-const fn, but then calling it causes "UB" (it causes a CTFE engine error, to be more precise).

This should be allowed, we said const fn explicitly after all!

So when using Bar in a const fn, the field always needs to be const fn, even if we don't care about that because we'd just use the value "by move"
const fn foo(b: Bar) -> (Bar, i32) { (b, 42) }

Would be impossible to write for allowing non const fns for b's field, even though
fn bar(b: Bar) -> (Bar, i32) { (b, 42) }

Is ok without b's field being const fn ?

So when using Bar in a const fn, the field always needs to be const fn

Yes, you asked for const fn specifically. Bar is a newtype around const fn, the two should behave the same.

That kind of constness adding would then add constness to all function pointers inside the struct, even if that is not necessary due to only one of them being called inside the function

Yeah, I'm not a fan either. But at least it keeps newtypes working, which I think is something we should absolutely not break.
What you are asking for is essentially types which are generic wrt. const-ness. I'd rather avoid such an effect system until we have a clearly demonstrated need.

Sgtm. I am for the simple version, since it covers the real use cases I can think of. artificial examples are easy to come up with but rarely useful in practice. I have just one more thing: I presume we can now transmute function pointers to const function pointers (unsafely) and call them and then either weird things happen (like half of full miri things working without feature gates and super useless errors for very nonconst things) or we error out with "tried to call non const fn". I personally am for the former, for the lulz, but I'm happy with either scheme. Unsafe is unsafe after all, and we kind of give the user a way around the guarantees of the language.

What currently happens is the latter, I think -- I hope (should add a test once calling fn pointers is possible). And indeed I think we should error out immediately when calling a non-const fn, to avoid accidentally stabilizing whatever the heck happens then.^^

Yes that's the current behaviour. OK, let's keep it. it's way saner, even if less fun


13520 - Mari - Incorrect lat-lon for song 3505; Suggest changing society lat-lon

Location name for song 3505 is "Lipovka, Mari El Republic, Russia," which is correct. However, lat-lon corresponds with Lipovka, Leningrad Oblast, which is far away. There are a lot of towns called Lipovka. The Lipovka in Mari El Republic doesn't come up on google maps, but other sources list its coordinates as 56.35, 46.30. So, I suggest changing lat-lon to that.

Society lat-lon is pretty far outside of the Mari El Republic. Suggest changing to average song lat-lon, 56.29, 49.83, which puts it closer to the songs and to the glottolog lat-lon.

Note for @kirbykat: coordinates for Mari (Ch4) on D-PLACE are pretty far from the lat-lon of the language assigned to it, and from where other web sources report the society to be located. Are these coordinates correct?

Part 2 implemented


[SPARK-36645][SQL][FOLLOWUP] Disable min/max push down for Parquet Binary

What changes were proposed in this pull request?
Disable min/max push down for Parquet Binary
Why are the changes needed?
Parquet Binary min/max could be truncated. We may get wrong result if we rely on parquet Binary min/max.
Does this PR introduce any user-facing change?
No
How was this patch tested?
modify existing tests

Test build #144477 has started for PR 34346 at commit 06532de.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/48949/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/48949/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/144477/

Test build #144495 has finished for PR 34346 at commit 1dcef61.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #144520 has started for PR 34346 at commit 93225b0.

also cc @sadikovi @timarmstrong @sunchao @viirya @c21

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/48991/

Merged to master.

Test build #144520 has finished for PR 34346 at commit 93225b0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Thank you so much, everyone!


Unable to Import React Azure Maps

Vitest is unable to correctly import react-azure-maps during testing with an import error.
This is likely caused by incorrect package.json.
At the moment:
{
"source": "src/react-azure-maps.ts",
"module": "dist/react-azure-maps.es5.js",
"typings": "dist/types/react-azure-maps.d.ts",
}

It should be:
{
"module": "dist/react-azure-maps.es5.js",
"types": "dist/types/react-azure-maps.d.ts",
"exports": {
    ".": {
      "import": "./dist/react-azure-maps.es5.js",
      "types": "./dist/types/react-azure-maps.d.ts"
    }
  },
}

@sebasptsch, can you elaborate on the import error that you're having? A sample code to reproduce the error would be much appreciated. Thank you.

import {
  AzureMap,
  AzureMapDataSourceProvider,
  AzureMapFeature,
  AzureMapLayerProvider,
  AzureMapsProvider,
} from "react-azure-maps";

Vite fails to compile the code citing that the above line is the problem and that it failed to resolve react-azure-maps.
If you look at the package.json reference provided on npmjs.com you can see how code is typically exported from a package.

Thank you @sebasptsch. Tested https://github.com/Azure/react-azure-maps/pull/133 and LGTM!
Just for future reference, the error from vitest is:
Error: Failed to resolve entry for package "react-azure-maps". The package may have incorrect main/module/exports specified in its package.json.
 ❯ packageEntryFailure node_modules/vite/dist/node/chunks/dep-51c4f80a.js:34143:11
 ❯ resolvePackageEntry node_modules/vite/dist/node/chunks/dep-51c4f80a.js:34140:5
 ❯ tryNodeResolve node_modules/vite/dist/node/chunks/dep-51c4f80a.js:33881:20
 ❯ Context.resolveId node_modules/vite/dist/node/chunks/dep-51c4f80a.js:33642:28
 ❯ Object.resolveId node_modules/vite/dist/node/chunks/dep-51c4f80a.js:40199:46
 ❯ TransformContext.resolve node_modules/vite/dist/node/chunks/dep-51c4f80a.js:39964:23
 ❯ normalizeUrl node_modules/vite/dist/node/chunks/dep-51c4f80a.js:36874:34
 ❯ TransformContext.transform node_modules/vite/dist/node/chunks/dep-51c4f80a.js:37015:47
 ❯ Object.transform node_modules/vite/dist/node/chunks/dep-51c4f80a.js:40271:30
 ❯ loadAndTransform node_modules/vite/dist/node/chunks/dep-51c4f80a.js:36658:29


[desktop] readjusted spacing and layout in TransferDetailGeneral

If you can take a look @gubatron  - Small adjustments in spacing and layout of the general tab. I think its a bit cleaner to read through all the information. Let me know what you think.
This one is before pic:

This one is after:

Also made all the cells in Files tab resizable with adjusted widths for better readability.

Kudos @marcelinkaaa.


AzureDevOps: New App - Initial Implementation

Please ensure your pull request (PR) adheres to the following guidelines:

Please refer to our contributing documentation for any questions on submitting a pull request, link: Contribution Guide

Pull Request Checklist
Please check if your PR fulfills the following requirements:

[x] Testing of all the changes has been performed (for bug fixes / features)
[ ] The readme.html has been reviewed and added / updated if needed (for bug fixes / features)
[x] Use the following format for the PR description: <App Name>: <PR Type> - <PR Description>
[x] Provide release notes as part of the PR submission which describe high level points about the changes for the upcoming GA release.
[ ] Verify all checks are passing.
[x] Do NOT use the next branch of the forked repo. Create separate feature branch for raising the PR.
[x] Do NOT submit updates to dependencies unless it fixes an issue.

Pull Request Type
Please check the type of change your PR introduces:

[x] New App
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation
[ ] Other (please describe):

Security Considerations (REQUIRED)

[ ] If you are exposing any endpoints using a REST handler,
please document them in the readme.html.
[ ] If this is a new connector or you are adding new actions

[ ] Please document in the readme.html all methods (eg, OAuth) used to authenticate
with the service that the connector is integrating with.
[ ] If any actions are unable to run on SOAR Cloud, please document this in the readme.html.

[ ] Are you introducing any new cryptography modules? If yes, please elaborate their purpose:
[ ] Are you are accessing the file system? If yes, please verify that you are only accessing paths returned through
the Vault API.
[ ] Are you are marking code to be ignored by Semgrep with nosemgrep?
If yes, please provide justification in an additional comment next to the ignored code.

Release Notes (REQUIRED)

Initial implementation of the app.

What is the current behavior? (OPTIONAL)

Describe the current behavior that you are modifying.

What is the new behavior? (OPTIONAL)
get work item - Get information about a single work item.
add work item - Creates a single work item.
list iterations - Get team's iteration
add comment - Add a comment on a work item.
Other information (OPTIONAL)

Any other information that is important to this PR such as screenshots of how the component looks before and after the change.

Pay close attention to (OPTIONAL)

Any specific code change or test case points which must be addressed/reviewed at the time of GA release.

Screenshots (if relevant)

Thanks for contributing!

Hi @import-au,
We observed that you have added "Person" in the publisher and license fields in the JSON file. Can you please update this with an appropriate value?

Hi @import-au,
Can you please check this comment - https://github.com/splunk-soar-connectors/azuredevops/pull/1#issuecomment-1262204623 and update the publisher and license accordingly

Hi @import-au,
We have decided to proceed with the publisher as "Splunk Community" and license as "Copyright (c) 2022 Splunk Inc.".  If you require any changes, feel free to raise a new PR to update it.


Add more elements (and fix the coloring code)

Adds:

Creative inventory search
Recipe book search
Options slider bar

You can see the new options at https://susko3.github.io/Translations-Size-Checker.
The Recipe book could be cropped if desired.

Looks pretty good to me!
Impressive work thanks a lot for that!


feat(haskell) disable unsafe features in student submissions

What

This PR disables various unsafe features in student submissions:

the pre-processor: it can be abused to read other files at compile time. In particular, it could be used to extract test and solution data.
passing custom compilation flags: it can be used to re-activate the pre-processor
symlinks: they can be abused to link to solution or testing data.

Moreover, this PR changes the test behaviour on local machines by outputting the test results in a pretty format on the console rather than creating a xml.

Why

One of our tutors discovered these security issues. They allow students to cheat by reading either solution or test files.
XML is not made to be read by humans. For local tests, the console output is way nicer to read.

I am wondering if any of this might be dangerous for test environments of other programming languages on artemis too? Everything that uses a pre-processor and shows students failed build outputs might be affected by i and ii.
Everything that uses sample solutions during testing might be affected by iii.

I am wondering if any of this might be dangerous for test environments of other programming languages on artemis too? Everything that uses a pre-processor and shows students failed build outputs might be affected by i and ii.
Everything that uses sample solutions during testing might be affected by iii.

thanks for the contribution 👍

thanks for the contribution 👍

Approve

Approve


Windows 10 volumes cannot find folder

I used volumes:
-/var/win:/storage
Why can't I find the/storage folder when I mount it after entering Windows

is there any method to mount directory directly into windows, so that i can use it like a share folder?


Simplify CLI instructions

@jkotas @schellap PTAL
This is in context of simplifying the CLI access Jan was talking about in https://github.com/dotnet/corert/pull/521

LGTM

Thanks!


Doens't show year in datepicker

There is code:
var ipObj1 = {
        callback: function (val) {  //Mandatory
        },
        from: new Date(1950, 0, 1),
        to: new Date(2009, 0, 1),
        inputDate: new Date(1957, 2, 15),
        setLabel: 'Выбрать',
        closeLabel: 'Отмена',
        mondayFirst: true,
        dateFormat: 'yyyy-MM-dd',
        closeOnSelect: false,
        templateType: 'popup'
    };

    $scope.openDatePicker = function(){
        ionicDatePicker.openDatePicker(ipObj1);
    };

As you see at screenshot, inputDate is ok, but if month and day are selected, year is not. There is no any error. Can you help me?

I have the same issue.
need help. Thanks very much.

Same issue for me.

Can anyone make a codepen and paste the link here?

`//日期选择
function getLocalTime(nS) {
return new Date(parseInt(nS)).toLocaleString().replace(/年|月/g, "-").replace(/日/g, " ");
}
//alert(getLocalTime(1177824835));
var ipObj1 = {
  callback: function (val) {  //Mandatory
    console.log('Return value from the datepicker popup is : ' + val, new Date(val));
    $scope.selectedDate = val;
    console.log(getLocalTime($scope.selectedDate));
  },
  from: new Date(2016, 1, 1), //Optional
  to: new Date(2030, 12, 31), //Optional
  inputDate: new Date(),      //Optional
  mondayFirst: true,          //Optional
  closeOnSelect: false,       //Optional
  templateType: 'popup'       //Optional
};

$scope.openDatePicker = function(){
  ionicDatePicker.openDatePicker(ipObj1);
};`

Hello,This is my code, I can open the date picker, but it can't display the year .

Please take a look at the demo page. It will show correctly. And also please double check the properties from and to, which should have the current year in the range or it should be in the range of inputDate.

This is still an issue. Even with correct from and to within the range. I'm trying to figure out why it does work in your demo, but I can't trace it.

You should't close the issue. Demo works correct because its based on older version of Ionic, where used an older version of angular.
After I updated for Ionic 1.3 - year doesn't show correctly. And I guess you just need to change and unpdate some things in plugin... Try to test at Ionic 1.3.
Still waiting for solution :) Thanks.

@rajeshwarpatlolla
The problem seems only show on the new ionic version .


OpenApi 3.0 support to allow ordering

The current implementation, Swagger v2 support, allows to configure the order of the parameters, operations and definitions. Also, allows to group paths by tags.
Ideally, OpenApi 3.0 support #340  should be allow above customization too.

I would like to ... third this request.
It's extremely useful. Especially when you have DTO's & that have parent classes, or it only makes sense to enter data in one specific order for parameters.


Disconnect when transfer complete

Describe the bug
Disconnect connection must happen when transfer complete and UI responds happen in iOS.
Expected behavior
Disconnect connection happens when transfer complete.
Actual behavior
Disconnect connection not happening.
Screenshots
If applicable, add screenshots to help explain your problem.
Add the screenshot of the profile page with commit id
Smartphone (please complete the following information):

Wallet Device: [e.g. iPhone6]

Phone make/model: [e.g. :Vivo Y73]
OS: [e.g. iOS8.1]
BLE version : [e.g. 4.2]

Verifier Device: [e.g. iPhone6]

Phone make/model: [e.g. :Vivo Y73]
OS: [e.g. iOS8.1]
BLE version : [e.g. 4.2]

Inji app version: [e.g 0.3.0]

Mimoto version: [e.g 1.2.x]

MOSIP Version: [e.g. 1.2.1]

Where does the issue occur: Wallet/Verifier?
Logs of wallet and verifier:
Additional context
Add any other context about the problem here.

The following PRs implements disconnection of the verifier and wallet after the VC is transferred and accepted/rejected on the iOS side.
PR for mosip/tuvali: https://github.com/mosip/tuvali/pull/28
PR for mosip/inji: https://github.com/mosip/inji/pull/595, https://github.com/mosip/inji/pull/597
The PRs have been merged in 28-02-2023 Release and the latest commit id on mosip/inji/develop is 7cdee82

Closing since issue as it was delivered.


Add remarvin mountpoints to xochitl application file

remarvin uses bind mounts and gocryptfs to add multiple profiles and encryption.
These mount points aren't included in the current chroot for xochitl, keeping it from seeing the decrypted files.
remarvin is not in toltec yet but compatibility would be nice to have and I experienced no issues with these changes on a non-encrypted setup.
Should fix https://github.com/plan5/remarvin/issues/6

Please make sure to update the toltec copy of xochitl.oxide when remarvin is added to toltec. I would recommend adding instructions to your repo for how to manually add it to the chroot for now.

Please make sure to update the toltec copy of xochitl.oxide when remarvin is added to toltec. I would recommend adding instructions to your repo for how to manually add it to the chroot for now.

Ok, thanks. Then I'll close the PR for now.

Oh, I wasn't asking you to close the PR, I was going to merge it as soon as the build finished.

Oops, okay, reopening then :)


Add nats connector app

Signed-off-by: Vivek Singh<EMAIL_ADDRESS>
Description

Motivation and Context

[x] I have raised an issue to propose this change (required)
Fixes #112

How Has This Been Tested?

Tested on my local desktop with k3d
./bin/arkade-darwin install nats-connector -n openfaas
2020/06/17 14:18:31 Client: x86_64, Darwin
2020/06/17 14:18:31 User dir established as: /Users/viveks/.arkade/
map[]
"openfaas/nats-connector" has been added to your repositories

VALUES values.yaml
Command: /Users/viveks/.arkade/bin/helm3/helm [upgrade --install nats-connector openfaas/nats-connector --namespace openfaas --values /var/folders/tw/6ww2mtms12ndnypdycqfy_q40000gy/T/charts/nats-connector/values.yaml]
Release "nats-connector" does not exist. Installing it now.
NAME: nats-connector
LAST DEPLOYED: Wed Jun 17 14:18:38 2020
NAMESPACE: openfaas
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thanks for installing nats-connector. Please follow the instructions below to get you started.

You can watch the Connector logs to see it invoke your functions:

$ kubectl logs -n openfaas deploy/nats-connector -f
=======================================================================
= nats-connector has been installed.                                   =
=======================================================================

# View the connector logs:

kubectl logs deploy/nats-connector -n openfaas -f

# Find out more on the project homepage:
https://github.com/openfaas/faas-netes/tree/master/chart/nats-connector

Thanks for using arkade!
➜  arkade git:(nats-connector) kubectl logs -n openfaas deploy/nats-connector -f
==============================================================================
NATS Connector for OpenFaaS

Gateway URL: http://gateway.openfaas:8080
NATS URL: nats://nats:4222
Topics: 30s
Upstream timeout: [nats-test]
Topic-map rebuild interval: 5s
Async invocation: "false"
==============================================================================

2020/06/17 08:48:39 Configured topics: [nats-test]
2020/06/17 08:48:39 Binding to topic: "nats-test"
2020/06/17 08:48:39 Subscription: nats-test ready

➜  arkade git:(nats-connector) export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
➜  arkade git:(nats-connector) faas-cli deploy --name receive-message --image openfaas/receive-message:latest --fprocess='./handler' --annotation topic="nats-test"
➜  arkade git:(nats-connector) kubectl port-forward -n openfaas svc/gateway 8080:8080 &
[1] 63950
➜  arkade git:(nats-connector) Forwarding from <IP_ADDRESS>:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

➜  arkade git:(nats-connector) faas-cli deploy --name receive-message --image openfaas/receive-message:latest --fprocess='./handler' --annotation topic="nats-test"
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
Handling connection for 8080

Deployed. 202 Accepted.
URL: http://<IP_ADDRESS>:8080/function/receive-message

➜  arkade git:(nats-connector) faas-cli deploy --name publish-message --image openfaas/publish-message:latest --fprocess='./handler' --env nats_url=nats://nats.openfaas:4222
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
Handling connection for 8080

Deployed. 202 Accepted.
URL: http://<IP_ADDRESS>:8080/function/publish-message

➜  arkade git:(nats-connector) faas-cli invoke publish-message <<< "test message"
Handling connection for 8080
Sent "test message"%                                                                                ➜  arkade git:(nats-connector) kubectl logs -n openfaas deploy/nats-connector -f
==============================================================================
NATS Connector for OpenFaaS

Gateway URL: http://gateway.openfaas:8080
NATS URL: nats://nats:4222
Topics: 30s
Upstream timeout: [nats-test]
Topic-map rebuild interval: 5s
Async invocation: "false"
==============================================================================

2020/06/17 08:48:39 Configured topics: [nats-test]
2020/06/17 08:48:39 Binding to topic: "nats-test"
2020/06/17 08:48:39 Subscription: nats-test ready
2020/06/17 08:50:03 Topic: nats-test, message: "test message"
2020/06/17 08:50:03 Invoke function: figlet.openfaas-fn
2020/06/17 08:50:03 Invoke function: receive-message.openfaas-fn
2020/06/17 08:50:03 connector-sdk got result: [200] nats-test => figlet.openfaas-fn (372) bytes
2020/06/17 08:50:03 connector-sdk got result: [200] nats-test => receive-message.openfaas-fn (28) bytes

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

[ ] I have tested this on arm, or have added code to prevent deployment

I think there is something buggy with the pr. I setup a fresh k3d cluster and did an arkade install nats-connector.
It seems that the app didn't update the helm repo. Also the app didn't create an namespace if the --namespace flag is used. If someone can verify it, I will raise an issue.

I created a new k3s cluster with k3d and installed openfaas and nats-connector, it worked fine.
k3d create
INFO[0000] Created cluster network with ID ce2c5b1f6f5d39e37667a9308dafae25563b3f34b0fd5bbcd2090d2b067b273a
INFO[0000] Created docker volume  k3d-k3s-default-images
INFO[0000] Creating cluster [k3s-default]
INFO[0000] Creating server using docker.io/rancher/k3s:v1.17.2-k3s1...
INFO[0000] SUCCESS: created cluster [k3s-default]
INFO[0000] You can now use the cluster with:

export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
kubectl cluster-info
➜  arkade git:(nats-connector) export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
WARN[0000] Couldn't get the kubeconfig from cluster 'k3s-default': Maybe it's not ready yet and you can try again later.
FATA[0000]  Couldn't copy kubeconfig.yaml from server container 513b60fdad438e0c93d0c51957923ac25aac051f6261d18891d9c4eae65d7d51
Error: No such container:path: 513b60fdad438e0c93d0c51957923ac25aac051f6261d18891d9c4eae65d7d51:/output/kubeconfig.yaml
➜  arkade git:(nats-connector) export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
➜  arkade git:(nats-connector) kubectl cluster-info
Kubernetes master is running at https://localhost:6443
CoreDNS is running at https://localhost:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://localhost:6443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
➜  arkade git:(nats-connector) arkade install openfaas --set basic_auth=true \  --set functionNamespace=openfaas-fn
Using kubeconfig: /Users/viveks/.config/k3d/k3s-default/kubeconfig.yaml
Using helm3
Node architecture: "amd64"
Client: "x86_64", "Darwin"
2020/06/17 23:03:35 User dir established as: /Users/viveks/.arkade/
"openfaas" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "inlets" chart repository
...Successfully got an update from the "nats-connector" chart repository
...Successfully got an update from the "openfaas" chart repository
...Successfully got an update from the "mqtt-connector" chart repository
...Successfully got an update from the "openfaas/nats-connector" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
VALUES values.yaml
Command: /Users/viveks/.arkade/bin/helm3/helm [upgrade --install openfaas openfaas/openfaas --namespace openfaas --values /var/folders/tw/6ww2mtms12ndnypdycqfy_q40000gy/T/charts/openfaas/values.yaml --set faasnetes.imagePullPolicy=Always --set basicAuthPlugin.replicas=1 --set serviceType=NodePort --set functionNamespace=openfaas-fn --set gateway.directFunctions=true --set operator.create=false --set openfaasImagePullPolicy=IfNotPresent --set gateway.replicas=1 --set queueWorker.replicas=1 --set basic_auth=true --set clusterRole=false]
Release "openfaas" does not exist. Installing it now.
 Installing it now.
NAME: nats-connector
LAST DEPLOYED: Wed Jun 17 23:05:58 2020
NAMESPACE: openfaas
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thanks for installing nats-connector. Please follow the instructions below to get you started.

You can watch the Connector logs to see it invoke your functions:

$ kubectl logs -n openfaas deploy/nats-connector -f
=======================================================================
= nats-connector has been installed.                                   =
=======================================================================

# View the connector logs:

kubectl logs deploy/nats-connector -n openfaas -f

# Find out more on the project homepage:
https://github.com/openfaas/faas-netes/tree/master/chart/nats-connector

Thanks for using arkade!
➜  arkade git:(nats-connector) kubectl logs -n openfaas deploy/nats-connector -f
==============================================================================
NATS Connector for OpenFaaS

Gateway URL: http://gateway.openfaas:8080
NATS URL: nats://nats:4222
Topics: 30s
Upstream timeout: [nats-test]
Topic-map rebuild interval: 5s
Async invocation: "false"
==============================================================================

2020/06/17 17:36:07 Configured topics: [nats-test]
2020/06/17 17:36:07 Binding to topic: "nats-test"
2020/06/17 17:36:07 Subscription: nats-test ready

Try using a another namespace with —namespace=Test123

I think it only works because you installed OpenFaaS at first and openfaas creates the openfaas namepspace. If you deploy nats-connector without using an already existing namespace it will run into an issue:
`
~/repo/arkade   43  k3d create                                                                                (43|…)
INFO[0000] Created cluster network with ID e35dccb43adff147726cde94c18c7868eaa58f4c9efbe3a2f9300481c043459d
INFO[0000] Created docker volume  k3d-k3s-default-images
INFO[0000] Creating cluster [k3s-default]
INFO[0000] Creating server using docker.io/rancher/k3s:latest...
INFO[0000] SUCCESS: created cluster [k3s-default]
INFO[0000] You can now use the cluster with:
export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
kubectl cluster-info
~/repo/arkade   43  export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"                                                                                (43|…)
~/repo/arkade   43  ./arkade install nats-connector --namespace test123                                                                                (43|…)
2020/06/17 21:05:45 Client: x86_64, Darwin
2020/06/17 21:05:45 User dir established as: /Users/markushartmann/.arkade/
"openfaas/nats-connector" has been added to your repositories
VALUES values.yaml
Command: /Users/markushartmann/.arkade/bin/helm3/helm [upgrade --install nats-connector openfaas/nats-connector --namespace test123 --values /var/folders/nj/q4hj6sr17gzf6fxwrg74h_v80000gn/T/charts/nats-connector/values.yaml]
Release "nats-connector" does not exist. Installing it now.
Error: create: failed to create: namespaces "test123" not found
Error: exit code 1, stderr: Error: create: failed to create: namespaces "test123" not found
`


Hugepage backed memory support

Author Name: 海涛 肖 (海涛 肖)
Original Redmine Issue: 3042, https://dev.opennebula.org/issues/3042
Original Date: 2014-07-15

The memory page size of your system influences the overhead of virtual to physical memory translations, increasing your memory page size would reduce this overhead. HugePages is a feature that makes it possible for the operating system support memory pages larger than the default 4KB, assuming HW support. Hugepage support can deliver a significant improvement in memory access throughput, especially in memory intensive and database workloads.
This feature enables libvirt configure virtual machines to use hugepage backed memory.
This feature can be used Intel DPDK vSwitch and NFV workloads.

Original Redmine Comment
Author Name: Ruben S. Montero (@rsmontero)
Original Date: 2014-07-15T09:52:45Z

moving to backlog for the next release. This issue will expose the memory attributes to the guest as described here:
http://libvirt.org/formatdomain.html#elementsMemoryBacking

#3256 (Implemented as part of it)


Losses, winrate and games returning 0

In the API-call https://owapi.net/api/v2/u/:battletag/stats/general the values for losses, winrate and games return 0. I am not aware if this is a known issue.
Does v3 solve this issue?

See #70.
Blizzard dun goofed and won't give me stats for quick play.


Background color extends outside circle

If you set the background color of the CircleImageView, it will fill the entire rect of the view, extending outside the circular border.

This is the expected behaviour. For a circular shaped background you should use a ShapeDrawable.


Multiple referencies to nested owned entities generates broken migration

Intro
We have a nested owned entities which we wanted to re-use in our model, but after doing so it lead to the point where it was generating "broken" migration which was trying to drop key property of owned entity and so on. (key of owned entity is not actually stored). I have extracted this into small sample and create a repository: efcore_broken_migration
Steps to reproduce

Clone the repository
Delete migrations folder
Create a migration. It creates what seems to be a normal migration (I use command: dotnet ef migrations add Migration_1)
Create a second migration without any changes to a code. It creates migration with statements like this:

migrationBuilder.DropColumn(
    name: "AddressVOClientDetailsVOBusinessClientId",
    table: "Orders");

Here: AddressVO is an owned entity for entity Order.
Issues:

It should generate empty migration since there are no code changes
Generated migration makes no sense (a.k.a. broken migration)
All subsequent migrations generate that broken code.

More insights
Now if I try to fiddle around with the model it starts throwing some exceptions.

Unable to determine the relationship represented by navigation property

Steps to reproduce

Delete migrations folder
Open DatabaseContext.cs
Change:

        protected override void OnModelCreating(ModelBuilder builder)
        {
            builder.ApplyConfiguration(new RegularClientConfiguration());
            builder.ApplyConfiguration(new BusinessClientConfiguration());

            builder.ApplyConfiguration(new OrderConfiguration());
        }

To:
        protected override void OnModelCreating(ModelBuilder builder)
        {
            builder.ApplyConfiguration(new OrderConfiguration());

            builder.ApplyConfiguration(new RegularClientConfiguration());
            builder.ApplyConfiguration(new BusinessClientConfiguration());
        }

(Changing only the order of configurations)

Try to create migration

It throws following error (Without creating migration! which in my opinion is a way better than taking modelSnapshot in a broken state):
Exception message: Unable to determine the relationship represented by navigation property 'Order.DeliveryAddress#AddressVO.PrimaryAddress' of type 'AddressDTO'. Either manually configure the relationship, or ignore this property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.
Stack trace: at Microsoft.EntityFrameworkCore.Metadata.Conventions.Internal.PropertyMappingValidationConvention.Apply(InternalModelBuilder modelBuilder)
   at Microsoft.EntityFrameworkCore.Metadata.Conventions.Internal.ConventionDispatcher.ImmediateConventionScope.OnModelBuilt(InternalModelBuilder modelBuilder)
   at Microsoft.EntityFrameworkCore.Metadata.Conventions.Internal.ConventionDispatcher.OnModelBuilt(InternalModelBuilder modelBuilder)
   at Microsoft.EntityFrameworkCore.Metadata.Internal.Model.Validate()
   at Microsoft.EntityFrameworkCore.ModelBuilder.FinalizeModel()
   at Microsoft.EntityFrameworkCore.Infrastructure.ModelSource.CreateModel(DbContext context, IConventionSetBuilder conventionSetBuilder, IModelValidator validator)
   at Microsoft.EntityFrameworkCore.Infrastructure.ModelSource.<>c__DisplayClass5_0.<GetModel>b__1()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at Microsoft.EntityFrameworkCore.Infrastructure.ModelSource.GetModel(DbContext context, IConventionSetBuilder conventionSetBuilder, IModelValidator validator)
   at Microsoft.EntityFrameworkCore.Internal.DbContextServices.CreateModel()
   at Microsoft.EntityFrameworkCore.Internal.DbContextServices.get_Model()
   at Microsoft.EntityFrameworkCore.Infrastructure.EntityFrameworkServicesBuilder.<>c.<TryAddCoreServices>b__7_2(IServiceProvider p)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitFactory(FactoryCallSite factoryCallSite, ServiceProviderEngineScope scope)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(IServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScoped(ScopedCallSite scopedCallSite, ServiceProviderEngineScope scope)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(IServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, ServiceProviderEngineScope scope)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(IServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScoped(ScopedCallSite scopedCallSite, ServiceProviderEngineScope scope)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(IServiceCallSite callSite, TArgument argument)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine.<>c__DisplayClass1_0.<RealizeService>b__0(ServiceProviderEngineScope scope)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngine.GetService(Type serviceType, ServiceProviderEngineScope serviceProviderEngineScope)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Microsoft.EntityFrameworkCore.DbContext.get_DbContextDependencies()
   at Microsoft.EntityFrameworkCore.DbContext.get_InternalServiceProvider()
   at Microsoft.EntityFrameworkCore.DbContext.Microsoft.EntityFrameworkCore.Infrastructure.IInfrastructure<System.IServiceProvider>.get_Instance()
   at Microsoft.EntityFrameworkCore.Internal.InternalAccessorExtensions.GetService[TService](IInfrastructure`1 accessor)
   at Microsoft.EntityFrameworkCore.Infrastructure.AccessorExtensions.GetService[TService](IInfrastructure`1 accessor)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(Func`1 factory)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(String contextType)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.AddMigration(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigration.<>c__DisplayClass0_1.<.ctor>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)

The entity type <Type> cannot be added to the model because a weak entity type with the same name already exists

Steps to reproduce

Undo the changes to DatabaseContext.cs
Delete migrations folder if any.
Open Order.cs
Rename class name Order to ReguralOrder
Create a migration. Again it creates what seems to be normal migration.
Create second migration. It throws the following:

Exception message:The entity type 'ef_bug.AddressVO' cannot be added to the model because a weak entity type with the same name already exists.
Stack trace: at Microsoft.EntityFrameworkCore.Metadata.Internal.Model.AddEntityType(EntityType entityType)
   at Microsoft.EntityFrameworkCore.Metadata.Internal.Model.AddEntityType(String name, ConfigurationSource configurationSource)
   at Microsoft.EntityFrameworkCore.Metadata.Internal.InternalModelBuilder.Entity(TypeIdentity& type, ConfigurationSource configurationSource, Boolean allowOwned, Boolean throwOnQuery)
   at Microsoft.EntityFrameworkCore.Metadata.Internal.InternalModelBuilder.Entity(String name, ConfigurationSource configurationSource, Boolean allowOwned, Boolean throwOnQuery)
   at Microsoft.EntityFrameworkCore.Metadata.Builders.ReferenceOwnershipBuilder.FindRelatedEntityType(String relatedTypeName, String navigationName)
   at Microsoft.EntityFrameworkCore.Metadata.Builders.ReferenceOwnershipBuilder.HasOne(String relatedTypeName, String navigationName)
   at ef_bug.Migrations.DatabaseContextModelSnapshot.<>c.<BuildModel>b__0_13(ReferenceOwnershipBuilder b3) in C:\Users\Ramunas Adamonis\Stuff\Sources\ef_bug\Migrations\DatabaseContextModelSnapshot.cs:line 179
   at Microsoft.EntityFrameworkCore.Metadata.Builders.ReferenceOwnershipBuilder.OwnsOne(String ownedTypeName, String navigationName, Action`1 buildAction)
   at ef_bug.Migrations.DatabaseContextModelSnapshot.<>c.<BuildModel>b__0_12(ReferenceOwnershipBuilder b2) in C:\Users\Ramunas Adamonis\Stuff\Sources\ef_bug\Migrations\DatabaseContextModelSnapshot.cs:line 169
   at Microsoft.EntityFrameworkCore.Metadata.Builders.ReferenceOwnershipBuilder.OwnsOne(String ownedTypeName, String navigationName, Action`1 buildAction)
   at ef_bug.Migrations.DatabaseContextModelSnapshot.<>c.<BuildModel>b__0_11(ReferenceOwnershipBuilder b1) in C:\Users\Ramunas Adamonis\Stuff\Sources\ef_bug\Migrations\DatabaseContextModelSnapshot.cs:line 156
   at Microsoft.EntityFrameworkCore.Metadata.Builders.EntityTypeBuilder.OwnsOne(String ownedTypeName, String navigationName, Action`1 buildAction)
   at ef_bug.Migrations.DatabaseContextModelSnapshot.<>c.<BuildModel>b__0_5(EntityTypeBuilder b) in C:\Users\Ramunas Adamonis\Stuff\Sources\ef_bug\Migrations\DatabaseContextModelSnapshot.cs:line 143
   at Microsoft.EntityFrameworkCore.ModelBuilder.Entity(String name, Action`1 buildAction)
   at ef_bug.Migrations.DatabaseContextModelSnapshot.BuildModel(ModelBuilder modelBuilder) in C:\Users\Ramunas Adamonis\Stuff\Sources\ef_bug\Migrations\DatabaseContextModelSnapshot.cs:line 137
   at Microsoft.EntityFrameworkCore.Infrastructure.ModelSnapshot.<.ctor>b__1_0()
   at Microsoft.EntityFrameworkCore.Internal.LazyRef`1.get_Value()
   at Microsoft.EntityFrameworkCore.Infrastructure.ModelSnapshot.get_Model()
   at Microsoft.EntityFrameworkCore.Migrations.Design.MigrationsScaffolder.ScaffoldMigration(String migrationName, String rootNamespace, String subNamespace, String language)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.AddMigration(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigration.<>c__DisplayClass0_1.<.ctor>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)

It is very weird that ordering of confuguration or even naming of a class changes the behavior of the error, but I hope it helps a bit.
My humble apologies if I didn't narrowed the issue to a specific point, but I hope my repo will help to gain some insights for the issue. Let me know if you need anything from my side or having trouble to replicate the issues.
Further technical details
EF Core version: 2.2.6-servicing-10079
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10
IDE: Visual Studio Code 1.36.1

This is a duplicate of #9148 since the entity types are being configured as both non-owned and owned.

@ajcvickers it is not really the case here, there is no entity that is configured both non-owned and owned. I have also tried to update repository to EF Core 3.0 (3.0.0-preview7.19362.6) and it still produces same broken migration.

@RamunasAdamonis When running the code, I thought that there were both IEntityTypeConfiguration<TEntity> and OwnsOne<T> for the same TEntity. If that's not the case then I will investigate some more.

@RamunasAdamonis I was able to reproduce this on the current nightlies.
@AndriySvyryd Could be a dupe?


Feat : Implementing Auth functionality. GSSOC'24

Description
When I click logout, it shows that authentication is not present. I will resolve this issue and also add a Google Sign-In feature.
Changes
Implement the Google Sign-In feature and fix the logout issue.
Screenshots

Checklist
Before submitting your pull request, ensure that you have completed the following tasks:

[x ] Gone through the rules and guidelines of the project.
[x ] When you are creating PR, your PR should title follows the specified format: [Feature/Enhancement/Bug Fix]: Brief description of the change.
[ x] Attached OSSI or GSSoC in the heading of the Issue.
[ x] I have checked this issue is not already covered in another issue.

Expected Time to Complete
I estimate that it will take approximately 1 day to complete the changes proposed in this issue.
Additional Notes
This implementation includes:
Integration with Google Sign-In API.
Proper handling of authentication state during logout.
Ensuring the user experience is seamless and secure.
GSSOC'24

We will be using firebase for authentication. But before that, we need to get the UI of the auth page. Please attach an UI of auth page.

if this is ok i can work on this. else you can suggest any ui i can replicate it.

Use black button with white text instead of green. Otherwise it looks good to me. Use the existing UI lib that we are using.

I need to know the logic. I have planned to make like - First user need to signin or signup to get access to home page or any other page. I think this is good too. What do you think?

Yes that's it. We also need to redirect to the auth pages if the user is not logged in.

But I want the UI for now as a pull request.

Not expecting a big change in a single PR.

Please check into  #151


posts: Fix weirdness with Posts page

Since we do not use Titles anywhere, just remove it from the CSS for now. This fixes the issue with the word Posts sitting on top of the OPI image on the Posts page.
Signed-off-by: Kyle Mestery<EMAIL_ADDRESS>

Before the fix:

After the fix:


Drupal Formatting

Hi there,
I have been looking into the module and as it is at the moment it probably isn't in quite the correct state to be accepted onto drupal.org
Basically, I am wondering how I would split apart some bits so that it could be accepted potentially in the future. How much support do you have for the php library? I know at the moment, the simplesamlphp library is the most popular way of using saml with Drupal. Which uses this module https://drupal.org/project/simplesamlphp_auth
I will start a fork and make a pull request for some parts and report back more later.

Hi @willhallonline,
I'm the maintainer of the php-saml toolkit, so is well supported ;)  Is a nice alternative of simpleSAMLphp, that sometimes is quite complex to handle.
Thanks for taking the time to adapt this module, my expertise is on PHP and SAML but this was my first Drupal module and can't spend time to learn it since my goal is to provide SAML support to any open source software rather than making perfect modules, that why help is always welcome to adapt my work to follow each software guidelines.
Let me know i f you have any doubt.

@willhallonline, in what status is the Drupal adaptation?

ping!

Hey. At the moment, for me it is just looking like too much work to do. How much of the module replicates what is in the php-saml toolkit, just extends it, or is it a complete saml solution inside the module?
I do know of a few people who have worked with simplesamlphp and I don't particularly like having to drag it around as a library.


an issue with stream definition

there is a problem with stream quilty when using headless mode
it writes that quilty changed to 160p but i doesn't i test it more than a time and still consume alot of data after waiting for a while
hope that fixed in next update

after more test sometimes it stays bugged on 1080p for long time and sometimes it works at 160p idk to be honest what may cause this
hope u check it ^^

it consumes data like it's 1080p i tested it with netlimiter

it consumes data like it's 1080p i tested it with netlimiter

You can check the browser interface and see if the definition changes automatically.