Can't Figure Out Proper Implementation For gluesql::store::Store::scan_data

Full disclosure, I'm newer to Rust that I'd probably like to admit.

I used converting a parser for DataFlex fixed-width flat-file "databases" I wrote in Python to Rust as a means of actually learning Rust. I've got everything working correctly in Rust to read (and eventually write) the "database" files.
I'm trying to implement gluesql's Store trait so that I can run queries against the parsed "databases". I'm not getting something, and I'm having a hard time wrapping my head around what. I know that's vague, so I'll try to illustrate with code instead.
As it sits now, I have a struct called DataFlexDB that is analogous to the directory that contains all of the database files as well as a struct called DataFlexTable that represents the actual table. They look like this:
struct DataFlexTable {
    pub header: Header,
    pub file_path: PathBuf,
}

struct DataFlexDB {
    pub db_path: PathBuf,
    pub tables: Vec<DataFlexTable>,
}

Each of the structures provides their own methods for pulling whatever relevant thing you need (the DB can find tables, Tables can find rows, etc...). The DataFlexTable struct also has gluesql-oriented stuff like:
impl DataFlexTable {

    // ...

    fn schema(&self) -> Option<gluesql::Schema> {
        Some(gluesql::Schema {
            table_name: self.header.file_root_name.to_string(),
            column_defs: self
                .header
                .columns
                .iter()
                .map(|col| col.definition())
                .collect::<Vec<ColumnDef>>(),
        })
    }

    // ...

}

impl<'a> Iterator for DFTableIter<'a> {
    type Item = gluesql::Row;

    fn next(&mut self) -> Option<Self::Item> {
        // ...
    }
}

All of which works as advertised. What's got me tripped up is the type checker not being happy with anything I come up with to return from scan_data. Clearly I'm misinterpreting how / what RowIter is supposed to be.
What I've got so far is basically just:
async fn scan_data(&self, table_name: &str) -> Result<RowIter<T>, SqlError> {
    let table = self
        .tables
        .iter()
        .find(|entry| cl_eq(table_name, &entry.header.file_root_name));

    // What now?
    unimplemented!()
}

If you were to step through what I've got, you'd have an Option<&DataFlexTable> right before the unimplemented!() causes a panic. Assuming that unwraps into a table, you'd then be able to call table.iter() and have an iterator of proper gluesql::Row objects. And I'm absolutely not sure what to do from there.
Hopefully I've illustrated enough with the code above to make up for the vagueness of my explanation. Is there any way someone could point me in the right direction?

For a really simple example of a storage, have a look at MultiSQL's CSV store (note that there is minor differences in implementation between Glue and Multi):
https://github.com/SyRis-Consulting/multisql/tree/main/src%2Fstorages%2Fcsv_storage

If Store trait is only which you need for now, then you might not need key struct, then you can use RowIter<T> using T as ().
Details you provided looks not sufficient for me to understand the point.
However, it seems like that you are currently stuck at code compile.
pub type RowIter<T> = Box<dyn Iterator<Item = Result<(T, Row)>>>;

/// By implementing `Store` trait, you can run `SELECT` query.
#[async_trait(?Send)]
pub trait Store<T: Debug> {
    async fn fetch_schema(&self, table_name: &str) -> Result<Option<Schema>>;

    async fn scan_data(&self, table_name: &str) -> Result<RowIter<T>>;
}

Whatever the internal implementation is used, once you make the return type to trait methods, then code will run.
You don't need to implement StoreMut for now, so it can be more simple.
You even might not need to have key, so..
impl Store<()> for DataFlexStorage {
    async fn fetch_schema(&self, table_name: &str) -> Result<Option<Schema>> {
        ..
    }

    async fn scan_data(&self, table_name: &str) -> Result<RowIter<()>> {
        ..
    }
}

For scan_data, if you read file using Rust code, then file reader may provide Iterator.
You can begin with that Iterator and using map like methods to change the form to fit Item = Result<((), Row)>.

@panarch  Following your advice, I've refactored the Iterator implementation on the table reader thusly:
impl<'a> Iterator for DFTableIter<'a> {
    type Item = gluesql::Result<(gluesql::Value, gluesql::Row)>;

    fn next(&mut self) -> Option<Self::Item> {
        if self.position > self.table.header.record_count || self.table._record_data.is_empty() {
            return None;
        }

        let ret_val = match self
            .table
            .record_from_bytes(&self.table._record_data[self.position as usize])
        {
            Ok(val) => Some(gluesql::Result::Ok((gluesql::Value::I64(self.position as i64), val))),
            Err(_) => None,
        };

        self.position += 1;

        ret_val
    }
}

Assuming I'm not completely daft, the signature should now correctly match Iterator<Item = gluesql::Result<(T, gluesql::Row)>> wherein T = Value. If I understood your advice correctly (which the compiler appears to be insisting I haven't), the implementation of Store should be something like:
#[async_trait(?Send)]
impl gluesql::Store<gluesql::RowIter<Value>> for DataFlexDB {
    async fn fetch_schema(&self, table_name: &str) -> gluesql::Result<Option<gluesql::Schema>> {
        // ....
    }

    async fn scan_data(&self, table_name: &str) -> gluesql::Result<gluesql::RowIter<Value>> {
        let db_file = self.tables.iter().find(|entry| cl_eq(table_name, &entry.header.file_root_name));

        if let Some(table) = db_file {
            return gluesql::Result::Ok(Box::new(table.iter()));
        }

        panic!()
    }
}

The compiler, however, is yelling at me about:
error[E0277]: `(dyn Iterator<Item = Result<(gluesql::Value, gluesql::Row), gluesql::Error>> + 'static)` doesn't implement `Debug`
    --> src/lib.rs:1173:6
     |
