blog.mdunn.io

Reader

Read the latest posts from blog.mdunn.io.

from quiet optimism

Upgrading to a newer version of GHC is relatively painless when using stack to maintain the Haskell toolchain for a Haskell package. The workflow looks generally like this:

1) Change the resolver 2) Bump dependency version numbers 3) Make code modifications to account for breaking API changes (if any)

I'm going to demonstrate by upgrading the coinbase-pro package that I maintain.

Changing the resolver

First step is to change the resolver parameter in the project's stack.yaml. The latest lts for GHC 8.8.3 is lts-16.7, so that's what the new resolver should be:

stack.yaml:

resolver: lts-16.7

ghc-options:
  "$locals": -Wall

packages:
- .

extra-deps:
  - unagi-streams-0.2.6
  - unagi-chan-0.4.1.3

system-ghc: false

extra-include-dirs: ["/usr/local/opt/openssl/include"]
extra-lib-dirs: ["/usr/local/opt/openssl/lib"]

Now I can just stack build and have stack tell me what package dependencies I need to change. Here is the stack output I get after changing the resolver:

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for coinbase-pro-0.8.0.0:
    network-3.1.1.1 from stack configuration does not match >=2.6 && <2.9  (latest matching version is 2.8.0.1)
    time-1.9.3 from stack configuration does not match ==1.8.*  (latest matching version is 1.8.0.4)
needed since coinbase-pro is a build target.

Some different approaches to resolving this:

  * Set 'allow-newer: true' in /home/mdunn/.stack/config.yaml to ignore all version constraints and build anyway.

  * Recommended action: try adding the following to your extra-deps in /home/mdunn/Code/coinbase-pro/stack.yaml:

- network-2.8.0.1@sha256:0f165dffa752d8cde30c2bde86f80609c4f1dc5eeb3182d593041f97839c5b3b,3011
- time-1.8.0.4@sha256:3f6eddf238b828eb4f82683acce1c3afe64784f0d20114239b738c123316c85c,5494

So stack is telling me that two packages can't be reconciled given the existing version bounds for the packages. Currently, I have the network and time package bounds set to:

  - network >= 2.6  && < 2.9
  - time >= 1.8  && < 1.9

This is problematic, considering the package versions that come packaged with lts-16.7 for network and time are 3.1.1.1 and 1.9.3 respectively. I'll need to increase the upper bounds of these two packages to allow for newer versions:

  - network >= 2.6  && < 3.2
  - time >= 1.8  && < 2

If you'll notice though, I'm attempting to upgrade the network library to a new major release (2.x vs 3.x), so I'll expect to have to make some code changes (and testing) to be sure that everything still works properly with the new network package. As for time, I can be sure that not much as changed considering it is just a minor version upgrade – but you can never be too careful!

Fix Compilation

Attempting to stack build now results in the following error:

/home/mdunn/Code/coinbase-pro/src/lib/CoinbasePro/Environment.hs:11:43: error:
    Module ‘Network.Socket.Internal’ does not export ‘PortNumber’
   |                          
11 | import           Network.Socket.Internal (PortNumber)
   |                                           ^^^^^^^^^^
                              

Ok, interesting, so it doesn't look like the network library doesn't expose PortNumber via Network.Socket.Internal. The latest docs show that PortNumber is just exposed through Network.Socket. It was probably a mistake to import Network.Socket.Internal in the first place; usually importing from modules with Internal namespace is a red flag!

The new import is as such:

import           Network.Socket (HostName, PortNumber)

Now I can finish my build.

Wrapping Up

After upgrading to the new lts, I'll increment the minor version of the package and push it up to github and make a new release! As you can see, using stack to help guide you through managing dependencies is a fairly straight-forward process.

Here is the changeset that was made in this post.

EDIT:

Here is the newest changeset after I realized that I migrated the code incorrectly the first time.

 
Read more...

from quiet optimism

After discussion with some of the community over at r/AdminCraft, I decided to take a stab at switching my FabricMC server over to PaperMC and run the DynMap plugin. It ended up being a fairly easy switch. It should be noted that I loaded in a world that I’ve been playing since 1.14, so new chunk generation was at a minimum.

Run Flags

I’m using the standard aikars flags, setting Xms and Xmx to 6G, which is just under the 8G capacity for the Raspberry Pi 4 8GB. This leaves some room for the OS and any other miscellaneous services I have running.

