[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Réflexion sur l'infrastructure de la liste
|
From: |
Jean Abou Samra |
|
Subject: |
Re: Réflexion sur l'infrastructure de la liste |
|
Date: |
Wed, 28 Jun 2023 23:30:30 +0200 |
|
User-agent: |
Evolution 3.48.3 (3.48.3-1.fc38) |
Le mercredi 28 juin 2023 à 20:12 +0000, Ya Gloops a écrit :
Bonsoir Jean !
Pour ma part, j'avais été déçu du passage de Nabble à cette liste de diffusion, car j'utilisais un lecteur de flux RSS...
Maintenant je télécharge les archives en mbox format, ce qui n'est pas si mal finalement...
Donc, si Discours fait les deux je signe tout de suite...
On peut effectivement suivre un forum Discourse par RSS.
À ma connaissance, il n'y a pas d'interface pour télécharger les messages en mbox. Par contre, on peut choisir de recevoir des messages groupés. La liste permet de recevoir un message groupé par jour, Discourse permet de choisir entre un par jour, un par semaine, un par mois et un tous les 6 mois (exemple en pièce jointe).
Cordialement,
Jean
--- Begin Message ---
|
Subject: |
[Rust Internals] Summary |
|
Date: |
Fri, 19 May 2023 21:39:16 +0000 |
A brief summary since your last visit on May 12
|
![Rust Internals]()
|
|
|
|
Since your last visit
Popular Topics
|
![wwylele]()
|
Weiyi Wang
wwylele
|
![matthieum]()
|
Matthieu M
matthieum
|
|
If you already know about the Storage API, and its motivation, feel free to skip this section. The key idea of the Storage API is that the Allocator API is just not good enough for a variety of situations:
|
![Ayush1325]()
|
Ayush
Ayush1325
|
|
I have been working with Rust in embedded contexts for a while now. While I absolutely love the rust compiler and borrow checker, I am still not completely sold on Rust panics.
|
![fdasfe]()
|
fdasfe
|
|
One way to allow self-referential structs would be a new type UnsafeAlias, which allows a pointer and a mutable reference to overlap. The proposed api would be:
|
![stackinspector]()
|
stackinspector
|
pub struct ArrayStr<const N: usize> {
bytes: [u8; N],
}
impl<const N: usize> core::ops::Deref for ArrayStr<N> {
type Target = str;
fn deref(&self) -> &Self::Target {
unsafe { core::str::from_utf8_unchecked(&self.bytes) }
}
}
impl<const N: usize> core::ops::DerefMut for ArrayStr<N> {
fn deref_mut(&mut self) -> &mut Self::Target {
unsafe { core::str::from_utf8_unchecked_mut(&mut self.bytes) }
}
}
impl<const N: usize> TryFrom<&str> for ArrayStr<N> {
type Error = core::array::TryFromSliceError;
fn try_from(value: &str) -> Result<Self, Self::Error> {
Ok(ArrayStr { bytes: value.as_bytes().try_into()? })
}
}
|
|
|
|
Popular Posts
| |
|
(NOT A CONTRIBUTION) Yea, these are clearly two forces in tension in any project. But I feel very comfortable saying which of these forces the Rust project is too biased towards.
|
|
I agree with the general assessment that this might be the case, but nonetheless it would be interesting to find some concrete example of “algorithms(s) built on top of windows” to see whether this will actually handle edge cases of any reasonable, practical algorithms ![:slight_smile:]( ":slight_smile:")
|
|
Hypothetically if core/std had a mechanism like Cargo features (ala the std-aware Cargo work), one of the on-by-default features could be panic.
|
|
I would consider this one unacceptable, because to me one essential property of chunks is that .chunks(n).flatten() recovers the original. (And .chunks_exact(n).flatten() recovers the original other than potentially fewer than n missing from the end.)
|
|
(NOT A CONTRIBUTION) Anyway, I can't drive this idea any further than this thread. If anyone reading is excited by this idea, please do take it on.
|
|
|
New for you
|
|
|
--- End Message ---
signature.asc
Description: This is a digitally signed message part
Re: Réflexion sur l'infrastructure de la liste, Olivier Miakinen, 2023/06/28