DEV Community: Michael Brackett

Week 3 - Part 2

Michael Brackett — Wed, 29 Sep 2021 03:45:44 +0000

This time we learnt about Jumps, Branches, and Procedures.

Jumps literally means jump to another part of the code. Using this you can actual make conditional statements using compare instructions.

i.e. if accumulator = 6 jmp to label 'print'

Branches (which we used previously to create the week two lab you, you can view my blog post about it here) but in you can pretty much stop execution and 'branch' off to a different part. This is specifically useful in loops where you can check to see if the accumulator is equal to something, if it is you continue, if not you go back to the starting of the loop

Lastly you can use procedures, which are basically methods. You can use the instruction JSR to 'Jump to subroutine' and go to a different part of the code, once that executes it will return back to where the JSR instruction is and continue the execution there.

I think these three principles + the define and DCB would make working on the Week 2 lab a lot easier (And hopefully next weeks lab 'Pong' super easy)

It's a bit of a short blog this week but there wasn't a lot carried for this part of the lesson, next week while I'm working on the pong application I'm sure there is going to be A TON.

Week 3 - Part 1

Michael Brackett — Wed, 29 Sep 2021 03:22:48 +0000

Inside of week 3 we learn about math, but not just any math, math inside the 6502 emulator. We also learnt about creating the equivalent of a constant inside the 6502 which is called a Define Constant Byte (dcb).

What's actually cool about the dcb is that you can store anything inside of one. Want to store a smiley face? map out the colours and store it inside of a dcb! Blue box? Samething!

You can also store variables using the 'define' keyword. A good use case example of this is like storing a colour inside of a define keyword, something like

define WHITE $01

Now onto math, I won't go super into detail about this but I think addition was pretty cool when Chris was explaining it.

Basically, we use the 'ADC' (add with carry) instruction where it will add whatever you want to the accumulator + the carry flag.

I think a good example of this is on the cdot wiki here

LDA #$F0      ; A=$F0
CLC           ; C=0
ADC #$20      ; Result is $F0+$20+C = $110; therefore A=$10 and C=1
STA LOWBYTE
LDA #$30      ; A=$30
ADC #$01      ; Value is $30+$01+C = $32; therefore A=$32 and C=0
STA HIGHBYTE

Where this code adds $30F0 and $0120 together and stores it.

You may be wondering a couple of things, what is LOWBYTE/HIGHBYTE, well in a previous blog post you can find my explanation of what that does and why it's here (6502 is a little endian, my explanation is here)

You might also be wondering, what dos CLC (or C) mean? that's the carry flag, when something goes above what a byte can represent you need to turn on the carry flag so that the program knows that we had somewhat of an 'overflow'

Addition is simple, but we can also do subtraction, division, multiplication which make up the basics of math operations!

Week 2 - Part 2

Michael Brackett — Wed, 29 Sep 2021 03:10:01 +0000

In Week two we learnt about the Binary representation of data.

I never really thought about how my integers, floating points, or anything for that matter was REALLY stored in memory (Obviously I knew they were stored in bits somehow)

It was fairly interesting to find out that Fixed-Point numbers are stored by separating the binary into two parts, one number, and one part fractional.
Here is an example - 000001.00 is decimal 1.0, and 000001.11 is decimal 1.75.

Also watching the lecture, Chris explained something that caught my attention. Sometimes you can actually just make what seemingly has to be a double, an integer! How? Well think about it like this, when a bank needs to store how much money an account has in the system, they would typically need two parts, one for the dollars then one for the cents. Which would be stored like how I explained above. But what happens if they stored the entire thing denominated in cents? That way we can just store the entire number as an integer and make it easy on ourselves & only convert it back to dollars when we need to display it on the frontend.

Floating-point numbers actually have three parts, a sign bit (to determine positive or negative number) a mantissa, than an exponent. Here is how a floating point number is interpreted:

sign mantissa * 2^exponent

The last thing I'd like to talk about is compression of images which I found particularly interesting. Specifically the idea of 'Pallettization' in which an image in stored as a sequence of multiple colours instead of storing each colour separate think of it like instead of saying

blue blue blue blue blue green green

you just said - blue 5 green 2

See how it would make it a lot better in terms of compression? I never thought about how it was stored and I found it pretty cool that that's how they do it.

Overall I think Week 2 was pretty interesting, especially the lab!

Week 2 - Part 1

