2,398,738 events, 1,108,269 push events, 1,799,556 commit messages, 139,581,542 characters
add in command to run ARC-Solver via benchmark and extract results from the run
Lot of progress here, really happy it went this smoothly. I thought it would be a royal pain to get
python to be able to communicate with ARC-Solver, but I figured it out. See ARC-Solver by default
uses Conda as an environment keeper. So I used subprocess.run in conjunction with the
conda run command and I was able to force conda to run the ARC-Solver script in the conda environment
that had been set up already. This is huge for me! To top it off, I was able to get the results from
the run of the script and get the number of correct and incorrect answered questions. We'll have to
see how things go, but maybe 10 more hours on this project will let me get to a place I can run the
benchmark and be confident in how it works. Definitely gonna need to unit test this, that'll be
difficult but doable.
Added some additional configs to benchmarkConfig.yaml, not all things make sense to enter via the terminal, I'm considering removing those entirely so it is simple how to configure it, I'll think about that some more. The next step is to set up the automation of running the index. I already have the reset and copy test set functions all set up. There's some additional work I need to do to get the articles associated with their files... that'll be a little sucky but I'll make it work.
Lacking a lot of coverage for arc_runner.py, I'll add it soon.
loopy: Add A LOVE LETTER FROM THE SAD BOY (2020)
Attack the Light (god does anybody remember that)
-Lúcia now has modified stats -You can fight Lúcia on her own by talking to her in the debug room -Faith in You has been changed to Faith in Us, it now affects all allies, and its healing formula has changed to be both more consistent and more dependent on Brillia -The Exposed status effect now deals 5% of your health in damage rather than 13%
--To-Do--
Angie - Write the Attempted Jailbreak scene, test the design for the fight some more, write up the full descriptions for Finn's moveset
Rhesus - Write incidental dialogue for after each special move is used, starting with Lúcia and Ray's then moving on to Finn and Fang's
Nick - We'll need sprites of Fang running right, as well as fallen (for use both in this scene and the Meeting scene). Also low priority thing, could we get unique idle animations for each of the battlers? Also an actual Finn design would be reeaalllly helpful now
Raz - Edit the Meeting scene, you've got free reign over it before we implement it into the game
FallingStar Games - Have some fun, get some rest, do what we gotta do
All types of lovely and fantastic miscellany ... “clu.constants.polyfills” no longer depends on anything from “clu.constants.consts” (in fact the latter will now attempt a guarded import from the former, because we can) ... The new boolean constant “clu.constants.consts.NUMPY” is True if you can import numpy from within the Python environment in which CLU is operating ... “clu.mathematics” doesn’t export anything when it has to mock the numpy module (which it will do if that aforementioned const value is False) ... New “noxfile.py” logic attempts to install numpy when it looks like it’ll need to test code that conditionally leverages it ... Running Nox using Make rules will generate a JSON report of how everything worked out, by default ... “clu.repl.ansi.ANSIFormat” now employs a pretty conservative instance-caching scheme – hard references, keyed on hashed enum values, queries follow the same exhaustive normalization we’ve been using all along before calling up to “super().new(…)” – that seems to work all nice and transparent like ... Other assorted frippery, devil-may-care flim-flam, and sundry jocund elements of imaginative fancy
Update README.md
Marlene didnt do any of this. Love Mohen , you guys re my best friends. PS Dont leave me
[analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters
The following series of refactoring patches aim to fix the horrible mess that MallocChecker.cpp is.
I genuinely hate this file. It goes completely against how most of the checkers are implemented, its by far the biggest headache regarding checker dependencies, checker options, or anything you can imagine. On top of all that, its just bad code. Its seriously everything that you shouldn't do in C++, or any other language really. Bad variable/class names, in/out parameters... Apologies, rant over.
So: there are a variety of memory manipulating function this checker models. One aspect of these functions is their AllocationFamily, which we use to distinguish between allocation kinds, like using free() on an object allocated by operator new. However, since we always know which function we're actually modeling, in fact we know it compile time, there is no need to use tricks to retrieve this information out of thin air n+1 function calls down the line. This patch changes many methods of MallocChecker to take a non-optional AllocationFamily template parameter (which also makes stack dumps a bit nicer!), and removes some no longer needed auxiliary functions.
Differential Revision: https://reviews.llvm.org/D68162
"9:05am. I've been up for 10m. Let me chill for a while and then today I will do this for real. Essential TS is definitely the book I am looking for. Then come HTML/CSS. Then I will figure out the ASP.NET examples. Then comes making that server. It is a simple plan, but it will take me at least a few weeks to go through.
9:45am. Enough wasting time. Let me get on with the book. I'll skim the first chapter as it is relatively simple, but I will give the rest a try.
let hatPrice = 100;
console.log(`Hat price: ${hatPrice}`);
let bootsPrice = "100";
console.log(`Boots price: ${bootsPrice}`);
function sumPrices(first, second, third) {
return first + second + third;
}
let totalPrice = sumPrices(hatPrice, bootsPrice);
console.log(`Total Price: ${totalPrice}`);
Uf, I did not think JS would not throw an error even for an invalid number of arguments.
let sumPrices = (...numbers) =>
numbers.reduce((total, val) =>
total + (Number.isNaN(Number(val)) ? 0 : Number(val)));
Oh, I haven't notice before that the return is not needed here.
...Well, it is not Spiral's indentation sensitive syntax. It only allows for one expression here.
10:40am. I think it is pretty cool how nodaemon just reruns the file on each save. This is something I'd kill for in Spiral.
Despite its reputation, I really do have a lot to gain for immersing myself into webdev.
11am. Uh, what the hell. I am way too distract with that HN thread. Let me finish the damn chapter.
11:10am. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
Interesting.
11:15am. 91/551. Ok, this book is much more palatable than the previous one as I expected. Hopefully I'll be able to learn something of use by the end of it.
Let me take a break here."
Plug and Play work (#6357)
-
start cleaning up banking for some of the SunPlus games (helps when you remember that the port wrirtes supply a mem_mask)
-
banking improvements (nw)
-
further improvements (nw)
-
(nw)
-
make more DRC friendly (nw)
-
cleaner banking for some in here, although mysprtcp doesn't want to behave, the port dirtection bits we need to output to aren't set to output?!
-
new NOT WORKING software list entries
mobigo_cart.xml [TeamEurope] Tinkerbell - Tal der Feen (Germany) (80-250904) Dino-Zug - Erforsche die Welt (Germany) (80-252304) Planes (Germany) (80-253004) Sofia die Erste (Germany) (80-253204) Doc McStuffins - Spielzeugarztin (Germany) (80-253304) Ultimate Spider-Man (Germany) (80-253604)
"12:20pm. Done with breakfast. Next comes chores. After that I will put a dent in this book. I want to get through the JS stuff today. Part two I will just skim unless the examples turn out to be really applied. Part 3 is where the meat of the book will lie.
12:35pm. Done with chores. Let me start.
Unusual that I am doing this so soon. But now that I have a hook, I feel that I am more motivated.
Let's get this thing going.
1:10pm. 97/551.
This part is so annoying. Having to deal with learning inheritance hierarchies. Honestly, I am tempted to just leave this for later.
I want to rant a bit, but I'll leave that for much later. Let me just focus on getting through part 1 of the book first.
1:15pm. The code on this page is stupidly convoluted and I am not that interested in learning it.
1:25pm.
let Product = function(name, price) {
this.name = name;
this.price = price;
}
Product.prototype.toString = function() {
return `toString: Name: ${this.name}, Price: ${this.price}`;
}
console.log(`prot: ${Object.toString()}`);
Ugh, I hadn't learned anything. I don't even want to learn this shit.
Should Product.prototype be Object? And then shouldn't this mutate it?
1:40pm.
class Product {
constructor(name, price) {
this.name = name;
this.price = price;
}
toString() {
return `toString: Name: ${this.name}, Price: ${this.price}`;
}
}
function createProductIterator() {
const hat = new Product("Hat", 100);
const boots = new Product("Boots", 100);
const umbrella = new Product("Umbrella", 23);
let lastVal;
return {
next() {
switch (lastVal) {
case undefined:
lastVal = hat;
return { value: hat, done: false };
case hat:
lastVal = boots;
return { value: boots, done: false };
case boots:
lastVal = umbrella;
return { value: umbrella, done: false };
case umbrella:
return { value: undefined, done: true };
}
}
}
}
let iterator = createProductIterator();
let result = iterator.next();
while (!result.done) {
console.log(result.value.toString());
result = iterator.next();
}
JS pretty much took all the worst aspects of C and modern OO languages and smushed it together in one big pile of shit. There is really a case to be made that C causes brain damage. Agh, why couldn't SML have become the dominant PL of the modern era?
function* createProductIterator() {
yield new Product("Hat", 100);
yield new Product("Boots", 100);
yield new Product("Umbrella", 23);
}
[...createProductIterator()].forEach(p => console.log(p.toString()));
This is much nicer, but generators are one thing completely subsumed by monadic computation. Well, I'll keep this pattern in mind.
The same goes for async/await. I always look askance at language features that are completely subsumed by more general ones.
Still, I can understand why one would do things this way.
Monadic computation are hard to do without the type system holding your hand.
2pm. 108/551. This is so boring. I've already started surfing the ML sub on the side. Let me take a short break. How much longer till the chapter is over?
2:05pm. 10 more pages. Then I am done with the JS primer. So I might as well bear with it.
After that comes the TS stuff. I should be able to go through that quickly.
Ok, let me focus hard for 10 more pages and then I'll take a break. After that I'll start skimming the stuff that I've already been through so many times.
2:15pm. https://github.com/WebAssembly/gc
Oh, there are proposals to add GC to WebAssembly. GC is the most important single feature I would need to Spiral top level targets to have. At the top level it really does need GC to allocate arrays, closures and recursive union types.
Still, this is just a proposal so I do not need to hurry here.
E:\Typescript\essential-ts\primer\index.js:1
import calcTax from "./tax";
^^^^^^
SyntaxError: Cannot use import statement outside a module
Why is this happening?
2:35pm. I get this same error even in the sample code. What the hell?
I am looking at SO answers and it seems for browsers I need to specify that I am compiling a module. I am guessing the same goes for JS.
"At the time of writing, Node.js only provides support for standard modules as an experimental feature. To work around this limitation, stop the nodemon process you started in Listing 4-2 and use the command prompt to run the command shown in Listing 4-23 in the primer folder. This command installs a package called esm that provides support for working with modules."
Ah, whops, I should have read the book more carefully.
Also there is a very recent update to that question.
"2020 Update (Node 13.2.0+) Verify that you have the latest version of Node installed. The --experimental-modules flag is no longer necessary. Simply do one of the following:
Add "type": "module" to the nearest parent package.json. With this, all .js and .mjs files are interpreted as ES modules. You can interpret individual files as CommonJS by using the .cjs extension. OR
Explicitly name files with the .mjs extension. All other files, such as .js will be interpreted as CommonJS, which is the default if type is not defined in package.json."
2:45pm. Hmmm, I surprised I have a lower node version number than the above given how recently I've installed it.
I guess I'll just get the latest nodejs rather than mess with experimental packages.
E:\Typescript\essential-ts\primer>node --experimental-modules index.js
(node:12472) ExperimentalWarning: The ESM module loader is experimental.
With this it works, but it complains that JS modules are experimental.
Let me just get the latest node rather than installing packages to get this functionality.
3pm. Damn it, even with the latest everything installed I still get that annoying experimental warning.
3:05pm. I am looking around and it does not seem there is any way to disable the warning without disabling all of them. Forget this for now.
...Maybe I should have just gotten the esm package after all. What the hell.
3:20pm. Well, at any rate I am done with the chapter and am taking a short breather here. The next chapter is on the TS compiler specifically, so I am going to go through it top to bottom.
3:30pm. Let me chill for a while longer."
Hacktivity IT Security Conference
For Contributions/Speakers This year we are offering two alternatives: you can either give a presentation as usual or you can give a workshop.
Presentations This is the business as usual. We require a similar thing as in any other IT security conference CFP. We are accepting presentations from a wide spectrum of IT security topics. It is up to you to apply for a presentation which is in line with the spirit of Hacktivity. We favour presentations with a demo.
Please write your slide deck in English. Your speech can be in English (favoured) or Hungarian.
As a speaker, you can have either a 20 minutes or a 40 minutes slot to present your topic. Comprehensive workshop We all know there is a huge difference between seeing and doing. Real knowledge grows from issuing your first command. Therefore, to help visitors start off learning we organize workshops. Comprehensive workshops are 2 hours long courses introducing basic/intermediate IT security skills. Previous years included topics like:
Burp Extensions Malicious PDF analysis Basic rootkit techniques SQL injections A comprehensive workshop should meet the following requirements:
participants should acquire a definite and useful piece of knowledge; participants bring their own equipment you should calculate with the diversity; a workshop will not have more than 25 attendees; it should fit into 60 plus 60 minutes (seeing plus doing) from preparation to takeaways. one workshop will be held max. 2 times during the two days Topics Here are some topics that we are especially interested in:
Vulnerabilities at unexpected territories Exploit mitigations and their mitigations Malware analysis inside or outside the sandbox Blue Team techniques / operation Big Data / Cloud / APT / any_fancy_buzzword What’s the big deal? Are there any / What are the new threats? Extraordinary stories of #FAIL Any research which brings something brand new to the security world These are just examples though, please feel free to submit your talk as long as it fits to the spirit of Hacktivity.
How to apply as a speaker? Please fill out our CFP application form: https://forms.gle/3AJq2gWFs4V8D2rR7
In case the Program Committee accepts your submission, we will get in touch with you to get the Speaker Agreement signed and to finalize every detail of your travel, accommodation & presentation.
Speaker benefits Speaker benefits are applicable to every person presenting at least one 40 minutes or two 20 minutes long presentations and/or holding 2 hours long comprehensive workshop sessions.
Hacktivity offers speakers accommodation for 2 nights + 1 bonus night next to the venue of the conference and cover travel expenses up to 350 EUR, plus a Budapest sightseeing tour the day after the conference ends. (In case there are two or more speakers for one topic, Hacktivity can provide travel cost reimbursement and accommodation for only one of them. However, the organizers help to book the accommodation for both of them.)
circleci has catalina, travis doesn't
love yaml
babysteps
logging
easier without the tmpdir
try path owned by user
two tests, one result
add more logging
reorder tests
watching directories is failing?
remove ancient go, add recent macos
debugging
more tests
even more tests, and don't make tmp files exec'able
speed up the tests :D
eval symlinks
whoops. weird kinda off by 1 error.
don't set working directory
install goenv / go
skip goenv for now
new indentation
sw_vers, add go-1.12 to bash_env
remove lines that make tests pass on 10.15
try to install go without homebrew
timeout after 15s of waiting
go back to homebrew, remove some extra logging
remove debug info / comments
don't autoupdate homebrew
introduce new release process (#4513)
After multiple discussions about our current release schedule and process, we've come to the conclusion that we need to be able to make a distinction between technical snapshots and marketing releases. In other words, we need to be able to create a bundle for early adopters to test without making it an officially-supported version, and without necessarily implying everyone should go through the trouble of upgrading. The underlying goal is to have less frequent but more stable "official" releases.
This PR is a proposal for a new release process designed under the following constraints:
- Reuse as much as possible of the existing infrastructure, to minimize effort but also chances of disruptions.
- Have the ability to create "snapshot"/"nightly"/... releases that are not meant for general public consumption, but can still be used by savvy users without jumping through too many extra hoops (ideally just swapping in a slightly-weirder version string).
- Have the ability to promote an existing snapshot release to "official" release status, with as few changes as possible in-between, so we can be confident that the official release is what we tested as a prerelease.
- Have as much of the release pipeline shared between the two types of releases, to avoid discovering non-transient problems while trying to promote a snapshot to an official release.
- Triggerring a release should still be done through a PR, so we can keep the same approval process for SOC2 auditability.
The gist of this proposal is to replace the current VERSION file with
a LATEST file, which would have the following format:
ef5d32b7438e481de0235c5538aedab419682388 0.13.53-alpha.20200214.3025.ef5d32b7
This file would be maintained with a script to reduce manual labor in
producing the version string. Other than that, the process will be
largely the same, with releases triggered by changes to this LATEST
and the release notes files.
Because one of the goals is to reduce the velocity of our published version numbers, we need a different version scheme for our snapshot releases. Fortunately, most version schemes have some support for that; unfortunately, the SDK sits at the intersection of three different version schemes that have made incompatible choices. Without going into too much detail:
- Semantic versioning (which we chose as the version format for the SDK
version number) allows for "prerelease" version numbers as well as
"metadata"; an example of a complete version string would be
1.2.3-nightly.201+server12.43. The "main" part of the version string always has to have 3 numbers separated by dots; the "prerelease" (after the-but before the+) and the "metadata" (after the+) parts are optional and, if present, must consist of one or more segments separated by dots, where a segment can be either a number or an alphanumeric string. In terms of ordering, metadata is irrelevant and any version with a prerelease string is before the corresponding "main" version string alone. Amongst prereleases, segments are compared in order with purely numeric ones compared as numbers and mixed ones compared lexicographically. So 1.2.3 is more recent than 1.2.3-1, which is itself less recent than 1.2.3-2. - Maven version strings are any number of segments separated by a
., a-, or a transition between a number and a letter. Version strings are compared element-wise, with numeric segments being compared as numbers. Alphabetic segments are treated specially if they happen to be one of a handful of magic words (such as "alpha", "beta" or "snapshot" for example) which count as "qualifiers"; a version string with a qualifier is "before" its prefix (1.2.3is before1.2.3-alpha.3, which is the same as1.2.3-alpha3or1.2.3-alpha-3), and there is a special ordering amongst qualifiers. Other alphabetic segments are compared alphabetically and count as being "after" their prefix (1.2.3-really-final-this-timecounts as being released after1.2.3). - GHC package numbers are comprised of any number of numeric segments
separated by
., plus an optional (though deprecated) alphanumeric "version tag" separated by a-. I could not find any official documentation on ordering for the version tag; numeric segments are compared as numbers. - npm uses semantic versioning so that is covered already.
After much more investigation than I'd care to admit, I have come up with the following compromise as the least-bad solution. First, obviously, the version string for stable/marketing versions is going to be "standard" semver, i.e. major.minor.patch, all numbers, which works, and sorts as expected, for all three schemes. For snapshot releases, we shall use the following (semver) format:
0.13.53-alpha.20200214.3025.ef5d32b7
where the components are, respectively:
0.13.53: the expected version string of the next "stable" release.alpha: a marker that hopefully scares people enough.20200214: the date of the release commit, which MUST be on master.3025: the number of commits in master up to the release commit (included). Because we have a linear, append-only master branch, this uniquely identifies the commit.- `ef5d32b7ù : the first 8 characters of the release commit sha. This is not strictly speaking necessary, but makes it a lot more convenient to identify the commit.
The main downsides of this format are:
- It is not a valid format for GHC packages. We do not publish GHC
packages from the SDK (so far we have instead opted to release our
Haskell code as separate packages entirely), so this should not be an
issue. However, our SDK version currently leaks to
ghc-pkgas the version string for the stdlib (and prim) packages. This PR addresses that by tweaking the compiler to remove the offending bits, soghc-pkgwould see the above version number as0.13.53.20200214.3025, which should be enough to uniquely identify it. Note that, as far as I could find out, this number would never be exposed to users. - It is rather long, which I think is good from a human perspective as it makes it more scary. However, I have been told that this may be long enough to cause issues on Windows by pushing us past the max path size limitation of that "OS". I suggest we try it and see what happens.
The upsides are:
- It clearly indicates it is an unstable release (
alpha). - It clearly indicates how old it is, by including the date.
- To humans, it is immediately obvious which version is "later" even if they have the same date, allowing us to release same-day patches if needed. (Note: that is, commits that were made on the same day; the release date itself is irrelevant here.)
- It contains the git sha so the commit built for that release is immediately obvious.
- It sorts correctly under all schemes (modulo the modification for GHC).
Alternatives I considered:
- Pander to GHC: 0.13.53-alpha-20200214-3025-ef5d32b7. This format would be accepted by all schemes, but will not sort as expected under semantic versioning (though Maven will be fine). I have no idea how it will sort under GHC.
- Not having any non-numeric component, e.g.
0.13.53.20200214.3025. This is not valid semantic versioning and is therefore rejected by npm. - Not having detailed info: just go with
0.13.53-snapshot. This is what is generally done in the Java world, but we then lose track of what version is actually in use and I'm concerned about bug reports. This would also not let us publish to the main Maven repo (at least not more than once), as artifacts there are supposed to be immutable. - No having a qualifier:
0.13.53-3025would be acceptable to all three version formats. However, it would not clearly indicate to humans that it is not meant as a stable version, and would sort differently under semantic versioning (which counts it as a prerelease, i.e. before0.13.53) than under maven (which counts it as a patch, so after0.13.53). - Just counting releases:
0.13.53-alpha.1, where we just count the number of prereleases in-between0.13.52and the next. This is currently the fallback plan if Windows path length causes issues. It would be less convenient to map releases to commits, but it could still be done via querying the history of theLATESTfile.
Note: We have decided not to have release notes for snapshot releases.
Release notes are a bit tricky. Because we want the ability to make snapshot releases, then later on promote them to stable releases, it follows that we want to build commits from the past. However, if we decide post-hoc that a commit is actually a good candidate for a release, there is no way that commit can have the appropriate release notes: it cannot know what version number it's getting, and, moreover, we now track changes in commit messages. And I do not think anyone wants to go back to the release notes file being a merge bottleneck.
But release notes need to be published to the releases blog upon releasing a stable version, and the docs website needs to be updated and include them.
The only sensible solution here is to pick up the release notes as of the commit that triggers the release. As the docs cron runs asynchronously, this means walking down the git history to find the relevant commit.
Note: We could probably do away with the asynchronicity at this point. It was originally included to cover for the possibility of a release failing. If we are releasing commits from the past after they have been tested, this should not be an issue anymore. If the docs generation were part of the synchronous release step, it would have direct access to the correct release notes without having to walk down the git history.
However, I think it is more prudent to keep this change as a future step, after we're confident the new release scheme does indeed produce much more reliable "stable" releases.
Just like releases are currently controlled mostly by detecting
changes to the VERSION file, the new process will be controlled by
detecting changes to the LATEST file. The format of that file will
include both the version string and the corresponding SHA.
Upon detecting a change to the LATEST file, CI will run the entire
release process, just like it does now with the VERSION file. The main
differences are:
- Before running the release step, CI will checkout the commit specified in the LATEST file. This requires separating the release step from the build step, which in my opinion is cleaner anyway.
- The
//:VERSIONBazel target is replaced by a repository rule that gets the version to build from an environment variable, with a default of0.0.0to remain consistent with the currentdaml-headbehaviour.
Some of the manual steps will need to be skipped for a snapshot release.
See amended release/RELEASE.md in this commit for details.
The main caveat of this approach is that the official release will be a different binary from the corresponding snapshot. It will have been built from the same source, but with a different version string. This is somewhat mitigated by Bazel caching, meaning any build step that does not depend on the version string should use the cache and produce identical results. I do not think this can be avoided when our artifact includes its own version number.
I must note, though, that while going through the changes required after
removing the VERSION file, I have been quite surprised at the sheer number of
things that actually depend on the SDK version number. I believe we should
look into reducing that over time.
CHANGELOG_BEGIN CHANGELOG_END
fuck you react native go and burn in the 18th floor of hell
"3:50pm. Let me resume.
I want to get through that chapter.
4pm. https://www.npmjs.com/package/tsc-watch
This thing is interesting.
4:30pm.
{
"name": "tools",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "tsc-watch --onSuccess \"node dist/index.js\"",
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
As expected, having somebody explain to me how to make good use of the command line tools is really highly beneficial. Somehow, I feel like I am getting a lot out of this chapter.
In particular, having command line tools like these would really have made my Spiral life easier back in 2018.
I am definitely going to develop them for v0.2.
4:55pm.
import {sum} from "./calc"
Ah, I can't believe this is still fucking with me. I thought the TS compiler would take care of it, but it seems I was wrong. Should I install esm after all?
Even with raw .js modules the thing is too stupid to import them without an explicit file suffix. This is unlike in the book.
import {sum} from "./calc.js"
Actually this works. The TS compiler is smart enough to ignore the .js suffix.
5pm. Since I am doing it my own way, the generated import code is quite different from the example in the book.
Object.defineProperty(exports, "__esModule", { value: true });
var calc_1 = require("./calc");
This is what the book says, but my own generated code is exactly what I wrote it. I guess I'll just append .js where needed.
5:10pm.
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
I am trying the CommonJs module system, but here it is saying that exports is not defined.
...Ah, whatever. It is not like this is a big deal. I'll deal with it later if I need to.
Let me move on. Probably the issue is "type" : "module" in the package.json file.
5:15pm. 142/551. Finally done with chapter 5.
Somehow I was really into that one despite it being all about compilation options. But knowing how to compile a project is important, so if there is a time to pay attention, that time is here.
5:20pm. Taking a little breather. Let me start the next chapter which is on debugging TS code.
5:25pm. "Code editors that have good TypeScript support, such as Visual Studio Code, allow breakpoints to be added to code files. My experience with this feature has been mixed, and I have found them unreliable, which is why I rely on the less elegant but more predictable debugger JavaScript keyword."
Yeah, debuggers can be like this.
Installing C# dependencies...
Platform: win32, x86_64
Downloading package 'OmniSharp for Windows (.NET 4.6 / x64)' (32544 KB).....
Why did this happen immediately after I clicked Add Configuration? This has to be related to me trying out those plugins a while ago. I terminated their downloads a while ago and the thing is resuming now...
I have no idea. I guess I'll just have to wait for this thing to finish downloading.
5:30pm. Let me slack then. Damn, sudden downloads really kill the mood.
5:35pm. Ok, the thing finally finished. Let me continue. I still have a bit more steam left in me.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"skipFiles": [
"<node_internals>/**"
],
"program": "${workspaceFolder}\\index.js",
"preLaunchTask": "tsc: build - tsconfig.json",
"outFiles": [
"${workspaceFolder}/dist/**/*.js"
]
}
]
}
I can't believe I actually understand this shit now.
There are some differences from the book though.
"program": "${workspaceFolder}/dist/index.js"
Oh, just as the book says, I did have to change it to this. Otherwise I get an exception.
Really, the book is great. This is just the handholding I need. Without this, I would not have the courage to fiddle with configuration files.
5:45pm. Had no idea about the debug console. As expected, I am getting quite a bit out of this.
146/551. Ok, 10 more pages and then I will be done with the chapter and call it a day.
5:55pm. 148/551. This is quite useful. I had no idea one could debug like this.
6:10pm. 153/551. I am just going to skim the unit testing stuff rather than try it.
6:15pm. 155/551. This watching of file for changes is quite cool. I'll definitely be able to make do with this in Spiral.
6:20pm. 158/551. Done with part one. Finally onto part two. I'll leave that for tomorrow. It should not take me more than a few hours to get through it in its entirety as I am familiar with with all of it by this point."
Significant refactor of the “ExporterBase.export(…)” rename logic ... this is the first significant update to this logic – which oh by the way is kinda one of CLU’s most-executed and crucial-est bits of logic by like a long shot – in I have no fucking idea how long or how many commits it’s been more specifically than just “A FUCKING LOT” ... The main piece is that function-renaming – which used to only apply to lambdas and phi-type partials – has been expanded such that we try it on basically everything. If you are callable, and you have a “name” attribute, we will absolutely attempt to rechristen you in the fullest (as in writing name and editing qualname, “non-destructively” assigning a value for lambda_name that is backwards-compatible with every single random snippet that nooks at lambda_name, and selectively resetting module for phi-type instances. ... Note how that last
IT WORKED IT FUCKING WORKED HOLY SHIT I DON'T REALLY KNOW WHY OR HOW BUT WOW IT WORKED I LOVE MATH
holy fucking shit i had to regex parse the fucking files because they were invalid json to begin with and hell to parse if the json was even valid to start with so fuck it and holy shit using json to parse urls ends up on some 500 fucking line extravaganza i wanna die and i have to study now so fuck this i already did it can you all enjoy it ok good
start to support split BPMs in ScreenPlayerOptions
.ssc charts support individual stepcharts having their own BPM values. This is in contrast to .sm files where a single set of BPMs applies to every stepchart in the file.
SM5 has supported "slit timing" like this for quite a while, and Simply Love has pretty much just... not. Simply Love's layout was designed for an engine that didn't have to worry about this.
Until now, in cases where I needed to display the current BPM value I would use the current player's BPM if one player was joined or the MasterPlayerNumber's BPM is both were joined. Most of the time this was fine because, to be honest, very few songs use split timing. It quietly nagged me, though.
So, in my recent commits 5c20a596cd41b46459d4cbde5e4ff414876180a3 and 0e032e099b75bdd88ebf5c37b5c851f2eb12e937 I added support for split BPMs to SelectMusic.
This commit adds mostly-working support to ScreenPlayerOptions.
Part of making this work was creating a custom OptionRow for choosing a difficulty (beginner, easy, medium, hard, expert, edit). It was previously handled by the engine. I needed to be able to broadcast when the selected difficulty changed and update the necessary scroll-speed displays on ScreenPlayerOptions in realtime if the entire BPM range for that player had suddenly changed.
In using Ace For Aces and one custom chart of my own as test cases, I've played around with having both players joined, switching between [X, C, M] mods, changing music rate, and changing difficulties. This part of it seems to work well.
There are currently two bugs:
-
The help text in the gutter for the MusicRate OptionRow doesn't yet support split BPMs. There's not enough space there to display 2 completely different BPM ranges simultaneously. I have a plan to move this information elsewhere in the screen but haven't gotten to it yet. It shouldn't be too hard.
-
If you change your difficulty on ScreenPlayerOptions using the new custom OptionRow, your difficulty will apply correctly and you'll play the stepchart you wanted in Gameplay, but your difficulty will then reset when you return to SelectMusic.
My testing so far suggests that when you get back to SelectMusic, the difficulties are set correctly at the time the InitCommand for the main ActorFrame of SelectMusic overlay is called, but they have been reset by the time of OnCommand.
I'll need to keep digging into this, but wanted to commit what I have for now.
Major plugin update
Now that I've had an excuse to get a dev environment up and running at work, where I use Windows, I kinda need to rework my plugin checks. I also found out that coc-clangd is a thing now, which is neat. I also found out how to have coc manage installing its plugins automatically, so double neat. I now have the best of both worlds, automatic plugin install, coc managing it's plugins, and transferring plugins completely between computers with zero extra work. Gotta love it. Added checks for node and python, so I can still use these config files on machines without them without worry.