1173 | impl Store<RowIter<Value>> for DataFlexDB {
     |      ^^^^^^^^^^^^^^^^^^^^^ `(dyn Iterator<Item = Result<(gluesql::Value, gluesql::Row), gluesql::Error>> + 'static)` cannot be formatted using `{:?}` because it doesn't implement `Debug`
     |
    ::: ./.cargo/registry/src/github.com-1ecc6299db9ec823/gluesql-0.6.0/src/store/mod.rs:21:20
     |
21   | pub trait Store<T: Debug> {
     |                    ----- required by this bound in `Store`
     |
     = help: the trait `Debug` is not implemented for `(dyn Iterator<Item = Result<(gluesql::Value, gluesql::Row), gluesql::Error>> + 'static)`
     = note: required because of the requirements on the impl of `Debug` for `Box<(dyn Iterator<Item = Result<(gluesql::Value, gluesql::Row), gluesql::Error>> + 'static)>`

So I'm pretty sure I've still got something wrong, and I'm 110% positive it's something trivial and silly and I'm gonna feel real dumb when you point it out but I'm hoping you'll be gracious enough to do so anyway. 😩

Rather than implementing impl<'a> Iterator for DFTableIter<'a> {...
It looks like _record_data in &self.table._record_data[self.position as usize] is shape of Vec.
Then, you will be able to simply use _record_data.into_iter().map(...) like approach.
Also in the beginning, it would be enough to set T = () you don't need to use gluesql::Value for T.
impl Store<RowIter<Value>> for DataFlexDB {

This should not use RowIter<Value>, if you choose to use T = Value then it must be also Value.
However, as I mentioned, () would be enough.
btw, error message is simple.
generic T requires Debug but RowIter<Value> does not implement Debug so it cannot be used as a T.

Rather than implementing impl<'a> Iterator for DFTableIter<'a> {...
It looks like _record_data in &self.table._record_data[self.position as usize] is shape of Vec.
Then, you will be able to simply use _record_data.into_iter().map(...) like approach.

_record_data is a vec, but it's not parsed or usable as is (it's a Vec<u8>). It's basically just an internal cache of the unparsed record data, it's sort of a side-effect of the way the tables are structured and therefore loaded that I'm taking advantage of to reduce... well effort duplication really. The records are actually parsed out into usable gluesql::Row objects by record_from_bytes() which is what the Iterator implementation uses as well.
I apologise so hard that this just isn't clicking for me yet, but could I ask you to give me the "correct" versions of these two lines for your suggestion of T = () ?
impl gluesql::Store<gluesql::RowIter<Value>> for DataFlexDB {   // <---- this line
    // ....

    async fn scan_data(&self, table_name: &str) -> gluesql::Result<gluesql::RowIter<Value>> {   // <---- and this line
        // ....
    }
}

No problem, T is used for key representation and that T is used when you update data using queries like.. INSERT, DELETE or UPDATE which requires StoreMut.
However, you don't need StoreMut for now and it means that T is not necessary.
impl gluesql::Store<()> for DataFlexDB {   // <---- this line
    // ....

    async fn scan_data(&self, table_name: &str) -> gluesql::Result<gluesql::RowIter<()>> {   // <---- and this line
        // ....
    }
}

() just literally means (), no value.
You can simply replace all Ts to ().


QRcode not readable (IDFGH-8652)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v4.4.2
Operating System used.
Linux
How did you build your project?
Eclipse IDE
If you are using Windows, please specify command line type.
No response
Development Kit.
Atom M5
Power Supply used.
USB
What is the expected behavior?
QR-Code: readable.
What is the actual behavior?
QR-Code: not readable.
however: only the QR on the Console not readable.
the QR-Code
link
readable fine.
Steps to reproduce.

Step build example https://github.com/espressif/esp-idf/tree/master/examples/provisioning
Step Read the QR-Code: not readable.

Debug Logs.
Executing action: monitor
Running idf_monitor in directory /home/franz/git/hr/LOGIBUS_integration_Hutschienenmoped/Application
Executing "/home/franz/.espressif/python_env/idf4.4_py3.8_env/bin/python /home/franz/esp-idf-v4.4.2/tools/idf_monitor.py -p /dev/ttyACM0 -b 115200 --toolchain-prefix xtensa-esp32-elf- --target esp32 --revision 3 --print_filter  /home/franz/git/hr/LOGIBUS_integration_Hutschienenmoped/Application/build/Application.elf -m '/home/franz/.espressif/python_env/idf4.4_py3.8_env/bin/python' '/home/franz/esp-idf-v4.4.2/tools/idf.py'"...
--- idf_monitor on /dev/ttyACM0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, 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:0x3fff0030,len:7168
load:0x40078000,len:15580
load:0x40080400,len:4572
0x40080400: _init at ??:?

entry 0x400806c4
I (60) HOOK: This hook is called BEFORE bootloader initialization
I (35) boot: ESP-IDF v4.4.2-dirty 2nd stage bootloader
I (35) boot: compile time 20:50:46
I (35) boot: chip revision: 3
I (38) qio_mode: Enabling default flash chip QIO
I (43) boot.esp32: SPI Speed      : 80MHz
I (48) boot.esp32: SPI Mode       : QIO
I (53) boot.esp32: SPI Flash Size : 8MB
I (57) boot: Enabling RNG early entropy source...
I (62) HOOK: This hook is called AFTER bootloader initialization
I (69) boot: Partition Table:
I (73) boot: ## Label            Usage          Type ST Offset   Length
I (80) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (88) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (95) boot:  2 factory          factory app      00 00 00010000 0036b000
I (103) boot:  3 storage          Unknown data     01 82 0037b000 000f0000
I (110) boot: End of partition table
I (114) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=4e420h (320544) map
I (211) esp_image: segment 1: paddr=0005e448 vaddr=3ffbdb60 size=01bd0h (  7120) load
I (214) esp_image: segment 2: paddr=00060020 vaddr=400d0020 size=184b8ch (1592204) map
I (656) esp_image: segment 3: paddr=001e4bb4 vaddr=3ffbf730 size=03fc8h ( 16328) load
I (661) esp_image: segment 4: paddr=001e8b84 vaddr=40080000 size=1e9c0h (125376) load
I (702) esp_image: segment 5: paddr=0020754c vaddr=50000000 size=00010h (    16) load
I (718) boot: Loaded app from partition at offset 0x10000
I (718) boot: Disabling RNG early entropy source...
I (729) psram: This chip is ESP32-PICO-V3-02
I (729) spiram: Found 16MBit SPI RAM device
I (730) spiram: SPI RAM mode: flash 80m sram 80m
I (735) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (742) cpu_start: Pro cpu up.
I (746) cpu_start: Starting app cpu, entry point is 0x40081918
0x40081918: call_start_cpu1 at /home/franz/esp-idf-v4.4.2/components/esp_system/port/cpu_start.c:160

I (0) cpu_start: App cpu up.
I (1008) spiram: SPI SRAM memory test OK
I (1018) cpu_start: Pro cpu start user code
I (1018) cpu_start: cpu freq: 240000000
I (1018) cpu_start: Application information:
I (1021) cpu_start: Project name:     Application
I (1027) cpu_start: App version:      513c8fb-dirty
I (1032) cpu_start: Compile time:     Nov  2 2022 20:50:44
I (1038) cpu_start: ELF file SHA256:  42a015f3884a852a...
I (1044) cpu_start: ESP-IDF:          v4.4.2-dirty
I (1050) heap_init: Initializing. RAM available for dynamic allocation:
I (1057) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (1063) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (1070) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (1076) heap_init: At 3FFC9930 len 000166D0 (89 KiB): DRAM
I (1082) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1088) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1095) heap_init: At 4009E9C0 len 00001640 (5 KiB): IRAM
I (1101) spiram: Adding pool of 1998K of external SPI memory to heap allocator
I (1110) spi_flash: detected chip: generic
I (1114) spi_flash: flash io: qio
I (1127) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (1130) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
isobus_sample!
This is esp32 chip with 2 CPU core(s), WiFi/BT/BLE, silicon revision 3, 8MB embedded flash
Minimum free heap size: 2220691 bytes
CONFIG_FREERTOS_HZ: 1000 must be 1000 !!!! (200Hz at least for 5ms )
app_main starting
app_main
I (1183) wifi:wifi driver task: 3ffd81e8, prio:23, stack:6656, core=0
I (00:00:00.163) system_api: Base MAC address is not set
I (00:00:00.164) system_api: read default base MAC address from EFUSE
I (1193) wifi:wifi firmware version: eeaa27d
I (1195) wifi:wifi certification version: v7.0
I (1199) wifi:config NVS flash: enabled
I (1203) wifi:config nano formating: disabled
I (1207) wifi:Init data frame dynamic rx buffer num: 32
I (1212) wifi:Init management frame dynamic rx buffer num: 32
I (1217) wifi:Init management short buffer num: 32
I (1222) wifi:Init static tx buffer num: 16
I (1226) wifi:Init tx cache buffer num: 32
I (1230) wifi:Init static rx buffer size: 1600
I (1234) wifi:Init static rx buffer num: 10
I (1237) wifi:Init dynamic rx buffer num: 32
I (00:00:00.222) wifi_init: rx ba win: 6
I (00:00:00.226) wifi_init: tcpip mbox: 32
I (00:00:00.231) wifi_init: udp mbox: 6
I (00:00:00.236) wifi_init: tcp mbox: 6
I (00:00:00.240) wifi_init: tcp tx win: 5744
I (00:00:00.245) wifi_init: tcp rx win: 5744
I (00:00:00.250) wifi_init: tcp mss: 1440
I (00:00:00.255) wifi_init: WiFi/LWIP prefer SPIRAM
I (00:00:00.260) wifi_init: LWIP IRAM OP enabled
I (00:00:00.266) wifi_prov_scheme_ble: BT memory released
I (00:00:00.272) app: Starting provisioning
I (00:00:00.277) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
I (1390) wifi:mode : sta (ac:0b:fb:6c:b5:c4)
I (1391) wifi:enable tsf
I (00:00:00.373) BTDM_INIT: BT controller compile version [bf9c077]
I (00:00:00.541) protocomm_nimble: BLE Host Task Started
I (00:00:00.544) wifi_prov_mgr: Provisioning started with service name : PROV_6CB5C4
I (00:00:00.544) app: Provisioning started
I (00:00:00.549) app: Scan this QR code from the provisioning application for Provisioning.
I (00:00:00.559) QRCODE: Encoding below text with ECC LVL 0 & QR Code Version 10
I (00:00:00.566) QRCODE: {"ver":"v1","name":"PROV_6CB5C4","pop":"abcd1234","transport":"ble"}
I (00:00:00.570) NimBLE: GAP procedure initiated: advertise;
I (00:00:00.582) NimBLE: disc_mode=2
I (00:00:00.586) NimBLE:  adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 adv_itvl_min=256 adv_itvl_max=256
I (00:00:00.597) NimBLE:

  █▀▀▀▀▀█ ▀▀    ▀ ▀▄█▀▀█ ▄▄ █▀▀▀▀▀█
  █ ███ █ █▄ █▀█ ██▄▄   ▀▀▄ █ ███ █
  █ ▀▀▀ █ ▀█▀▀▄ ▀▀▀▀▀█  ▀▀▀ █ ▀▀▀ █
  ▀▀▀▀▀▀▀ ▀▄▀▄▀ █▄█▄█▄█ █ █ ▀▀▀▀▀▀▀
  ▀▀█▀▄▄▀▄▀▄   ▄▄▀█▀ █▄▄ ▄█▀▄ ▀▀█▄█
  ▄█▀▄▀▄▀ ▄  ▄▄█▀ ▄  ▄ ▀ ██▀ ▀▄▀▀▀▀
  ▄█▀▄██▀▄▀▀▄█ ▀▄████▄  ▄█▄▀ █▀▄ ▀
  ▄▀ ▄ ▀▀▀▄▀▄ █    ▀ █ ▄ ▄ ▄  ▄ █ ▄
   ▄▀█▀█▀▀ ▄█▀▄█ ▄▀ ▄ ▀▀▄▀█▄█▄█ █▀█
   █▀ ██▀ ▀▀▄▀█▀▄█▄▄ ▄▄   ▄  ▀▀▄ ▀
  █▀█▄▄▀▀ ▄▀▀▀█▄▀▀█▀▄▄▀▀▀▀ █▄▄  █▀▄
   ▄▄█▀▄▀▀█▀█▀▀▄  █   ▀ ██ ▄▄▄ █▀ █
  ▀ ▀   ▀▀█▀▄▄█▀██▄▀▀▄▄   █▀▀▀█▀ ▄▀
  █▀▀▀▀▀█  █ █ ▀█ ▀ █▀ █▀▄█ ▀ █ █
  █ ███ █ ▄ █  █▀▄▀   ▄▀▀▀▀█▀▀▀ ▀█▀
  █ ▀▀▀ █ █▄█▄▄▀▄▀▄█▀▄▀▀  ▀ █▀▄█▀▀▄
  ▀▀▀▀▀▀▀ ▀  ▀▀ ▀  ▀▀  ▀ ▀ ▀▀ ▀ ▀

I (00:00:00.781) app: If QR code is not visible, copy paste the below URL in a browser.
https://espressif.github.io/esp-jumpstart/qrcode.html?data={"ver":"v1","name":"PROV_6CB5C4","pop":"abcd1234","transport":"ble"}

More Information.
No response

Did you try another terminal? I had the same problem with the DPP example, the builtin terminal of eclipse gave this problem, termterm did not.

i did try:

Eclipse
The Terminal of https://github.com/esphome/esp-web-tools

both same Problem.
Am Do., 3. Nov. 2022 um 08:43 Uhr schrieb allard-potma <
@.***>:

Did you try another terminal? I had the same problem with the DPP example,
the builtin terminal of eclipse gave this problem, termterm did not.
—
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/10098#issuecomment-1301741042,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJAHMXLEMKQIDRL3FH77NNTWGNUJRANCNFSM6AAAAAARVPAHCU
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Diplom-Informatiker Franz Höpfinger e.K.
Reibersdorf 16a
84419 Schwindegg

This bug is known for a while. If you absolutely need the QR code you can try putty. Until now that has always rendered a readable QR code on my side. However the whole issue can be easily solved by opening the link generated below the QR code.
By opening that link you will find the same QR code properly displayed in your internet browser. If you need the QR code for a commercial product, you can just print out that QR code and put it into the packaging of the product so that the end user can provision their devices easily.

Am Do., 3. Nov. 2022 um 12:40 Uhr schrieb Peter B @.***

:

This bug is known for a while.

any chance to help espressif ?

If you absolutely need the QR code you can try putty. Until now that has
always rendered a readable QR code on my side. However the whole issue can
be easily solved by opening the link generated below the QR code.

true, and this works fine. as i stated.

By opening that link you will find the same QR code properly displayed in
your internet browser. If you need the QR code for a commercial product,
you can just print out that QR code and put it into the packaging of the
product so that the end user can provision their devices easily.

true, but in my case it should be used by a "online" installer.

—
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/10098#issuecomment-1301976340,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJAHMXP7B5W2VOVCYGMKA3DWGOQBRANCNFSM6AAAAAARVPAHCU
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Diplom-Informatiker Franz Höpfinger e.K.
Reibersdorf 16a
84419 Schwindegg


Input value and floating label

Hi,
I'm using floating label on a simple input. When I pass value to this component, the label subscribe the value. If I enter the input and press something, label works nice. I tried autoFocus but when I just exit, label subscribe again.

"native-base": "^2.0.12",
"react-native": "0.42.0",
"react": "15.4.2"

icon color also not working for Form item floating labels #629

cc @shivrajkumar

I've got the same problem

Same problem for me. I connected form-redux and every time I leave the input the floating label goes back as it assumes the text field is empty.

@luksfk are you using redux-form by any chance and run into this issue?

+1 . Any news on this ?

@fkrauthan  yes, i'm using redux.

@luksfk My issue was that I was doing something like this:
<Field name="lastName" component={() => this.renderMyInput()} type="text"/>

This recreated the input field every time I was pressing a key. After changing this to the recommended way of
<Field name="lastName" component={this.renderMyInput} type="text"/>

It was working fine. I think native base has a problem with there javascript code if the underlying input field gets recreated instead of just updated.

is in production?

when will this be available in production ?

By the end of this week.

Fixed with 2.1.5

Check the latest version 2.2

@sankhadeeproy007 When 2.1.5 will be release?
The latest release to me is 2.1.4

@oximer The latest of NativeBase is 2.2.1
Check the release tags

@shivrajkumar for me this issue is not resolved in 2.2.1, and is the same as https://github.com/GeekyAnts/NativeBase/issues/1073

Its working fine in iOS Simulator, but overlapping in iPhone.

working fine on iOS simulator but overlapping in iPhone

this is a huge problem imho. I didn't realised this until we "shipped" product with release configuration and animations are not working properly in the release mode,
shutters and overlapping due to its not properly rendering last frames.

i'm same problem! in native-base 2.3.9!

I have also the same problem. This happens only in the release mode. version 2.3.9

I'm also seeing this issue on 2.3.9 and 2.3.10

In release, the displayName of the Input is set to "Styled(t)" instead of the expected "Styled(Input)". This prevents the inputProps from being set in componentWillReceiveProps so the value isn't recognized as being set.
componentWillReceiveProps(nextProps) {
    const childrenArray = React.Children.toArray(nextProps.children);
    let inputProps = {};
    _.remove(childrenArray, item => {
      if (item.type.displayName === "Styled(Input)") {
        inputProps = item.props;
        this.inputProps = item.props;
        return item;
      }
    });

Example Snack:
https://snack.expo.io/SJqB3fu5M
A hackish fix is to set the displayName directly after importing withInput.displayName = 'Styled(Input)';  as here:
https://snack.expo.io/@spcotter/native-base-floating-label-issue-627-patch
The label displayName is also "Styled(t)".

nice find @spcotter !

@spcotter this worked for us! Thank you!

I've tried @spcotter's fix and it's not working for me<EMAIL_ADDRESS>

@timhuff were you able to output Input.displayName in release to see if it's correct? I couldn't get snack to install<EMAIL_ADDRESS>

@spcotter I'm pretty sure I verified that - I spent a decent amount of time trying to get it to work. I'll double check here when I get second. For now, I decided to just stop using floating labels and go with the default behavior until this feature's a bit less buggy. It's not as nice but it's better than giving my users the impression on the get-go (login) that the app is buggy.

I've got the same problem

I am having the same issue. how soon we can get an update on it? it only happen when input already filled in.

I have the same issue, when the input layout starts with data, the floating label just "get up" after the first focus/blur
Ps.: This not happens on Emulator, just real devices

are we going to have an update on this soon?

This problem still occurs in<EMAIL_ADDRESS>

I found a workaround. If possible, use controlled input (i.e. set the value)

Attempted to use the fix by @spcotter, but still having the same issue.  @jpolo - can you elaborate on what you mean by a controlled input?

It's from react doc : https://reactjs.org/docs/forms.html#controlled-components

the problem still persist on Android and IOS, when I read the value assigned to onChangedText I do not get all the input

It's just you have to use like this (with value):
<Input     value={this.state.name}     onChangeText={ (text) => this.setState({ name: text }) }  />
Because the input don't know the value so by default it's null.

ensure have  added value field geuss native base assumes you have to add it by default,,
like this  Email
<Input
value={this.state.email}
autoCapitalize="none"
onChangeText={text => this.setState({ email: text })}
/>
works like charm on both android and ios.

Anyone still having the issue :Please upgrade your "react-native" and "native-base" versions...and check...An example code for you below...should work perfectly fine both in Ios and Android... Label floats up perfectly-

import React, { Component } from "react";
import { StyleSheet, View, TextInput } from "react-native";
import {
  Container,
  Content,
  Form,
  Item,
  Input,
  Label,
  Text,
  Left,
  Right,
  Body,
  Card,
  CardItem,
  Button,
  Separator,
  Icon,
} from "native-base";

const styles = StyleSheet.create({
  label: {
    fontSize: 15,
    color: "#fff",
    lineHeight: 20,
  },
});
export default class Register extends Component {
  constructor(props) {
    super(props);
    this.state = {
      data: { name: "", email: "", password: "" },
    };
  }
  updateValue(text, field) {
    const { data } = this.state;
    data[field] = text;
    this.setState({
      data,
    });
  }

  submit() {
    //Action
  }

  render() {
    return (
      <View style={{ flex: 1 }}>
        <Container
          style={{
            margin: 10,
            marginTop: 40,
          }}
        >
          <Content>
            <Card
              style={{
                backgroundColor: "green",
                margin: 20,
              }}
            >
              <Left />

                <CardItem
                  header
                  bordered
                  style={{
                    margin: 10,
                  }}
                >
                  <Text>
                    <Icon active name="home" />
                    REGISTRATION FORM
                  </Text>
                </CardItem>

              <Right />
              <Form
                style={{
                  margin: 20,
                }}
              >
                <Item floatingLabel>
                  Username
                  <Input
                    style={styles.label}
                    onChangeText={text => this.updateValue(text, "name")}
                  />
                </Item>
                <Item floatingLabel>
                  Email
                  <Input
                    autoCapitalize={"none"}
                    style={styles.label}
                    onChangeText={text => this.updateValue(text, "email")}
                  />
                </Item>
                <Item floatingLabel>
                  Password
                  <Input
                    autoCapitalize={"none"}
                    style={styles.label}
                    onChangeText={text => this.updateValue(text, "password")}
                  />
                </Item>
              </Form>
            </Card>
            <Button full primary onPress={() => this.submit()}>
              <Text> REGISTER </Text>
            </Button>
          </Content>
        </Container>
      </View>
    );
  }
}

Closing the issue due to no response for a while...Hope your issue has been resolved.You can reopen the issue if you still feel the issue is exclusive to "native-base"...

Still happening in 2.12.1

Working


Update README.md

Added digital shield, contact tracing in realtime using bluetooth, privacy oriented

@jotatsu
Read the contribution guidelines please.


feat: choose path separator for copy command

resolves #1861
This PR adds support for choosing the path separator for the copy command between:

auto: uses / on Unix-like systems and \ on Windows
unix: forces forward slashes (/) in the path copied to the user's clipboard

Note
EDIT: The tests in CI passes! So it should be working now.
I havn't written mcuh cross-platform Rust code, and I'm unsure how to run tests targeted for Windows on my Linux machine 😅. Any advice or extra caution during review would be appreciated.

Thanks for the PR!
There's already a backslash_to_slash(), could you use it instead, that'll simplify a lot of the code I think:
https://github.com/sxyazi/yazi/blob/0baccdc9aaa26bbea458f0b7fcbe7916c8b2c1df/yazi-shared/src/fs/path.rs#L173-L192

Thanks for the PR!
There's already a backslash_to_slash(), could you use it instead, that'll simplify a lot of the code, and also can handle non-UTF-8 file paths correctly (no need for String and to_string_lossy()):
https://github.com/sxyazi/yazi/blob/0baccdc9aaa26bbea458f0b7fcbe7916c8b2c1df/yazi-shared/src/fs/path.rs#L173-L192

Thank you for pointing that out! I hadn’t noticed backslash_to_slash before. I’ll update the code to use it.


[Android] Could not build lib from source

How to reproduce:
git clone https://github.com/react-community/react-native-maps.git
cd react-native-maps
yarn install
yarn build:android

result:
FAILURE: Build failed with an exception.

* Where:
Build file 'C:\git\react-native-maps\lib\android\build.gradle' line: 46

* What went wrong:
A problem occurred evaluating project ':react-native-maps-lib'.
> Could not find method compileOnly() for arguments [com.facebook.react:react-native:+] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

This is related to this pull https://github.com/react-community/react-native-maps/pull/2096 since it updated gradle files that are used when this lib is included on rn apps, but not the gradle files to build the lib itself.

got to react-native-maps\lib\android\build.gradle'
and change compileOnly() with provided
and implementation as compile


Pressing enter in query-textbox will update the table content

I updated the "start"-view to be more user-friendly. Pressing enter in textbox will now update the table content.

This may conflict with #47. If one of them is merged i will take a look at the other one :)


python3Packages.langchain: init at 0.0.158

Description of changes
Building applications with LLMs through composability
https://github.com/hwchase17/langchain
relates #220360
cc @larsr @mausch @happysalada

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@happysalada san, would you please review it when you have time?

Nice thanks!


Added support to fabric smartbft protos.

Signed-off-by<EMAIL_ADDRESS>

Bug fix

Description
Add support to fabric smartbft protos parsing.
Related issues
Add support for "Orderers" and BFT "Options" parsing from binary to json. #57

@yacovm


Missing phone_code and email_code verification strategies

I was trying to list all users via clerk_rs::apis::users_api::User::get_user_list, and the response deserialisation failed with this error:
Serde(
    Error(
        "unknown variant `email_code`, expected `admin` or `from_oauth_google`",
        line: 1,
        column: 754,
    )
)

Based on the Backend API docs, they have two variants of verification:

OTP
Admin

phone_code, email_code
admin

I also can't find the from_oauth_google variant.

Thanks for opening @TmLev. I'll be resolving this soon in 0.2.0 when we realign with clerk's new api spec

This should now be fixed in 0.2.2 https://crates.io/crates/clerk-rs/0.2.2

As of version 0.2.3 unknown variants for strategy and identification_link.type deserialize to "Other" variant. That should fix issues with listing users.


Not able to create libtensorflow-lite.a from build_ios_universal_lib.sh

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): NO
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Mac 10.15.4
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: NO
TensorFlow installed from (source or binary):
TensorFlow version (use command below): 2.1.1
Python version: Python 2.7.16 and Python 3.7.3
Bazel version (if compiling from source): bazel 3.4.1-homebrew
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

Describe the current behavior
I was able to create libtensorflow-lite.a on my mac for Tensorflow version 1.8.0 before.
Now, I am trying to do the same for version 2.1.0 but it's giving the following error
clang: error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
clang: error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/core/api/flatbuffer_conversions.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/allocation.o] Error 1
clang: clang: error: no such file or directory: 'i386'
error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
clang: error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/arena_planner.o] Error 1
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/core/api/error_reporter.o] Error 1
clang: error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
clang: error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/core/api/op_resolver.o] Error 1
clang: error: no such file or directory: 'i386'
clang: warning: no such sysroot directory: '-arch' [-Wmissing-sysroot]
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/c/c_api_internal.o] Error 1
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/core/api/tensor_utils.o] Error 1
make: *** [/Users/myMac/TFLite_2_1/tensorflow/lite/tools/make/gen/ios_i386/obj/tensorflow/lite/core/subgraph.o] Error 1

