Source code help

[chan] bitmessage
Mar 7 01:42 [raw]

Hi Peter, devs, Can someone please explain the difference between the variables in shared.py and those in state.py, and help to clarify for example why state.curses and state.maximumNumberOfHalfOpenConnections (shared configuration parameters set once on startup) are defined in state.py, while shared.connectedHostsList or shared.ackdataForWhichImWatching (purely runtime state variables) are defined in shared.py ? Also as a follow-up, if a fellow coder wanted to introduce a new set-once-on-startup global variable affecting the operation of the client (fictional example: a CLI switch --ignore-ttl to force the object processor to temporarily ignore TTLs in order to replay older streams), where would that variable be defined: shared or state? I think it's shared, but could use some educated advice. Thank you.

[chan] bitmessage <<Ext>>
Mar 7 06:30 [raw]

Peter is in process of deprecating shared.py. So use defaults.py, paths.py, protocol.py, queues.py, state.py or add a new module, whatever is appropriate.

[chan] bitmessage
Mar 7 12:04 [raw]

this is the type of confusing bullshit that happens when you use classes and object oriented "programming." functional code would be 10x ++ easier to follow and parse. When I read the BM codebase, I have to jump back and forth between many files and classes just to see what one thing is doing. I think feds promoted object oriented programming because of the huge attack surface that evolves from it and the internal state of classes all over. you can use python to do functional programming and put each function in a file by that name. then debugging anything is just about instant.

[chan] bitmessage
Mar 7 18:39 [raw]

> Hi Peter, devs, > > Can someone please explain the difference between the variables in > shared.py and those in state.py In the past, shared.py contained both some methods and global variables, which caused problems. I moved some variables to newly created state.py as a workaround but it was never properly finished. Ideally, the methods will be moved elsewhere and shared.py will be used for global variables. I also partially did that one, some methods were moved to helper_something and protocol.py, but they haven't been removed yet from shared.py. I kind of stopped once it unbroke as there are zillions of other things to fix. > and help to clarify for example why > state.curses and state.maximumNumberOfHalfOpenConnections (shared > configuration parameters set once on startup) are defined in > state.py, while shared.connectedHostsList or > shared.ackdataForWhichImWatching (purely runtime state variables) > are defined in shared.py ? Probably my unfinished attempts to work around problems. One of those duplicate variables should be scrapped, possibly even both and a better approach chosen. > Also as a follow-up, if a fellow coder wanted to introduce a new > set-once-on-startup global variable affecting the operation of the > client (fictional example: a CLI switch --ignore-ttl to force the > object processor to temporarily ignore TTLs in order to replay older > streams), where would that variable be defined: shared or state? At the moment state.py is safer, things may break if you try to do it in shared.py. > I think it's shared, but could use some educated advice. See above. PS. I'm in the process of hiring developer(s) to fix all this crap as I am overloaded with all the stuff around the project. > Thank you. Cheers, Peter

[chan] bitmessage
Mar 7 18:45 [raw]

Yes, you're right, I forgot about it in my previous post, some parts were moved to defaults.py (constants), queues.py (global queues), paths.py (that's kind of specific to deployment internals), state.py (stuff that screwed up importing shared.py), and some things which are closely related to a specific subsystem were moved to the classes where that subsystem is used. It really needs to be properly refactored as originally it was a broken mess, now it is a distributed mess with occasional duplicates. Peter Surda Bitmessage core developer

[chan] bitmessage
Mar 7 18:53 [raw]

I think you can make unreadable code with both approaches, and readable code as well. I think classes make more sense in some cases and functional programming in other cases. Regarding PyBM I don't think the existenence of classes is what's making it less readable, in fact I think in some places we need more OOP. Peter Surda Bitmessage core developer

[chan] bitmessage
Mar 8 03:20 [raw]

Thanks everyone for the clarifications. Can I suggest putting a one-line deprecation notice at the top of deprecated files? It would help the understanding and, since it's not code, there's no regression risk.

[chan] bitmessage
Mar 11 22:43 [raw]

I can't agree with you because state is an ugly thing and the cause of much pain and agony, but I also can't recommend straying too far from OOP here. Pretty much every source you can find about FP in python will more or less tell you not to, since the language is a *lot* more suited for OOP--Guido made it that way. It makes sense to a degree because Python has a strong focus on user friendliness and OOP is (unfortunately) already familiar to most people. The best way to go functional would be to write another version in Haskell or Scala or something.

[chan] bitmessage
Mar 12 17:12 [raw]

> The best way to go functional would be to write another version in Haskell or Scala or something. a worthwhile suggestion. would we add to the pain of portability? is scala running on standard JVM yet?

[chan] bitmessage
Mar 13 03:07 [raw]

