IT/Software career thread: Invert binary trees for dollars.

  • Guest, it's time once again for the massively important and exciting FoH Asshat Tournament!



    Go here and give us your nominations!
    Who's been the biggest Asshat in the last year? Give us your worst ones!

Deathwing

<Bronze Donator>
16,768
7,790
Any time I've ever written Python for work, it's been spaghetti code mishmash that I somehow made work and put it somewhere and forgot about it.

I assume most people developing in python do the same thing. "This isn't my job" lol
When I first started, I found working with Python really frustrating. I didn't know the language, no one else here really had a good IDE to recommend, so I was winging it in Notepad++. Admittedly, my year or so of code is really sloppy. I've since found that using an IDE with an automatic linter and intellisense really helps.

Honestly, this is less a Python thing and just people working with a language that's markedly foreign to their preference. I commonly find people that are used to curly braces, semi-colons, and strong typing, do not initially produce good Python code. And they complain a lot about indentation sensitivity.

I bet 10 years ago, we could find the same issues with shell and perl scripts.
 

Noodleface

A Mod Real Quick
38,287
15,129
I definitely write Python like I'd write a C program, and I've come to learn that is bad. However, I write Python infrequently enough (like 1-2 programs a year, max) that I just don't know if it's worth me learning it deeper than I have.
 

Asshat wormie

2023 Asshat Award Winner
<Gold Donor>
16,820
30,968
If you arent writing spicy list comprehensions (that no one in the world would understand) while wearing a fedora and calling yourself a pythonista, you arent really writing python.
 

Noodleface

A Mod Real Quick
38,287
15,129
I actually had a really great project where interpreting signal data on large files could take 60-90 minutes. My new program interpreted it exactly the same but in under 2 minutes.

I always felt like I should've gotten a fucking award for that
 
  • 1Quality Calories
Reactions: 1 user

Noodleface

A Mod Real Quick
38,287
15,129
It wasn't regex haha, it was signal data from a radar - no way.

We could never understand why it was so slow before. The original was in Java and ours was Matlab though so that probably explains 95% of it
 

Asshat wormie

2023 Asshat Award Winner
<Gold Donor>
16,820
30,968
It wasn't regex haha, it was signal data from a radar - no way.

We could never understand why it was so slow before. The original was in Java and ours was Matlab though so that probably explains 95% of it
Nothing prettier than properly vectorized code <3
 

ShakyJake

<Donor>
7,918
19,985
Since some of you work with firmware for embedded systems, maybe you can shed some light on this problem I have.

For some background: our company has a data manager that can communicate with a variety of devices from different manufacturers. As one of the developers, I am implementing support for a new device that was requested.

So, this particular device allows their users to update it's firmware remotely. So we are developing the option in our data manager to support this feature.

The update file is encoded as a base64 string, broken into 32kb chunks. We then transmit each of these chunks in a separate message along with an offset until the entire thing is sent.

The problem is, it's not clear to me how this "offset" is computed.

The vendor states:
offset = previous(PKG.block_offset) + previously downloaded data quantity

In other words, the block_offset is a number/offset/address that defines the position of the datablock (that would like to be downloaded) in the original/complete data (address/offset)

So the very first 32kb chunk would have an offset of '0' since we're at the beginning. The device accepts this. Next 32kb chunk I'm sending an offset of 32769 (32768 + 1) but the device NAKs us.

Any clue what I'm doing wrong? And this is all the information that was given to us. No examples or anything and the vendor is difficult to communicate with.
 

Deathwing

<Bronze Donator>
16,768
7,790
Time to bust out your oscilloscope! I'm assuming you've tried different offsets around 32kb, testing for ++ errors somewhere in the code. My initial guess is that the initial communication isn't being handled correctly to leave continued communication as a possibility. Is this SPI or I2C?
 

ShakyJake

<Donor>
7,918
19,985
Time to bust out your oscilloscope! I'm assuming you've tried different offsets around 32kb, testing for ++ errors somewhere in the code. My initial guess is that the initial communication isn't being handled correctly to leave continued communication as a possibility. Is this SPI or I2C?
Hah. Fortunately I'm not working that low level. Communication is done via a TCP/IP connection and the protocol is XML-based.

Wouldn't you just measure the size of the last transmitted chunk and start at that +1?
Right, that was my interpretation but it ain't having it.
 

alavaz

Trakanon Raider
2,003
714
Yeah I guess if the formula is previous + current you wouldn't want to put in the +1. I was assuming he had already tried without incrementing though. I'd try setting the first block to 1 as well.
 

ShakyJake

<Donor>
7,918
19,985
Yeah I guess if the formula is previous + current you wouldn't want to put in the +1. I was assuming he had already tried without incrementing though. I'd try setting the first block to 1 as well.
Yeah, I've tried several variations. Nothing works. I thought i may have missed a common approach used for this stuff. I guess I'll just have to ask for an explicit example from them.
 

Noodleface

A Mod Real Quick
38,287
15,129
Common approarch is just start at 0 and increment offset by block size

Only caveat are if they have header information or a wrapper on the chunk you need to split off. Other thing that's possible is they might not start at 0 or 1, could be funky.

Finally, it might be NAKing if it doesn't like the data you sent
 

Deathwing

<Bronze Donator>
16,768
7,790
Committed some code just now that's in response to review comments on a merge request. Unbeknownst to me, git will tell you how much of a file you've rewritten for a commit. I think this has a minimum threshold as it didn't report this on every file.

Food for thought: if responding to review comments ends up with ~75% of previously functioning code rewritten, is it at least possible the reviewer was being unreasonable? I'm not saying they're being malicious, that it was intentional, or that their suggestions were bad. More of a "out of scope" question.