Michael Brackett — Wed, 29 Sep 2021 02:36:15 +0000

This blog post will speak about Week Two Part 1, which contains the lab 2

You can view Lab 1 using the cdot wiki here but in essence I had to draw 4 lines around a square in different colours.

Sounds easy right? Well, it's surprisingly difficult when you are working with 6502 Assembly code.

Below is my entire code for the program:

    lda #$00    ; load A with 00
        sta $40     ; set lowbit to 00
    lda #$02    ; load A with 02
    sta $41     ; set highbit to 02 (0200)

    lda #$05    ; load a with color green

    ldy #$00    ; set y index to 0

top:    sta ($40),y ; store A inside memory location $40+y highbit is 02, lowbit is 00 so 0200+y
    iny     ; increment y
    CPY #$20    ; compare y to hash value 20 (dec 32)
    bne top     ; if y does not equal #$20 go back to top

    lda #$05    ; load accumulator with final page (0500)
    sta $41     ; store a inside highbit
    lda #$06    ; load blue color into A
    ldy #$e0    ; load final line in Y (05e0)

bottom: sta ($40),y ; store A inside memory location $40+y highbit is 05, lowbit is e0 so 05e0+y
    iny     ; increment y
    cpy #$ff    ; compare y to hash value ff (end of line 05ff)
    bne bottom  ; get out of loop once you go to next page

    ldy #$00    ; reset Y to 00 (follow commands are to reset pixel to first line first pixel)
        lda #$00    ; load A to 00
        sta $40     ; store A inside lowbit
        lda #$02    ; load A with 02
        sta $41     ; store A inside highbit

left_to_right: 
    lda #$07    ; load A with colour yellow
    sta ($40),y ; store A inside memory location $40+y highbit is 02, lowbit is 00 so 0200+y (will change after first loop = 0200)
        tya         ; transfer y to a
        clc         ; clear counter bit for next line since we are adding
        adc #$1f    ; this addition skips to the other side of the bitmap

        tay     ; transfer a to y

        lda #$04    ; load A with colour purple   

        sta ($40),y ; store A inside memory location $40+y highbit is 02, lowbit is 00 so 0200+y (will change after first loop = 021f) 
        iny         ; increment y
        bne left_to_right ; restart loop until end of page

        inc $41     ; increment highbit to next page (first loop goes from 02 to 03)        
        ldx $41     ; load x with current page
        cpx #$06    ; compare page to 06 (05ff is final pixel of bitmap so if it equals highbit equals 06 we are outside of bitmap)

        bne left_to_right    ; restart loop if current page (highbit) does not equal 6

Here is what it outputs:

You can actually run the code yourself here

As you can see, it doesn't even look that great. Just 4 flat plain colours around the border of a square. But it was actually fun & interesting while I was working on it.

Something that I had trouble understanding was why we used memory location 40 when storing the accumulator when memory location 41 was where the actual page number was stored (40 just always contained 00).

Well Chris came to my rescue and explained to me that 6502 is something called 'little endian' which basically means that the memory locations are split in two, the lowbyte and the highbyte.
Take a look at this line and it might help you understand as well:

sta ($40),y ; store A inside memory location $40+y highbit is 02, lowbit is 00 so 0200+y

Basically we use the lowbyte to access the entire point in memory (40 = 0200).

Once I understood this concept the rest was fairly straight forward!

SPO600 - Lab 1

Michael Brackett — Mon, 13 Sep 2021 02:58:50 +0000

Lab 1 contained us finding two open source projects that had different licenses. You can find the exact details here: Lab 1 - Code Review Lab

The two open source projects I chose are previous projects that I actually looked into / committed to!

Seneca's Telescope Project

I previously had the chance to work on Seneca's Telescope project when I was in OSD600. It was a great experience. Basically Telescope is a blog aggregator which aggregates most of the Seneca students that have open source classes & need to blog about the progress.

This project is hosted on Github & is licensed under BSD 2-Clause "Simplified" License

You can find my pull request here where I changed the 'Guide' for the search box.

The review process was pretty simple and Telescope actually has a contributors documentation that you can follow along here

But in essence, a contributor chooses / creates an issue, then creates a pull request for it. Reviewers then take a look at the code and either approve it, reject it, or make some comments & hold off on approval or rejection. In this specific case, I had some changes that I had to make. The entire process took ~8 days (from creation of the pull request to merge) and had around 5 commits one of which was a rebase to pick up the latest changes from master.