/usr/bin/java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar server.jar nogui

DynMap Rendering

I was able to do a full render, while having two simultaneous players move around the world, with very few complaints from the server except for the start:

Jul 09 20:30:42 ubuntu java[123761]: [20:30:42 WARN]: Can't keep up! Is the server overloaded? Running 48595ms or 971 ticks behind
Jul 09 20:31:26 ubuntu java[123761]: [20:31:26 WARN]: Can't keep up! Is the server overloaded? Running 14277ms or 285 ticks behind

During the full render, I was getting statistics around these (this many tiles rendered is at ~1 hour of full rendering):

Full render of map ‘flat’ of ‘world’ in progress - 18900
 tiles rendered (332.65 msec/tile, 293.30 msec per render)

After majority (if not all) of the map had had rendered, I switched to using /dynmap radiusrender.

Check out the current render of dynmap on my server: mcmap.mdunn.io

Timings Report

Using the /timings report command, I was able to generate the following report after doing some nether fortress raiding with two concurrent players:

https://timings.aikar.co/?id=c7c579402a264a7da95e06b36633a3c6

The largest percentage of time is spent on tickEntities. This isn’t surprising given how many villagers I have (plus animals). If I were to look into any optimization via plugins or otherwise, that would be my place to start.

Conclusion

Overall, I’d say that running PaperMC on a 8GB RasperryPi 4 is very suitable for a few players with little to no lag. I’m looking to see if I can get more players so I can do some more rigorous benchmarking!

 
Read more...

from quiet optimism

When I first heard about the the Raspberry Pi 4 8GB, I knew I had to self host a Minecraft server. Well, last week I finally received my back-ordered rpi and got to work.

My standard Minecraft setup was either playing the client in single-player mode, with no mods, or paying for a realm just so I could easily play with other people. When figuring out what server I wanted to run, my main objective was to run as close to vanilla as possible. After digging around it seemed to me that the most popular option was papermc. However, I also heard about Lithium, which is a mod within the FabricMC framework. After reading some posts on AdminCraft, I chose to run FabricMC with the Lithium and Phosphor mods. Why? They have lots of performance benefits with the objective of not modifying core Minecraft game mechanics.

Setup

Hardware

Software

Example

Check out my github repo to see an example of the setup I have, so you can run it yourself!

 
Read more...

from quiet optimism

The famous University of Chicago economist Milton Friedman once stated “the least bad tax is the property tax on the unimproved value of land”. Most popular with Georgist economists (followers of famous American political economist, Henry George), the Land Value Tax is the taxation on the value of land separate from the value of the structure on the property. In residential terms, taxation only on the land beneath the house, instead of the combined value of both. Many American's might simply state: “Land Value Tax is close enough to property tax, and I already pay too much. We need less taxes!” However, it would be a mistake to not explore and understand the subtle differences in the two tax policies, as they have quite different economic implications. As with the review of any tax policy, one must understand the economic impact, unless you want to kill the goose that lays the golden egg.

What's the difference?

The primary distinction between a pure land value tax and property tax is a progressive vs. regressive one. Progressive taxes are a tax in where the tax rate increases as the taxable amount increases. [1] On the other hand, Regressive Taxes are taxes imposed in such a manner that the tax rate decreases as the amount subject to taxation increases. [2] Some examples of progressive taxes are income taxes (not a good tax, but is implemented properly), and high sales taxes on luxury items, and tax exemptions on basic necessities. Examples of regressive taxes include sin taxes, fuel taxes, and soda taxes. But what does this mean exactly? It means that progressive taxes proportionally tax individuals relative to the assets they own. Higher the value of the assets, the more paid in taxes. However, one must keep in mind the ratios. With regressive taxes, individuals that have lower incomes pay more taxes in proportion to those who have higher incomes. If a poor person and a rich person are both buying the same food, with the same sales tax, the poor person would be paying more taxes relative to their income. That's a regressive tax. The ratio of tax between the value of land and structure becomes heavily weighted on the structure when the land value is low. Conversely, when the land values are high, the structure on the land becomes less of the tax burden in relation to the land value. This suggests that occupants of housing in lower land value areas pay a higher proportional tax bill than a occupant in a high land value area. Pure land value taxes are progressive, as the rate of tax is strictly tied to the value of the land. Occupants in lower land value areas pay much less than the owners with expensive land values.

