whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
_whitelogger has joined #glasgow
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQIR
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark ddcbb7d - applet.program.xc6s: clock JSTART in RTI while polling.
<whitequark> uhhh, time to bump python requirement to 3.7, i think
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fjQI6
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 050a5ca - Bump required Python version to 3.7.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fjQIi
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 97a151b - Bump required Python version to 3.7.
<_whitenotifier-3> [Glasgow] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/GlasgowEmbedded/Glasgow/builds/568160258?utm_source=github_status&utm_medium=notification
<_whitenotifier-3> [whitequark/libfx2] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQId
<_whitenotifier-3> [whitequark/libfx2] whitequark 9d6146a - Work around a bug in SDCC 3.5.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/fjQIF
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark de89ab8 - firmware: work around a bug in SDCC 3.5.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 54abd25 - firmware: fix type of glasgow_config.revision.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQIN
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 8ef4bc8 - Commit missing part of 97a151ba.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQIh
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 650db96 - software: only build the library part of libfx2.
ahou has joined #glasgow
kuso has quit [Ping timeout: 244 seconds]
<marcan> whitequark: uhh, really?
<marcan> I mean yes I *can* bump that to 3.7 but let me see if I can find whatever gentoo bug for how much stuff is going to break...
<marcan> personally I think it's reasonable to support the current and prior major versions
<marcan> (can also just use a virtualenv for glasgow but I prefer to avoid maintaining virtualenvs unless I really need to...)
<marcan> there isn't even a tracker bug for 3.7 yet, heh
<marcan> what do you need so desperately from 3.7?
<marcan> it's even masked in stable so you can't even build for it on non-~ in gentoo
<marcan> (you can still install python3.7 core, by manually unmasking it as unstable, but you can't build any packages/modules to target it, on a stable system, unless you unmask the USE flag but then I bet a million packages will fail to build due to the async/await keyword change, so that's a terrible idea)
<marcan> (I run unstable on my desktop, so it doesn't apply to my main machine, but e.g. I put glasgow on a server running stable last week so...)
ali_as has quit [Quit: Leaving]
<tnt> same here I'm on 3.6 too :/
q3k has quit [Ping timeout: 264 seconds]
_whitelogger has joined #glasgow
m4ssi has joined #glasgow
<whitequark> marcan: i didn't find a way to get asynccontextmanager on 3.6
<whitequark> marcan: but more importantly: python3.7 is in *debian stable*. what kinda hell distro do you run that it lags behind debian stable?!
<daveshah> FWIW, the support benchmark for Yosys and nextpnr is usually Ubuntu 16.04
<whitequark> yes, the CI runs xenial
<daveshah> And we still get a few people complaining about stuff not working on 14.04...
<whitequark> i remember there's a guy who complains solvespace doesn't work on ATI RS600
<whitequark> a video card from 2007
<whitequark> he can go pound sand, of course
<whitequark> marcan: tnt: anyway, i actually added a hax to support sdcc 3.5, since that's something we're going to be stuck for a while
<whitequark> even though the latest sdcc is 3.9
<whitequark> but i don't understand why is python an obscure hard to upgrade dependency
<whitequark> ok
<whitequark> sure
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fjQnS
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark b5c7f12 - software: add back Python 3.6 support, by popular request.
<whitequark> marcan: ^
<whitequark> note that by your own criteria, i will be able to revert this in november, when 3.8 gets released
<whitequark> and tbh i would actually like to support 3.8+ as soon as possible because that has an asyncio REPL
<whitequark> the current asyncio REPL workaround in glasgow works very very badly
<whitequark> and i don't believe the asyncio REPL can be backported, though i'll look at it
<gruetzkopf> RS600? wow.
<whitequark> >The compile() built-in has been improved to accept the ast.PyCF_ALLOW_TOP_LEVEL_AWAIT flag. With this new flag passed, compile() will allow top-level await, async for and async with constructs that are usually considered invalid syntax. Asynchronous code object marked with the CO_COROUTINE flag may then be returned.
<whitequark> yeah
<whitequark> not backportable
<gruetzkopf> oldest i have is RS880M
<gruetzkopf> and old python is usually a sign of gentoo
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<hellsenberg> I thought gentoo would use a newer python; afaik portage uses it
<marcan> whitequark: uhh, I see what debian did there
<marcan> they install all python3 packages under a common python3 directory, not separated out by minor version?
<marcan> that... works for *most* packages I guess?
<marcan> I mean gentoo has python3.7 just fine
<marcan> $ python3.7
<marcan> Python 3.7.3 (default, Apr 1 2019, 16:44:26)
<marcan> it just doesn't build *everything else* for it, and it doesn't automatically pick anything up because package dirs are split by minor version
<whitequark> hmm fine
<whitequark> i mean, i agree to hold off requiring 3.7 until november, sure
<marcan> I mean I'm not going to cry a river if you force 3.7 on me, I'll just try building $everything for it and if anything I care about fails, I'll just use a virtualenv and call it a day
<marcan> but it feels premature :p
<whitequark> glasgow heavily relies on asyncio and asyncio in python is... immature
<marcan> yeah, I've noticed
<marcan> lots of changes to that in 3.7
<marcan> so I get wanting to stay on the bleeding edge
<marcan> not saying I wouldn't want to either
<marcan> I just feel "current + last" is a decent policy
<marcan> for the sake of users :p
<whitequark> i expect i'll have to provide docker containers anyway
m4ssi has quit [Remote host closed the connection]
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjQlO
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 230e8e7 - support.pyrepl: make imports relative to toplevel package.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 396ddaa - support.pyrepl: store result of coroutine in _, not coroutine itself.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQ84
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 6392af0 - interface.jtag_probe: simplify XR scanning.
<electronic_eel> whitequark: test jig pcb is finished
<electronic_eel> do you think it makes sense to wait with ordering them to let esden have a look?
<electronic_eel> he seems to be busy at blackhat and he wasn't especially keen on looking at the schematics
<whitequark> electronic_eel: i'll take a look ... i have some travel nightmare soon so probably around 10th?
<electronic_eel> I can wait for a few days, no problem
diverger has quit [Ping timeout: 272 seconds]
diverger has joined #glasgow
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQ0k
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark aca3597 - cli: add `safe`, a command to turn off Vregs and drivers quickly.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 3 commits to master [+0/-0/±3] https://git.io/fjQ09
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 6bbc527 - access.direct.arguments: fix default=..., required=True combination.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark ad30823 - applet.memory.25x: add a convenient default pin assignment.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 1639a25 - applet.interface.spi_master: --bit-rate → --frequency.
<_whitenotifier-3> [Glasgow] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/GlasgowEmbedded/Glasgow/builds/568563097?utm_source=github_status&utm_medium=notification
<whitequark> tnt: here's a commit for you
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQEI
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 9621694 - cli: allow overriding revision requirement.
<gruetzkopf> neat
<tnt> whitequark: :) Hehe yeah, I've been doing that manually so far.