The pull request also had to go through 3 checks before it could successfully be merged (Building on MacOS, Linux, and Windows)

Freetube

Freetube is an open source application that displays youtube without all the ad's, trackers, and anything else that is invasive to your privacy.

This project is hosted on Github & is licensed under GNU Affero General Public License v3.0

The pull request that I tracked was Pull request 1148. I chose this pull request because I actually previously made a pull request that got rejected which you can find here. My code changes did fix the problems but not for non-portable versions of FreeTube.

Freetube also has contribution documentation & guidelines which can be found here

Freetube is a lot more strict with their contribution but if you take a look at the pull request, but there is actually no discussion for the fix.

Look at their contribution document

This specific pull request actually took from March 28th to April 10th! Pretty long but to be fair the code change was fairly large.

In conclusion since both projects were on Github the contribution was similar but had differences in the response from the community. I also noticed a huge difference in where with the Telescope project, if there was something wrong they would tell me to fix it & keep the pull request up (then approve it after). With Freetube, the pull request was rejected & I was told to remake a new pull request. Maybe the reason why this did this was to remove the pull request from the queue & make it organized.

I think the advantage of the Telescope way is you give the chance for the programmer to keep working on the project & can continuously keep a stream of help for the programmer. Which the Freetube way you end the communication and leave the programmer in the dark when it comes to help (You can still post comments on the issue instead)

But the advantage for the Freetube way is that you don't have a bunch of open pull requests & you can keep it clean and organized.

Release 4.0 Final

Michael Brackett — Thu, 10 Dec 2020 06:30:40 +0000

Finally, I am done with my final pull request which you can find here.

This was a very hard bug to work with as I've never worked with an electron app before and I've also never worked with vue before. But it was pretty educational, and it gave me that good feeling I was looking for after fixing it.

Starting off from my last blog, I was correct in my finding that the code was never actually running because of the if statement, doing some more research throughout the code I actually found that the value that they were checking "this.descriptionHtml" was actually always going to be null because it was never set to anything in the first place. Once I fixed that I could use console.logs to test if I was getting into the function or not (Good ole trusty print statements). It found that weirdly enough I was getting into the function but nothing in the description was changing. This was because I needed to add another line that changed the static text of the description to include all the proper linkers and tags in it, like if there is a link add a tag around it and make a href for it.

Luckily that was fairly easy as there was a package that they used to do so, now comes the more difficult part, figuring out why exactly the program wasn't actually changing the description href. Well the short answer was that the old regex from a past contributor actually was wrong, and I guess he never knew that it was wrong because he could never test it properly because the function would never run properly.

After fixing the regex (which took me a while to find the proper regex for it) and replacing it with the proper link I finished the bug.

This bug took me probably the longest so far in the class totalling at around 3-4 hours. But let me tell you, the hardest, longest, and most confusing bugs are always the ones that feel the best once you fix them.

In addition this was actually the first bug that I fixed throughout OSD600 so it was cool working on someone else's broken code and trying to fix it up.

Well that's all for me this semester, I had a incredible time working with all of you and I wish you the best in the new semester.

And to my teacher, thank you for teaching this course. I really liked every aspect of this course (especially Hacktoberfest) and you really were supportive to students that needed the help. I'm looking forward to working with you in OSD700 next semester!

Now all I have to do is just wait for my pull requests to be merged.

Release 4.0 Mid point

Michael Brackett — Thu, 10 Dec 2020 06:18:51 +0000

During the middle of Release 4.0 I have fixed the description to jsonMergeUtil and fixed a bug in the program which gave me a hard time to actually find out why this was happening.

Basically Python has a library called logger, where you can log stuff. In my previous request I added an optional argument when running the program to specify the logging level, if you are logging at INFO it will output whatever is loaded into the logging.info variable in another file called output. Basically it wasn't outputting anything, which was pretty bad because that means that my last commit to this repository actually broke the program a little bit. Luckily I could fix this program in just 1 line after a while of searching through the logger documentation.

I've also decided to pick up another issue from a project named dev-jot which is a web based project that allows developers to jot down note quickly (I really like the idea). The pull request that I made can be found here. It was very small and just a little pull request but I actually had to do some research about viewports and meta tags, which I think is actually going to be really useful for me since I can implement this in my own personal website mljbrackett.com

While it was small I actually learnt some good things about using Google Lighthouse to give your website a quick score on how you are doing.

