text:
# Schrodinger's Bug: Adventures in Asynchronous Debugging
Published March 20th, 2016

Lately I've been writing integration tests for [Elsen](https://elsen.co)
using node.js to verify our Haskell backend is indeed returning to us
what we expect to be there. Using a combination of the Mocha, Chai, and
Supertest frameworks I've managed to make a comprehensive set of tests.
It's a simple process: Mocha runs the tests and outputs if everything
passed or not, Supertest makes the actual requests to our API, and Chai
verifies the JSON we get back is what we would expect. One of our tests
would look like this:

```javascript
//This is our context that certain endpoints are wrapped in
context('Functions', function() {
  //This is the more specific context and where we start usin endpoints
  context('Syntax Checking', function() {
    var endpoint = '/v2/syntaxcheck';
    var syntax, syntax_res;

    //This is one of the tests. It makes the request with API
    it('Syntax is valid', function(done) {
      syntax = 'function succ(x) { return (x+1); }';
      API.post(endpoint)
        .set('Authorization',LOGIN_TOKEN)
        .send(syntax)
        .expect(200)
        .expect('Content-Type', 'application/json; charset=utf-8')
        .end(function(err,result) {
          //Here we make the actual comparisons
          //Done is used for all the calls because they're asynchronous
          if (err) return done(err);
            syntax_res = result.body;
            syntax_res.should.to.equal(true);
            done();
        });
    });

    //This is like above but we have an error here that I spent about
    //two days debugging. Look at the previous one and see if you
    //can figure it out at all.
    it('Syntax is invalid', function() {
      syntax = 'function succ(x) { return (x+ }';
      API.post(endpoint)
        .set('Authorization',LOGIN_TOKEN)
        .send(syntax)
        .expect(200)
        .expect('Content-Type', 'application/json; charset=utf-8')
        .end(function(err,result) {
          if (err) return done(err);
            syntax_res = result.body;
            syntax_res.should.to.eql(
              { msg: 'Parse error at line 1, col 31', position: { line: 1, col: 31 } }
            );
          done();
      });
  });
});
```

Note that these are only a small section of the thousands of lines of
code written to test the API. One error here though made me frustrated
to no end. If you ran these tests as they're written above then they
both pass without issue.

I discovered the issue when I was adding some more tests. I tested
whether or not the JSON I got back even it existed. The test said it
did. Then I tried to console.log() the result. Nothing was printed out.
I tested if it didn't exist as well. That test also passed. How can the
JSON I'm getting back both exist and not exist simultaneously? This
made absolutely no sense! Much like Schrodingers famous thought
experiment I had something that existed and didn't until I tried to
observe it.

Now what? The test I was doing was a POST as well much like my syntax
checker endpoint. I also had some more that did a POST. I changed each
of them to make them wrong and fail. I verified the correct results
using curl to hit the endpoints manually. I ran the tests again. All
the ones I changed failed except the syntax checker. This was where I
started to go crazy. How come it worked for some of them but not all of
them? I added a console.log() to the syntax checker as well just to see
if I got anything unlike the first time. That's when I really started
to lose my mind. I got a result back this time. What I didn't realize
then though was that the result should have printed out where my test
executed not later on in the middle of another test.

Visually it looked like this:

```bash
#Syntax Test executes here
Pass
#More Tests
Pass
#More Tests
Pass
#Syntax Test Result Outputs here
{ JSON }

#It should have been like this:
#Syntax Test executes here
Pass
#Syntax Test Result Outputs here
{ JSON }
#More Tests
Pass
#More Tests
Pass
```

I spent many hours checking documentation and checking to see if it was
a bug in versions of the testing frameworks. Long story short none of
that helped in the slightest. I was chasing a red herring. That's when
I commented everything out but the login test (in order to authenticate
our connections) and the syntax check test. This test still had the
console.log() statement. Guess what? Nothing printed this time! This
was the second day I was working on this test and still nothing. My
boss Zac came in at this point to help me out and we spent a while
trying to figure it out. We lloked at the docs again and other working
bits of my code. That's when we figured it out. The fact one word was
not used caused the tests to pass.

I had forgoten one word in the whole process that would cause it all to
work as intended: done.

Remember this line of code?

```javascript
it('Syntax is invalid', function() {
  //Other stuff is in here
});
```

