<whitequark>
the reason i'm skeptical about that claim specifically is that well
<whitequark>
any argument that goes against things like delivery services first of all disadvantages disabled and poor (owning a car is expensive!) people
AndresNavarro has quit [Quit: rcirc on GNU Emacs 25.2.1]
<whitequark>
so there's a lot of incentive to publish bullshit about it
<cr1901_modern>
I don't remember the paper I heard this from... googling "grocery delivery effect on environment" gives mixed results as to whether its good or bad.
<cr1901_modern>
And I think grocery delivery is a good thing for disabled/poor people too!
<whitequark>
jevons paradox would cleanly apply if people bought more groceries as a result
<cr1901_modern>
The utility function for groceries is likely a cliff
<whitequark>
more enough to like, offset fuel savings
<whitequark>
this is absurd
<TD-Linux>
people burning co2 in their free time is a separable problem and it seems pointless to try to conflate the two into one result
<whitequark>
yes
<whitequark>
also
<whitequark>
that problem is solved by not having office workers commute
<cr1901_modern>
likely a cliff (as in "once you have enough groceries, there isn't much marginal utility at all")
<cr1901_modern>
right, I could get behind that one too :P
<whitequark>
gasoline transportation on light duty vehicles in the US in 2017 is about 650 GW
<whitequark>
well
<whitequark>
20.5 EJ
<whitequark>
i have the numbers in gigawatts to compare them to cryptocurrencies
<whitequark>
(Ethereum is about 1.5 GW)
<TD-Linux>
GWh?
<whitequark>
no, GW.
<cr1901_modern>
What is EJ?
<whitequark>
exajourle.
<whitequark>
*exajoule
<Ultrasauce>
i would imagine with grocery delivery people actually end up buying less
<cr1901_modern>
wow ._.
<TD-Linux>
ah just a continuous burn
<whitequark>
that's uhhhh
<whitequark>
5.7 PWh
<Ultrasauce>
because storefronts are extremely effective marketing instruments and also people would buy smaller batches and suffer less spoilage
<TD-Linux>
yeah transportation is just ridiculous
<whitequark>
petawatt hours
<whitequark>
which is a stupid unit, watt hours should die
<whitequark>
just fucking use joules
<whitequark>
00:09 < Ultrasauce> i would imagine with grocery delivery people actually end up buying less
<whitequark>
yes of course
<TD-Linux>
will fite you on that one
<whitequark>
and possibly healthier food as well
<whitequark>
though that's debatable
<whitequark>
TD-Linux: watt hours are useful for exactly one thing, figuring out how much your kettle costs you
<whitequark>
just like fahrenheit is only useful for a kitchen thermometer
<whitequark>
celsius or kelvin and joule is useful for, well, the rest of human interaction with technology
<TD-Linux>
they are super useful for battery capacity estimation
<whitequark>
yeah, use watt seconds. i mean watts.
<whitequark>
*i mean joules
<cr1901_modern>
Fahrenheit is also useful for having nice round numbers for "really cold" and "really hot" :P (this is a shitpost)
<TD-Linux>
unrelated is there a good calculator program that has unit support
<cr1901_modern>
as opposed to "mild cold" and "dead" for Celsius and "dead" and "dead" for Kelvin
<whitequark>
TD-Linux: cargo install rink
<cr1901_modern>
TD-Linux: rink.rs
<whitequark>
it's like gnu units but better
<TD-Linux>
installing it now thanks
<TD-Linux>
nice my car contains 205MJ
<cr1901_modern>
I don't think you can define your own units in rink yet (that last beyond one calculation)
<TD-Linux>
that's okay, I wanted a predefined toolkit of units
<whitequark>
yeah, that's a pity
<whitequark>
i really like one feature of rink i requested
<whitequark>
try:
<whitequark>
> molar_mass of C5H10
<whitequark>
give it any gross formula and it calculates.
<whitequark>
i can't believe i used to do that shit by hand in high school *and* still remember many atomic masses
<TD-Linux>
I just typed in "H2O" and wow
<cr1901_modern>
6 million billion billion "things"
<whitequark>
specifc heat being in grays per kelvin amuses me
<TD-Linux>
bit sad that this doesn't work
<TD-Linux>
(H2O*10degC)-(H2O*0degC)
<TD-Linux>
Operation is not defined: <283.15 kelvin (temperature; K) water> - <273.15 kelvin (temperature; K) water>
<Ultrasauce>
i was just going to question that
<whitequark>
what are you even trying to do
<whitequark>
Ultrasauce: it's a bug in canonicalization code
yhetti has quit [Read error: Connection reset by peer]
<whitequark>
gray is J/kg
mossmann has quit [Read error: Connection reset by peer]
<Ultrasauce>
yeah i mean the unit analysis fits there's just semantics
yhetti has joined ##openfpga
<whitequark>
> specific_energy
<whitequark>
Definition: specific_energy = energy / mass = 1 gray (specific_energy; m^2 / s^2)
<whitequark>
this is really cool imo
mossmann has joined ##openfpga
<Ultrasauce>
i forgot it's a relatively pure unit though and not with an arbitrary absorption coefficient like rad
Ekho has quit [Quit: An alternate universe was just created where I didn't leave. But here, I left you. I'm sorry.]
<TD-Linux>
aha got it to work with enough casting
<TD-Linux>
((specific_energy of (H2O*10degC))-(specific_energy of (H2O*0degC))) * 1 kg in J
<TD-Linux>
41868 joule (energy)
<cr1901_modern>
why'd didn't you just multiply the specific heat of water by 10 :P?
<TD-Linux>
I was originally hoping it would figure out I wanted the specific_energy
<whitequark>
is that even right?
<TD-Linux>
I dunno
<whitequark>
> specific_heat of H2O * 10 degC * 1 kg
<whitequark>
approx. 1.185492 megajoule (energy)
<TD-Linux>
but turns out that water*temperature can also yield "temperature of water"
<cr1901_modern>
whitequark: huh
<cr1901_modern>
well I was guessing
<whitequark>
wait
<whitequark>
what
<whitequark>
> specific_heat of H2O * 1 kg * 10 K
<whitequark>
41.868 kilojoule (energy)
<whitequark>
> specific_heat of H2O * 1 kg * 10 degC
<whitequark>
approx. 1.185492 megajoule (energy)
<TD-Linux>
1 megajoule sounds wrong
<cr1901_modern>
because specific heat of water is 4.186 J/g
<whitequark>
ohhhhhh
<whitequark>
> 10 degC
<whitequark>
283.15 kelvin (temperature)
lexano has quit [Ping timeout: 245 seconds]
<TD-Linux>
yeah that's why I had to subtract
<whitequark>
> furlong/fortnight
<whitequark>
approx. 0.0001663095 meter / second (velocity)
<cr1901_modern>
Ahh okay, my units were off but the "4.186" was the important part
<Ultrasauce>
also isnt it friggin nonlinear
<cr1901_modern>
specific heat? Dunno. I'm assuming it doesn't matter for 10deg difference
<cr1901_modern>
sphere cow etc
<whitequark>
i usually use 4200 J/kg
<whitequark>
easier to do in your head
lexano has joined ##openfpga
<cr1901_modern>
I kinda want to do that experiment w/ the paddles in water and weight to calculate the specific heat of water
Maya-sama is now known as Miyu
Ekho has joined ##openfpga
zino has quit [Quit: Leaving]
zino has joined ##openfpga
<Ultrasauce>
one wikihole later I have determined that It's Complicated and stp is sufficiently far above the knee in the curve that it doesnt matter too much. and there are three separate models giving decent accuracy at different temperature ranges
<Ultrasauce>
and liquids are beyond the comprehension of humanity
<Ultrasauce>
all these tables floating around with five significant figures should be legally mandated to have a shrug emoji in the header
azonenberg_work has quit [Ping timeout: 245 seconds]
<sorear>
PWh >>> quads
<cr1901_modern>
triangle strips >>> quads
<Ultrasauce>
deltoids
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 255 seconds]
Flea86 has joined ##openfpga
azonenberg_work has joined ##openfpga
ym has quit [Ping timeout: 246 seconds]
ym has joined ##openfpga
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
dj_pi has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
<sorear>
I should look up sometime how jet aircraft compare to HSR within the context of a fossil fuel economy. Jets have a significant advantage from the thinner air…
<sorear>
When we’ve moved to PV+batteries+nuclear HSR will have a significant edge because wired energy transfer is >90% efficient and chemical isn’t
<sorear>
Aircraft with onboard nuclear power sources for the turbofan shafts are a theoretical possibility but aviation security is bad enough now :(
<whitequark>
forget security
<whitequark>
one crash and uh no
<Flea86>
sorear: Dunno, aircraft safety is actually pretty darn good - except for uncontained engine failures, those still present a serious problem imho and going nuke would be.. well we're not ready for that yet I think
<Flea86>
}:A
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
m_w_ has joined ##openfpga
m_w_ has quit [Client Quit]
m_w_ has joined ##openfpga
m_w_ has quit [Client Quit]
m_w_ has joined ##openfpga
emeb has left ##openfpga [##openfpga]
rohitksingh has joined ##openfpga
m_w_ has quit [Quit: leaving]
m_w_ has joined ##openfpga
emeb_mac has joined ##openfpga
Bob_Dole has quit [Ping timeout: 252 seconds]
<catplant>
sorear: doesn't HSR have greater capacity than a jet?
<catplant>
so the fuel per passenger-km may be offset by that
<sorear>
maybe, but every jet I've been on has had empty seats
<catplant>
0.o
<catplant>
that would just tip it further towards HSR?
futarisIRCcloud has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
CounterPillow has quit [Quit: No Ping reply in 180 seconds.]
CounterPillow has joined ##openfpga
rohitksingh_work has joined ##openfpga
dj_pi has quit [Ping timeout: 255 seconds]
Bob_Dole has joined ##openfpga
s_frit has quit [*.net *.split]
keesj has quit [*.net *.split]
somlo has quit [*.net *.split]
oeuf has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
cnomad has quit [*.net *.split]
cpresser has quit [*.net *.split]
Stary has quit [*.net *.split]
horizon has quit [*.net *.split]
jn__ has quit [*.net *.split]
mwk has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
laintoo has quit [*.net *.split]
brizzo has quit [*.net *.split]
cyrozap has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
Bike has quit [Quit: Lost terminal]
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 245 seconds]
laintoo has joined ##openfpga
jn__ has joined ##openfpga
horizon has joined ##openfpga
mwk has joined ##openfpga
kristianpaul has joined ##openfpga
Lord_Nightmare has joined ##openfpga
brizzo has joined ##openfpga
oeuf has joined ##openfpga
Stary has joined ##openfpga
s_frit has joined ##openfpga
keesj has joined ##openfpga
cpresser has joined ##openfpga
cnomad has joined ##openfpga
somlo has joined ##openfpga
RaYmAn has joined ##openfpga
cyrozap has joined ##openfpga
Zorix has quit [Ping timeout: 252 seconds]
Zorix has joined ##openfpga
m_w_ has quit [Quit: leaving]
m_w has joined ##openfpga
Bob_Dole has quit [Ping timeout: 252 seconds]
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
m_w has quit [Ping timeout: 240 seconds]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
rohitksingh_work has quit [Ping timeout: 255 seconds]
rohitksingh_work has joined ##openfpga
Bob_Dole has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 244 seconds]
m4ssi has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
emeb_mac has quit [Ping timeout: 240 seconds]
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 244 seconds]
Bob_Dole has quit [Ping timeout: 252 seconds]
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
Marex has quit [Ping timeout: 259 seconds]
Marex has joined ##openfpga
Bob_Dole has joined ##openfpga
Marex has quit [Client Quit]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
Marex has joined ##openfpga
_whitelogger has joined ##openfpga
<_whitenotifier>
[Boneless-CPU] zignig synchronize pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxmz
azonenberg_work has quit [Ping timeout: 255 seconds]
azonenberg_work has joined ##openfpga
<somlo>
I use screen on linux with a bunch of SoC designs (lowRISC, LiteX, the various versa_ecp5 examples from prjtrellis) and I noticed that, invariably, the "firmware" programs tend to use '\n' only for newlines, which ends up looking weird on the terminal (but ends up looking fine if logged with e.g. 'script'). Then, once Linux starts booting, on e.g. LowRISC, it uses '\n\r' and terminal output looks fine (but I have to run 'dos2unix' on anything I
<somlo>
capture with 'script')...
<somlo>
any idea why it's common practice to use just '\n' in bare-metal firmware programs?
m_w has joined ##openfpga
<catplant>
just '\n' is common practice for basicall everything
dj_pi has joined ##openfpga
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
kosborne__ has quit [Quit: Leaving]
Bob_Dole has joined ##openfpga
gsi__ is now known as gsi_
<somlo>
everything until Linux boots, then it's '\n\r'. So everything looks like crap on my terminal emulator while the firmware is outputting stuff to the display. Maybe it's the other way around if one uses a terminal emulator on Windows, but I wouldn't know...
<shapr>
iirc, windows is \r\n and unix is just \n
<shapr>
I thought something used only \r but I forget what
<somlo>
right, so you'd think terminal emulators on unix/linux would reflect that
<somlo>
but if I use "screen /dev/ttyUSB1 115200" (i.e., your vanilla, garden variety serial console in an xterm), then bare-metal firmware output containing just \n will start a new line from the column where the previous line ended
<somlo>
and look horrible
<shapr>
that's surprising
<azonenberg_work>
my experience has been that most firmware outputs \r\n
<adamgreig>
uarts have traditionally used \r\n ime
<azonenberg_work>
Because that is the way the old dec vt-100 etc worked
<azonenberg_work>
and teletypes before that
<adamgreig>
and consequently things like at modems etc i guess too
<azonenberg_work>
\r = go to beginning of current line
<azonenberg_work>
\n = go down one line
<adamgreig>
so really it's unix that's wrong :p
<somlo>
so the uart *hardware* automatically adds a \r when it sees a \n from the bare-metal program ?
<azonenberg_work>
this is one of the most common things i find in firmware reversing
<adamgreig>
the program should send \r\n for a newline over a uart, really
<azonenberg_work>
a loop over a string that outputs a \r if it sees a \n
<adamgreig>
hah
<azonenberg_work>
and otherwise just sends the byte direct
<adamgreig>
wonder if the extra codespace for the loop is a win over using \r\n in the strings
<azonenberg_work>
well it means you can just print \n like you normally would for a linux tty etc
<azonenberg_work>
most libraries and devs are used to doing that
<adamgreig>
fair
<azonenberg_work>
and let the text mode translator do the rest
<azonenberg_work>
it's just like opening a file in text mode on windows, the conversion is done for you
<adamgreig>
iirc miniterm will accept \n without \r, unlike screen
<azonenberg_work>
well technically thats wrong and could break some complex curses-type interfaces
<adamgreig>
but most fancier serial terminals will have an option
<azonenberg_work>
\n is only supposed to be line feed
<somlo>
the even funnier thing is that, if you log screen's interaction to a file, or if you use 'script', you get dos-formatted "cr-lf" content from normal unix programs :)
<azonenberg_work>
they're separate motors in a true tty
<adamgreig>
nice to have the option though
<azonenberg_work>
somlo: exactly, because the tty layer does that for yo
<azonenberg_work>
you*
<somlo>
and it looks "normal" if you log \n-only bare-metal stuff
<azonenberg_work>
just like a text mode file on linux
<shapr>
according to that wikipedia article, \n for unix, \r\n for most dos/win/atari/etc, but acorn and risc os use \n\r and IBM mainframes use \025 in ebcdic
<azonenberg_work>
on windows*
<azonenberg_work>
\n\r vs \r\n is immaterial in most cases
<azonenberg_work>
unless you have code that expects one or the other
<azonenberg_work>
real hardware / faithful terminal emulators will not care
<azonenberg_work>
just a questino if you move the carriage before or after the paper
<shapr>
c64, zx spectrum used \r
<daveshah>
The picosoc demo firmware does the translation from \n to \r\n in its putchar function
<somlo>
so I guess the Linux serial/uart driver will insert \r for me, which is why stuff looks normal and logs extra \r's to 'script'
<somlo>
and e.g. lowRISC's bare-metal code "might want to consider" adding extra \r characters automatically, similarly to picorv32
<somlo>
then we just continue to blindly "dos2unix" the output from script, and don't have to deal with existential questions brought up by inconsistent behaviour :D
<daveshah>
Just have to be careful if dealing with non-ASCII
<somlo>
I should maybe submit a patch along the same lines to LiteX (which also doesn't automatically insert \r's and therefore looks horrible in 'screen')
<ylamarre>
Some devs add a switch to their terminal emulator to automatically \r on newline, or pipe the uart output to a file...
<ylamarre>
The \r adding weirdo symbol to their screen...
<somlo>
I'm surprised 'screen' doesn't come with one already -- I started out by googling for just that, and found nothing but endless discussion, like a "vi vs. emacs" holy war :)
<tnt>
emeb: led blinking colors ... blindingly so.
<tnt>
and uart too "up5k 6502 cc65 serial test"
dj_pi has quit [Ping timeout: 240 seconds]
dj_pi has joined ##openfpga
wolfspraul has quit [Quit: leaving]
wolfspraul has joined ##openfpga
somlo has quit [Remote host closed the connection]
somlo has joined ##openfpga
m_w has quit [Ping timeout: 255 seconds]
rohitksingh has quit [Remote host closed the connection]
dj_pi has quit [Ping timeout: 252 seconds]
Bob_Dole has quit [Ping timeout: 252 seconds]
Bob_Dole has joined ##openfpga
somlo has quit [Ping timeout: 255 seconds]
<sxpert>
shapr: I had to use \r\n otherwise screen would not carriage return with \n only
Asu[LifeIsBread] has quit [Ping timeout: 245 seconds]
Asu[LifeIsBread] has joined ##openfpga
<emeb>
tnt: aha - you got it built & running!
<emeb>
I've been messing around with cc65, trying to add a little command line processor to do peek/poke etc.
<emeb>
but I've found that cc65 is "not quite C"
<emeb>
and there are a lot of things about it that don't work the way one would expect.
<sxpert>
emeb: and the generated code is less than good
<emeb>
sxpert: I've not looked closely at it, but that wouldn't surprise me.
<TD-Linux>
6502 is a pretty nasty target for C
<emeb>
Yes - tiny stack and small native wordsize are a handicap. But if speed/efficiency was my goal then perhaps a 6502 isn't the best choice to start. ;)
<TD-Linux>
it's not the worst though (I think that would be PIC)
<emeb>
lol, yes.
<emeb>
w register all the things!
<emeb>
actually, PIC24 and dsPIC have pretty nice architectures. I wouldn't mind having those on an FPGA.
<TD-Linux>
also 16 word hardware stack means you need a second parallel data stack
<emeb>
yep
<TD-Linux>
I wonder how they would compare to e.g. vexriscv
m_w has joined ##openfpga
<emeb>
gotta go - bbl
emeb has quit [Quit: Leaving.]
<davidc__>
I used to use a tiny hacked-up pic16 core for all of my FPGA sequencing needs. I recall it being pretty small, but writing code was always very tedious
<davidc__>
UNless you are counting gates, I'd use something with nicer tools
wolfspraul has quit [Quit: leaving]
linzhi-sonia has joined ##openfpga
linzhi-sonia has quit [Client Quit]
dj_pi has joined ##openfpga
Asu[LifeIsBread] has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
Thorn has joined ##openfpga
dj_pi has quit [Ping timeout: 246 seconds]
emeb_mac has joined ##openfpga
<emeb_mac>
davidc__: yeah - 6502 tools are a lot nicer than that.
<davidc__>
emeb_mac: it doesn't help that I added a few custom instructions to the core, so I needed my own tools....
<emeb_mac>
davidc__: NEON SIMD? :)
<tnt>
emeb_mac: yeah, that was pretty seamless, just a couple path change in Makefile for yosys and updated pcf to match the icebreaker.