I have also begun work on my third issue which is from the project FreeTube. I've done a little work on it so far and have narrowed down the larger problem to one of the functions that needs to be run never actually gets run because of an if statement calling it. I haven't gotten past that yet and am still looking into it.

I'm looking forward to fixing this bug though cause it's a hard one and this is for sure gonna feel good when I fix it.

Weirdly enough I get such a great feeling when I fix a hard bug but I assume most developers feel the same way.

Release 4.0 Starting

Michael Brackett — Tue, 08 Dec 2020 06:28:26 +0000

For our final assignment we are supposed to work on something that builds upon our recent projects, something bigger or something more involved.

I've decided to go back to one of my favorite repos that I have worked on during this course which you can find here Basically what I have to do is update the documentation for the tool. I chose this issue because it was actually me that originally changed the feature in the first place so it would make sense that I get to update the documentation of the tool as well.

I think this demonstrates something that's good about Open Source programming, while it is just a documentation fix, it shows consistency of working on a project, I assume this is also what it would sorta be like in OSD700 (Working on a bigger project throughout the term)

The reason I came back to this one is because of the great experience that I had with the owner of the repo, he was very helpful and actually gave me constructive criticism on the work when I created my last pull request which you can find here (A total of 28 comments!) I also really like the tool that Blank1611 has created, basically it just compiles a bunch of separate JSON objects into one big object.

For the second issue that I decided to take on I wanted to go for something that was more of a bug/feature request for a repository that I have never worked on before you can find the issue here This will be my first bug fix that I do in the course, normally in the past pull requests that I made they were always additions of features, so I am excited to dive into some buggy code (Hopefully its not that bad)

Lap 9 - OSD600

Michael Brackett — Sat, 05 Dec 2020 06:57:53 +0000

For this week we were tasked with finalizing our Link Checker program, as always you can find mine here

Basically we had to package our program and host it on a dedicated package website, for my Python program I chose: https://pypi.org/

What was the process for creating a release? Be detailed so that other developers could read your blog and get some idea how to do the same.

The process was generally easy and PyPi had some great documentation on how to package and host your program, mostly I had to set up 1 file (Which I just copied and pasted from their tutorial then changed a bit of it) and then run a few commands to get it hosted.

I had to change A LOT of my programs file structure in order to host the package cleanly and to get it running globally from the command line, I found out that I can actually use something called command entries to achieve this though.
The biggest time waster was having to restructure my code and order them in files, but honestly this was probably for the better anyways since it's a lot easier to work with now.

My user testing was pretty smooth but I also realized that I had to change my documentation to include that you could download it on PyPi from this point forward, So now I have two different installation instructions. One of the contribution page. Incase other programmers wan't to get started and help out, and one in the Readme.MD so the average person can just install it from PyPi and use the tool directly.

I chose someone that had no programming experience, which obviously they had trouble installing the program (using git clone and stuff) But actually running the program and using the commands was very easy for them to do so. I did a second run with the updated readme.md (The one that says to download it from PyPi) and that went a lot smoother since there was no other tools needed to install the program.

You can download the release of my Link Check project at:
Link Check

Lab8 OSD

Michael Brackett — Fri, 27 Nov 2020 20:11:00 +0000

This week we were tasked to implement testing functionality within our link checker code. You can find mine here.

The testing framework that I chose was Unittest, it is the basic testing framework and is actually included inside of Python with newer versions. You can find the link to it here

The code coverage tool that I used is called coverage, which you can find here.

Both of these tools were very easy to implement inside my project, all I had to do was install them with pip and off I could go with coding. (I also had to put them inside my requirements.txt file so other programmers could download them easily)

This was a very educational lab for me because I wasn't writing my code with testing in mind, this gave me a lot of trouble since I had to refactor a lot of my code so I could easily access the functions that I needed to test. If I could go back and rewrite my code for the first time, I would for sure do it with testing in mind. (But sadly I didn't even know anything about testing when I first started my link-check program)

Unittest actually has a built in mock feature using the keywords @patch and mock. Basically using @patch makes it so that any request that would be sent out by your program doesn't actually get sent out anywhere and instead will get replaced by the values that you put in.
These two lines is how I approached networked mock tests.

@patch("link_check.requests.head")  # Mock 'requests' module 'head' method.
mock_head.return_value.status_code = 200