Standalone code to reproduce the issue

Have downloaded the code from https://github.com/tensorflow/tensorflow/tree/r2.1
First, run download_dependencies.sh script and then build_ios_universal_lib.sh.

Facing the same issue in ver 2.2. I have also tried for ver 2.3 but it showed warning "This build script is deprecated..."

@SimonFernandes7
Could you please refer to this link and let us know if it helps.

@Saduf2019 Thanks, but the error that I'm facing is while creating the libtensorflow-lite.a file and not while using that file in Xcode. The reference link that you have provided is an issue while accessing the .a file in Xcode.

Thanks, for your reference. I was able to solve the issue by running the below command on terminal.
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer/
As it was not able to locate SDK "iphonesimulator"


Unable to Authenticate with Entra ID or use MFA for SQL MI Connections

Type: Bug
I am not able to use the Azure Active Directory Universal with MFA to connect to Azure AQL MIs. When I attempt to add an Azure Account I get the following error:
[Verbose]: Initialized Azure account extension storage. - []
[Verbose]: FileEncryptionHelper: Fired encryption keys updated event. - []
[Verbose]: Initializing stored accounts [] - []
[Verbose]: Starting login - []
[Information]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Info - getAuthCodeUrl called - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Verbose - initializeRequestScopes called - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT] : [bc6a329a-a80c-404b-870c-060412cd3edd]<EMAIL_ADDRESS>: Verbose - buildOauthClientConfiguration called - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT] : [bc6a329a-a80c-404b-870c-060412cd3edd]<EMAIL_ADDRESS>: Verbose - building oauth client configuration with the authority: https://login.microsoftonline.com/organizations - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT] : [bc6a329a-a80c-404b-870c-060412cd3edd]<EMAIL_ADDRESS>: Verbose - createAuthority called - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Trace - Retrieving all cache keys - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Trace - Getting cache key-value store - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Verbose - Attempting to get cloud discovery metadata in the config - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Verbose - Did not find cloud discovery metadata in the config... Attempting to get cloud discovery metadata from the cache. - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Verbose - Did not find cloud discovery metadata in the cache... Attempting to get cloud discovery metadata from the network. - []
[Error]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Error - A non-MSALJS error was thrown while attempting to get the cloud instance discovery metadata.
Error: Error
Error Description: Error: unable to get local issuer certificate - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Verbose - Did not find cloud discovery metadata from the network... Attempting to get cloud discovery metadata from hardcoded values. - []
[Verbose]: [Tue, 21 May 2024 16:55:34 GMT]<EMAIL_ADDRESS>: Verbose - Found cloud discovery metadata from hardcoded values. - []
[Error]: An error occurred in MSAL library when requesting auth code URL. For more detailed information on error, please check 'Azure Accounts' output pane.

