<JamesMunns[m]>
scorpion2185 I don't think there are very many people actively working on the pinetime. You are probably the most active out of everyone right now.
<JamesMunns[m]>
The answer to your question is probably "yes", but I think you are unlikely to get people who have solved the issues you have questions about. You're the trailblazer here!
<JamesMunns[m]>
* the pinetime (in Rust, at least). You
<scorpion2185[m]1>
not sure to how use slint i need to see that repo
Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
<scorpion2185[m]1>
i am quite the newbie
<scorpion2185[m]1>
i updated probe-rs and now pinetime-rs does not build
<scorpion2185[m]1>
error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait
<scorpion2185[m]1>
Error Failed to run cargo build: exit code = Some(101).
<scorpion2185[m]1>
i removed slint but it does not build anyway
<JamesMunns[m]>
does cargo build --release give you better output?
<igiona[m]>
<scorpion2185[m]1> "not sure to how use slint i need..." <- It's quite straight forward and the slint doc has a nice embedded MCU example you can look at.
<adamgreig[m]>
eating crisps at my desk lol, it's been a long week
<JamesMunns[m]>
misc official announcement for wg members: if you think you might attend the all-hands, and haven't RSVP'd yet, please send me a DM so I can put you in touch with Mara!
<JamesMunns[m]>
I don't think there have been a ton of RSVPs from the WG, and it would be a shame to not have y'all there!
<adamgreig[m]>
can I check if I RSVPd? I think I did...
<JamesMunns[m]>
I'll check Mara's list while the meeting is going
<adamgreig[m]>
one announcement from me is the same: rust all-hands is happening at RustWeek in Utrecht, May 13-17, and will have an unconf with space for the embedded wg, like this year
<adamgreig[m]>
I think the unconf and the all-hands essentially overlap
<adamgreig[m]>
or are perhaps the exact same thing; in any event the embedded wg will be having another meeting there
<JamesMunns[m]>
adamgreig[m]: you're on the RSVP list
<therealprof[m]>
James Munns: Is there a song about it, too? 🤣
<adamgreig[m]>
the other announcement from me is that we'll have our usual two weeks off for the next two weeks, so the next meeting will be Jan 7th 2025
<therealprof[m]>
thejpster[m]: LOL, somehow I read reballed and got confused for a second.
<adamgreig[m]>
lead-free defmt
<JamesMunns[m]>
therealprof[m]: at some point we should discuss the plan for the WG in the meeting. I'm talking to the more idle groups right now, but I'll come back around to wg-embedded at some point
<adamgreig[m]>
Jack's reply seemed sensible to me but I'm not sure how it translates into any particular action
<adamgreig[m]>
I've not got any other announcements and there's not currently anything else on the agenda, so I'm open to suggestions
<JamesMunns[m]>
I guess does anyone have any objections to me EOL'ing the Rust Embedded Twitter? I haven't been using twitter for a while, which means I'm not really maintaining it
<JamesMunns[m]>
I don't plan to close the acct, but I can post a "not monitored" notice or something.
<adamgreig[m]>
fine with me, would you signpost any other locations?
<adamgreig[m]>
rip cohost
<JamesMunns[m]>
adamgreig[m]: I'm not sure if we have anywhere else to signpost
<JamesMunns[m]>
we can make a bsky account if we want, I'm not super excited about being the only one who runs it, would be happy to do so with another person or two :)
<JamesMunns[m]>
(there are some active rust/embedded/rust+embedded circles on bsky)
<adamgreig[m]>
there's a lot of embedded and rust people over on bsky, but I'm probably not the person to actually run an account
<therealprof[m]>
adamgreig[m]: Same here, I think the threefold explanation of what we do is accurate. But since terms like "the Project" are equally loosely defined I can't really figure out what that means. Also it's not exactly that we have declared that we wanted to be a WG (at least as far as my recollection of the early days(TM) goes) but that was a stamp put on by "the Project".
<adamgreig[m]>
wouldn't mind sharing though
esden[cis] has joined #rust-embedded
<esden[cis]>
+1 to bsky rust embedded account. Would be nice to follow and engage with. :)
<adamgreig[m]>
does bsky have any way to share accounts besides sharing the password?
<JamesMunns[m]>
adamgreig[m]: I could make app passwords for people, which you can use to log in
<therealprof[m]>
Oh hey, Piotr. 👋
<esden[cis]>
therealprof: 👋:)
<JamesMunns[m]>
it's not quite all the way to permission scoping, but does separate "main" passwords from "sub" passwords
<adamgreig[m]>
oh, I guess that would work OK. I'm also happy to set it up if you don't care to
<therealprof[m]>
My stance on social media hasn't change, the only one I'm willing to engage in is "the bar".
<therealprof[m]>
s/change/changed/
<JamesMunns[m]>
adamgreig[m]: either works! Do we have a third maybe who is active on bsky that would want to lend a hand?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
<JamesMunns[m]> "I'll check Mara's list while the..." <- I also think I have RSVPed but am uncertain. Am definitely planning to go.
<adamgreig[m]>
👀
<adamgreig[m]>
maybe they'll show up later...
<JamesMunns[m]>
bartmassey[m]: I don't see you on the "haven't rsvp'd" list, so you should be good :)
<adamgreig[m]>
well, in the meantime shall we set one up?
<bartmassey[m]>
The other obv place is Mastodon, maybe?
<adamgreig[m]>
yep! we did talk about a mastodon acct a while back but no one ended up setting it up iirc
<adamgreig[m]>
<therealprof[m]> "Same here, I think the threefold..." <- yea... but I think efforts are being made to put more strict definitions on things
<bartmassey[m]>
I'm not much of a Mastodon, but would be happy to help someone who was…
<esden[cis]>
SBTW, not sure what the responsibilities are regarding those social accounts. But I am pretty active on both fediverse and bluesky. And I am happy to help with those rust embedded accounts.
<therealprof[m]>
adamgreig[m]: Fair, but I'd have to check that first before figuring out what that might imply. 😉
<JamesMunns[m]>
adamgreig[m]: yeah, the goal of that issue is generally to close subteams under the Launching Pad, and that includes "legacy" working groups. So the general plan is "find a home in the project or make it more clear we are no longer officially affiliated with the Project"
<esden[cis]>
esden[cis]: But I guess I am not active enough in rust embedded to be of any use. (I am just a user so far :D)
<bartmassey[m]>
Idk mygnu but if they're still interested I'd be happy to help. I don't think "just a user" is any kind of disqualification — a lot of it is just being a POC I think?
<adamgreig[m]>
JamesMunns[m]: do you think any of the other LP teams might provide a template for what we might do, or does it seem like we're too different and probably need to think about something from scratch?
<adamgreig[m]>
bartmassey[m]: yea, and mostly just reposting interesting rust embedded content!
<JamesMunns[m]>
adamgreig[m]: we're a weird one, for sure.
<adamgreig[m]>
we discussed codifying a bit what would get RT'd and things like when to RT job adverts and how often and so forth but the conversation didn't reach a firm conclusion
<adamgreig[m]>
so no good reasons to kick us off but also not clear where to put us, huh
<adamgreig[m]>
same story as last time
<JamesMunns[m]>
ehhhhh?
<JamesMunns[m]>
the main thing is "we don't build things part of 'the project', e.g. the stdlib, compiler, cargo, etc."
<adamgreig[m]>
I think jack's right that we could have an outside-of-project but centralised space to meet, but maybe unlike him I think that the people involved in that should probably be the ones maintaining those crates he mentioned maybe wanting to be part of The Project
<JamesMunns[m]>
so, there are some arguments that our charter is more that of a "user group", than "part of the Rust Language".
<adamgreig[m]>
but unlike most user groups, we also do maintain a bunch of "standard" crates for embedded work, which could become part of the project if its remit included things outside of the stdlib
<adamgreig[m]>
and it seems weird to split the maintainers of those crates from the people doing "advocacy inside the project for things useful for embedded" and perhaps "running the centralised discussion/meeting space"?
<adamgreig[m]>
I mean, still, I totally see the point of view, it's true we have extremely little involvement in the compiler or stdlib
<adamgreig[m]>
so... ???
<therealprof[m]>
adamgreig[m]: We had quite a bit of involvement in the discussions that lead to the split into core/alloc/std in the early days.
<therealprof[m]>
therealprof[m]: It's just that we weren't the ones to implement most of it.
<adamgreig[m]>
yea, many years ago, but since then...
<adamgreig[m]>
at that time more rewg people were also involved in rust-lang teams, too
<therealprof[m]>
adamgreig[m]: I can certainly see a lot of ideas that were discussed at various meeting with e.g. Amanieu implemented now.
<therealprof[m]>
... or worked towards.
<adamgreig[m]>
right, but that's still stuff from years ago, and the conversation is about what people are doing now
<JamesMunns[m]>
<adamgreig[m]> "but unlike most user groups..." <- yep, making a case for an embedded subteam for libs, etc., are an option on the table
<JamesMunns[m]>
<adamgreig[m]> "and it seems weird to split..." <- yeah, this is the thing I struggle with too, not sure how to address it
<adamgreig[m]>
I think as well from our point of view being a working group seems to work fine, so if the project could have a "working groups team" that has working groups shaped like ours, that would suit us fine
<adamgreig[m]>
the main incentive for us to change is because the project apparently wants us to, I think? not because we feel like it would work better for us
<JamesMunns[m]>
adamgreig[m]: the issue with this is we're kind of the only one :D
<therealprof[m]>
adamgreig[m]: I still do believe that our inputs are driving some of the decisions made in other teams, so not quite sure what has changed or why the exact involvement matters.
<bartmassey[m]>
Is it a problem that we are the only one? Why not just let us keep being the Embedded Working Group, a unique piece of the ecosystem?
<JamesMunns[m]>
JamesMunns[m]: there are other groups SORT OF like us, but they came along later and not part of the project. "Rust in the Linux Kernel" is an example or the "Rust for GUI" folks
<JamesMunns[m]>
JamesMunns[m]: I have proposed having an "advocacy" group, as sort of a "community bridge between the project and the ecosystem".
<therealprof[m]>
adamgreig[m]: We've been trying to convince "the Project" for years to include us more or at least in a better way than having a WG that really has no connection to the project. Now the roles have switched.
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
I could certainly see being involved in core/alloc/std making sense to have a grasp on things like code size, but I don't necessarily speak for either Rust embedded or Rust
<adamgreig[m]>
it would make some sense, but people in the wg are basically working on wg projects, and if someone was interested in working on stdlib stuff, I think they'd mostly (also) join the libs team or something like that
<JamesMunns[m]>
also, to make it clear, there is no huge urgent push to kick the embedded-wg (or any other wg/team) out.
<adamgreig[m]>
from a practical point of view, we've ended up with a wg of people working on wg projects
<JamesMunns[m]>
When the council was formed, the Launching Pad was intended to be "for now"
<adamgreig[m]>
so I don't know that we could really swap it to being people working on rust-lang stuff without it being just a different set of people
<JamesMunns[m]>
the goal was to eventually re-org/find home/define new steady-state. And it's been a while now, and I'm trying to slowly make some progress. But there's no deadline
<JamesMunns[m]>
s/home/homes/
<JamesMunns[m]>
therealprof[m]: The goal is actually to RESOLVE this tension, one way or the other. There isn't a strong mandate "the wg must go", just "we should finally figure out what the plan is"
<JamesMunns[m]>
<bartmassey[m]> "Is it a problem that we are..." <- the balance is:
<JamesMunns[m]>
* being a project team has some benefits to it, like qualifying for funding from the foundation, access to infra, etc.
<JamesMunns[m]>
* if an exception is made for the embedded-wg, then the question is "why not other groups"? just because we were "grandfathered in"?
<therealprof[m]>
JamesMunns[m]: Agree, but that's exactly my issue. For years no one cared but now it's our job to figure it out in a way that makes the project happy so they won't kick us out (for whatever that actually means, other than not being mentioned on the Rust homepage anymore).
<JamesMunns[m]>
therealprof[m]: I mean it is my job, for sure. I'm the council rep for the launching pad, and the job of the launching pad is to empty the launching pad
<JamesMunns[m]>
but i'm not telling ANY of the groups what they must do, just to advocate for them and work with them to find something that makes sense.
<bartmassey[m]>
> for whatever that actually means, other than not being mentioned on the Rust homepage anymore
<therealprof[m]>
Gotta run for now, will check in later.
<bartmassey[m]>
Well for example, would we be invited to the All Hands if we weren't currently part of some official WG?
<bartmassey[m]>
Because it sure feels like we should be there in 2026 or whenever it's held next as well.
<JamesMunns[m]>
bartmassey[m]: not as part of the project. There are side "invited groups" (like RfL, gui), but not as part of the project.
<adamgreig[m]>
but in practice so far we've been invited to the unconf regardless of project status, which is the same as all hands in '25
<JamesMunns[m]>
adamgreig[m]: yes, with a little bit of arguing and at the discretion of the organizers
<adamgreig[m]>
so I guess that's another way it's a bit tricky: it's not immediately clear what we get from being part of The Project apart from the authenticity that comes from association
<bartmassey[m]>
My 2¢ is that the best plan for the Launchpad would be to give it a more permanent name, keep at least us and RfL and probably the GUI folks and anybody else who's willing to do the procedural things that the Project requires, and just go on from there. I'm not sure why the Project would want to officially distance themselves from good help in any way.
<bartmassey[m]>
But I'm probably missing something.
<adamgreig[m]>
we don't meaningfully use any rust-lang infra, we don't have any special access to teams that anyone else wouldn't have
<adamgreig[m]>
hmm, there is the foundation grants and things like that
<adamgreig[m]>
and embedded people have benefited from them in the past, certainly
<JamesMunns[m]>
adamgreig[m]: we do use the team infra
<JamesMunns[m]>
JamesMunns[m]: e.g. permissioning, etc.
<adamgreig[m]>
bartmassey[m]: afaik the RfL project is totally distinct from rust-lang, unlike us
<adamgreig[m]>
we do, but I'm not sure about "meaningfully"
<adamgreig[m]>
we already manually add everyone to the duplicate teams in the gh org
<adamgreig[m]>
so the teams infra mainly serves to make sure people are listed on the rust-lang webpage
<adamgreig[m]>
we could use the teams infra more usefully 😅 but we'd be fine withou tit
<adamgreig[m]>
s/withou/without/, s/tit/it/
<bartmassey[m]>
Ah, misunderstood. So I'd revise my plan to bring those orgs into the renamed Launchpad, if they want in and are willing to deal with the terms.
<JamesMunns[m]>
bartmassey[m]: then the impetus to that is defining what that overarching team is, what it does, and get that approved as an RFC, with embedded being a subteam of that group
<JamesMunns[m]>
I am not against that plan!
<bartmassey[m]>
It just feels like having some of Rust's most visible public representatives be administratively third-party is an unusual idea and not a great one.
<JamesMunns[m]>
I don't know how to draw that line between "it makes sense in the project" vs say, "the tokio ecosystem", for example
<bartmassey[m]>
Alright. Let's try to put together an RFC for a "Launchpad NG" but with a much better name?
<adamgreig[m]>
yea, true, what's the distinction? tokio could well consider themselves the rewg of async
<adamgreig[m]>
perhaps one distinction is they have competitors, but there are plenty of embedded rust users totally outside our bubble too
<adamgreig[m]>
so maybe the difference is that we are trying to create portable, standard, useful-by-anyone things like e-h and the arch crates, where tokio is all its own thing?
<JamesMunns[m]>
JamesMunns[m]: the issue to this is, "where do you draw the line of where it makes sense to be a member of that top level team", vs "the ecosystem as a whole"
<bartmassey[m]>
I guess the distinction is topic-based vs solution based? The groups we are considering as candidates all are focusing on a topic. I think there could and should be an async group as part of this, and if it happens to be mostly tokio people then, well, ok, but it should be about async not specifically tokio.
<JamesMunns[m]>
there is a wg-async, BUT it's focused on implementing async *in the compiler and stdlib*, not "in userspace" or "in the community"
<adamgreig[m]>
right, which makes it a much more obvious fit for "inside the project"
<adamgreig[m]>
and if rewg mostly focused on working on rustc and stdlib to ensure it's good for embedded users, we'd be in a similar position
<bartmassey[m]>
Which is a rough distinction when 1/4 of the ecosystem is in the compiler and stdlib, and the other 3/4 is outside.
<bartmassey[m]>
I don't think we're necessarily saying any of these groups need to be part of the compiler or stdlib: providing homes for that is kind of the point of Launchpad NG. (Somebody please suggest a better name.)
<JamesMunns[m]>
bartmassey[m]: I mean, the point of this is defining what that team is, or what it does.
<bartmassey[m]>
Fair.
<JamesMunns[m]>
we can make the container, but we need to define what that container is, or what it does. Because that goes towards making the point of why it should be part of the project, rather than outside of the project.
<bartmassey[m]>
Offhand I would say that it's about providing "official" support, for some value of official, around topics in the Rust ecosystem outside of the core Project. Iow, it should be part of the "Project" writ large, and the vision for the Project can include LPNG as a team without causing themselves any grief? But I want to go off and think about it more for sure.
<JamesMunns[m]>
bartmassey[m]: yeah, I guess if you can think of a clear line where you say "it makes sense for this group to be in LPNG, and it doesn't for this group for these reasons", then I think that would help.
<bartmassey[m]>
Yeah, let's start by working on a story a bit before we put something out there.
<JamesMunns[m]>
or even, "what do we want for/from LPNG", that would be good too :)
<bartmassey[m]>
I agree that it's hard to make that line clear, but I also think we may all have a pretty similar feel for what would be in or out.
<bartmassey[m]>
Let's think about that.
<adamgreig[m]>
and a name before lpng sticks 😅
<JamesMunns[m]>
> we may all have a pretty similar feel for what would be in or out
<JamesMunns[m]>
I'm less certain if this, but that's what the discussion is for :)
<JamesMunns[m]>
adamgreig[m]: the "low pressure natural gas" team
<bartmassey[m]>
What we want is for/from LPNG is easier: official recognition from the Project/Foundation/whatever helps the teams in LPNG, the LPNG teams help the Rust ecosystem.
<JamesMunns[m]>
s/if/of/
<bartmassey[m]>
I was thinking Low Pressure Natural Gas too. Sigh.
<JamesMunns[m]>
bartmassey[m]: "recognition of what"?
<bartmassey[m]>
Recognition of their leadership and expertise, I guess? Eligibility for funding and participation in governance in some way?
<bartmassey[m]>
It's definitely easier to talk to the press, for example, when we can qualify ourselves as some "official" Rust thing than it would be if we were just "some Rust folks".
<JamesMunns[m]>
I think it benefits us, the rewg, for sure!
<JamesMunns[m]>
I don't know how it benefits the project, for example. The project does already have informal "ping groups" for recognized experts or interested parties, but those aren't "part of the project", more "a handy list of people we can notify on github"
<bartmassey[m]>
Yeah, the "ping groups" thing is the kind of thing that's been political trouble for the Project in the past. An official open process is always better than some informal clique for this kind of thing.
<JamesMunns[m]>
I'm being a little argumentative, I do still want to figure out the right thing here, and I think there is some benefit to this.
<JamesMunns[m]>
But I want to push back about "just call it done", because I don't think that's the desire of the project or the wgs, honestly.
<bartmassey[m]>
The biggest benefit to the Project, I think, is that it gets Rust recognized as more than just a compiler and a library: it's an ecosystem of officially-connected expertise
<JamesMunns[m]>
I am strongly against the position of "just yeet the whole LP" as well :)
<JamesMunns[m]>
yep, but the project has to define the limit's to ITS charter at some point as well.
<adamgreig[m]>
I think we're out of time for this week but it's been a productive chat, thanks everyone!
<JamesMunns[m]>
yeah, I gotta run out the door now. Thank you all!
<JamesMunns[m]>
s/limit's/limits/
<adamgreig[m]>
have a great break everyone, see you in three weeks!
<bartmassey[m]>
Thanks everyone! Happy Holidays!
bogdan[m] has quit [Quit: Idle timeout reached: 172800s]
<scorpion2185[m]1>
is there a way to convert u8 to string without extern crate alloc; ?
<JamesMunns[m]>
core::str::from_utf8, for a borrowed str, if you need specifically `String`, that has to come from alloc
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]