Something that came up when I was running my code coverage analysis that I had a big problem with was getting it to run down all the pathways since I used an argument library to choose which part of the code to run. If I had to go back and do it again I would probably choose a framework that I could easily change the arguments that I am running with my code so that I could test all pathways of my code, but in the end I reached a 74% code coverage when I ran it with my tests which I think it pretty good, but can for sure be improved.

The GitHub Actions CI Workflow was very easy and all I had to do was make sure that It ran this line when it built:

python3 unittest

This would test all the files within the repository that had the keyword test in them.

I partnered up with someone that wrote his project in Go, this was pretty interesting since I never programming in Go. Fourtentatly for me his documentation was very straight forward and to the point so I could get coding right away, looking at other tests that he wrote I was able to pick up the syntax that I needed to use to write my tests. Overall it was fairly easy to write tests for my partners code.

I will 100% keep in mind testing while I am writing functions now. Another great thing is the Github Actions Workflows, these are very cool and I am actually going to be implementing it in my own personal website, which you can find here This way, when I create a pull request to my repository I can have a hosted pull request on netlify or something that shows the changes that I made before I accept the pull request. Something like how our telescope pull requests work.

Release 3.0 P-2

Michael Brackett — Tue, 10 Nov 2020 23:34:33 +0000

For Release 3.0 we needed to create two pull requests, one to an external repository and one internal to Seneca College, this blog is about my pull request to an internal repository.

During my work on the external pull request requirement of this Release, user c3ho on our Slack team posted an issue involving UI changes. I thought this was going to be easy enough and decided that I would like to give it a shot as my first pull request to the Telescope program. The issue can be found here and you can find the pull request that I made here

Basically, I was tasked with creating a UI that would explain to the user how to use the new Search Query functionality created in pull request #1275

Starting up my development enviorment was very easy considering that I had to set everything up in a previous lab, so it was as simple as running the command

npm run develop

Which I found in the Telescope deployment docs

After this I got straight to work and started researching on the best way to develop this feature, I decided that it would be best to keep true to the design that the previous developers created and I didn't want to do anything out of the ordinary that would draw away from the attention of the page. My fix was a hoverable info icon that has a popout that would explain all the new key symbols that users can use when searching.

It looks nice and clean and doesn't create to much of a difference in UI design from the previous developers that worked on this page.

I had to do a lot of research about material UI & react which I never used before, primarly I had to choose between all of these different tooltips but I settled on the HtmlToolTip because this would give me the most freedom to choose how I would like the design to be once the user hovered over the info button.

The biggest take away was the use of Material UI which seemed to be incredibly useful as my first 30minutes was trying to just use basic HTML inside the component. There is an abundance of tools that will be at your disposal when working with Open Source projects and you can't be scared to learn new skills if you want to create good pull requests.

Release 3.0 P-1

Michael Brackett — Tue, 10 Nov 2020 23:11:59 +0000

For Release 3.0 we needed to create two pull requests, one to a external repository and one internal to Seneca College, this blog is about my pull request to a external repository.

For Release 3.0 I wanted to submit another pull request to a repository that I previously worked with (It also actually told us that we might want to do this is the assignment page) The repository that I chose was the one that I had the most trouble with previously, Awesome Adoption. I liked contributing to this repository because:

I had some trouble fixing my past issues and it taught me a lot
I think the website could be useful and I support what the owner of the repo is trying to create

The pull request that I did you can find here, its about issue #26. Basically, I was tasked with creating a resource page in React and adding information about, Adoption, Covid-19, and Adoption during Covid-19. I found this pull request to be pretty interesting because I had to do a lot of research about adopting pets. Did you know that every year around 6.5 million companion pets enter shelters in just the USA, and thats only dogs and cats. Out of those 6.5 million, only 3.2 million are adopted and 1.5 million are euthanized (Statistics provided by ASPCA).
This leaves 1.8 million pets that go untouched each year

This submission reinforced my ability in React web programming which funniliy enough was well needed since Senecas Telescope program is written with React. This pull request helped me greatly and was a refresher of the React syntax so when I started work on the Telescope problem I could get right into it.

Another reason why I think this pull request is important is because I think it shows a very important part of open source development, like my last pull request to this repo all I had to do was create a placeholder image. This pull request I had to do a lot of research, when working on Open Source projects you may be tasked to do something that doesn't entirely relate to programming but instead relates to the project it self. Even though I did a bunch more programming in this pull request than my last, I think both demonstrate something more about Open Source programming which weirdly enough is that it's not all about programming.