[]
[Error]: Login failed: Error: An error occurred in MSAL library when requesting auth code URL. For more detailed information on error, please check 'Azure Accounts' output pane.

endpoints_resolution_error: Error: could not resolve endpoints. Please check network and try again. Detail: ClientAuthError: openid_config_error: Could not retrieve endpoints. Check your authority and verify the .well-known/openid-configuration endpoint returns the required endpoints. Attempted to retrieve endpoints from: https://undefined/organizations/v2.0/.well-known/openid-configuration - []
[Error]: {
"originalMessage": "endpoints_resolution_error: Error: could not resolve endpoints. Please check network and try again. Detail: ClientAuthError: openid_config_error: Could not retrieve endpoints. Check your authority and verify the .well-known/openid-configuration endpoint returns the required endpoints. Attempted to retrieve endpoints from: https://undefined/organizations/v2.0/.well-known/openid-configuration",
"originalException": {
"errorCode": "endpoints_resolution_error",
"errorMessage": "Error: could not resolve endpoints. Please check network and try again. Detail: ClientAuthError: openid_config_error: Could not retrieve endpoints. Check your authority and verify the .well-known/openid-configuration endpoint returns the required endpoints. Attempted to retrieve endpoints from: https://undefined/organizations/v2.0/.well-known/openid-configuration",
"subError": "",
"name": "ClientAuthError"
}
} - []
I have manually set the Accounts.Azure.Cloud URIs as prescribed in other troubleshooting documents. Please find the settings below:
`{
"workbench.editorAssociations": {
"*.{sqlplan}": "workbench.editor.executionplan"
},
"datasource.connectionGroups": [
{
"name": "ROOT",
"id": "C777F06B-202E-4480-B475-FA416154D458"
}
],
"window.newWindowDimensions": "inherit",
"editor.insertSpaces": false,
"workbench.colorTheme": "Default Dark Azure Data Studio",
"workbench.enablePreviewFeatures": true,
"security.workspace.trust.untrustedFiles": "open",
"editor.minimap.enabled": true,
"files.autoSave": "onWindowChange",
"editor.formatOnType": true,
"editor.acceptSuggestionOnEnter": "off",
"editor.inlineSuggest.showToolbar": "always",
"editor.quickSuggestionsDelay": 8,
"editor.suggest.preview": true,
"files.trimTrailingWhitespace": true,
"workbench.editor.highlightModifiedTabs": true,
"workbench.editor.titleScrollbarSizing": "large",
"editor.bracketPairColorization.independentColorPoolPerBracketType": true,
"editor.defaultFormatter": "Microsoft.mssql",
"editor.suggest.localityBonus": true,
"[json]": {
"editor.defaultFormatter": "vscode.json-language-features"
},
"azure.loggingLevel": "Verbose",
"http.systemCertificates": true,
"http.proxyStrictSSL": false,
"accounts.azure.cloud.authority": "https://login.microsoftonline.com/[redacted]/",
"accounts.azure.cloud.authorizationEndpoint": "https://login.microsoftonline.com/[redacted]/oauth2/authorize",
"accounts.azure.cloud.tokenEndpoint": "https://login.microsoftonline.com/[redacted]/oauth2/token",
"azure.customProviderSettings": [
],
"files.hotExit": "onExitAndWindowClose",
"mssql.logDebugInfo": true,
"mssql.enableSqlAuthenticationProvider": false

}`
Azure Data Studio version: azuredatastudio 1.48.0<PHONE_NUMBER>ef8254b7c22a5dc55af7f8a1dea93f, 2024-02-27T00:05:08.293Z)
OS version: Windows_NT x64 10.0.19045
Restricted Mode: No
Preview Features: Enabled
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-10310U CPU @ 1.70GHz (8 x 2208)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
15.78GB (3.09GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (14)

Extension
Author (truncated)
Version

admin-pack
Mic
0.0.2

admin-tool-ext-win
Mic
0.1.3

agent
Mic
0.49.0

azuremonitor
Mic
0.1.9

dacpac
Mic
1.14.0

import
Mic
1.6.1

machine-learning
Mic
0.12.0

managed-instance-dashboard
Mic
0.4.2

powershell
ms-
2023.2.1

profiler
Mic
0.14.0

query-history
Mic
0.5.3

schema-compare
Mic
1.21.0

sql-assessment
Mic
0.6.4

sql-database-projects
Mic
1.4.2

The key error is this: Error: unable to get local issuer certificate - [], which is most likely caused by local ssl config on the machine. Are you running ADS behind a proxy?
Can you give this a try? https://learn.microsoft.com/en-us/answers/questions/1352107/unable-to-add-account-in-azure-data-studio
You can also download and install this extension, and run commands manually to test your proxy environment configuration (if any) and OS certificates: https://marketplace.visualstudio.com/items?itemName=chrmarti.network-proxy-test

Thank you @caohai. For all my searching I couldn't find that solution. This resolved the issue.


Change the name of the manifest file as it conflicts with other specifications like Web manifest

Clear and concise description of the problem
When configurIng Vite to generate a "manifest" file, it generates a file called manifest.json, at the root of the defined outDir.
This conflicts with other specifications like Web Manifest, which also uses a manifest.json file.
Suggested solution
I see two potential solutions:

Change the default name from manifest.json to something else, like  vite-manifest.json. I like this approach as manifest feels a very generic name anyway.  The problem with this is that would a breaking change
Have an option on Vite config to define an alternate name for the manifest file.

I would prefer the first option, as I think the purpose of the file would be more clearer. The issue is that it would break backward compatibility as people using the manifest file in their projects are most likely parsing it and expecting it to have the current name.
The second one, can probably be a better compromise as only projects using the Web manifest file, for example, would need to override the default location.

Fixed in https://github.com/vitejs/vite/pull/6667


CPU overload when nerdtree is open

Hi @w0rp, here i recorded the issue https://asciinema.org/a/1pqmucabmdtogsflmolcow4s7
When the nerdtree is open and i'm placing the cursor on the line with error sign the CPU % start to grow
It's growing even more when i'm expanding custom folder
I'm using NVIM v0.1.6-175-g7246750

Your output includes the process ID, but which process is taking CPU time? Is it Vim itself? Does this only happen when NERDTree is open?

Do you get the high CPU usage if you use NERDTree, and ALE is disabled? Do you experience the usage when you disable some or all of the autocmd commands for ALE?

As you can see on the screencast http://storage1.static.itmages.com/i/16/1025/h_1477397970_1924606_8f19f1f7ba.png
it's nvim test.js
Also in this screencast i recorded how it looks when the nerdtree is opened and closed
This is when it's opened http://storage1.static.itmages.com/i/16/1025/h_1477398161_2666007_0d50995e3d.png
And here when it's closed http://storage7.static.itmages.com/i/16/1025/h_1477398247_1631479_a65de97cd6.png

Do you get the high CPU usage if you use NERDTree, and ALE is disabled?

no

Do you experience the usage when you disable some or all of the autocmd commands for ALE?

here my ale configs:
let g:ale_linters = {
\   'javascript': ['eslint'],
\}
let g:ale_sign_error = '✘'
let g:ale_sign_warning = '☹'
let g:ale_lint_delay = 700

let g:ale_echo_msg_error_str = 'E'
let g:ale_echo_msg_warning_str = 'W'
let g:ale_echo_msg_format = '[%linter%] %s [%severity%]'

hi ALEErrorSign guifg=red guibg=#073642
hi ALEWarningSign guifg=yellow guibg=#073642

let g:ale_sign_column_always = 1

Also i'm using ALEGetStatusLine function in airline but when i disable it the issue is still persists

Ah, I missed the process on the right hand side. Do you see the same CPU usage if you disable linting when text is changed, buffers are opened, with a larger delay, etc? Try changing some of the global configuration options, and see if you can figure out exactly what is causing this. I don't experience the high CPU usage myself.

One cause might be that the TextChanged event is firing inside the NERDTree buffer quite a lot, or something like that. I might take a stab in the dark and make it never execute anything if the filetype is nerdtree.

Try these steps to reproduce:

open big project with many folders and files;
open a file with errors;
open nerdtree and there open a subfolder that contains many files
place the cursor on the line with the error sign;

i don't get high CPU usage on small projects when there are not many folders/files opened in the nerdtree

I just pushed a commit to a branch for experimentally disabling ALE for NERDTree and Unite.vim buffers. You can check that out and see if that helps at all.

No it didn't help
Just want to clarify that the issue occurs only when NERDTree is open but the cursor is placed on the error sign in the opened file, so i'm not sure that your commit can help because the NERDTree itself is  not active
here i recorder another screencast https://asciinema.org/a/dlwv80cq56kb42f8l36sgu291
As you can see when i open a file and place the cursor on the error sign nvim doesn't take many CPU usage
After that i opened NERDTree and placed the cursor back to the line with error sign and nvim start to overload CPU
On 00:37 i placed the cursor above the line with error sign and CPU usage get back to normal
In the end i closed the NERDTree to show that CPU usage get back to normal while the cursor is still on the line with error sign
If this still can't help to reproduce the issue then i'll try to figure this out little later

Also i noticed that the cursor starts to blink fast when it's on the line with error sign and NERDTree is open
you can see it on the screencast

Does the high CPU usage disappear if you set g:ale_echo_cursor to 0? Does it stop happening if you remove the CursorHold event?

let g:ale_echo_cursor = 0 fixed the issue

Hmm, if you turn that back on, but edit the plugin in plugin/ale.vim to remove CursorHold, but keep CursorMoved, do you see the same issue?

The cursor stop to blink but CPU is still overloaded

Hmm, okay then. I might have to write a check in the handler to see if the cursor has actually moved, and take the CursorHold event away. It looks like it's somehow calling the function many times, even when the cursor hasn't actually moved.

Great, thank you for your effort

If you check out the latest code on master, I had a go at doing that. It seems to work for me.

Thank you! It fixed the issue 👍

Nice. No problem. Thank you for reporting the issue. That fix should hopefully reduce CPU usage for some other users.

It's too late to answer, but I leave the comment for someone suffering the same problem like me.
In my case, after installing the plugin, "tiagofumo/vim-nerdtree-syntax-highlight", the CPU usage is higher, and the cursor on NerdTree is slower.
The main reason is described at the bottom of the page of the plugin, Mitigating lag issues part.
https://github.com/tiagofumo/vim-nerdtree-syntax-highlight
For the result, refer to the below options and comments. It looks like the ExactMatch and PatternMatch functions need more CPU processing.
set lazyredraw " slow down the update screen
let g:NERDTreeLimitedSyntax = 1
let g:NERDTreeFileExtensionHighlightFullName = 1 " set color for full file name
" let g:NERDTreeExactMatchHighlightFullName = 1 " ExactMatch not used
" let g:NERDTreePatternMatchHighlightFullName = 1 " PatternMatch is not used
" let g:NERDTreeSyntaxDisableDefaultExtensions = 1
let g:NERDTreeSyntaxDisableDefaultExactMatches = 1 " ExactMatch is not used
let g:NERDTreeSyntaxDisableDefaultPatternMatches = 1 " patternmatch is not used
Additionally, remove the plugins that are not used like the below example.
Because I have used the coc, I don't need the below plugins. But I didn't realize it is still enabled.
Plugin 'xolox/vim-easytags'
Plugin 'xolox/vim-misc'


training configuration of STR model

Hi, thank you for open-sourcing your work.
I have a question about the training configuration of STR model used in your paper.
How did you set the sensitive character mode and data_filtering_off option in BEST model?

Thank you for your detailed and kind response!


Generating production-ready image on docker example

Hi! I'm trying to optimize a docker image for production. Is there any example of a workflow to achieve this?
As far as I understand, I should generate an artifact with the build script:
    "build": "ts-node --transpile-only src/index.ts"

then copy this dist folder and run it normally. Is it right?
I'm currently using this as my Dockerfile.prod
FROM node:12-slim

RUN mkdir /app
WORKDIR /app

COPY package*.json ./

RUN prisma2 generate
USER node

RUN npm run build
RUN npm install pm2 -g

COPY ./dist .

EXPOSE 4000

CMD ["pm2-runtime","index.js"]

with pm2 for process managing.
Any thoughts on that? Any tips?

@outerlook - Did you ever get this working properly? I'm having trouble generating the TS definitions inside my Docker container.


musiQ app v1.872|| Unable to find the album when it's added on the favorite album.

How to reproduce:

Start musiQ app v1.872.
Go to any album artist and from the home page artist photos just to find the bug.
Chose an album and at the bottom left of that album image you will find an option for adding it in your favorite album. Click on add favorite album.
Then click back and come back to home page where you've started and swipe left all the way for favorite albums tray at the very last of the tray you'll find it. And it will show you that specific album you've added recently.
Now click on the album to see the album details of your favorite album.
Note that the app will show the user that it is finding the album but after waiting several seconds  albums does not show the details after adding it on the favorite album.

App version: musiQ v1.872
Android version 7.0
Recorded video: https://vimeo.com/281266912

Thanks! I will look into this.


Recently selected choice will appear as default choice

Fixes #2316

Thanks! However I don't understand how this is supposed to work - where is the recently selected choice stored? Also, I tried running this and now the "Match" button does not do anything anymore.

@wetneb I thought it worked, but you are right, the Match button isn't working. I tried other methods of doing this, but nothing is leading to what is expected.

The 2 options are radio buttons, so one of them must be selected by default, I would expect. You could replace both radio buttons by a single checkbox, but it would probably not be as clear as the current UI.

The 2 options are radio buttons, so one of them must be selected by default, I would expect. You could replace both radio buttons by a single checkbox, but it would probably not be as clear as the current UI.

True. Also, changing that might break other functions.

Closing per https://github.com/OpenRefine/OpenRefine/issues/2316#issuecomment-606469655


[WIP] [Questions] Use Space API to handle wi,wit and wilt

related to: https://github.com/almighty/almighty-core/issues/955 and https://github.com/almighty/almighty-core/issues/943
I have the following questions:

Initially I started adding space_workitems, space_workitemtypes,... but if we are going to move everything under space/*. Why don't we simply reuse the existing resources and add Parent(space). According to this changes, I had to prefix stuff  with Space keyworkd such as SpaceWorkItemController, CreatedSpaceWorkitem..... That could change based on the answer to the question aforementioned here.
In the existing code, we get the SpaceID out of the Payload. However with this new implementation, the space ID will be eventually extracted from the URL e.g. api/space/:id/workitems/*. Am I right ?
I saw that iterations only bring under the space API the operation list, create. Will that happen for the others wi, wit and wilt ? Or we move  ALL the operations delete,show,create under the space umbrella. I just want to be sure, we're in the same page and to avoid longer coding cycles.

TODO list:

[ ] Address my questions
[ ] Adapt the tests
[ ] Test all the stuff

Initially I started adding space_workitems, space_workitemtypes,... but if we are going to move everything under space/*. Why don't we simply reuse the existing resources and add Parent(space). According to this changes, I had to prefix stuff with Space keyworkd such as SpaceWorkItemController, CreatedSpaceWorkitem..... That could change based on the answer to the question aforementioned here.

If Adding Parent without any controller changes is quicker, then do that for now. UI should rely on URLs anyway so it doesn't really matter if spaces/n/workitems points to /spaces/n/workitems/n or /workitems/n. We can clean / align that later.

In the existing code, we get the SpaceID out of the Payload. However with this new implementation, the space ID will be eventually extracted from the URL e.g. api/space/:id/workitems/*. Am I right ?

yes, Space relationship should be inferred here if missing and overwritten if not.

I saw that iterations only bring under the space API the operation list, create....

See #1

closing this cause in favor of https://github.com/almighty/almighty-core/pull/1001


Fix the conversion utility functions, word is 16 bits not 32

For the sake of setting up the pattern for later work, can someone else review this and then PR if its ready?

Much better on the test cases, I approve, my question on bit extension vs masking still stands but we're fine to merge


Handle playability status is not ok

Description
handle error when playability status is not ok.
And follow kkc's proposal in PR#62 to print status and reason in the error
Issues to fix
Please link issues this PR will fix:
#65

LGTM


Elide the temporary container created when returning from algorithms

When we write something like
auto xs = make_tuple(...);
auto ys = transform(xs, f);

A temporary tuple is created and then move-assigned to ys. This should be elided most of the time, but providing a way to make sure that this is always the case (without relying on the optimizer) would be nice. This can be achieved e.g. by providing mutating algorithms:
auto xs = make_tuple(...);
Result ys;

length(xs).times.with_index([&](auto i) {
    ys[i] = f(xs[i]);
});

There are probably other ways to achieve this too. See the original discussion on the Boost.Devel mailing list.

I think this issue is unsolvable without either

Introducing mutable versions of all algorithms where it makes sense. I'm not going to do this because these algorithms wouldn't be sufficiently composable, and it would represent too much of a big leap for Hana for the sake of one optimization.
Relying on the fact that in practice, any decent compiler should elide the copy.

Since P0135R0 is in the works for C++17, I'd rather rely on this.
@tzlaine: Since you were the original person to ask for this on the mailing list, does relying on P0135R0 seems reasonable to you? One of your comment on the mailing list was

No, I'm trying to get rid of the temporary altogether.  We all know that copies of temporaries get RVO'd out of code like the above a lot of the time, but not always.  I want a guarantee that I don't need to rely on RVO in a particular case, if efficiency is critical.

If RVO became mandatory, would it be satisfying?

P0135R0 definitely helps.  However, I don't think the compiler is capable
of applying RVO to unbounded call depths.  I'm sure I can make calls into
the Hana interface that result in temporaries, even if P0135R0 becomes
standard.
Mutating operations are simply necessary in efficient C++ code.
If that's out of scope for Hana, then that's just what we'll have to live
with.  But it almost certainly will not be optimal in many, many cases.
Zach
On Wed, Nov 11, 2015 at 6:30 AM, Louis Dionne<EMAIL_ADDRESS>wrote:

I think this issue is unsolvable without either

Introducing mutable versions of all algorithms where it makes
sense. I'm not going to do this because these algorithms wouldn't be
sufficiently composable, and it would represent too much of a big leap for
Hana for the sake of one optimization.
Relying on the fact that in practice, any decent compiler should
elide the copy.

Since P0135R0
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html is
in the works for C++17, I'd rather rely on this.
@tzlaine https://github.com/tzlaine: Since you were the original person
to ask for this on the mailing list, does relying on P0135R0 seems
reasonable to you? One of your comment on the mailing list was
No, I'm trying to get rid of the temporary altogether. We all know that
copies of temporaries get RVO'd out of code like the above a lot of the
time, but not always. I want a guarantee that I don't need to rely on
RVO in a particular case, if efficiency is critical.
If RVO became mandatory, would it be satisfying?
—
Reply to this email directly or view it on GitHub
https://github.com/boostorg/hana/issues/150#issuecomment-155764821.

Indeed, I just re-convinced myself that I was wrong. Consider the following example, where x,y and z are expensive to copy and/or move. This is mostly for my future reference so I don't fall back into the trap of thinking that RVO will be enough:
auto tuple = hana::make_tuple(x, y, z);

auto f() {
    return hana::transform(tuple, some_function1);
}

auto g() {
    return hana::transform(f(), some_function2);
}

auto result = g();

If RVO is applied, then the above code is equivalent to
auto tuple = hana::make_tuple(x, y, z);

auto g() {
    auto result_of_f = hana::transform(tuple, some_function1); // RVO-ed from f()
    return hana::transform(std::move(result_of_f), some_function2);
}

auto result = g();

which in turn is equivalent to
auto tuple = hana::make_tuple(x, y, z);
auto result_of_f = hana::transform(tuple, some_function1);
auto result = hana::transform(std::move(result_of_f), some_function2); // RVO-ed from g()

The problem is that we still end up with a move of result_of_f, even if RVO is both mandatory and applied transitively. Instead, with a view, what you would get is
auto tuple = hana::make_tuple(x, y, z);

auto f() {
    return hana::transform_view(tuple, some_function1);
}

auto g() {
    return hana::transform_view(f(), some_function2);
}

auto result = g();

which is RVO-equivalent to
auto tuple = hana::make_tuple(x, y, z);
auto result_of_f = hana::transform_view(tuple, some_function1);
auto lazy_result = hana::transform_view(result_of_f, some_function2);

Now, however, when you evaluate the result,
auto result = evaluate(lazy_result);

what you get is equivalent to the following:
auto result = hana::make_tuple(
    some_function2(some_function1(tuple[0])),
    some_function2(some_function1(tuple[1]))
    some_function2(some_function1(tuple[2]))
);

which indeed does not create any temporary. Of course, there are some downsides to views, but it seems like it would be useful to support them in the future.

On Wed, Nov 11, 2015 at 10:16 AM, Louis Dionne<EMAIL_ADDRESS>wrote:

Indeed, I just re-convinced myself that I was wrong. Consider the
following example, where x,y and z are expensive to copy and/or move.
This is mostly for my future reference so I don't fall back into the trap
of thinking that RVO will be enough:
auto tuple = hana::make_tuple(x, y, z);
auto f() {
return hana::transform(tuple, some_function1);
}
auto g() {
return hana::transform(f(), some_function2);
}
auto result = g();
If RVO is applied, then the above code is equivalent to
auto tuple = hana::make_tuple(x, y, z);
auto g() {
auto result_of_f = hana::transform(tuple, some_function1); // RVO-ed from f()
return hana::transform(std::move(result_of_f), some_function2);
}
auto result = g();
which in turn is equivalent to
auto tuple = hana::make_tuple(x, y, z);auto result_of_f = hana::transform(tuple, some_function1);auto result = hana::transform(std::move(result_of_f), some_function2); // RVO-ed from g()
The problem is that we still end up with a move of result_of_f, even if
RVO is both mandatory and applied transitively. Instead, with a view, what
you would get is
auto tuple = hana::make_tuple(x, y, z);
auto f() {
return hana::transform_view(tuple, some_function1);
}
auto g() {
return hana::transform_view(f(), some_function2);
}
auto result = g();
which is RVO-equivalent to
auto tuple = hana::make_tuple(x, y, z);auto result_of_f = hana::transform_view(tuple, some_function1);auto lazy_result = hana::transform_view(result_of_f, some_function2);
Now, however, when you evaluate the result,
auto result = evaluate(lazy_result);
what you get is equivalent to the following:
auto result = hana::make_tuple(
some_function2(some_function1(tuple[0])),
some_function2(some_function1(tuple[1]))
some_function2(some_function1(tuple[2]))
);
which indeed does not create any temporary. Of course, there are some
downsides to views, but it seems like it would be useful to support them in
the future.

Right.  Furthermore, views are often a pessimization too.  Consider a
view-version of STL range algorithms:
MySeq seq = {a, b, c, d, ..., z};
sort(seq); // mutates in-place
transform(seq, out_iterator); // access is in-order and cache-friendly
versus:
MySeq seq = {a, b, c, d, ..., z};
auto sorted = sort_view(seq); // (ignore the cost of this copy; it could
just as easily have been inlined below)
transform(sorted, out_iterator); // access is out-of-order and
cache-unfriendly in the general case
I care a lot about cache coherency.
My perfect Hana interface would have a mutating overload for each
possibly-mutating algorithm (some of them should not mutate anything).
So if I want functional, I could write:
result1 = sort(seq);
result2 = transform(seq);
or, if I want mutating:
sort(seq);
transform(seq, out_seq);
Note that without a bit of work, the sort() overloads above are ambiguous.
This could be fixed with a "mutating" namespace, by tagging the type of
"seq" above as being mutable, etc.  The exact mechanism is not that
important, but I really want to be able to use the moral equivalent of
std::sort(), std::transform(), etc., on Hana tuples.
Zach

sort(seq);

Sorting in place is simply impossible in the general case, since the type of the sorted sequence may differ from the type of the original sequence. Hence, sorting in-place only makes sense when you have e.g. hana::tuple<int, int, int> (all with the same type). But then, you probably should be using a std::array.

transform(seq, out_seq);

Regarding a mutating transform, I don't see any difference between
auto tuple = hana::make_tuple(x, y, z);
hana::tuple<T, U, V> result; // suppose you can predict the type of the resulting tuple
hana::transform_mutate(tuple, function, result);

and
auto tuple = hana::make_tuple(x, y, z);
auto result = hana::transform(tuple, function);

assuming RVO applies. Actually, the difference is that in the first case, you have to default-construct result, which might even be less efficient.
Don't get me wrong; I'm not trying to argue against you just for the sake of it. What I'm really trying to do is to go through the thought process of making the algorithms mutable, and see if that makes sense.
I'm not sure, but I think that heterogeneous sequences make those mutable operations not-so-well-defined in the general case, and equivalent to std algorithms in the special cases.

On Wed, Nov 11, 2015 at 11:14 AM, Louis Dionne<EMAIL_ADDRESS>wrote:

sort(seq);
Sorting in place is simply impossible in the general case, since the type
of the sorted sequence may differ from the type of the original sequence.
Hence, sorting in-place only makes sense when you have e.g. hana::tuple<int,
int, int> (all with the same type). But then, you probably should be
using a std::array.

Right. sort() is a bad example.  Pretend I wrote filter() and the issue
remains the same.

transform(seq, out_seq);
Regarding a mutating transform, I don't see any difference between
auto tuple = hana::make_tuple(x, y, z);
hana::tuple<T, U, V> result; // suppose you can predict the type of the resulting tuplehana::transform_mutate(tuple, function, result);
and
auto tuple = hana::make_tuple(x, y, z);auto result = hana::transform(tuple, function);
assuming RVO applies. Actually, the difference is that in the first case,
you have to default-construct result, which might even be less efficient.

RVO simply cannot be applied to some functions:
void not_rvo_able (MySeq seq_a, MySeq seq_b)
{
if (some_predicate())
return seq_a;
else
return seq_b;
}
Other optimizations may make the code above reduce to nearly nothing, but
not RVO (SSA-style analysis probably kicks in above, but also probably not
if the args are refs/pointers).
The point is that if I can't mutate, I can't eliminate all
temporaries/copies that are not strictly necessary.

Don't get me wrong; I'm not trying to argue against you just for the sake
of it. What I'm really trying to do is to go through the thought process of
making the algorithms mutable, and see if that makes sense.

I get that completely.  I work the same way.

I'm not sure, but I think that heterogeneous sequences make those mutable
operations not-so-well-defined in the general case, and equivalent to std
algorithms in the special cases.

I agree.  It's completely case-by-case.  The ones that are isomorphic with
STL algorithms are the ones I probably want the most anyway though.
Zach

Right. sort() is a bad example.  Pretend I wrote filter() and the issue remains the same.

filter will also not work in-place, because the type of the filtered sequence may change. Consider for example
hana::tuple<int, double, char> tuple{1, 3.4, 'x'};
hana::tuple<double> result = hana::filter(tuple, hana::traits::is_floating_point);

Actually, I think that none of the algorithms can be in-place in the general case. Going through the important algorithms in the cheatsheet,

transform: In the general case, the type of each element may change so transforming in-place would be a special case.
drop_front: Can only be in-place when we don't drop anything, since the number of elements in the tuple is encoded in its type.
filter: Explained above
sort: Explained above
remove_at: The type of the resulting sequence will change, since the size of the sequence is encoded in its type.
reverse: Again, it is not possible to reverse in-place, since hana::tuple<int, char, float> != hana::tuple<float, char, int>.

More generally, we can see that any algorithm that changes the size of the original sequence is bound not to be implementable in-place, because that size is encoded in the type of the sequence. Also, any algorithm that reorders the elements of a sequence can't have an in-place version, unless the reordering is done in such a way that the types of the initial sequence are respected. For example, consider
hana::tuple<int, char, int> tuple{1, 'x', 3};
auto result = f(tuple); // some reordering of the tuple

The only way f can ever be implemented in-place is if f is either the identity function, or if it swaps the two ints together (and perhaps apply a type-preserving transformation to the elements). If we remove all the algorithms that change the size of the sequence or reorder elements, we're left with the algorithms from Functor. Do you agree with me up to this point?
Now, since all those algorithms from Functor can be implemented very easily in terms of transform, let's just consider transform. As I said above, transform can only be implemented in-place if the function it maps over the sequence is type-preserving. However, it is very easy to implement such an in-place transformation as:
auto tuple = hana::make_tuple(x, y, z);
hana::for_each(tuple, [](auto& x) {
    x = f(x); // x is a reference, so we mutate in-place
});

Since it only applies to these algorithms from Functor, and since they are so easy to implement with for_each, I do not think it would be wise to provide then as part of Hana's interface. I would also argue that whatever the name we might pick for such an in-place transform, nothing will be as clear as writing the above for_each.

RVO simply cannot be applied to some functions:
[...]

I know, but my point was that RVO trivially applies to hana::transform. Let's clarify things. For any given algorithm, we have four ways of implementing it:

Non-mutating version, as-if:
template <typename Tuple, typename F>
auto transform(Tuple&& tuple, F const& f) {
    return hana::make_tuple(f(tuple[0]), f(tuple[1]), ..., f(tuple[n]));
}

Mutating version, as-if:
template <typename Tuple, typename F, typename Result>
void transform_mutate(Tuple&& tuple, F const& f, Result& result) {
    result[0] = f(tuple[0]);
    result[1] = f(tuple[1]);
    ...
    result[n] = f(tuple[n]);
}

In-place version, as-if:
template <typename Tuple, typename F>
void transform_inplace(Tuple& tuple, F const& f) {
    result[0] = f(result[0]);
    result[1] = f(result[1]);
    ...
    result[n] = f(result[n]);
}

Lazy version, as-if:
template <typename Tuple, typename F>
auto transform_lazy(Tuple& tuple, F const& f) {
    return some_view_that_does_the_computation_lazily(tuple, f);
}

First, we have already considered views, and I think we agree that they can be useful. This is on the roadmap for a future version of Hana.
Secondly, I have argued above that in-place algorithms are impossible to implement for heterogeneous sequences in the general case.
Thirdly, there's our discussion about mutating versus non-mutating algorithms. My claim is that both are strictly equivalent, assuming a trivial RVO kicks in. Indeed, if you look at the definition of the non-mutating transform, since the body is only a return statement, the compiler should trivially apply RVO there (do you agree?). And if P0135R0 is adopted, then this easy-to-apply RVO becomes mandatory, and we're not just relying on QOI anymore. Hence, assuming that RVO for transform is applied, the following code snippets should be equivalent:
auto tuple = hana::make_tuple(x, y, z);
hana::tuple<T, U, V> result;
hana::transform_mutate(tuple, function, result);

and
auto tuple = hana::make_tuple(x, y, z);
auto result = hana::transform(tuple, function);

Do you agree with this third point, or am I making a factual mistake somewhere? If you do agree with the third point, then the only thing left to do would be to confirm that Hana's non-mutating algorithms are indeed implemented in a way that allows RVO to happen. If so, then providing mutating algorithms is not necessary. If not, then we should implement the algorithms in a different way that takes advantage of RVO.

On Wed, Nov 11, 2015 at 3:25 PM, Louis Dionne<EMAIL_ADDRESS>wrote:

Right. sort() is a bad example. Pretend I wrote filter() and the issue
remains the same.
filter will also not work in-place, because the type of the filtered
sequence may change. Consider for example
hana::tuple<int, double, char> tuple{1, 3.4, 'x'};
hana::tuple result = hana::filter(tuple, hana::traits::is_floating_point);
Actually, I think that none of the algorithms can be in-place in the
general case. Going through the important algorithms in the cheatsheet,

transform: In the general case, the type of each element may change
so transforming in-place would be a special case.
drop_front: Can only be in-place when we don't drop anything, since
the number of elements in the tuple is encoded in its type.
filter: Explained above
sort: Explained above
remove_at: The type of the resulting sequence will change, since
the size of the sequence is encoded in its type.
reverse: Again, it is not possible to reverse in-place, since hana::tuple<int,
char, float> != hana::tuple<float, char, int>.

More generally, we can see that any algorithm that changes the size of the
original sequence is bound not to be implementable in-place, because that
size is encoded in the type of the sequence. Also, any algorithm that
reorders the elements of a sequence can't have an in-place version, unless
the reordering is done in such a way that the types of the initial sequence
are respected. For example, consider
hana::tuple<int, char, int> tuple{1, 'x', 3};auto result = f(tuple); // some reordering of the tuple
The only way f can ever be implemented in-place is if f is either the
identity function, or if it swaps the two ints together (and perhaps
apply a type-preserving transformation to the elements). If we remove all
the algorithms that change the size of the sequence or reorder elements,
we're left with the algorithms from Functor. Do you agree with me up to
this point?

Yes.

Now, since all those algorithms from Functor can be implemented very
easily in terms of transform, let's just consider transform. As I said
above, transform can only be implemented in-place if the function it maps
over the sequence is type-preserving. However, it is very easy to implement
such an in-place transformation as:
auto tuple = hana::make_tuple(x, y, z);hana::for_each(tuple, [](auto& x) {
x = f(x); // x is a reference, so we mutate in-place
});
Since it only applies to these algorithms from Functor, and since they
are so easy to implement with for_each, I do not think it would be wise
to provide then as part of Hana's interface. I would also argue that
whatever the name we might pick for such an in-place transform, nothing
will be as clear as writing the above for_each.

Fair enough, but we're talking about slightly different things, I think.
The in-place issue is not my main concern; I was simply trying to show that
views jumble the order of access, making them cache-unfriendly.  I picked
sort() and filter() badly, but the main idea is that in some cases the
optimal thing to do is to copy so that later accesses are in-order (e.g.
with a large sequence of cheap-to-copy objects).  Sometimes the optimal
thing is to use a view (e.g. with a small sequence of expensive-to-copy,
copy-only objects).  Sometimes moves might be more appropriate (e.g. with a
small sequence of expensive-to-copy, moveable objects).
For homogeneous sequences, the STL is still useful under all the usage
conditions above and more, except for its lack of views.  Right now, all
Hana does is copy.  I really want analogues of std::copy(), std::move(),
std::copy_backward(), and std::move_backward() in Hana, as well as
overloads of transform et al with an out-iterator.
RVO simply cannot be applied to some functions:

[...]
I know, but my point was that RVO trivially applies to hana::transform.
Let's clarify things. For any given algorithm, we have four ways of
implementing it:

Wait, you're skipping over my point.  Consider:
template
auto not_rvo_able (MySeq seq_a, MySeq seq_b, F f)
{
if (some_predicate())
return transform(seq_a, F);
else
return transform(seq_b, F);
}
Ok, so now, why does it matter that transform() trivially gets RVO?  The
point is that if I use copy-happy algorithms that are all RVO-able
individually, I end up writing code that does not use RVO.  Even so, for
many use cases this will be optimal or near-optimal code.
Views help, but only if you can compute the type of the result beforehand:
template
auto not_rvo_able (MySeq seq_a, MySeq seq_b, F f)
{
decltype(transform_view(seq_a, f)) retval;
if (some_predicate())
retval = transform_view(seq_a, F);
else
retval = transform_view(seq_b, F);
return retval;
}
This is a bit awkward, but it works.  It is not appropriate if copies
and/or views themselves are not appropriate, as I outlined above.  For many
use cases though this will be exactly right.
But for other cases, maybe this is the optimal code:
some_other_t result;
transform(some_predicate() ? seq_a : seq_b, F, result); // or begin(result)
for the last arg, you get the idea
Note that the code above is allowed to copy, move, construct something new,
or even chose which to do on a per-element basis.
The point is, I need the flexibility of choosing the right approach for my
particular circumstances.

Non-mutating version, as-if:
template <typename Tuple, typename F>auto transform(Tuple&& tuple, F const& f) {
return hana::make_tuple(f(tuple[0]), f(tuple[1]), ..., f(tuple[n]));
}

Mutating version, as-if:
template <typename Tuple, typename F, typename Result>void transform_mutate(Tuple&& tuple, F const& f, Result& result) {
result[0] = f(tuple[0]);
result[1] = f(tuple[1]);
...
result[n] = f(tuple[n]);
}

In-place version, as-if:
template <typename Tuple, typename F>void transform_inplace(Tuple& tuple, F const& f) {
result[0] = f(result[0]);
result[1] = f(result[1]);
...
result[n] = f(result[n]);
}

Lazy version, as-if:
template <typename Tuple, typename F>auto transform_lazy(Tuple& tuple, F const& f) {
return some_view_that_does_the_computation_lazily(tuple, f);
}
First, we have already considered views, and I think we agree that they
can be useful. This is on the roadmap for a future version of Hana.

Agreed.

Secondly, I have argued above that in-place algorithms are impossible to
implement for heterogeneous sequences in the general case.
Agreed.

Thirdly, there's our discussion about mutating versus non-mutating
algorithms. My claim is that both are strictly equivalent, assuming a
trivial RVO kicks in. Indeed, if you look at the definition of the
non-mutating transform, since the body is only a return statement, the
compiler should trivially apply RVO there (do you agree?).

Yes.

And if P0135R0 is adopted, then this easy-to-apply RVO becomes mandatory,
and we're not just relying on QOI anymore. Hence, assuming that RVO for
transform is applied, the following code snippets should be equivalent:
auto tuple = hana::make_tuple(x, y, z);
hana::tuple<T, U, V> result;hana::transform_mutate(tuple, function, result);
and
auto tuple = hana::make_tuple(x, y, z);auto result = hana::transform(tuple, function);
Do you agree with this third point, or am I making a factual mistake
somewhere? If you do agree with the third point, then the only thing left
to do would be to confirm that Hana's non-mutating algorithms are indeed
implemented in a way that allows RVO to happen. If so, then providing
mutating algorithms is not necessary. If not, then we should implement the
algorithms in a different way that takes advantage of RVO.

I agree that RVO will be mandatory and that that is a good thing.  It's
just not sufficient.
Zach

[...]
Now, since all those algorithms from Functor can be implemented very
easily in terms of transform, let's just consider transform. As I said
above, transform can only be implemented in-place if the function it maps
over the sequence is type-preserving. However, it is very easy to implement
such an in-place transformation as:
auto tuple = hana::make_tuple(x, y, z);
hana::for_each(tuple, [](auto& x) {
x = f(x); // x is a reference, so we mutate in-place
});
Since it only applies to these algorithms from Functor, and since they
are so easy to implement with for_each, I do not think it would be wise
to provide then as part of Hana's interface. I would also argue that
whatever the name we might pick for such an in-place transform, nothing
will be as clear as writing the above for_each.

Fair enough, but we're talking about slightly different things, I think.
The in-place issue is not my main concern; I was simply trying to show that
views jumble the order of access, making them cache-unfriendly. I picked
sort() and filter() badly, but the main idea is that in some cases the
optimal thing to do is to copy so that later accesses are in-order (e.g.
with a large sequence of cheap-to-copy objects). Sometimes the optimal
thing is to use a view (e.g. with a small sequence of expensive-to-copy,
copy-only objects). Sometimes moves might be more appropriate (e.g. with a
small sequence of expensive-to-copy, moveable objects).

I understand, and I agree with you about the need to sometimes copy, sometimes move and sometimes be lazy.

For homogeneous sequences, the STL is still useful under all the usage
conditions above and more, except for its lack of views. Right now, all
Hana does is copy.

If I understand correctly what you mean, this is incorrect. Hana will move when given a sequence that can be moved from, and it will copy otherwise. Consider the following example:
auto tuple = hana::make_tuple(x, y, z);
auto result = hana::transform(tuple, function);

Here, since tuple is passed to transform as an lvalue, it can't be moved-from and function will be called as function(x), function(y), and function(z). However, consider the following:
auto tuple = hana::make_tuple(x, y, z);
auto result = hana::transform(std::move(tuple), function);

Now, tuple is passed to transform as an rvalue-reference, and transform will call function as function(std::move(x)), function(std::move(y)), and function(std::move(z)). If function takes advantage of move semantics, then you just moved your resources instead of copying them. This is the same for e.g. sort. If you write
auto tuple = hana::make_tuple(x, y, z);
auto result = hana::sort(std::move(tuple));

it will steal the elements from tuple and move-construct result with them.
Is this what you meant?
[Note that this is actually a lie for sort right now, but only because of a QOI issue. I do have a more runtime-efficient implementation of sort locally, but it behaves badly at compile-time. I should fix this.]

I really want analogues of std::copy(), std::move(),
std::copy_backward(), and std::move_backward() in Hana, as well as
overloads of transform et al with an out-iterator.

For std::copy and std::move, you can just write
auto tuple = hana::make_tuple(x, y, z);
auto a = tuple; // std::copy
auto b = std::move(tuple); // std::move

If you want to do it across sequence types, just use:
auto tuple = hana::make_tuple(x, y, z);
auto a = hana::to<hana::ext::boost::fusion::vector_tag>(tuple); // std::copy
auto b = hana::to<hana::ext::boost::fusion::vector_tag>(std::move(tuple)); // std::move

For the *_backward variants, I admit that there's no such thing out of the
box in Hana. You could write it with a for_each with appropriate indices,
but you'd have to write it by hand. Same goes for transform with an output
iterator. I fear that adding iterators to Hana would spoil its functional design, and I am reluctant to do so.

RVO simply cannot be applied to some functions:
[...]
I know, but my point was that RVO trivially applies to hana::transform.
Let's clarify things. For any given algorithm, we have four ways of
implementing it:

Wait, you're skipping over my point. Consider:
template
auto not_rvo_able (MySeq seq_a, MySeq seq_b, F f)
{
if (some_predicate())
return transform(seq_a, F);
else
return transform(seq_b, F);
}
Ok, so now, why does it matter that transform() trivially gets RVO? The
point is that if I use copy-happy algorithms that are all RVO-able
individually, I end up writing code that does not use RVO.

Ah, you're right. I was overlooking the context in which the function is called.

[...]
But for other cases, maybe this is the optimal code:
some_other_t result;
transform(some_predicate() ? seq_a : seq_b, F, result); // or begin(result)
for the last arg, you get the idea
Note that the code above is allowed to copy, move, construct something new,
or even chose which to do on a per-element basis.
The point is, I need the flexibility of choosing the right approach for my
particular circumstances.

You're right, your alternative is more flexible. It also comes at a cost, though, which is

reduced expressiveness
you need to default-construct the result

Hmmm this issue is hard. I want the best of both worlds, i.e. performance and expressiveness. I'll try to come up with a minimal implementation of mutating algorithms and see where that leads me. Frankly, I don't think this has its place in Hana as-is, because it would just clash massively with the rest of the library. However, there might be a way to provide these algorithms in another way, perhaps even a different library.

On Fri, Nov 13, 2015 at 10:05 AM, Louis Dionne<EMAIL_ADDRESS>wrote:

For homogeneous sequences, the STL is still useful under all the usage
conditions above and more, except for its lack of views. Right now, all
Hana does is copy.
If I understand correctly what you mean, this is incorrect. Hana will move
when given a sequence that can be moved from, and it will copy otherwise.
Consider the following example:
auto tuple = hana::make_tuple(x, y, z);auto result = hana::transform(tuple, function);
Here, since tuple is passed to transform as an lvalue, it can't be
moved-from and function will be called as function(x), function(y), and
function(z). However, consider the following:
auto tuple = hana::make_tuple(x, y, z);auto result = hana::transform(std::move(tuple), function);
Now, tuple is passed to transform as an rvalue-reference, and transform
will call function as function(std::move(x)), function(std::move(y)), and
function(std::move(z)). If function takes advantage of move semantics,
then you just moved your resources instead of copying them. This is the
same for e.g. sort. If you write
auto tuple = hana::make_tuple(x, y, z);auto result = hana::sort(std::move(tuple));
it will steal the elements from tuple and move-construct result with them.
Is this what you meant?

Not exactly.  I was saying something much simpler -- just that I can use
copy(), move(), mutating transform(), mutating for_each(), etc.
However, it is very cool that Hana does what you show above.  I already
knew that, I just meant that Hana doesn't support the mutating options
other than move in its algorithm interfaces.

[Note that this is actually a lie for sort right now, but only because of
a QOI issue. I do have a more runtime-efficient implementation of sort
locally, but it behaves badly at compile-time. I should fix this.]
I really want analogues of std::copy(), std::move(),
std::copy_backward(), and std::move_backward() in Hana, as well as
overloads of transform et al with an out-iterator.
For std::copy and std::move, you can just write
auto tuple = hana::make_tuple(x, y, z);auto a = tuple; // std::copyauto b = std::move(tuple); // std::move
Those are great.

If you want to do it across sequence types, just use:
auto tuple = hana::make_tuple(x, y, z);auto a = hana::tohana::ext::boost::fusion::vector_tag(tuple); // std::copyauto b = hana::tohana::ext::boost::fusion::vector_tag(std::move(tuple)); // std::move
Those, not so much.  As a user, I really want to write what's in the
comment above, not what's in the code above.  That's a lot of typing just
to say "copy".

For the *_backward variants, I admit that there's no such thing out of the
box in Hana. You could write it with a for_each with appropriate indices,
but you'd have to write it by hand. Same goes for transform with an output
iterator. I fear that adding iterators to Hana would spoil its functional
design, and I am reluctant to do so.

I really think it's just a matter of writing convenience functions that
wrap these simple patterns:
template <typename SeqA, typename SeqB>
SeqB&  copy (SeqA const & seq_a, SeqB & seq_b)
{
return seq_b = hana::tohana::ext::boost::fusion::vector_tag(seq_a);
}
template <typename SeqA, typename SeqB>
SeqB&  copy_backward (SeqA const & seq_a, SeqB & seq_b)
{
return seq_b = /* something similarly simple for you but not anyone
else :) */;
}
Don't get hung up on the return value; it's just there for chaining, if
that's desirable.
As you can see, iterators are not strictly necessary, and in fact are not
in keeping with the way the new range-based STL is going.  If you do stuff
like this example, I think you're a great deal of the way there.  When
users inevitably ask for operations on susequences, give them STL2-style
ranges based on indexes:
template <typename Seq, typename First, typename Last>
struct subsequence_view
{
Seq seq;
};
template <typename Seq, typename First, typename Last>
auto range (Seq && seq, First first, Last last)
{
return subsequence_view<decltype(std::forward(seq)), First,
Last>{std::forward(seq)};
}
auto tuple3 = hana::make_tuple(x, y, z);
auto tuple2 = hana::make_tuple(s, t);
hana::copy(range(tuple3, 1_c, 3_c), tuple2); // copies tuple3[1] ->
tuple2[0] and tuple3[2] -> tuple2[1]
hana::move(range(std::move(tuple2), 1_c, 2_c), range(tuple3, 0_c, 1_c)); //
moves tuple2[1] -> tuple[0]
Easy, peasy, lemon squeezy.

