2,268,803 events, 1,103,348 push events, 1,765,262 commit messages, 134,521,063 characters
Merge pull request #2 from GoldenPot8o/patch-1
fuck you
fuck you i did the thing and now you cant stop me
your pants are now shiten
2020-02-23 MSS Code Factory CFAll 2.13.11155-202002232145 Remanufactured by 2.12.11154-202002232045 correcting leaks, bugs, and oversights
Although I created the readCachedXxx() routines yesterday, I'd neglected to actually use them in the deepDisposeXxx() routines. That oversight has been corrected.
Some of the leaks were still corrected because I had used the new routines in the reallyDeepDispose() probes, and because I found an unnecessary buffer clone in the RAM create routines that was probably causing some leakage for class hierarchy data. Those leaks were at least plugged by my last round of testing.
I don't expect to be doing any more testing until the wee hours of the morning after I've had some sleep. I'm being forced to cut my caffeine intake to a small fraction of what it used to be because I've become sensitive to it, so I'm feeling tired and draggy this evening. I might well have to give up my beloved coffee entirely, but I hope I can at least continue having a couple of mugs when I get up in the mornings. I'd miss my morning coffee terribly, having been addicted to the stuff for 42 years since I was 14 years old!
This is a github-only release.
Adjust to multitudinous quantities of BOIDS
After settling on an avoidance algorithm, now comes the other key aspects of the Boids algorithm: cohesion, and alignment. To build out those parts, I added a crap ton of Boids to the simulation.
I first had to increase the raycast count to 35 - the Boids were so small that they were slipping through each other's raycast nets.
In my vision of this prototype's final iteration, friendly Boids will not collide with each other. So I changed around some of the collision layers and masking - Boids cannot, currently, physically collide with one another. Since we have to change the masks around at death (which I think will rapidly get out of hand), I isolated the dieing tasks in their own function, die().
However, I noticed that the Boids were still dieing when touching each other - that's because the body_entered signal triggers WHENEVER a body is entered. It doesn't matter whether the physics COLLIDE with that body - a body entered is a body entered. To counteract this, I came up with the idea of a boid_team, which we'll use to code friend/foe for the Boids. I'm not sure how we'll execute it exactly - right now it's just a string and that's good enough.
I also separated all raycast/threat-vector code from _integrate_forces into it's own function, calculate_avoidance_vector. This better represents the functions place in the avoidance-alignment-cohesion paradigm.
But now I'm thinking - what if we separated out the brain from the boid? Then we could make just about anything a boid...
fixed my fucked up deleteMin, got rid of some numElement fuckups, fixed some times that i didnt set delted items to nullptr which fucked up the destructor, got stuff to work i think im over this shit
"8:20am. I am up. I am yawning here. Let me chill for a bit first and then I will start.
///
Beginner Roadmap and Guide https://github.com/kamranahmedse/developer-roadmap https://www.youtube.com/watch?v=0pThnRneDjw [Embed] [Embed]
Free beginner resources to get started with HTML, CSS and JavaScript https://developer.mozilla.org/en-US/docs/Learn - a good starting point to learn about webdev fundamentals https://javascript.info/ - quite a good JS tutorial according to many posts https://www.freecodecamp.org - curriculum including HTML/CSS/JS, React, Node.js, Express, and MongoDB https://www.theodinproject.com - curriculum including HTML/CSS/JS, Ruby on Rails, and SQL
https://fullstackopen.com/en/ - requires you to have basic web dev, db and git knowledge
List of PHP resources https://pastebin.com/gfBPg24A (lots of stuff, should be re-checked and trimmed maybe?)
Need help? Create an example and post the link https://jsfiddle.net - if you need help with HTML/CSS/JS https://3v4l.org - if you need help with PHP/HackLang https://codesandbox.io - if you need help with React/Angular/Vue
///
/g/ has these webdev threads and what I am going to do is go through the video in the second link. I'll keep these links in mind since HTML/CSS/JS is exactly what I need to learn to start things off.
9:05am. Ok, let me start. My sleep was really shit tonight, but let me do what I can today. Sometimes I do better work under strain.
Let me start with that video.
10:20am. https://youtu.be/0pThnRneDjw?t=3720
The entire video is quite interesting, but this stuff about native web apps is new to me.
10:40am. I need a break. Ok, just as I thought, I think I will be following the plan in it, until I come to the front/back end fork.
I'll study HTML/CSS seriously after I deal with the TS books. Then I'll give ASP.NET a try again.
Let me stop here for a while and then after that I'll go at the TS book full blast."
Create index.html
Q. How did God reveal His words to man? A. Spoken by God Heb. 1:1-2
Q. How were the words of God recorded and preserved until today? How were these words handed down to us? A. He commanded His servants to write Jer. 30:2
Q. Which book contains the words of God, in its entirety? A. The Holy Scriptures ....................................... II Tim. 3:15
Q. What makes the Bible unique? Why do we regard it as above all books? A. The Bible is inspired by God .............................. II Tim. 3:16-17
Q. How were those commissioned to write the Bible prevented from committing errors? Since it is just human nature to err (is human)? A. The writers were guided Rev. 10.4
Q. What is one of the characteristics of the words of God? A. Truth Jn. 17:17
Q. What does it mean? Why is it said to be the truth? A. Because God’s word have fulfillment Is. 46:11
Q. What did God say through our Lord Jesus Christ in the beginning of the Christian era that He said would happen near the end of the Christian era? A. The two world wars Mt. 24:6-7
Q. What else did God say through our Lord Jesus Christ in the beginning of the Christian era but destined to take place at some later time? A. followed by famine and poverty Mt. 24:7-8
Q. What did God say through the Prophet Daniel concerning the knowledge of man during the last days? A. Knowledge shall increase Dan. 12:4
Q. What about the kind of people that will live during these days? What did God say by means of the Apostles about the kind of people that will live during these days? A. Perilous times ........................ ………………………. II Tim. 3:1-5
Q. What is the value of believing in the words of God written in the Bible? A. May have life everlasting ........................................ Jn. 20:30-31
Q. Thus, what is the strict instruction of the Apostles so that we may not fall prey to erroneous faiths? A. Do not go beyond what is written I Cor. 4:6
Q. What is God’s warning to those who add to or subtract from the words of God written in the Bible? What is wrong with that? A. They will be punished and will not be saved ………………. Rev. 22:18-19
some QOL updates
NPC still pending as i learn shit. sorry life's gotten busy.
Merge pull request #8 from Bamboo01/FUCK-MY-ASS-AND-CALL-ME-SALLY
Nigger SHit
Created Text For URL [www.nation.co.ke/lifestyle/dn2/I-love-my-girlfriend-more-than-my-wife/957860-5466426-y2xtbu/index.html]
"4:10pm. That bath washed away some of the tedium. Let me resume.
Let me see if I can at least clear the theoretical parts of the book today, leaving the practical parts for tomorrow.
Then I will follow that video guide from beginning to the end.
4:20pm. 344/546. This async stuff might be of interest to me, but epub is such an awful format for code. I can't copy paste anything and all the formating is messed up. Also all the footnotes break up the flow.
Maybe I should have just gone with the other book.
4:40pm.
let url = window.location.href;
const input = document.createElement('input');
input.classList.add('input','URLInput');
input.addEventListener("change", () =>
url = input.value.toUpperCase()
);
Finally I am doing some actual programming, though I really do not need this book for that.
I am really impressed how autocomplete popped up when I was writing "change" on that last line. TS is using union types here to guide me and that is quite cool. This is some inspired language design.
4:45pm. Ok, the book by Boris Cheny is trash. I am almost through it, but no concrete example are to be found in it. I wasted my time on it. The framework chapter might as not be there at all. Ditto for the example code.
Let me move on to the book by Adam Freeman. If that fails me, what I will do is really start from the beginning and build up my skills that way.
export class TodoItem {
public id: number;
public task: string;
public complete: boolean = false;
public constructor(id: number, task: string, complete: boolean = false) {
this.id = id;
this.task = task;
this.complete = complete;
}
public printDetails() : void {
console.log(`${this.id}\t${this.task} ${this.complete
? "\t(complete)": ""}`);
}
}
Yeah, this seems a lot more promising. This actually starts from some sensible examples.
5:20pm. I am skimming the first chapter of this book and it seems a lot more promising. It does not treat me like a retard and starts with a concrete example that uses a class.
5:25pm. There are plenty of examples accompanying the repo from the book.
That having said, at this point I am honestly too tired. That bath gave me a second spurt, but the attempt I made today wasted most of my energy. I am out of focus.
5:30pm. Reading books is possible the worst way to learn programming. And all of this is tedious shit I mostly know from past experience in different languages. I am literally flushing my time down the drain.
But I'll give going through a book one more try. This time I will have a bunch of examples to chew on.
5:35pm. Hopefully once I get to HTML/CSS/JS that will give me leg up.
6:20pm. Done with lunch. Let me stop here as I said I would. It is time to slack."
24.1.Assertions / Profile "Tests"{Recommendations Versus Assertions; Hello .blackfire.yaml; Adding your first "Test"}
Adding specific assertions inside a test is really cool:
40 lines tests/Controller/MainControllerTest.php class MainControllerTest extends WebTestCase { public function testGetGitHubOrganizationBlackfireHttpRequests() { $blackfireConfig = (new Configuration()) ->assert('metrics.http.requests.count == 1'); } } But you can also add assertions globally. What I mean is, whenever you trigger a real Blackfire profile - like through your browser - you can set up assertions that you want to run against that profile.
Recommendations Versus Assertions Actually, we've already seen a system that's similar to this. Click into one of the profiles. Every profile has a "Recommendations" tab on the left, which tells us changes that we should probably make. In reality, recommendations are assertions in disguise! For example, the "Symfony debug mode should be disabled in production" is displayed here because the assertion that metrics.symfony.kernel.debug.count equals zero, failed. Yep, metrics are everywhere! I love that Blackfire gives us so many of these recommendations for free. But we can also define our own. When we do, they'll show up under the assertions tab.
Hello .blackfire.yaml How do we do that? Just send an email to [email protected], pay $19.95 for shipping and handling, and wait 6-8 weeks for delivery. If you order now, we'll double your order and include a signed-copy of the blackfire-player source code printed as a book. Or you can configure global assertions with a special Blackfire config file. At the root of your project, create a new file called .blackfire.yaml. A few different things will eventually go here - the first is tests:. Honestly, the trickiest thing about writing assertions is trying to figure out... a good assertion to use! Writing time-based assertions is the easiest... but because they're fragile, we want to avoid those.
Adding your first "Test" Let's start with one we've already done. Say: "HTTP requests should be limited to 1 per page":. Below this, add path set to the regular expression /.*. This means that this assertion will be executed against any profile for any page. Only want the assertion to run against a single page or section? Use this option. Now add assertions: with one item below. Go steal the metrics expression from our test... and paste it here. Change this to be less than or equal to 1. That's it! Let's try it out! Back in your browser... go back to our site, refresh, and create a new profile. I'll call it: [Recording] Added first assertion. Click into the call graph. Actually, go back. See this little green check mark? That already tells us that this profile passed all our "tests". We can see that on the "Assertions" tab: metrics.http.requests.count was 0, which is less than or equal to 1. So at this point, these "tests" are basically a nice way to create your own custom recommendations. These will become more interesting later when we talk about environments and builds. Next, let's talk about a tool from the Blackfire ecosystem called the Blackfire player. It's a command line utility that allows us to write simple files and execute them as functional tests... completely independent of the Blackfire profiling system. What we learn from it will form the foundation for the rest of the tutorial.
22.2.Performance Tests{Adding a Performance Assertion}
Adding a Performance Assertion Here's the idea: in addition to asserting that this response contains JSON with an organization key, I also want to assert that it only made one HTTP request. To do that, first add a trait from the SDK: use TestCaseTrait. Next, in the method, add $blackfireConfig = new Configuration() - the one from Blackfire\Profile: the same Configuration class we used earlier when we gave our custom-created profile a title. This time call assert() and pass it a very special string: metrics.http.requests.count == 1. I'll show you where that came from soon. Finally, below this, call $this->assertBlackfire() and pass this $blackfireConfig and a callback function. So... this confused me at first. When we call $this->assertBlackfire() it will execute this callback. Inside, we will do whatever work we want - like making the request. Finally, when the callback finishes, Blackfire will execute this assertion against the code that we ran. To get this to work, we need to use ($client). If this doesn't make sense yet... don't worry: we'll dive a bit deeper soon. But right now... try it! Run the test again:
php bin/phpunit tests/Controller/MainControlerTest.php And... it fails! Woo! Failed that metrics.http.requests.count == 1!
Performance Tests Create Real Profiles Behind the scenes, the Blackfire SDK created a real Blackfire profile for the request! You can even copy the profile URL and go check it out! This takes us to an "assertions" tab. We're making 2 requests instead of the expected one. We'll talk a lot more about assertions soon. Ok, but how did this really work? It's beautifully simple. When you run the test, it does make a real Blackfire profile in the background. However, if you go to your Blackfire homepage, you won't see it. Why? Hold Cmd or Ctrl and click the assertBlackfire() method. I love it: this method uses the SDK - just like we did! - to create a real profile. When it does that, it also adds a skip_timeline option, which simply tells Blackfire to hide this from our profile page... so it doesn't get cluttered up with all these test profiles. You can totally override that if you wanted... via the Configuration object. In reality, the Blackfire PHPUnit integration is doing the exact same thing that we just finished doing in our code: manually creating a new profile. This is really nothing new... and I love that! Except... for this metrics thing. Where did that string come from? And what else can we do here? Let's dive into metrics next.
Initial version of gui package
Infernio: Had to squash a whole bunch of these together in order to have the resulting commit not break dev. Introduces a decent first design for the GUI package featuring layouts, buttons and some text components.
Move layouts to new gui package with fully wrapped classes
The goal is to replace balt with this, fully encapsulating the wx classes inside.
Add regular buttons to new gui package
The onButClickEventful argument is not yet implemented, but it's only used in one class (the ColorPicker dialog) so it isn't a massive concern. It's waiting for better event handling before it can be implemented.
Add ToggleButton and CheckBox to gui, plus more
The main widget API now uses properties instead of getters and setters.
Add text edit fields to gui
Still to do: * styles (no border, sunken border) * fonts (mostly monospace) * event binding (on_lose_focus) * a lot of documentation
WIP - Add labels to gui
again, this is not even close to done. barely more than a stash
Cleanup some leftovers from nycz's initial work
Rename abstract classes to fit WB style
We use 'A' instead of 'Abstract'. Also renamed Widget to _AWidget since instantiating that class doesn't seem useful.
Import directly in balt
Leads to slightly cleaner looking code. Also deleted the remnants of the StaticText class.
Create gui.DeselectAllButton
Make TextCtrl wrappers more consistent
There is no reason for anything but TextArea to ever have a 'wrap' parameter. However, the 'modified' property is useful for both TextAreas and TextFields, so let's move it to the abstract class.
Remnants of balt.StaticText -> gui.Label transition
Rename abstract classes in layouts.py to fit
Carry over wx3 SendSizeEventToParent edit
Was the only actually needed one from the wx3 TEMP commit
layouts: Use SetSizer by default
Fixes dialogs opening way too small and not remembering their size
Add docstrings and typing
Also removed some obsolete labels in patcher_dialog.py.
Rename 'text' and 'name', both forbidden names
Get rid of all 'text' usages in the new GUI code
Forbidden name, see wiki.
Get rid of all 'name' usages in the new GUI code
Fobidden name, see wiki. I almost definitely missed some here.
Rename some setter parameters
To avoid forbidden names etc.
Reintroduce support for some missing features
- Hiding text input borders
Also turns the INI details name back into a read-only text area again (works better for small screens).
- StaticText.Rewrap (now Label.rewrap)
Cut out some parts of this that I don't think are needed, but we'll have to see.
Drop noAutoResize
When in doubt, leave it out - can't find any breakage from not supporting this, so dropping it.
Remove HideNativeCaret() usage
Doesn't even seem to work, and why are we even doing this in the first place??
Split into modules earlier
gui/init.py should become a central import point, will significantly reduce commit noise and simplify the API usage (in exchange for a very painful conflict resolution that I'll now have to slug through...).
Notes for these squashed modules:
Move text-related classes into gui/text_components.py
gui/init.py is starting to become pretty large and there's no reason to limit ourselves to one file anyways.
Also randomly noticed that the copyright dates were still from 2015 here.
Move button classes into gui/buttons.py
Since these are going to expand soon (BitmapButton), now felt like a good time to do it.
Some minor improvements to layouts.py
Fix 'Modified' field not being editable
Got the incorrect assignment (False instead of True), but I dropped the entire assignment instead. Don't know why it was there in the first place.
Add string prefixes to gui
Co-authored-by: Infernio [email protected]
exclusive record handling
The data model can in theory support a distinction between exclusive ownership of a name vs. a name+type+class, but in practice trying to be flexible enough to support this was stupid and the source of some contradictory mDNS behavior. Put the flag in the name where it goes.
This also means we (finally) take care of the NSEC pseudo records automatically.
Also fix a wild-ass wtf query format bug in probe.
https://kinoz.to/Stream/Konosuba_Gods_Blessing_on_This_Wonderful_World.html IMDB: Rating: 7.8 http://www.imdb.com/title/tt5370118/
...
introduce new release process
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
fixed customer section factor's ui. fixed doneTheBill button in cash. and fix some other shit that I don't remember nor I have the fucking ability to type 'em down. it's been 16 hours and 30 minutes.
rework swayidle and lock screen
Unfortunately, swayidle cannot run as a user service, it has to run in the session. Not that bad in principle, but that means it has to be started by sway, and that is bad (sway is not a process manager). However, there were other things I can improve on, especially now that swayidle understands more systemd (really surprised that they merged more systemd support). For one, swayidle now listens to the loginctl lock signal and not only to suspend. Then, I replaced my very bad shell hack to get DPMS with the lockscreen with an even uglier, but better working shell hack. I think I need to wrap swaylock anyway (set lock hints, evict credentials from memory, prepare to crash sway if crashed itself), so I might just add some slightly-less-ugly signalling of creating some private files. Or I'll have the shell script check with logind, who knows. Maybe also a completely separate daemon that watches for idle and lock hints, with possibly more flexible policies?
Screen 1 Of Level 1
fuck you kid you are nothing.