<esden[m]>
ahh yeah individually center them might work too.
<josHua[m]>
I seem to have a spare </div> there
<josHua[m]>
but the general idea is to make each one a row. if you want to be fancy you could like add `mb-2` or something to each `div class="row"` to give them a little room to breathe
<josHua[m]>
you could presumably also make that col-12 or something, there is no reason for it to be narrow
<esden[m]>
Ok yeah, makes "sense" ... 😄
<josHua[m]>
I dunno, I am pretty inexpert with this web shit. I also do not know how to make the navbar add to the bottom of the page rather than overlapping it
<josHua[m]>
"Fixed navbars use position: fixed, meaning they’re pulled from the normal flow of the DOM and may require custom CSS (e.g., padding-top on the <body>) to prevent overlap with other elements.", says the docs
<esden[m]>
URGH... did not notice that yet...
<esden[m]>
I could just leave it at the end of the content too... It looks bit jank but maybe a better of the all evils.
<esden[m]>
Yeah I think I will just do that and move on...
<q3k[cis]>
give it a background
<q3k[cis]>
same as the background colour of the page
<josHua[m]>
adding `bg-light` to the `<nav>` class indeed adds the background
<josHua[m]>
or bg-dark apparently
<esden[m]>
Yeah, but then it overlaps the content when using a small device. That would suck.
<josHua[m]>
yeah
<esden[m]>
I mean it hides the content.
<q3k[cis]>
then you by definition don't want a floating bar :)
<esden[m]>
Exactly.
<esden[m]>
What I want is something that sticks to the bottom of the page when there is space, otherwise not. But I guess I am asking for too much.
<q3k[cis]>
i know how to solve this with flexbox and plain css
<q3k[cis]>
but that wouldn't be the bootstrap way i guess :P
<esden[m]>
Yeah it is fine @q3k... I will just stick it in the main content and be done.
SnoopJ has quit [Quit: "Entropy always comes for its due, and that's what even lobsters must accept."]
SnoopJ has joined #glasgow
<SnoopJ>
.8b is configuring nick notes from plugins.conf working?
<SnoopJ>
…this is not the right buffer
redstarcomrade has quit [Read error: Connection reset by peer]
Guest46 has joined #glasgow
Guest46 has quit [Client Quit]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
mmerkel1 has joined #glasgow
mmerkel has quit [Read error: Connection reset by peer]
mmerkel1 is now known as mmerkel
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<nekrondev[m]>
esden (@_discord_269693955338141697:catircservices.org) I personally and job related use most often https://bulma.io/ which I can highly recommend... simply import the static compressed CSS file and annotate your common HTML elements using the Bulma classes... there you go for a fancy and modern UI experience... the CSS classes also work nicely with HTMX server-side rendered UIs or if you write your own web components.
redstarcomrade has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
<esden[m]>
nekrondev (@_discord_794302168014127154:catircservices.org) ohh neat! I will give it a try. (I do like the idea of HTMX, have not seriously used it yet)
<galibert[m]>
Nice evolution in the presentation. I'm afraid though, yesterday there needed to be 739 shipped before more, today it's 740..... if you need one more per day that's never going to stop :-)
notgull has joined #glasgow
notgull has quit [Ping timeout: 256 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
bvernoux has joined #glasgow
notgull has joined #glasgow
notgull has quit [Ping timeout: 268 seconds]
GNUmoon2 has quit [Ping timeout: 260 seconds]
GNUmoon2 has joined #glasgow
notgull has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
notgull has quit [Ping timeout: 268 seconds]
<esden[m]>
There is an explanation for that. We had a backer that had an outstanding $1 shipping adjustment fee on their order. And because of that the order was not in the CSV that CrowdSupply provides. They sorted it out yesterday, and got their spot back in the queue. This is why things shifted. I don't think this will be happening every day. 😄
<galibert[m]>
Oh fun
<galibert[m]>
I would never have guessed
redstarcomrade has quit [Read error: Connection reset by peer]
<josHua[m]>
well, uh, wtf, hmm
<josHua[m]>
despite that my order has my new shipping address in CrowdSupply, UPS appears to have delivered my package to my old address
<josHua[m]>
I will go try to retrieve it, but.......
<esden[m]>
Ugh... 😦 I hope you manage to retrieve it. I will mention the issue to CS.
<esden[m]>
josHua (@_discord_256468461818085377:catircservices.org) is that the 111784 order?
<josHua[m]>
it is
<esden[m]>
ok, that is useful so that they can track down what went wrong.
<josHua[m]>
429 N Rengstorff is correct, 217 Ortega was original
<esden[m]>
👍
Guest3 has joined #glasgow
Guest3 has quit [Client Quit]
redstarcomrade has joined #glasgow
bvernoux has quit [Quit: Leaving]
<esden[m]>
josHua (@_discord_256468461818085377:catircservices.org) I have reported the issue to CrowdSupply. If you have trouble getting the UPS order you should contact CS. (they told me their support is in a better shape now than it was the last few weeks and they should be able to respond faster)
<esden[m]>
CS is able to reroute packages sometimes if there is enough time.
<josHua[m]>
a glasgow has been recovered!
<esden[m]>
WOOHOO! 🙂
<whitequark[cis]1>
nice
<josHua[m]>
I guess I should have expected no less, but I appreciated the poka-yoke pocketing on the bottom case
Jonimus has joined #glasgow
<esden[m]>
josHua (@_discord_256468461818085377:catircservices.org) lol... that one was a hard learned lesson 😄
<esden[m]>
Fortunately I caught it before making thousands of them.
<josHua[m]>
which? the pocketing I was referring to was the fact that it is rotationally symmetrical, even though there is only one E-stop button
<esden[m]>
yeah, that is what I mean. earlier versions of the bottom case were not rotationally symmetric, and it was relatively easy to mount it so that you smoosh the e-stop button or even worse the GPIO pins...
<josHua[m]>
ahh
<josHua[m]>
I wondered what the 'do not overtighten' was about. that was the kind of warning that was written in tears and blood
<Jonimus>
Is there a way to have the glasgow emulate or pretend to be another USB device? I'd like to have it be an option for emulating an old proprietery communication cable that samples in the wild are slowly dying and ideally be able to use it with the original software but if that isn't possible implementing a minimal communication routines in python is doable.
<whitequark[cis]1>
so... there are two answers
<whitequark[cis]1>
technically: yes, the FX2 can do that. practically: you're completely on your own, the glasgow project relies on a vertically integrated stack of hardware and we can't afford to support more than our stock firmware
<josHua[m]>
well, and super-technically: something else on the host side can pretend to be a USB device
<Jonimus>
I was more curious if it was supported in the glasgow framework/project if not I have other ideas to play with.
<whitequark[cis]1>
it is not
<josHua[m]>
which is sort of what we were discussing yesterday: using ruthlessly unstable drivers to emulate USB devices from userspace
<whitequark[cis]1>
the FX2 is a chip based on a very old and quirky architecture and you need very specific skills to be productive with it
<Jonimus>
I was more brainstorming first projects and that just happened to be one of the first to come to mind.
<Jonimus>
I might still attempt that project, I would just have to also build in the ability to load the files that would be sent to the device but there are already libraries for that in python so not too worried there.
<whitequark[cis]1>
what kind of files?
<whitequark[cis]1>
oh the proprietary device you mean?
<Jonimus>
Eh I'll just spell it out, I wanted to replicate the I/0 link cable for non-usb ti calculators.
<Jonimus>
So I'd have to load the .8x* files (eg 83p for TI-83 programs) and then send the correct data to the calculator.
<Jonimus>
It would likely be doable as a partial web app like what the OPx emulation applet does now that I think about it.
<whitequark[cis]1>
what protocol does the cable use?
<josHua[m]>
I think the other question is 'what protocol does the cable speak over USB'
<Jonimus>
Oh its just bulk transfer bytes getting converted to the IO protocol.
<SophiaNya>
how do you make the glasgow boot with a voltage? aka i have a bitstream flashed but the pins don't do anything becuase it doesn't know what voltage to do anything at
<SophiaNya>
my goal is to have the glasgow run a bitstream without a laptop connected
<Jonimus>
Anyway don't worry about my questions now, I'll play with this later when I have more time, just brainstorming things to do with the new toy.
<whitequark[cis]1>
<SophiaNya> "how do you make the glasgow boot..." <- this isn't currently implemented
<whitequark[cis]1>
which makes the "flash bitstream" functionality useless
<whitequark[cis]1>
unfortunately due to reasons, extending the config block is kind of painful right now, I reserved 64 bytes early on and then ran out
<whitequark[cis]1>
i don't think we actually need the whole 16 byte bitstream ID field; I think we can make bitstream IDs 8-byte without sacrificing anything meaningful
<whitequark[cis]1>
this lets us eke out 8 bytes for other stuff, like boot voltage
Wanda[cis] has joined #glasgow
<Wanda[cis]>
we only need like ... 2 bytes or something, right?
<Wanda[cis]>
for the voltages
<whitequark[cis]1>
per port
<Wanda[cis]>
ohh, the voltage is u16
<Wanda[cis]>
I see
<whitequark[cis]1>
so it's like... increase API level, make sure that if you did already have a flashed bitstream it won't cause some random voltage to appear, reuse 4 of those 8 bytes for boot voltage
<Wanda[cis]>
tricky mess
<whitequark[cis]1>
we had worse
<whitequark[cis]1>
but yes
<whitequark[cis]1>
eventually we'll have to properly extend the configuration block, in a somehow backward compatible way
<whitequark[cis]1>
now that will be annoying
<josHua[m]>
I was going to suggest having a per-bitstream config header at the beginning of iCE flash, specified by flags (or the MSB of bitstream size; there are no >2GB iCE bitstreams)
<josHua[m]>
* iCE flash, with its presence specified by
<whitequark[cis]1>
i really do not want to branch on flags because that means we run out of firmware space earlier
<whitequark[cis]1>
we only have like two hundred code bytes left?
<josHua[m]>
hm, and host software and fx2 firmware are not guaranteed to be lockstep, right?
<whitequark[cis]1>
they are
<whitequark[cis]1>
we have a concept of "API level"
<whitequark[cis]1>
it's reported in the descriptors; we have 255 of them potentially
<whitequark[cis]1>
once
sigstoat[m] has joined #glasgow
<sigstoat[m]>
ah this all reminds me. does the mirror voltage option measure the voltage once and set accordingly, or does it track the voltage (in any fashion)?
<josHua[m]>
so in this case I guess you can not branch on flags by putting a header in ice firmware unconditionally (and check it against your api level)
cr1901 has quit [Read error: Connection reset by peer]
<whitequark[cis]1>
there are many obvious solutions to this
<sigstoat[m]>
thanks
<josHua[m]>
indeed.l
<josHua[m]>
* indeed.
<whitequark[cis]1>
what is missing however is the difficult work required to validate it
<Wanda[cis]>
... yeah
<josHua[m]>
typing into irc is easy, typing programs is moderately more difficult, typing programs that work is dramatically more difficult
<Wanda[cis]>
I'm not particularly knowledgable about the firmware part of the stack
<whitequark[cis]1>
typing programs that work at scale in a backwards compat way even more so
<Wanda[cis]>
I could look at it when sufficiently bored, but right now I am the opposite of bored
<josHua[m]>
(the problem leading to me shitposting is that I am in fact bored of the FreeRTOS driver crap that I am supposed to do right now, and have a new shiny toy on my desk, and would rather be playing with the toy than doing my work)
<whitequark[cis]1>
i do think that API level bump + shortening bitstream ID to 8 bytes (maybe even 4?.. 4 seems a bit low) is the way to go
<whitequark[cis]1>
then add a flag for "IO voltage fields are valid" for backwards compat in the flag field
cr1901 has joined #glasgow
<josHua[m]>
the problem I realize I was trying to avoid was 'fx2 mem is out of sync with current state of ice mem and drivers get programmed to unreasonable voltages for a given bitstream', but that can already happen (bitstream ID out of sync vs ice mem) so I guess putting it in that header is no better or worse
<whitequark[cis]1>
the thing with API levels is that the device isn't unconditionally reflashed
<whitequark[cis]1>
it is reloaded live with the bitstream for the latest API level
<whitequark[cis]1>
but on the next boot it can come up again with the old one
<whitequark[cis]1>
(also, upgrades and downgrades are treated exactly the same)
<whitequark[cis]1>
so it's not like a phone bootloader where the level always monotonically increases
jstein has quit [Remote host closed the connection]