RVO simply cannot be applied to some functions:
[...]
I know, but my point was that RVO trivially applies to hana::transform.
Let's clarify things. For any given algorithm, we have four ways of
implementing it:
Wait, you're skipping over my point. Consider:
template
auto not_rvo_able (MySeq seq_a, MySeq seq_b, F f)
{
if (some_predicate())
return transform(seq_a, F);
else
return transform(seq_b, F);
}
Ok, so now, why does it matter that transform() trivially gets RVO? The
point is that if I use copy-happy algorithms that are all RVO-able
individually, I end up writing code that does not use RVO.
Ah, you're right. I was overlooking the context in which the function is
called.
[...]
But for other cases, maybe this is the optimal code:
some_other_t result;
transform(some_predicate() ? seq_a : seq_b, F, result); // or begin(result)
for the last arg, you get the idea
Note that the code above is allowed to copy, move, construct something new,
or even chose which to do on a per-element basis.
The point is, I need the flexibility of choosing the right approach for my
particular circumstances.
You're right, your alternative is more flexible. It also comes at a cost,
though, which is

reduced expressiveness

I hope not.  How so?

you need to default-construct the result

That always sucks, but is sometimes required.

Hmmm this issue is hard. I want the best of both worlds, i.e. performance
and expressiveness. I'll try to come up with a minimal implementation
of mutating algorithms and see where that leads me. Frankly, I don't think
this has its place in Hana as-is, because it would just clash massively
with the rest of the library. However, there might be a way to provide
these algorithms in another way, perhaps even a different library.

