<GrantM11235[m]>
<rjmp[m]> Hmm...I guess a non-const new could panic at least if they are wrong
<GrantM11235[m]>
You can panic in const fns now so it can be a compile time error
_whitelogger has joined #rust-embedded
n3t has quit [Server closed connection]
n3t has joined #rust-embedded
_whitelogger has joined #rust-embedded
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
Is there some way to force parts of the standard library into itcm? I'd prefer to not have to patch the libcore if possible. If not is there some issue related to this?
<i509vcb[m]>
For example like moving memcpy-like things to ITCM
<i509vcb[m]>
And on a slightly further extent, possibly moving specific functions from dependent libraries there
<thejpster[m]>
If you know the name of the object file the object code lives in, you can tell the linker to put it somewhere specific.
mkj[m] has joined #rust-embedded
<mkj[m]>
or make a linker wrapper script that objcopys stdlib inputs to have a different section then links with that?
<mkj[m]>
not sure how that'd work with LTO though (same as with thejpster's idea)
MovementNetwork[ has joined #rust-embedded
<MovementNetwork[>
<jason-kairos> Maybe if a mob of 50 or so embedded developers got together, they might be able to organize an effort to do something. Event if that something might be to complain to the cargo maintainers....
<diondokter[m]>
dcz[m]: I mean, the last commit is over 2 years old and it doesn't implement the embedded-hal 1.0 traits (judging from the open PR from 1.5 years ago that adds it)
<dcz[m]>
the master branch carries some nice improvements but last release was in 2021
<diondokter[m]>
I don't think anyone is maintaining it
<dcz[m]>
what would it take to change that? Find someone? step in?
<diondokter[m]>
Yeah
<diondokter[m]>
Fork it, update it, do some good work and probably you can be added to the main repo.
<diondokter[m]>
But I don't have any ownership in that project, so you'll have to find the people who do
<dcz[m]>
where's the best place to find those people? I was hoping someone would be hanging out here
<diondokter[m]>
A lot of people used to at least...
<diondokter[m]>
disasm is here, but I don't think I've seen him in a while. But maybe I'm wrong
<dcz[m]>
would it be helpful if I posted an issue in the wg repo
<diondokter[m]>
dcz[m]: To what end?
<dcz[m]>
perhaps the relevant people are more likely to read it than Matrix
<diondokter[m]>
That HAL is not active right now. Pinging people won't change that.
<diondokter[m]>
If you want to get added as a maintainer, usually people want to see some work and effort being done first.
<dcz[m]>
considering that the amount of work over the past years was close to 0, I think offering a new tested release is already an improvement
<dcz[m]>
reaching the people is still an open problem, if they don't look they won't see anything
<dcz[m]>
that's why I'm focusing on finding those people
<dngrs[m]>
I've recently been thinking about starting an embedded rust cookbook/wiki for common problems/tasks and corresponding solutions....
<JamesMunns[m]>
<dngrs[m]> I've recently been thinking about starting an embedded rust cookbook/wiki for common problems/tasks and corresponding solutions.......
<JamesMunns[m]>
thejpster started a wiki
<corecode[m]>
that would be great
<corecode[m]>
happy to add my limited experience
andar1an has quit [Quit: andar1an]
<dngrs[m]>
<JamesMunns[m]> thejpster started a wiki
<jannic[m]>
I won't make it to the meeting, again. Spontaneous decision to have a company dinner with colleagues from abroad.
wassasin[m] has joined #rust-embedded
<wassasin[m]>
If I have a workspace with an excluded cli app in the tree, how am I able to set a default target for the workspace, whilst keeping the target for the cli-app to "auto/host" (or however we call this?)
<adamgreig[m]>
public holiday yesterday in the uk so it feels like a monday but my computer tells me it is actually tuesday
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Element is flaky for me. 😕
<adamgreig[m]>
let's begin and hope element's not too annoying
ryankurte[m] has joined #rust-embedded
<ryankurte[m]>
adamgreig[m]: mine shows 6am on a wednesday... must be a bug
<adamgreig[m]>
first up, i509vcb, I can update the embedded-rust matrix space, is it just imxrt and mspm0 at the moment?
<adamgreig[m]>
this room is on version..... 5 😬
<i509vcb[m]>
Upgrading the room mid meeting is going to be kind of disruptive
<i509vcb[m]>
Let alone that upgrading is disruptive
<i509vcb[m]>
I don't know of other rooms, but I updated the mspm0 room and Tom upgraded imxrt
<adamgreig[m]>
upgrading is so disruptive, I'm not doing it now or any time soon I think
<adamgreig[m]>
so I'm on the embedded space but it already thinks the latest version of the rooms is there
<adamgreig[m]>
presumably it's wrong but... what
<i509vcb[m]>
Huh I guess it did migrate?
<i509vcb[m]>
Oh someone is editing the space currently
<adamgreig[m]>
I've removed both rooms from the space and re-added them, let's see if that helps
<i509vcb[m]>
Yup looks correct now
<adamgreig[m]>
great. solid UI there lol
<adamgreig[m]>
can't add the new rooms because the old rooms are there, they don't get automatically replaced, but I can delete the old rooms and then add the new rooms...
<adamgreig[m]>
anyway please let me know if any other embedded rust space changes are required
<i509vcb[m]>
Now the real fun comes with the other channels if they upgrade...
<adamgreig[m]>
next up, newam should we maybe remove deny(warnings) too?
newam[m] has joined #rust-embedded
<newam[m]>
I think that got removed in the unreleased changes too
<adamgreig[m]>
did anyone have further thoughts on the proposal so far?
<therealprof[m]>
Still have it open, just read the preamble.
<bartmassey[m]>
I think the time length and amount of technical debt in the general std build process makes it impossible for me to "catch up" with a reasonable amount of effort and make intelligent comments. So many weird moving parts…
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
it sounds really useful, but I haven't spent enough time going through it to provide more useful feedback
<adamgreig[m]>
just seemed like a nice time to bump the version number, semver is a bit weird for binaries anyway
<adamgreig[m]>
for build-std, my basic conclusion was "yay this will do what i want" but thejpster had a bunch of good more useful points/nitpicks too
<bartmassey[m]>
I just found an unrelated bug in cargo-objcopy in code I'm working on while we chat 😀. Will try to get an issue report and PR in today.
<adamgreig[m]>
haha ok, we'd better hold the release a minute then!
<therealprof[m]>
Too late.
<bartmassey[m]>
No, you should go ahead and release.
<bartmassey[m]>
It's really non-critical.
<adamgreig[m]>
we've waited years for this release, it can wait a tiny bit longer
<therealprof[m]>
Oh, you made it in time. 😄
<bartmassey[m]>
If you use cargo-objcopy to build a thing and there are linker errors, the build fails without reporting the errors. Meh.
<adamgreig[m]>
haha yea it turns out you can cancel merge queue and the binutils CI is kinda slow
<adamgreig[m]>
bartmassey: oh, that's just been fixed I think
<adamgreig[m]>
could you try from master?
<bartmassey[m]>
Oh. Will do!
<adamgreig[m]>
(in one of the PRs I just merged a minute ago)
<bartmassey[m]>
Yeah fixed. Sorry for false alarm.
<adamgreig[m]>
next thing on the agenda, if anyone in the arm team could have a look at https://github.com/rust-embedded/cortex-m/pull/606, I think that can be merged and I can do the second batch in a second PR then hopefully we can think about cutting 0.7.8 at last
<adamgreig[m]>
bartmassey[m]: sweet, on with the release!
<adamgreig[m]>
oh sigh, we need an updated lockfile too
<therealprof[m]>
On a lighter note: We're now officially not members of the Rust project anymore.
<adamgreig[m]>
ah, we're still members of the rust project, just they've cleaned the rust-lang github org to only people who are in teams that are inside that org
<adamgreig[m]>
unless you have other news
<ryankurte[m]>
oh i wondered about that too
<therealprof[m]>
Well, that and also they changed the homepage. We need to check whether there're any links pointing to the old governance page.
<dngrs[m]>
I looked at the signup criteria and personally find them too restrictive for a embedded Rust community wiki - requiring familiarity with Cortex-M excludes people only familiar with/interested in RISCV, also I'd prefer something world writable by default - I think Wikipedia has proven that this model can be hugely successful and resilient re: vandalism. Of course everyone is free to build their own spaces according to different
<dngrs[m]>
criteria but I suppose I'll set up my own thing then
<dngrs[m]>
* Cortex-M excludes e.g. people only
<dngrs[m]>
* I looked at the signup criteria and personally find them too restrictive for an embedded Rust community wiki - requiring familiarity with Cortex-M excludes e.g. people only familiar with/interested in RISCV, also I'd prefer something world writable by default - I think Wikipedia has proven that this model can be hugely successful and resilient re: vandalism. Of course everyone is free to build their own spaces according to different
<dngrs[m]>
criteria but I suppose I'll set up my own thing then
<dngrs[m]>
* I looked at the signup criteria and personally find them too restrictive for an embedded Rust community wiki - requiring familiarity with Cortex-M excludes e.g. people only familiar with/interested in RISCV, also I'd prefer something world writable by default: I think Wikipedia has proven that this model can be hugely successful and resilient re: vandalism. Of course everyone is free to build their own spaces according to different
<dngrs[m]>
criteria but I suppose I'll set up my own thing then
<dcz[m]>
how would I go about joining the RISC-V team?
<dcz[m]>
is there an interview? entrance exam :P?
<seds>
You can start by contributing with their open source stuff
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
<thejpster[m]>
dngrs: you can just mail me and ask for an account. It's fine.
<thejpster[m]>
The reason it isn't world writable like Wikipedia is because I don't have the editors Wikipedia has (and even then, Wikipedia editors work really hard keeping spam and filth off the platform). Rather than a sign up form, I thought I'd try and come up with something a spam bot couldn't easily pass.
<thejpster[m]>
Knowing about Cortex-M isn't a hard requirement. If you just told me "I don't like Arm" and "RISC-V is just better", that's a pass.
Darius has quit [Server closed connection]
Darius has joined #rust-embedded
<thejpster[m]>
<adamgreig[m]> next thing on the agenda, if anyone in the arm team could have a look at https://github.com/rust-embedded/cortex-m/pull/606, I think that can be merged and I can do the second batch in a second PR then hopefully we can think about cutting 0.7.8 at last
<thejpster[m]>
can you do a cargo semver-check on that PR?
norineko has quit [Server closed connection]
norineko has joined #rust-embedded
<adamgreig[m]>
<thejpster[m]> can you do a cargo semver-check on that PR?
<adamgreig[m]>
good idea
<adamgreig[m]>
can you run semver-checks with a cross-compiled target like thumb*?
<JamesMunns[m]>
adamgreig[m]: Yep!
<adamgreig[m]>
i've got three warnings from semver checks, one is because i made critical-section not an optional dependency which removed the "critical-section" feature, fixed by adding a dummy critical section feature that doesn't do anything (sigh)
<adamgreig[m]>
the other two are from things that are cfg(cortex-m) or cfg(not(cortex-m))
<adamgreig[m]>
which aren't serious but will go away if we have that cfg set appropriately
<JamesMunns[m]>
csc mostly just uses rustdoc json output
<adamgreig[m]>
how do you tell it which target then?
<adamgreig[m]>
doing --target thumbv7m-none-eabi just gives a bunch of errors and then fails to build rustdoc :/
<JamesMunns[m]>
Oh.
<JamesMunns[m]>
I misunderstood the actual intent
<adamgreig[m]>
it's currently checking there are no semver problems when building for a hosted platform but that's only medium useful :P
<JamesMunns[m]>
"In a project for a thumb* target" vs "specifically with that target selected because it affects conditional compile options"
<adamgreig[m]>
annoyingly it also complains if a repr(c) struct layout "changes"
<adamgreig[m]>
but it only checks the position of the fields in the struct definition, and not their position in the C memory layout that results
<adamgreig[m]>
so in this case we've split some padding in some cases to add a field in the middle which means the field indices have changed but the memory layout is identical