The anonymous function is missing the word done as a parameter. The
tests normally use it in those .end() calls I make to tell the test to
wait for whatever is in there to complete because it's asynchronus.
However without that done statement the .end() function wasn't even
being entered into causing the tests to pass otherwise. When a result
was logged later it was because it had finally been processed. When it
wasn't, that was because the test framework had already completed
running all of it's tests and so didn't bother to print the results!

Needless to say I was relieved to finally have the tests working as
expected. I learned quite a bit about debugging asynchronous code,
something I've never really touched upon. I've normally dealt with
either synchronous code or just sequential execution making this an eye
opening experience. The main take away is that if you are doing
asynchronous code make sure that you have your callback defined if you
want it to wait for the result!

repository: davidbarsky/mgattozzi

repo_name: davidbarsky/mgattozzi


text:
---
layout: default
---

# 1994-08-31 - Arizona State Email Non-Privacy Policy

## Header Data

From: "Gary Jeffers"<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 455befd8a7500e0d8c121196312b7816616e35a4d772a6ab30ae9b1aaa9dc35b

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1994-08-31 18:10:08 UTC

Raw Date: Wed, 31 Aug 94 11:10:08 PDT

## Raw message

```
{% raw  %}From: "Gary Jeffers"<EMAIL_ADDRESS>Date: Wed, 31 Aug 94 11:10:08 PDT
To<EMAIL_ADDRESS>Subject: Arizona State Email Non-Privacy Policy
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Netsurfer writes:

>Within the US Gov't it is not uncommon to be told that you are not to
>receive personal phone calls on government time/government equipment.  ot
>every office etc. enforces it, but it _is_ their equipment and you are
>working on _their_ time.  Seems kinda harsh, but is legal and within thir
>rights.  Naturally emergencies are an exception.

  I have some problems with this: "It is their equipment and you are
working on their time". Govt property is stolen property. To agree
that you are dealing with their property & their time is to confer
legitimacy on their theft.

  I have problems with this: "...and within their rights." The relation-
ship between rights & legal rights of the state is something like that
of turtle soup to" real mock turtle soup".

   I don't wish to flame you, but if we confer legitimacy to the state
thru our common conversation then it will be hard to free ourselves.

                                        PUSH EM BACK! PUSH EM BACK!
                                        WWWAAAYYY  BBBAAACCCK!
                                        BBBEEEAAATTTT  STATE!
                                        Gary Jeffers

{% endraw %}
```

## Thread

+ Return to [August 1994](/archive/1994/08)

+ Return to "["Gary Jeffers" <CCGARY@MIZZOU1.missouri.edu>](/authors/gary_jeffers_ccgary_at_mizzou1_missouri_edu_)"

+ 1994-08-31 (Wed, 31 Aug 94 11:10:08 PDT) - Arizona State Email Non-Privacy Policy - _"Gary Jeffers"<EMAIL_ADDRESS>

license: MIT

branch_name: refs/heads/master

extension: md

gha_license_id: MIT

license_type: permissive


text:
JbFileUploaderBundle
====================

