YB
инкрементальная компиляция при изменении чего-то в роутах warp увеличивается с 11 секунд до 21, при том что из изменений - добавление пяти роутов. это нормально?
Да, если ты не оборачиваешь всё подряд в
.boxed()Size: a a a
2020 November 30
YB
Особенности местной кухни https://github.com/seanmonstar/warp/issues/32
MB
у CString нет возможности преобразования в *mut c_char, как я понял
А into_raw() чем не подходит?
MB
Странно что нет метода, который просто возвращал бы мутабельный указатель, но вроде никто не мешает позвать into_raw(), запомнить указатель и сразу же вызвать from_raw()
r
как создать мутабельную C-строку? мне нужен *mut c_char
Сделать
Vec<c_char> (или массив) и отдать .as_mut_ptr() в C-код. Потом сделать из вектора CStringp
А into_raw() чем не подходит?
а, да, он. чето не заметил его. спасибо.
r
а, да, он. чето не заметил его. спасибо.
C-код не должен менять длину строки. То есть трогать нулевой байт
в🧇
red75prime
C-код не должен менять длину строки. То есть трогать нулевой байт
Ну если ты за аллокацию улетишь, то тебе в любом случае будет плохо
r
Ну если ты за аллокацию улетишь, то тебе в любом случае будет плохо
Это из документации: It should be noted that the length isn't just "recomputed," but that the recomputed length must match the original length from the CString::into_raw call. This means the CString::into_raw/from_raw methods should not be used when passing the string to C functions that can modify the string's length.
в🧇
red75prime
Это из документации: It should be noted that the length isn't just "recomputed," but that the recomputed length must match the original length from the CString::into_raw call. This means the CString::into_raw/from_raw methods should not be used when passing the string to C functions that can modify the string's length.
я к тому, что не могу придумать структуру которая бы позволяла неограниченно менять длинну
в🧇
red75prime
Это из документации: It should be noted that the length isn't just "recomputed," but that the recomputed length must match the original length from the CString::into_raw call. This means the CString::into_raw/from_raw methods should not be used when passing the string to C functions that can modify the string's length.
хм, а почему такое ограничение? Звучит достаточно странно
r
я к тому, что не могу придумать структуру которая бы позволяла неограниченно менять длинну
Это само собой, но into_raw/from_raw вообще не позволяет её менять.
r
хм, а почему такое ограничение? Звучит достаточно странно
Возможные проблемы при деаллокации Box<[u8]>, если его длина была изменена, скорее всего.
в🧇
red75prime
Возможные проблемы при деаллокации Box<[u8]>, если его длина была изменена, скорее всего.
а, там коробка...
Ну тогда да, видимо в этом дело
Ну тогда да, видимо в этом дело
в🧇
Ну т.е. это примерно проблема с вылезанием за аллокацию и есть, только тут ещё и меньше тоже нельзя т.к. длинна аллокации считается по первому нулю
2020 December 01
MK
IG
Наткнулся на такую странную проблему при сборке no_std пакета:
```
Compiling sp-io v2.0.0
error[E0152]: found duplicate lang item
|
1277 | pub fn panic(info: &core::panic::PanicInfo) -> ! {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: the lang item is first defined in crate
```
num_traits используется в proc-macro пакете только в кодогенерации. Разве импорты макросов могут как-то влиять на работу компилятора после препроцессинга?
```
Compiling sp-io v2.0.0
error[E0152]: found duplicate lang item
panic_impl
--> /Users/snjax/.cargo/registry/src/github.com-1ecc6299db9ec823/sp-io-2.0.0/src/lib.rs:1277:1|
1277 | pub fn panic(info: &core::panic::PanicInfo) -> ! {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: the lang item is first defined in crate
std (which num_traits depends on)```
num_traits используется в proc-macro пакете только в кодогенерации. Разве импорты макросов могут как-то влиять на работу компилятора после препроцессинга?
f
А есть какой-то удобный комбинатор для
?
У меня периодически Re
let a = match a {
Ok(a) => a,
Err(a) => a
}?
У меня периодически Re
sult<json::Value, json::Value>, интересно, есть ли что-то в std.K
.unwrap_or_else(std::convert::identity)