> is scala running on standard JVM yet? Scala compiles directly to Java bytecode, so yes. Anywhere a JVM runs, scala runs. There are *some* obnixious bits (for example tail recursion is not always possible), and the fact that FP is not enforced, but the benefit that interop gives is undenyable. There are other JVM languages with partial or full FP properties: Groovy (eh), Kotlin ( less eh), Clojure (kinky), and Scala (help im lost deep in the typesystem jungle) at least. But There are a *lot* to choose from for FP. Here are some comaparisions (note not all of them are functional languages): https://en.wikipedia.org/wiki/Functional_programming#Coding_styles

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
asyncronous data Jun 21 19:37 7
A question Jun 21 19:37 10
Integration with GPG (GnuPG) Jun 21 10:04 5
Inbox bug Jun 20 23:31 6
Patch 2 Jun 20 23:05 3
Patch Jun 20 07:36 2
Why did all my messages vanish? Jun 20 00:16 6
onionscan update Jun 19 22:43 9
PyBitmessage Security Scan on Branch v0.6 Jun 19 12:02 59
Feature request: delete all messages from user Jun 19 05:52 3
ERROR - Too many items in inv message! Jun 19 05:45 15
Feature request: delete all messages from user Jun 18 23:40 1
test Jun 18 23:24 5
attack? Jun 18 22:10 3
a GOOD implementation of 2fa for conventional email please! Jun 18 21:03 1
unpickling knownnodes to a readable format Jun 18 04:43 27
WARNING - Probably wrong category number in playSound() Jun 17 09:41 1
I don't receive any BMs when I have only one peer. Jun 16 17:13 6
identicon code bug? Jun 16 06:35 1
Free Git Replacement Jun 15 17:31 8
github Jun 15 04:35 1
Latest git pull: inbox doesn't update Jun 15 03:55 4
IPFS Jun 13 21:48 8
latest in the spy world Jun 13 19:14 2
(no subject) Jun 13 19:12 1
TIMESERVICE Jun 13 19:05 1
Questions about BM nodes Jun 12 22:53 7
D2A41B229F7BCE6F9B429D3E33A47598 Jun 12 22:26 1
Why not reject old clients from connection to the network? Jun 12 19:18 10
Add an option to connect only to onions Jun 12 00:42 2
Help Improving Algorithm Jun 11 23:48 3
hey - why not make pyBM as shitty as "Signal-App" by Marlinspike ? Jun 11 21:53 1
Silence debug.log foe less disk-write Jun 11 14:44 4
Questions about "Max acceptable difficulty" Jun 11 04:24 2
"Post to BM" API Jun 10 12:11 5
"Configuration NOT changed" Jun 10 09:41 2
Error/Warnings in debug log: Should I worry? Jun 10 09:34 1
Bitmessage Security Test: ZWD attempt Jun 10 08:05 1
bitmessage inaccessible Jun 10 08:04 1
mailchuck.com email gateway Jun 10 07:47 3
Microsoft owns GitHub Jun 9 15:23 1
NIST key management guidelines suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys… Jun 9 11:25 12
Cloudflare MITM blocker Jun 9 11:21 4
GitHub Jun 9 11:16 15
Improvement of Trustedpeer setting Jun 6 06:26 2
blank blank blank Jun 6 06:26 5
is multiple trustedpeers possible? Jun 6 01:00 7
Bitmessage Documentation Bug Jun 2 10:09 4
REAL security experts endorse "security by obscurity" May 31 13:22 7
TRUE LOVE May 31 06:38 1
PyBitmessage Security ... Security Levels May 30 04:56 2
How to force BM to use only .onion nodes? May 30 04:56 15
Dread May 29 16:31 1
6F3F2CF9891928A25B71BBC4707B8753 May 29 10:56 1
SMTP and IMAP integration in the client May 29 06:21 5
Bitmessage Wiki Blocked May 29 00:51 12
Desiderata May 28 20:07 2
Bitmessage Bug May 28 17:15 2
I solved the Bitmessage Captcha Puzzle! May 28 08:56 2
setup trusted peer question May 28 08:05 6
bitmessagemain from pyinstaller executable won't run May 28 07:41 4
help with messages.dat May 28 07:36 7
Roll Your Own Crypto! May 28 07:06 6
look closely May 27 18:33 5
How to use chan alt.anonymous.messages May 27 08:21 2
feature request May 27 01:34 10
YOU WANNA HIRE A LEGIT HACKER????? May 26 04:39 5
Security Test on PyBitmessage Branch Master May 26 00:11 1
#2 May 25 22:41 6
minimum difficulty for chans May 25 16:45 11
BM-2cWkFSxB4cyeNVr99tgJdkMA2nfivbXLiH May 25 07:07 2