[![SensioLabsInsight](https://insight.sensiolabs.com/projects/fc4abd08-89d9-45cd-bbae-9bda5d39ed97/mini.png)](https://insight.sensiolabs.com/projects/fc4abd08-89d9-45cd-bbae-9bda5d39ed97)
[![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/jbouzekri/FileUploaderBundle/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/jbouzekri/FileUploaderBundle/?branch=master)

This bundle aggregates the following bundles to provides ajax file upload with crop and validation :
* [OneupUploaderBundle](https://github.com/1up-lab/OneupUploaderBundle) : server implementation for file upload
* [KnpGaufretteBundle](https://github.com/KnpLabs/KnpGaufretteBundle) : Filesystem abstraction to store file on different support
* [LiipImagineBundle](https://github.com/liip/LiipImagineBundle) : Image resize

Documentation
-------------

[Documentation](https://github.com/jbouzekri/FileUploaderBundle/tree/master/Resources/doc/index.md)

Preview
-------

![Preview FileUploaderBundle](Resources/doc/img/screenshots.png?raw=true)

License
-------

[License](https://github.com/jbouzekri/FileUploaderBundle/blob/master/LICENSE)

repository: bluntelk/FileUploaderBundle

repo_name: bluntelk/FileUploaderBundle


text:
---
layout: post
title: First Week at BlueBolt Solutions
category: "Rovani in C♯"
excerpt_separator: <!--more-->
tags:
- career
---

{: .centered }
![BlueBolt Solutions](/images/bluebolt-logo.png)

After nearly 7 years of full-time employment with IFCJ (and five years prior to that of part-time consulting work), I have chosen to move to other opportunities and challenges. This presented itself in the form of an offer from [BlueBolt Solutions](https://blueboltsolutions.com) to join their team as a Senior Solutions Architect. My primary duties will consist of being a technical lead across several projects of varying size, architecting and scaffolding solutions, work with the project managers to ensure timely delivery of the completed project, and mentor junior/mid-level developers as they work on the project.

<!--more-->

## Day One - Initialization

As I expected, the first day was all about setting up my environment - getting applications installed, accounts initialized, paperwork completed. It has been quite a long time since I have built a work setup from scratch, so I fully expect to have forgotten tools that I used regularly. A (non-exhaustive) list of what I have already put in place:

- Windows Subsystem for Linux (WSL) and Ubuntu
- Visual Studio Code, including changing the default terminal to Bash and getting the environment set-up to run Bundler and Jekyll (for writing these posts).
- Visual Studio 2019 Professional
- Edge (Insiders, Chromium)
- LastPass + Browser extensions
- LinqPad
- Microsoft Office Products
  - Teams
  - Outlook
  - OneNote
  - Word
  - Excel
- Node.js (for future React projects)
- Spotify

## Day Two - 8:00 Is Early?

I arrived at the building today at 8:00, only to find that it was locked! Thankfully, a deliver driver and an employee of another office in the building were both walking in just before me, and so I was able to walk in behind them. I'll have to find out when the building opens up, and how I can get access before then. Additionally, when I came up to the office, the lights were on and the door was unlocked, but there was no one inside. It's definitely a big change from IFCJ, where people started rolling in at 7:00, and the office was in full business mode by 8:00. I also need to get a key to the office and find out the feasibility of me starting work at 7:00. Will there be awkward moments when I'm leaving at 4:00? I'm sure it'll all work itself out.

Later in the day, I joked about being all alone in the office. I was given a set of keys, today - which is great. I can now come whenever I need to. I think I'm going to end up really appreciating the quiet in the morning - a chance to really get some dedicated work done.

## Day Three, Four, Five - Getting Rolling

It turns out that there are about two other people who roll in before 8:30 - both of which seem to really like keeping a quiet, productive first hour or two. Which works out perfectly for me.

This first project, which fairly straight-forward, has its own set of challenges just getting up to speed. BlueBolt doesn't really have a formal structure for how projects, work items, branch policies, etc., are configured in Accelo or in Azure DevOps; however, this grants me incredible freedom to template the workflow how I would like it. Especially since the developer that will be doing the work is fresh to the company, there are no preexisting biases that I have to accomodate.

I'm going to keep detailed notes on what I created that worked out well and what needs tweaking for the next project. My long-term hope is to be able to get all of the Architects to converge on a very similar style of rules and structure in Azure DevOps, making it easier for developers to transition between teams.

branch_name: refs/heads/main

gha_language: HTML


text:
---
title: II-2 — Proctor Test and Slack Tips
computer-lab: false
---

When writing about a movie, or book, it's common to format the title to make it look different.

---

One way is to make the title _italic_. You can do that on Slack by surrounding the title with an underscore on each side.

e.g.
`_Your Name_` ---> _Your Name_
I think _Your Name_ looks like a great movie.

---

You can also make text **bold** by surrounding it with asterisks.
* <--- that is an asterisk.

e.g.
`*Your Name*`---> __Your Name__
The plot of __Your Name__ looks very interesting.

---

And if you want, you could make titles appear as both *bold* and _italic_.

e.g.
`_*like this*_` --->  ***like this***.
or
`*_like this_*` --->  ___like this___.

gha_language: CSS


text:
# tater:router

This package defines all routes in tater. Other packages contain templates for each page-level view, and this package renders them into the main layout.

This package creates a global `path` template helper.

repository: ecohealthalliance/mantle

gha_language: JavaScript

repo_name: ecohealthalliance/mantle


text:
---
title: Resize and compress a PDF in Linux
date: 2022-02-26 00:00:00 +0100
categories: [Linux, command line]
tags: [pdf, boox]
---

![My Boox Note Air2](/assets/img/posts/boox_note_air2.jpg){: width="700"}

I recently got my [Onyx Boox Note Air2](https://shop.boox.com/products/noteair2) and I'm loving it! It's an e-ink Android tablet that can be used as a classical e-reader, but it also allows taking notes with a stylus. Boox notebooks can be exported to PDF, and these PDFs can then be retrieved through BooxDrop on your PC.

The only problem is that these PDFs are *huge*. A 15-page notepad I exported weighs 29 Mb. Here is my solution to this problem:
1. First, I scale the PDF to 50% size. While this does not impact the file size significantly, it reduces the physical paper size to something more reasonable (the Boox Note Air2 is approximately A5 size).
2. Then, I compress the PDF by specifying the DPI to be something that I still find readable while the file size is greatly reduced (by a factor 10 from my tests).

First, install the required packages: `cpdf` and `imagemagick`.

Scale PDF to 50%:

```bash
cpdf -scale-page "0.5 0.5" in.pdf -o in_scaled.pdf
```

Compress PDF (100 DPI, specified below as `100x100`, works fine for me):

```bash
convert -density 100x100 -compress jpeg in_scaled.pdf out.pdf
```

With the above, I managed to shrink my 15-page notebook from 29 Mb to only 2.8 Mb.


text:
# ZIPLOC
*Nikki Nikki, where you been?*

Made a lil game for a special [dirty boi](https://www.instagram.com/xelelel/)'s birthday. First time using A-Frame and second time with Glitch!

## [Take A Drag](https://ziploc.glitch.me/) 🚬

(shout out to Tyler the Creators dope freestyle "Ziploc" that inspired the creation of this project)

repository: Teresawithoutah/ZIPLOC

repo_name: Teresawithoutah/ZIPLOC


text:
# SBNF

A BNF-style language for writing sublime-syntax files.

## Motivation & Goals

Writing syntax definitions is error prone and the result is hard to maintain.
The addition of `branch_point`, while a great feature, dramatically increases
complexity and duplication when used.

SBNF attempts do the following:
* Provide a maintainable, declarative language for writing sublime syntax
  definitions
* Compile quickly for fast iteration
* Compile to an efficient syntax, comparable to hand-made ones

## Usage

A SBNF file contains two types of elements: headers and rules. Headers provide
meta-data for the syntax, such as it's name, while rules are the bnf-style rules
that define the parsing and scoping of the grammar.

See `sbnf.sbnf` for a full example grammar.

### Headers

Headers are in the form `<head>: <value>`, ending at the end of the line. The
following values are allowed:

* `name`: The name of the syntax. This defaults to the name of the sbnf file.
* `extensions`: A space-separated list of file extensions. Equivalent to
  `file_extensions` in sublime-syntax.
* `first-line`: A regex for matching the first line of a file. Equivalent to
  `first_line_match` in sublime-syntax.
* `scope`: The default scope for the grammar. This defaults to `source.`
  followed by the name lowercased.
* `hidden`: Whether the syntax will be shown in the menu in Sublime Text.

Example:

```
name: SBNF
extensions: sbnf
# Don't need this, as this is already the default
# scope: source.sbnf
```

### Rules

Rules are in the form `<identifier> <arguments> = <expression> ;`.
Identifiers may contain any alphanumeric character as well as `-`, `_` and `.`.

Like sublime-syntax files, SBNF grammars have two entry points: `main`,
`prototype`. They behave identically to those in sublime-syntax files. Only
rules used directly or indirectly from an entry point are compiled.

Arguments come in the following form: `{<arg>, <key>: <value>}`. `<arg>`,
`<key>` or `<value>` may contain any text except `,`, `:` or `}`. There may be
any number of arguments given, as allowed by whatever the arguments are for.
When there are no arguments the `{}` are optional.

The following arguments are allowed for rules:

* `<meta-scope>`: The meta-scope of the rule. Equivalent to `meta_scope` or
  `meta_content_scope` in sublime-syntax.
* `include-prototype: <bool>`: Whether to include the `prototype` rule in this
  rule. Equivalent to `meta_include_prototype` in sublime-syntax. `<bool>` must
  be either `true` or `false`. Defaults to `true`.

Expressions may take any of the following forms:

* `` `<literal>` ``: A terminal matching text literally.
* `'<regex>'`: A terminal matching text according to a regex.
* `<identifier>`: A non-terminal matching another rule.
* `<expr> | <expr>`: An alternation of expressions. The grammar matches either
  the left or right expression. This can be used as a list, eg:
  `'a' | 'b' | 'c'`.
* `<expr> <expr>`: A concatenation of expressions. The grammar matches the left
  expression followed by the right expression. This can be used as a list, eg:
  `'a' 'b' 'c'`.
* `(<expr>)`: A grouping.
* `<expr>?`: An optional expression. The grammar matches nothing or the
  expression.
* `<expr>*`: A repeating expression. The grammar matches the expression any
  number of times, including 0.
* `~<expr>`: A passive expression. The grammar matches *any text* until the
  expression matches.

Literal and regex terminals are allowed the following arguments:

* `<scope>`: The scope of the terminal.
* `<capture>: <scope>`: The scope for a regex capture group. `<capture>` must be
  an integer.

## Limitations

### Regex Equivalence

When determining whether to create a branch point in the sublime-syntax, SBNF
has to consider whether regexes overlap. Take the following example:

```
main = 'aa?'{scope1} 'b'
     | 'a'{scope2} 'c'
     ;
```

The regexes `'aa?'` and `'a'` both match `a`, meaning a branch point would be
required to correctly parse this syntax. SBNF *does not* create a branch point
here. Due to the complexities of regex, a branch point is only created with
equivalent regexes. Rewriting the example to work as expected with SBNF yields
the following:

```
main = 'aa'{scope1} 'b'
     | 'a'{scope1} 'b'
     | 'a'{scope2} 'c'
     ;
```

This is unlikely to change in the future, as SBNF does not make any attempt to
understand any regexes.

## TODO

* Implement literal matches `` `like this` ``. Currently only regexes work.
* Fix known edge cases in compiler. In a couple places we panic!() instead of
  providing an implementation.
* Implement a proper command line interface.
* Implement proper error formatting
* Fix argument parsing when more than one scope is used
* Additional tests for compilation

repository: floydawong/sbnf

repo_name: floydawong/sbnf


text:
Evaluation of built in tokenizers are made using TsCorpus (`sadedgel.dataset.tscorpus`)

| Tokenizer       |   IoU (macro) |   IoU (micro) |
|-----------------|---------------|---------------|
| bert            |        0.8604 | 0.8702   |
| simple          |      0.8314   | 0.8395   |

Results can be reproduce by using

`python -m sadedegel.bblock tokenizer-evaluate`


text:
[![All Contributors](https://img.shields.io/badge/all_contributors-1-orange.svg?style=flat-square)](#contributors)
![StandardRB](https://github.com/andrewmcodes/dishwasher/workflows/StandardRB/badge.svg)
![Tests](https://github.com/andrewmcodes/dishwasher/workflows/Tests/badge.svg)

# Dishwasher

A CLI tool written in Ruby to help you remove unneeded GitHub forks.

## Installation

```sh
  gem install dishwasher
```

## Usage

[![asciicast](https://asciinema.org/a/311548.svg)](https://asciinema.org/a/311548)

## Development

After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/andrewmcodes/dishwasher. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.

### Code of Conduct

Everyone interacting in the Dishwasher project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/andrewmcodes/dishwasher/blob/master/CODE_OF_CONDUCT.md).

### Coding Standards

This project uses [Standard](https://github.com/testdouble/standard) to minimize bike shedding related to code formatting.

Please run `./bin/standardize` prior submitting pull requests.

## License

The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

## Contributors ✨

Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):

Andrew Mason
💻 📖 🔧 ⚠ 🚧

Kurtis Rainbolt-Greene
🐛

This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!

repository: andrewmcodes/dishwasher

gha_language: Ruby

repo_name: andrewmcodes/dishwasher


text:
# Rhino Developer Samples

<img align="left" src="https://github.com/mcneel/developer-rhino3d-com/blob/master/images/dev-logo-rhino-small.png">

This repository contains all the sample developer code for programming in the Rhino and Grasshopper ecosystem.

The source of this repository will be used to populate the [Samples](http://developer.rhino3d.com/samples/) section of the [Rhino Developer website](http://developer.rhino3d.com/).

Much like the Rhino Developer website, the version of Rhino that these samples are compatible with are determined by which branch of this repository one is viewing:

- The `master` branch corresponds to the current, stable, shipping version of Rhino.
- The `wip` branch corresponds to the version of Rhino currently in active development.
- Older versions of Rhino will be archived into version-specific branches (for example: `5`).

## Samples by SDK or Language

The samples in this repository are organized by folders that correspond to the different SDKs that make up the Rhino development platform.  For more information about the different Rhino SDKs and supported languages, please see the [Rhino Developer website](http://developer.rhino3d.com/).  This repository contains samples for:

- [C/C++](cpp)
- [Grasshopper](grasshopper)
  - [C#](grasshopper/cs)
  - [Python](grasshopper/py)
  - [VB.NET](grasshopper/vb)
- [openNURBS](opennurbs)
  - [C/C++](opennurbs/cpp)
  - [C#](opennurbs/cs)
- [RhinoCommon](rhinocommon)
  - [C#](rhinocommon/cs)
  - [Python](rhinocommon/py)
  - [VB.NET](rhinocommon/vb)
- [RhinoMobile](rhinomobile) (C#)
- [RhinoPython](rhinopython)
- [RhinoScript](rhinoscript) (VBScript)

## Building Samples

TODO: More info about building coming soon.

**Why are the sample projects prefixed with the word Sample?**

We gave each sample project a unique name in order to avoid command name collisions when these samples are run in Rhino.  The word Sample is prefixed to distinguish it from developer "Test" commands that sometimes used to test out new functionality in Rhino.  Since it is possible - and probable - that samples might be built, run, and tested in multiple languages, so we opted for a language code (C/C++ samples omit this simply because they came first), before the name of the sample.

## Testing

TODO: More info coming soon

repository: angellinares/rhino-developer-samples

repo_name: angellinares/rhino-developer-samples


text:
# Supporting the patcher

OpenCore Legacy Patcher is a hobby project for us developers, and while we love helping out the community it's very difficult for us to troubleshoot issues remotely. The best way for us to get to work on the patcher, fix issues and add enhancements is having the hardware in-hand. As a hobby project, neither of the main developers can afford to buy every legacy Mac to test on.

The best way to support us in all honesty is to donate any old hardware you no longer need, as this allows us to have machines to test locally and push fixes much faster. While we appreciate cash donations, this makes it much more difficult for us to handle as an organization.

Main hardware we'd appreciate:

* Any Mac you own
  * Does require SSE4,1 CPU to test on Sierra and newer however

Additionally, hardware info dumps are greatly beneficial for us to determine what patches a machine might need:

* [IORegistryExplorer](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-210.zip?raw=true)
  * `File -> SaveAs` and open an issue on Github
  * Note: We want IOReg dumps of hardware not running on OpenCore, instead running a clean, supported OS

If you have any legacy hardware you're willing to donate, please contact us at the following email:

*<EMAIL_ADDRESS>
Current hardware we own:

| Model | CPU | GPU | Owner | Notes |
| :--- | :--- | :--- | :--- | :--- |
| MacBook7,1 | Penryn | GT320M | Dhinak | N/A |
| MacBook7,1 | Penryn | GT320M | Mykola | N/A |
| iMac11,2 | Clarksdale | HD4670 | Mykola | N/A |

<!-- | MacBookPro5,3 | Penryn | 9400M + 9600M | Dhinak | Display's partially broken | -->
<!-- | Macmini4,1 | Penryn | GT320M | Dhinak | N/A | -->

repository: guanzhangrtk/OpenCore-Legacy-Patcher

gha_license_id: NOASSERTION

repo_name: guanzhangrtk/OpenCore-Legacy-Patcher


text:
# Policy gradient agent

## CartPole

With the following configuration after 2000 eposides, it converges almost perfectly

```
# cartpole.py discount_factor learning_rage entropy_factor
taskset -c 0-3 python cartpole.py 0.99 0.00001 0.0001
```

repository: julitopower/LearnMachineLearning

repo_name: julitopower/LearnMachineLearning