Zach


Fix - Firefox not showing modal tables

When using Firefox, the header selection and validation steps are showing as blank due to an issue with FF rendering divs of display:grid and padding/margin.
Tested to work on both FF and Chrome.

Thank you for finding this! I'll need to run some visual tests as this might impact the table component in unexpected ways.


error found in epoxy library

There were errors found when @EpoxyModelClass is implemented.

Care to share more details?


Archive items feature

Added can_be_archived method with test cases
Added the move_to_archive method with test cases

Everything works fine merge PR


Swift Package Manager package

There's been a good discussion on one of the the Swift mailing lists about a good logging framework. Any chance you could make a Package.swift file?

Can you please post a link to that discussion here or send as Twitter DM to @SwiftyBeaver?
I already thought about making a Package.swift file but all that stuff is so new :)
Anyone with more experience on that topic willing to contribute? I would love if SwiftyBeaver could be installed via Apple’s new Package Manager.

At the moment it looks like you would need to change the layout of the repo to support the packages, all the source files need to be under ./sources/
https://github.com/apple/swift-package-manager/blob/master/Documentation/SourceLayouts.md

@davidrothera Do you want to dive into it (maybe because you are anyway interested in that topic) or should I do it? I love the concept of the Swift Package Manager and it would be fantastic to support it better sooner than later :+1:

I'll take a look today :+1:

Awesome, thanks a lot!

@harlanhaskins - we made it! Can you point us please to the discussion that you mentioned or maybe directly endorse SwiftyBeaver? Thanks!

Woo! This is great! The discussion is on the mailing lists, here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000413.html
It'd probably be a good idea to make a general post as the owner of SwiftyBeaver on the swift-users mailing list announcing the SPM support.
Great job and great turnaround time!

Thanks! I just sent an email to the mailing list, I hope it hit the right tone :wink:


Deck file merge - Entity already exists

Hi Guys,
I am setting up a gitlab ci pipeline that will allow publishing apis in kong.  The error message is Error: building state: inserting route Swagger_Petstore-listPets: entity already exists.
In my pipeline, I have to convert an openapi (oas) specification to a kong specification (this is done with the command deck file openapi2kong -s oas.yaml -o kong-spec.yaml).
Then I make a backup of the current Kong configuration (deck dump -o current-spec.yaml) and I merge current-spec.yaml and kong-spec.yaml files to get the final file to synchronize on kong (deck file merge current-spec.yaml kong-spec.yaml -o merge-spec.yaml).
At the first occurrence of publication, it goes without a hitch. (deck diff -s merge-spec.yaml; deck sync -s merge-spec.yaml). On the other hand for all other occurrences of file merge, it does not work since the elements defining the api some already exist in kong.
So with the deck tool is it possible to do a file merge by solving the problem of duplication and prioritizing the specification to keep according to its position in the list of files provided as a parameter to deck.
Deck version : v1.25.0
Kong version : v3.2
Thanks in advance

duplicate of https://github.com/Kong/go-apiops/issues/84 see discussion there.
@cfw-cagip please do not create duplicate issues, or at least cross-reference them if there is no response. Thx.


[SPARK-49461][SS] Persistent Checkpoint ID to commit logs and read it back

What changes were proposed in this pull request?

In this change, we propose to add a new field to the commit log if STREAMING_STATE_STORE_COMMIT_LOG_VERSION is 2. The new field is a Map[String, Map[String, Map[String, Seq[String]]]] that maps OperatorId -> PartitionId -> StoreName -> Seq[uniqueId]. This is a necessary step to enable the v2 checkpoint.
Why are the changes needed?

New feature
Does this PR introduce any user-facing change?

No
How was this patch tested?

Added UT
Was this patch authored or co-authored using generative AI tooling?

No

cc @siying PTAL!

Same here, I'm merging the PR on behalf of @brkyvz as he asked personally. Just to leave DISCLAIMER.

Thanks! Merging to master.