<rqou>
btw azonenberg forking submodules is a huge pain
<azonenberg>
lol oh?
<rqou>
to make a fork of openfpga use a fork of e.g. xptools, you have to manually add a new remote
<rqou>
and then switch over to it
<azonenberg>
rqou: re the _windows define
<azonenberg>
pretty sure that was build system based
<azonenberg>
for win32 or win64
<azonenberg>
but i guess ms is being silly and compatible and having win32 be set even on win64 :p
<rqou>
yeah
<rqou>
_WIN32 is always defined
<azonenberg>
"was build system based" = i copied the code from another repo
<azonenberg>
and must have not copied that config :p
<rqou>
even on x86_64 or AARCH64 :P
<azonenberg>
lol
<rqou>
also, windows aarch64 is probably going to end up wrecking a bunch of assumptions all over again
<rqou>
er
<azonenberg>
this nonsense is the same reason we have win 10 instead of win 9
<azonenberg>
:p
<rqou>
maybe not, since we did also have ia64
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vHKtK
<openfpga-github>
openfpga/master 8a4cc70 Andrew Zonenberg: Added GetInput() to all BitstreamEntity-derived classes. Began work on post-PAR static timing.
<openfpga-github>
openfpga/master 21a9004 Andrew Zonenberg: Updated to latest xptools
<azonenberg>
rqou: also re std:: namespace collisions
<azonenberg>
my rule is, fix the offending code
<azonenberg>
If you ever namespace collide with std:: i consider your code wrong
<rqou>
except bind() the syscall predates std::bind() by at least a decade
<azonenberg>
Yes, so explicitly specifying the global namespace is an annoying necessity there (the one place in the whole codebase you call it)
<rqou>
make that more like 3+ decades actually :P
<rqou>
std::bind is a c++11 feature
<azonenberg>
I would also agree that naming a standard library function the same as a syscall on a major platform (all major platforms, in fact)
<azonenberg>
is a poor decision
<azonenberg>
namespaces or no namespaces
<rqou>
not a syscall on windows :P
<azonenberg>
IMO std:: should not have been namespaced in the first place
<azonenberg>
they should have been in the global namespace and considered reserved names
<rqou>
um... except there are thousands of them
<rqou>
what about freestanding c++ (no STL?)
<azonenberg>
Yeah, and?
<rqou>
you'll end up reserving thousands of really common names
<azonenberg>
Then it would be legal to use those keywords, but a horrible idea because you could never reuse that code in anything with STL
<rqou>
and what happens when you want to add more?
<azonenberg>
its legal to define your own function in c called printf
<azonenberg>
as long as you don't link to libc while doing it :p
<rqou>
what happens when the STL needs to add a new name?
<rqou>
it'll end up clashing
<rqou>
in general namespacing seems to kinda suck in every language though
<azonenberg>
well, in particular
<rqou>
C++ being particularly bad
<azonenberg>
namespacing is something you can use in 3rd party libraries, to prevent them from colliding with each other
<azonenberg>
the standard library should not be namespaced because it's assumed everyone is using it
<azonenberg>
or, if it *is* namespaced, your code should assume everyone is importing it
<rqou>
rust does it that second way
<azonenberg>
Because it's, well, the *standard* library
<rqou>
code auto-imports the standard library, but it's still namespaced
<rqou>
there's also #[no_std] if you're weird and doing embedded stuff
<rqou>
rust also has a separation between std (the standard library) and core (compiler intrinsics/glue/internal)
<rqou>
damn i really need to rework how raspbian builds are done
<rqou>
azonenberg did you know that qemu-user-static is slow? :P :P
<rqou>
please test this extensively, especially across distros
<rqou>
(i only have a native non-container install of debian-based distros)
<rqou>
it shouldn't change, but who knows
<rqou>
udev is a giant mess
<rqou>
hmm actually don't merge this yet
<rqou>
apparently I broke the rules and need to fix it
<rqou>
but sleep first
azonenberg_work has quit [Ping timeout: 246 seconds]
X-Scale has joined ##openfpga
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
qu1j0t3 has joined ##openfpga
m_w has joined ##openfpga
azonenberg_work has joined ##openfpga
Finnpixel has joined ##openfpga
digshadow has joined ##openfpga
amclain has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
azonenberg_work has quit [Ping timeout: 260 seconds]
digshadow has quit [Ping timeout: 246 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
azonenberg_work has joined ##openfpga
pie__ has quit [Changing host]
pie__ has joined ##openfpga
Finnpixel has quit [Ping timeout: 246 seconds]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou>
actually it seems the way i'm accessing sysfs is fine
digshadow has quit [Read error: Connection reset by peer]
<rqou>
supposedly kay sievers was the one who wrote the documentation claiming what I did is wrong
digshadow has joined ##openfpga
<rqou>
and he's the infamous "flamed by linus for breaking abi" guy
<azonenberg_work>
lol
<jn__>
rqou: isn't that Mauro, the media maintainer?
<rqou>
iirc they both got one of these flames
<jn__>
remember "Shut up, Mauro!"
<rqou>
anyways, the particular piece of sketchiness is that i'm accessing "/sys/dev/char/%d:%d/device/../../%s" to go from a hidraw device to the usb device
<rqou>
the first /device part has never been changed in the history of hidraw existing
<rqou>
and it goes from the hidraw node to the hid bus node
<rqou>
the first /.. goes from the hid bus node to the usb interface node, and this is considered a "testing" level ABI
<rqou>
(which de-factor means that you probably can't change it anymore :P )
<rqou>
*de-facto
<rqou>
and the second /.. goes from the USB interface to the US device
<rqou>
this is technically not stable, but wtf would you add that goes in the middle?
<rqou>
aanyways, tl;dr i think what i'm doing is fine, and it doesn't require a giant mess of file parsing
<rqou>
azonenberg_work: opinions about dropping mac os 10.5 support? (basically already didn't work anyways)
<azonenberg_work>
Not a mac guy
<azonenberg_work>
how old is that?
<rqou>
almost a decade old
m_w has quit [Quit: leaving]
<azonenberg_work>
Yeah drop it
<rqou>
our de-facto minimum is 10.7, which came out in 2011
<azonenberg_work>
Yeah that should be fine
<rqou>
lowering this is (hilariously) a build system problem
<rqou>
libc++ (with c++11 support) requires 10.7
<rqou>
but you can still somehow via huge amounts of effort get gcc+libstcd++ to work
<rqou>
and that gives you 10.6 support for anybody still clutching 10.6
<rqou>
this means that we don't have mac os x PPC support though
<rqou>
for anybody who wants to use this on a G5 tower or something
<rvense>
10.5 is the last to run on ppc
<rvense>
.. you just said that
<rqou>
yeah, too bad i guess?
<rqou>
use linux?
<rvense>
i think it's fine.
<qu1j0t3>
rqou: 10.5 is last on powerpc
<qu1j0t3>
oh
<qu1j0t3>
you just said that ;)
* qu1j0t3
still has g5 towers and a g4 powerbook on 10.4 but i suppose this is a losing battle
<qu1j0t3>
a lot of iMacs are locked to 10.6 (C2D generation)
<rqou>
wait is this the dumb problem with 32-bit EFI?
<rqou>
anyways, 10.6 can work, but the binaries i build require 10.7 because i can't be arsed to figure out _how_ to make it work
<rqou>
i want to remove an ugly hack for 10.5 though
<qu1j0t3>
rqou: Yeah the iMac issue is 32 bit EFI, i think.
<qu1j0t3>
rqou: or, at least, that's the issue on early Mac Pros, but they can unofficially run El Capitan with EFI hacks (I'm doing this on a 2,1)
<qu1j0t3>
rqou: iMacs can also be hacked but you run into device support issues, around video card, at least
<qu1j0t3>
rqou: much as it pains me to say this, i think you should go for your convenience but document the limitations and invite others to overcome them on their own time
<rqou>
i just felt that the 10.5 hack was a bit too disgusting to keep
<qu1j0t3>
rqou: development velocity is probably the more important thing
<qu1j0t3>
well, keep it if it's no cost to keep it?
<rqou>
it casts a pointer to a private struct somewhere in iokit
<rqou>
right now i'm trying to remove "silly useless shit" in hidapi
<rqou>
i can add it back later i guess?
<rqou>
it seems unlikely anyone is doing serious dev work on a mac os 10.5 machine
<qu1j0t3>
that is true, but i'd at least leave a note or something
<rqou>
yeah, i'm working on notes and other random bits
<qu1j0t3>
having tried to backport stuff it is a cost/benefit situation i think
digshadow has quit [Quit: Leaving.]
Hootch has quit [Quit: Leaving]
m_t has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
mifune has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
mifune has joined ##openfpga
nicdev` has joined ##openfpga
mithro_ has joined ##openfpga
cblam_ has joined ##openfpga
GreeningGalaxy has joined ##openfpga
cblam has quit [Ping timeout: 240 seconds]
mithro has quit [Ping timeout: 240 seconds]
bibor has quit [Ping timeout: 240 seconds]
Ellied has quit [Ping timeout: 240 seconds]
pointfree[m] has quit [Ping timeout: 240 seconds]
nicdev has quit [Ping timeout: 240 seconds]
gruetzkopf has quit [Ping timeout: 240 seconds]
cblam_ is now known as cblam
mithro_ is now known as mithro
gruetzkopf has joined ##openfpga
bibor has joined ##openfpga
gruetzkopf is now known as Guest61631
pointfree[m] has joined ##openfpga
mifune has quit [Ping timeout: 255 seconds]
nicdev` is now known as nicdev
mifune has joined ##openfpga
mifune has joined ##openfpga
<rqou>
whitequark: how do i go about debugging a problem with cmake where CMAKE_C_FLAGS only takes effect when I run cmake twice?
<rqou>
nvm, i found a relevant stack overflow post
m_t has quit [Quit: Leaving]
mifune has quit [Ping timeout: 260 seconds]
<rqou>
azonenberg: btw gp4prog works on linux ppc
<rqou>
:P
<rqou>
or at least --blink does
<rqou>
i didn't test if bitstreams potentially have endianness issues
<openfpga-github>
[openfpga] rqou opened issue #94: segfault if timing.json is missing https://git.io/vHild
<azonenberg_work>
o_O i need to debug that one
<azonenberg_work>
Will look into it when i get home
<azonenberg_work>
the timing analysis code is very hacky, i wrote it up last night lol
<azonenberg_work>
It assumes you're using a slg4662x
<azonenberg_work>
if you try to build for a 140 no idea how it'll react
<rqou>
yeah i'm just going to comment out PrintTimingReport for now
<azonenberg_work>
It *should* gracefully recover and revert to the old code if there's no timing data
<azonenberg_work>
so i need to figure out what's up with that
<rqou>
what voltage do i give blinky?
<rqou>
5v?
<azonenberg_work>
it should run on anything
<rqou>
do the leds auto-enable?
<azonenberg_work>
no, gp4prog has to take an argument for that
<rqou>
what args?
<azonenberg_work>
gp4prog --help
<azonenberg_work>
:P
<azonenberg_work>
also dont forget --emulate loads to sram and --program burns otp
<rqou>
there's a -n, but what pins do i pass?
<azonenberg_work>
Pin numbers :p
<rqou>
ah i don't need to look up an extra datasheet/manual?
<rqou>
amazing!
<azonenberg_work>
see Blinky.v
<azonenberg_work>
so probably 20,19,18,17,16,15,14,13
<azonenberg_work>
are the outputs
<rqou>
i didn't realize those were the actual actual pins
<azonenberg_work>
Those are pins on the zif socket / test points on the board
<azonenberg_work>
If your DUT does not have 20 pins
<azonenberg_work>
the DUT pin numbering may not match the ZIF pin numbering exactly
<azonenberg_work>
i dont know how they do that
<azonenberg_work>
would have to look at the stqfn-14 pin socket
<rqou>
oooo
<rqou>
azonenberg_work: gp4par/gp4prog work on my imac g3 (running linux)
<rqou>
so there weren't any subtle endianness bugs or anything
<rqou>
and the most amazing part?
<rqou>
real0m0.345s
<rqou>
user0m0.224s
<rqou>
sys0m0.080s
<rqou>
on a system that looks like this:
<rqou>
$ cat /proc/cpuinfo
<rqou>
processor: 0
<rqou>
cpu: 740/750
<rqou>
temperature : 30-32 C (uncalibrated)
<rqou>
clock: 333.333330MHz
<rqou>
revision: 2.2 (pvr 0008 0202)
<rqou>
bogomips: 33.32
<rqou>
timebase: 16663950
<rqou>
platform: PowerMac
<rqou>
model: iMac,1
<rqou>
machine: iMac,1
<rqou>
motherboard: iMac MacRISC Power Macintosh
<rqou>
detected as: 79 (Unknown Paddington-based)
<rqou>
pmac flags: 00000000
<rqou>
L2 cache: 512K unified
<rqou>
pmac-generation: NewWorld
<rqou>
Memory: 512 MB
<rqou>
although I did cheat and ran yosys on my desktop
<azonenberg_work>
Lol that is probably slower
<azonenberg_work>
also, packing up and heading home
<azonenberg_work>
back in a bit
<qu1j0t3>
rqou: nice!
<rqou>
this is probably the only eda tool in existence that a) actually works on ppc and b) can finish running in less than a second on a machine this slow
azonenberg_work has quit [Ping timeout: 268 seconds]
<rqou>
actually that's not completely true
<rqou>
kicad can launch on this machine
<rqou>
but it crashes if you enable GAL
<rqou>
hmm this was also a test that my no-udev rewrite of the hid backend does work on at least one "unusual" system