Developers, developers, developers!

Let's consider land development. Property tax discourages development and encourages buying and holding of land, while pure land value taxes encourage owners of land to either develop, use, or sell. Consider the scenario when a developer purchases land. Under the property tax regime, the moment that a structure is built, the taxable amount increases. Under the pure land value tax regime, it stays the same. This creates a situation where it is undesirable to improve the structure to keep property taxes low and simply extract rent using substandard structures. This is very prevalent in poorer neighborhoods, as land values are very low. If land values increase, due to other developments, the land owner collects unearned windfalls. Under the land value tax regime, it might be profitable to improve and development the land in order to command higher rents. If the land value increased, the unearned windfalls aren't collected by the land owner arbitrarily. Basically, the income collected from the property is more directly tied to the landowners ability to manage development, maintain, and operate the structure. A landowners ability to efficiently “produce” on a piece of land determines the amount of income collected. It also creates the incentive to use land efficiently. No longer can landowners hold out while more dense structures are being build around them. Eventually, the land value taxes would get high enough, where a single family home is no longer economically viable. At that point, the landowner would have two options: 1) Sell the property to a developer, or 2) Build a more dense structure to generate revenue. This would create the incentive to build more housing in areas that demand it.

Case Study: Pennsylvania

The state of Pennsylvania has had a type of land value tax implemented for a little over 100 years. [3] The tax policy is called a “split-rate” tax on land and property. Split-rate taxation taxes the value of land and the value of property at different rates. Pittsburgh used a split-rate tax system from 1913 to 2001, and then switched to a single-rate property tax. [4] During times in this period, Pittsburgh taxed land about 5.77 times the tax on improvements (structures). [4]

The obvious question is, what happened? What were the consequences during this period, and why was the split-rate tax ditched in favor of a single-rate property tax? According to a study by Wallace E. Oates and Robert M. Schwab:

“Pittsburgh experienced in the 1980s a dramatic increase in building activity, far in excess of other cities in that region. The analysis suggests that, while a shortage of commercial space was a primary driving force behind the expansion, the reliance on increased land taxation played an important supporting role by enabling the city to avoid rate increases in other taxes that could have impeded development.” [5]

They concluded split-rate taxation was a boon to commercial office space development during the 1980s, and the higher land value taxation leads to increased construction within the jurisdiction. [4] While other declining rust-belt cities were increasing other economically damaging taxes, Pittsburgh was able to capture more tax income, while increasing the rate of development in the much needed commercial office space sector. The eventual repeal of the split-rate taxation came when land values were reassessed after years of underassesment, leading into a dramatic, overnight increase in the tax rate. [4] It's not shocking that residents moved to repeal such a tax to a lower property tax rate instead.

So why doesn't everyone do this?

Implementations of a pure land value tax aren't without their challenges. Many argue that implementation difficulties are the reason why pure land value taxes aren't more commonplace. Assessing land value fairly, accurately, and on a regular basis is quite difficult. The lack of a competitive undeveloped land market makes land difficult to price. A process in which to evaluate development costs for structures would have to be instantiated. Perhaps looking to countries such as Denmark and Estonia could give some insights on how to deal with this problem. Once a competitive development cost rate could be established, it could be used to determine land prices by discounting recent real estate sale data by that factor.

An overnight pure land value tax implementation would have some undesirable consequences. Landowners, overnight, would suffer a windfall loss on all property values. A transition period would need to be established to create an orderly adjustment of property values. This is the perfect use case for split-rate taxation. Start with land and property being taxed at the same rate, and slowly increase the tax on the land, while slowly decreasing the tax on the property. During this transition, local governments may acknowledge that this type of taxation is so effective in terms of revenue and lack of economic impact, that income and corporate taxes could be reduced to encourage economic development. With affordable housing and office space, low income and corporate taxes, a local government and their communities could stand to benefit greatly from a land value tax policy.

Sources

[1]Britannica Concise Encyclopedia [2]Wikipedia [3]Ryan-Collins, Josh. Lloyd, Toby. Macfarlane, Laurie. “Rethinking The Economics of Land and Housing” 2017 [4]Wikipedia [5]The Impact of Urban Land Taxation: The Pittsburgh Experience

 
Read more...