--- Day changed Sat Oct 05 2019
01:49 < belcher> im having trouble with imports; in taker.py iv added `import jmclient.schedule` but it results in this error https://pastebin.com/syM1JRMD
01:51 < belcher> iv tried using different ways to import like `from jmclient.schedule import X` and so on, iv also noticed in schedule.py if the import to `validate_address` and `jm_single` is removed then the error goes away, those two names come from configure.py and other names that are imported dont cause the error
02:04 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
02:41 < undeath> waxwing: ping
03:22 < undeath> i messed up the commit message for merging #406. should i force-push a fixed commit?
03:41 < waxwing> undeath, fine with me
03:42 < undeath> waxwing: you pinged yesterday, what+s up?
03:43 < waxwing> was gonna ask about __getattr__ but i figured it out.
03:43 < waxwing> did it like this:
03:43 < waxwing>     def __getattr__(self, attr):
03:43 < waxwing>         # any method not present here is passed
03:43 < waxwing>         # to the wallet:
03:43 < waxwing>         return getattr(self.wallet, attr)
03:43 < waxwing> i presume that's basically what you meant? it seems to work like that.
03:44 < waxwing> i guess i should edit that comment, since it's not only methods but any attribute
03:44 < undeath> yeah, pretty much
03:45 < undeath> i think i would have put in a hasattr(walet, attr) check before that with an explicit raise
03:46 < waxwing> belcher, huh that's interesting, i wonder if it's an ordering thing
03:46 < waxwing> undeath, ah. ok, will do, makes sense.
03:49 < waxwing> belcher, also: did you try putting the specific methods from schedule you're going to use, in __init__.py and then importing the methods from jmclient?
03:50 < waxwing> i always thought in the past that that was the right way to do it, except, i feel like now it isn't. maybe undeath would have a comment on that, because i feel like he changed some of the import syntax in that sense?
03:51 < waxwing> i'm not at all clear what the difference is between those two ways of doing imports. obviously *outside* the package it should be "from jmclient" .. well at least I think that's obvious.
03:51 < waxwing> but we're talking about within.
03:51 < waxwing> i notice that the schedule.py still uses that `from jmclient import (blah)` syntax whereas most of the other modules in the package don't.
03:54 < waxwing> so if you want my guess, what's happening is, .taker import happens first in __init__ then, with your edit, you're now referencing schedule, which is lower down so not yet imported into jmclient (does that make sense?), so it tries to import schedule, then it sees references to validate_address from configure, but that's after .taker, so not done yet, so it fails to find it.
04:00 < undeath> within a package I would use relative imports
04:00 < undeath> but i+m totally missing any context right now :)
04:01 < undeath> btw, foce-pushed a nicer commi msg
04:06 < waxwing> you're missing context? you didn't see belcher 's questions at 09:50? i can just copy, it's only a couple of lines
04:07 < undeath> i think i missed it by 15min
04:07 < undeath> dont have a bnc running
04:07 < waxwing> <belcher> im having trouble with imports; in taker.py iv added `import jmclient.schedule` but it results in this error https://pastebin.com/syM1JRMD
04:07 < waxwing> <belcher> iv tried using different ways to import like `from jmclient.schedule import X` and so on, iv also noticed in schedule.py if the import to `validate_address` and `jm_single` is removed then the error goes away, those two names come from configure.py and other names that are imported dont cause the error
04:08 < undeath> thanks
04:10 < undeath> belcher: try "from .[module] import a, b, c"
04:10 < undeath> "from . import a, b ,c" will probably work, too
05:44 < belcher> in taker.py i changed it to `from .schedule import NO_ROUNDING` but still get the same error
05:44 < belcher> also adding to __init__.py was one thing i tried
05:44 < belcher> undeath waxwing ^
05:48 < undeath> maybe something is wrong with the way you call/test the new file?
05:49 < undeath> i mean, this import works just like it should: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/cryptoengine.py#L11
05:51 < belcher> yep im confused about it, since schedule.py gets imported in a few other places just fine
05:52 < belcher> its easy to reproduce this it seems, just go to taker.py and add something like `import jmclient.schedule`
05:59 < undeath> ah, yes, I see
06:00 < undeath> i think the problem is you get circular imports
06:01 < undeath> it works right now for schedule.py because it's nowhere imported directly, but as soon as you try this you get into trouble when __init__.py tries to do just that and notices it will need to evaluate __init__.py before it can actually handle schedule.py's imports
06:01 < undeath> or something along those lines
06:02 < undeath> which probably is a good showcase of why you should use relative imports of the correct module
06:02 < belcher> so would a solution be to make all imports in jmclient relative
06:02 < undeath> and try to avoid in-package imports with "from package import a, b, c"
06:02 < undeath> the ones in schedule.py rather, I believe
06:04 < belcher> whats the alternative to the in-package imports you mention
06:06 < undeath> this seems to work. in schedule.py i replaced the from jmclient import ... with
06:06 < undeath> from .configure import validate_address, jm_single
06:06 < undeath> from .support import rand_exp_array, rand_norm_array, rand_pow_array
06:07 < belcher> that worked for me
06:07 < belcher> im guessing that worked because it avoids trying to import jmclient's __init__.py
06:07 < undeath> exactly
06:07 < belcher> ty     
06:08 < belcher> any idea why it the error wasnt raised if the imports to `validate_address` and `jm_single` were removed
06:08 < belcher> they're the ones from configure.py
06:09 < undeath> because __init__.py import taker.py before configure.py I guess
06:10 < undeath> so when taker.py tried to import schedule.py, schedule.py tried to find the functions __init__.py had imported at that time, which did not include the imports from configure.py
06:11 < belcher> interesting, so perhaps another option is rearranging the order of imports in __init__.py
06:11 < belcher> but using relative imports is better
06:11 < undeath> yes, that would probably work, too
06:12 < undeath> yeah, with relative imports you don't have to care about it at all
06:12 < undeath> which kinda helps keeping you sane :)
06:12 < belcher> for sure
06:13 < belcher> thanks again for helping, i read a few articles on how imports work in python and still wasnt able to fix the issue
06:17 < undeath> yw!     
07:43 -!- viasil [~viasil@95.174.67.204] has quit [Ping timeout: 276 seconds]     
07:45 -!- viasil [~viasil@95.174.67.204] has joined #joinmarket     
07:50 -!- viasil [~viasil@95.174.67.204] has quit [Ping timeout: 276 seconds]     
07:51 -!- viasil [~viasil@95.174.67.204] has joined #joinmarket     
08:20 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 245 seconds]     
08:29 -!- achow101 [~achow101@unaffiliated/achow101] has joined #joinmarket     
10:12 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
11:55 < fiatjaf> can we do complex trustless coinswaps with many parties and without any blockchain footprint using taproot adaptor signatures?
11:55 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
11:56 < fiatjaf> like A pays B on a transaction, then B pays C on a transaction 10 blocks later, then C pays A more blocks later?
11:56 < fiatjaf> like all parties would have presigned transactions and could publish them, but a part of the signature is missing, however it's revealed when the previous transactions is seen on the blockchain
11:59 < undeath> kinda sounds like LN
12:55 < waxwing> fiatjaf, have you seen my blogpost on scriptless script swaps (ie adaptor based coinswap)?
12:56 < waxwing> also another one called 'multiparty S6' which is basically very similar to what you're saying. undeath's comment is valid of course, though, that coinswap is kinda what lightning does. (lots of devil in the details here)
13:42 < belcher> a big difference between coinswap and LN is the amounts that are generally practical to mix... LN is limited by channel capacity and generally wants to avoid big payments, you could imagine a coinswap with liquidity pricing like in joinmarket where it would be practical to coinswap 100 btc through it
13:45 < belcher> if coinswap makers earn a bit of money like joinmarket makers then they'd have the right incentive to put 100btc in a 2of2 multisig for a little while to make the coinswap work
13:46 < belcher> on the other hand; with LN today you can just buy incoming liquidity (but only from a few places)
14:57 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.6]     
17:26 -!- AgoraRelay [~jmrelayfn@p5DE4A0BE.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]     
17:27 -!- CgRelayBot [~CgRelayBo@p5DE4A0BE.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]     
17:39 -!- CgRelayBot [~CgRelayBo@p54866D99.dip0.t-ipconnect.de] has joined #joinmarket     
17:42 -!- AgoraRelay [~jmrelayfn@p54866D99.dip0.t-ipconnect.de] has joined #joinmarket