2,200,886 events, 1,070,483 push events, 1,722,410 commit messages, 128,139,651 characters
2020-02-27 2.13 Programmer's Notes
For now I'll continue to work on plugging memory leaks, and have already prepared for the release by incrementing the build numbers and taking snapshots of the freshly versioned code.
I've spent two days thinking about how I want to structure the reworked C++ CFLib exceptions, and I have a plan for dealing with my exception leaks.
On WSL2 And Eventual Debian debhelper Build Process
I've been waiting for WSL2 to come with the next big Windows 10 Home update. That will finally let me do proper .deb installers for data, amd64, and any targets (common data files used by both Java and C++, the Ubuntu 18.04 LTS amd64 builds, and the Java installation (which will be modified to actually install my jars to /usr/share/java/msobkow/2.0.13.) I'll probably start with packaging a Java installer for msscf_2_12, just to get back into the swing of using debheler. It won't run under WSL1 because WSL1 doesn't support virtual environments.
I'm going to have to learn how to write my own debhelper rule files. I don't like the automated process that builds a test version of a library before building the debian version of the code, and then builds both static and dynamic debian link libraries. I want to do build one dynamic link library and be done with it. I don't have the CPU horsepower to throw away to do three builds when one will do. I don't support nor encourage static linking for real projects.
I'll add scripts to PackageXxxTarballs213.bash which create compressed tarballs tarballs of the source code for each libxxx and xxxramloader directory, naming them com.github.msobkow-2.0.13.build-libxxx-src.tgz and com.github.msobkow-2.0.13.build-xxxramloader-src.tgz. Debian build processes like to take fresh extracts of the code in a clean chrooted directory tree when building .debs.
I can then have a debian subdirectory in each project analagous to the cplus directory tree, and manufacture the debian-specific debhelper files to that tree.
CleanDebian213.bash will completely wipe the debian directory tree for the schema/project of .tgz files, build litter, and non-debian source code (i.e. the extracted .tgz contents.)
CopyToDebianTarballs213.bash will copy the tarballs to a cleaned debian tree for building.
BuildDebianLayer213.bash scripts will be analagous to the BuildXxx.bash scripts I already have, but will get debian to do a build of the .debs for the library, and then install them instead of doing builds in the cplus directory.
The various cust libraries and executable directories would also need to be built. I may formalize custom executables and libraries and with the new SchemaDef elements CustLibrary and CustExecutable. CustLibrary would automatically add on the "libschemacust" part of the custom library name, and append the lowercase CustLibrary.Name to that, and hook them into manufactured scripts to support builds for those libraries.
CustLibrary would need to be able specify CustDepends that can name any library it likes using a raw shared library name as passed behind "-l" to the linker. CustDepends can optionally specify AppLayer to identify a particular application model and layer's library is a requirement. CustExecutable would be very similar, except it wouldn't automate the directory name at all. Obviously a CustExecutable depends on libraries, too.
Future MSS Code Factory 2.13 Features
I'm also thinking about adding a "-build build-version-string" option to the command line for the factory itself, and use that string instead of the default 12345 that I have in my current knowledge base. I don't like this restriction to 5-digit-exactly build identification in order for my ex.cmd magic in the BuildXxx.bash scripts for C++ to work.
The model would see the addition of SchamaDef elements CustExecutable, CustLibrary, and CustDepends as described in the above notes. I have realized I'd also want to specify CustDepends on a per-library basis, with the ability to inherit and append custom dependencies added on by each project schema in the system. Similarly, the executables and libraries would have to be accumulated, and I'd also need to automate the packaging and installation of those dependencies as well.
My goal is a "smart system" that knows how to perform an entire installation operation of the most common kinds: install, update-build-environment, clone-src, refresh-src, build-src, package-src-build, install-src-build, uninstall-src-build, clean-manufactured-src, manufacture-src, clean-src-build, distclean-src-build, package-src, post-build, install-build, reinstall-build, and so on. I want to completely automate the updating, rebuilding, packaging, and distribution of a build so I can just run one command, use one core plus threads, and let the computer chew for a few days until it encounters a problem and halts for manual intervention and code repair.
Ideally, I want two penultimate commands: make-it-so-src-system and make-it-so-system that will do all the appropriate run-around, build and install the code, and have the system ready for database installation or upgrades.
I could use https access to specify referenced models via URL as a fallback for local model file names, though I don't know how to write HTTPS clients with C++; I presume there are Apache libraries for it and code samples to follow. I don't recall the last time I tested URL resolution with Java. I don't think I've ever done it over HTTPS.
Then you could configure a filtration set of model resolution locations in your system's /usr/config/msobkow/.msscfrc and /usr/config/msobkow/.msscfclirc. Those would be searched by default, and must exist for any operations to be performed.
The home directory is searched for those two files first, allowing you to specify account defaults in locked-down system profiles, or override the system defaults in developer accounts and build accounts. If those aren't found, then $MSSCF_HOME/config/2.0.13/.msscf[cli]rc are to be searched for if MSSCF_HOME was specified. Next /usr/share/msobkow/2.0.13/config/.msscf[cli]rc are probed for, and then /usr/config/msobkow/2.0.13/.msscf[cli]rc. If all of those options exhast to no file, then I'll point you to a default hard-coded system URL to resolve the new-installation defaults. They'll be copied to your local /usr/config/msobkow/2.0.13/.msscf[cli]rc if no such exists.
I'd want to do builds on virtual machines that eventually can start out with no MSS Code Factory libraries for the minor version installed or fetched, using nothing more than a get command to fetch the initial .msscfrc and .msscfclirc to your HOME directory. That means there are no 2.0.13 subdirectories under /usr/share/msobkow, /usr/include/msobkow, or /usr/bin/msobkow on a clean-build system.
I'll want to add GitServer[n] configuration variables to the .msscf[cli]rc files, so you can specify where your git servers are located. You can clone any project to a local git server and have at it if you need to customize it; all the code is available under Apache V2. If local customization isn't found, your the default git servers for MSS Code Factory will be used.
The virtual machine would have a specific set of build tools pre-installed, a pre-installed release of the prior version of MSS Code Factory tools using whatever search path you have configured for your tool chains, and MSSCF_HOME set to a valid and existing potentially-empty directory somewhere.
I want to modify the resolution of .msscfrc and .msscfclirc to default to /usr/share/msobkow/2.0.13/config/.msscf[cli]rc, and to /usr/share/config/.msscf[cli]rc if those aren't found. You'll need to identify MSSCF_HOME, MSSCF_DEFAULT_MODEL_URL, and MSSCF_DEFAULT_CARTRIDGE_URL. The latter two will be optional, and will default to hard-coded initialization values by default. I'm not sure how to do that in standard C++2a, as I've never written an HTTP client in C++ before. Hopefully Apache has handy-dandy libraries available as I will need them someday regardless.)
Thus I could have a server of the most recently released shared models to be used by projects in the field, you could install system-level overrides of those shared models, or just search project, project-url, department, department-url, location, location-url, tenant-url, cluster-url, or top-domain-url locations. Each would be searched in turn for target files, allowing you to override them at any level. The same applies to cartridges and models in the existing versions of the configuration files.
On Report Generation
Someday I'll also write a report generation tool with MSS Code Factory. The idea is to instantiate an MssCFEngine and load it with the report definitions through a separate rule cartridge of reports, and then specifies GenReport specifications based on GenFile, but which work with passed-in stream handles instead of creating files. That way you could define any supporting rules common to your reports that you like.
I'd need to greatly enhance GEL to provide proper support for calculations and formatting, of course, so this won't happen any time soon.
The initialization time on the server for the MssCFEngine would be substantial, so you'd want to create a pool of MssCFEngine instances that have been pre-loaded with the report schema definitions.
scopecam: change angle adjustment from hudbob
While testing my "laser sight" for Ugly as Sin, I realized the scope camera doesn't seem to accurately match what the sights onscreen are doing. I'm not sure how the value .27 was originally obtained, but this value does not hold true for all weapons. "Physical" sights like the pistol, shotguns, boss irons, etc, tend to badly overshoot, and reflex sights like the ZM slightly overshoot. In other words, the sight points "ahead" of the actual scope camera when turning.
Hence, my initial doubling of the angle value (pitch appears fine). However, after changing this value, it appears the reflex sights on the rifles track less than the irons on most other guns, so with this value change they appear to lag behind the scope camera while the shotguns and pistol and SMG appear spot on.
I believe this is due to some math being applied to certain weaponsights, inconsistent with the scope camera sway. Perhaps the initial implementation of the ZM reflex was meant to point slightly ahead of the real angle, but later it was desired that the shotgun / pistol should move more in response to mouse movement and so the sight offsets relative to the scope bob were multiplied additionally, even though the scope camera is still doing the same movement under the hood. I'm not familiar enough with the code to determine exactly where this disconnect happens.
As-is, with my laser sight acting as a "debug" for the scope camera, I feel the angle multiplier of 0.54 and the pitch value of 0.27 are a better compromise that more accurately reflects what the player sees with iron sights, and perhaps the ZM / Lib reflex sights should have their bob offset multiplier increased. I'm open to suggestions and thoughts on this.
fuck your commit changelog I made Client.h prettier
Create Q1 - challenge1
Struggling with the last question.... If anyone has an idea ! Also please please read my code! I would love everyone's opinions!
"9:45am. Today I got up late it seems. Let me take the time to make that reply to the PM and then I will start with the book.
> Have you found some areas where inlining and join wouldn't be automatically infereable (or at least very hard)?
> It seems to me that join points are trivial to locate.
The easy way of doing it would be to just put them at the end of every `let` function statement and have the optimizer decide when to inline them. The point of Spiral though is that it allows the programmer to decide where to put them.
Also the difficulty in join points is not just where to put them, but whether to convert functions to heap allcoated closures, and whether to specialize to constants or push them to runtime. This is a lot harder problem. In the case of closure conversion, the v0.09 partial evaluator does not even have the information necessary to do this and so has to be done by hand.
> Is inlining powerful enough to replace any syntactic macros?
No, but conversely to get the same power that Spiral's partial evaluation offers, you'd actually have to reimplement those features via macros. Macros do not memoize the results of their evaluation - this is what join points actually are. Make macros lexically scoped (hygienic) and allow them to do that memoization, and you have the core of Spiral's functionality.
> What is the difference between specialization and inlining?
In the v0.09 documentation, I kind of mushed the meaning of the two together even when they aren't. Back when I was writing it, I was putting in the effort to make up my own explanation for what Spiral does because no other language has its feature set, but let me see if I can get my vocabulary in order.
Inlining is just when you inline the body of the function, and specialization is what happens in join points. Also it is what happens when you instantiate reified join points (layout types in v0.09).
inl add a b = a + b inl _ = add 1 2, add 1.1 2.2 // inlining - the bodies will get inlined
inl add a b = join a + b inl _ = add 1 2, add 1.1 2.2 // specialization - join points will get compiled to two function calls during code gen
> Did you try to replace type inference with partial evaluation?
Yeah, in v0.09 type inference is done via partial evaluation. In effect, the way it happens is similar to in dynamic languages in that you have to run the program to get the type errors, except it happens at compile time. I call it bottom-up type inference as opposed to top-down.
After programming like that for a good while back in 2018, I've concluded that it is too hard after all. One of the difficulties is that unlike in dynamic languages, you can't just put anything into an array, you have to specify its type somehow. So when doing generic functions (think of `Array.map`) that means having to run them at the type level and then once you have the array type at the value level. This is just the start of it, I had to do some gross hacks to infer the types for some functions. If you look at v0.09 you will see that it has `type_raise` and `type_catch` which allow me to do type inference by throwing exceptions. And I did even worse things in some cases.
It was interesting at the time, but good programming should be easy. Looking back, it is obvious to me now that I feel in love with experimentation a bit too much.
> Can you do runtime specialization?
No. It would be harder and not serve the same purpose. There are systems like Lancet which can, but in Spiral I only wanted to build a bridge from high level F# code to Cuda GPU kernels in order to make a ML library that does not rely on frameworks. This was my main goal, and I did not want to distract myself my making what is essentially a JIT compiler.
> How do you deallocate memory?
On the F# side, the GC takes care of that. In the ML library you do have to do it yourself for GPU memory, but I consider that a mistake. I should have used weak arrays in the GPU allocator and had the .NET GC take care of that as well. But I wasn't sure whether that sort of scheme would be reliable enough. Python is really lucky that it does reference counting and has reliable GC as a result.
I am going to have to do more research here - I definitely want full GC for my next ML library. Maybe it won't be needed though. For the sake of performance, in the next gen hardware effort is being made to localize memory to the cores rather than having them allocate from global pool. Meaning [neurochips](https://www.youtube.com/watch?v=jhQgElvtb1s) and [AI accelerators](https://www.youtube.com/watch?v=otoCxbZel1o) will (in programming terms) have static allocation (similar to shared and local Cuda memory).
Spiral is really well suited for this kind of thing by the way - if you look at how the ML code gets compiled you will see that all the tensors have their dimensions specialized in the GPU kernels. In some cases this is actually necessary in order to properly allocate shared memory. It also leads to less register use.
> How do you mutate memory?
Similarly to how the MLs and F# does it. References and arrays can be mutated directly. In GPU kernels the same philosophy is followed except they are statically allocated in registers.
There are also records with mutable fields, but I need to clean those up for v0.2.
I really like this explicit reference approach to mutation pioneered by the ML family of languages. Right now I am learning Typescript and everything is a huge mess as all the references are implicit.
I don't like how Haskell does it either as it is too rigid. Monadic code leads to coupling which is bad. I really made the right choice to write Spiral in F# as opposed to Haskell.
10:50am. The above is what I had been writing for the past hour. At my discretion, I'll paste it here in this journal since none of the questions are sensitive. If they were I'd have kept it private.
10:55am. Ok...I am thinking of whether to take a break here.
How about I give the Angular chapter a try for an hour and then I'll do that. I want to get this started.
11:45am. I've skimmed the rest of the book.
I really thought I would get a lot of out of the framework parts, but as it turns out I do want to leave this for when I actually need it.
With this I am finally done with the Essential TS book. Great.
Next up: the basics of web development. I am going to build my skills bottom up.
If I had to use a framework, I'd rather go for something which is a language. So maybe something like Elm or this.
11:55am. Let me take that break. I think I'll do the review today. Given that reply, and finishing the book ahead of schedule, today seems the ideal time to do it before I start on the next part. After that, I'll go through the video and go through those links.
It should not me too long to figure out the basics.
But ASP.NET after that should be more challenging. Still, I am looking forward to mastering this.
Just this thing and I will be able to do anything."
fuck you stream().sum() when used over an array(long)
doom2-pwad-eviternity: Imported version 1.0
Eviternity is a megawad comprised of six 5-map episodes (called Chapters) plus two secret maps. This project exclusively uses OTEX, a brand new high quality texture pack by ukiro.
Eviternity's six chapters explore a series of unique and varied themes, each featuring classic gameplay with an interest in making each map hold its own unique identity and personality. The themes are "Medieval", "Techbase", "Icy Castles", "Industrial / Brutalism", "Hell / Gore / Alien" and "Heaven".
This project was created as a birthday gift to Doom, which is celebrating its 25th birthday the day this was first released ("RC1", Released on December 10th, 2018. The texture pack used in this project, OTEX, was also released on the same day - so please do not use Eviternity as a base for your wads & mods. While mostly being a "Dragonfly project", with 24 maps being made or heavily worked on by myself, I present to you a mighty lineup of well-known guest mappers who have crafted beautiful and fun levels.
Update README.md
With the ever-rising cost of labor and materials, unexpected damage leading to replacing or repairing finished surfaces on the job site is a disaster for contractors. Proper surface protection on the job site is a necessity for all quality-oriented, financially wise contractors.
The days of throwing down a $5 roll of red rosin paper to protect the floor are over. Prudent contractors are turning to more premium surface protection solutions to save time and protect their bottom line.
Trends in flooring have shifted more towards hard surfaces with expensive stone, wood and more recently engineered hard surfaces. These surfaces tend to be more expensive and less forgiving to construction impacts than carpet. The need for impact protection has led to the dramatic rise of surface protection paperboard. These high caliper, heavy-duty paperboard products have taken the market by storm and are now widely accepted and trusted by contractors across the country.
cdf3fea85f358a07b1f989576fd330af.png
At over 40 mils thick, commonly used surface protection boards do offer excellent impact protection for hard surface flooring. It would be hard to argue that floor paperboard does not offer some peace of mind in the event of a construction mistake, like dropping a hammer or moving a ladder. There is a tremendous amount of marketing hype for these products with fancy names, printed characters, claims of special moisture barrier characteristics, etc. It’s all very convincing and the marketing efforts have taken hold. Truth be told, the product does work well. Even the creative advertising for simple sizing (adding starch) in the paperboard, does hold out water and liquid long enough for you to clean up the spill. However, be aware these paperboard products are not true barrier products; liquids will penetrate them if enough time passes.
Despite the undisputed advantages of high caliper floor protection paperboard products, there are some major disadvantages. First, unless you are moving heavy equipment on the floor, you probably do not need a 45 mil, thick paperboard. The product is heavy and difficult to handle. Conforming the material, overcoming the roll set curl of the roll and difficulty to cut the material all make is more time consuming to apply and more expensive. For many 45 mil, thick paperboard is simply put, Overkill.
With these advantages and unfortunate disadvantages of high caliper paperboard in mind, Holland Mfg. has designed a new product called Blue Shield F22. F22 is a 22-mil thick moisture hold out, paperboard made with the same fiber construction as our heavy gauge F45, 45 mil thick floor paperboard. At 22 mil, F22 is easier to conform, position and secure to the floor. The product still offers temporary moisture hold out similar in performance to the F45 board. Moving F22 rolls around the job site is much easier with a roll weight of 24 lbs. (half the weight of a F45 roll). Additionally, the product is less expensive.
No one would question that 45 mils of paperboard offers more impact protection than a 22-mil product. However, besides impact protection, other characteristics of the F22 board are nearly identical to the F45. At 22 mil thick, the F22 would never be considered thin in the surface protection world. The product is 2.5 to 3 times thicker than standard flooring papers like rosin papers or 50# kraft paper.
The surface protection paperboard product is popular and with new additions of lightweight options like F22, it will be a more user-friendly, properly gauged solution for many more construction projects.
Holland’s Blue Shield F22 Board is offered in 35” x 100’ rolls and is currently available. Featuring a water-resistant, high-density fiber construction, F22 might be the right sized surface protection product for your upcoming renovation or construction job site.
For more information about Blue Shield F22, Contact us for more information: https://www.hollandmfg.com/contact/contact-us/
Also Read Here: Water Activated Tape: everything you need to transform your packaging
About Holland Manufacturing Company: Holland Manufacturing Company Also Offers / Provides Products like Water Activated Tape, Blue Shield Industrial Products, Specialty Coated and Laminated Products, Custom Printed Labels & Tags, Industrial Paper Products, etc.
Get in touch with us on- 1-800-345-0492 Or FAX: 1-973-598-6233 Or Email us at [email protected]
Happy to help!
First hire at Intrepid - Gonna Miss You!
Hey D-Rod! You were my first ever hire with Intrepid, and started a long list (and love) of hiring web devs. Don't know how many times I had to say "yes, his name is really D-Rod" while you were interviewing, but I do know how happy everyone was when you said yes to joining the team! You're a consistent bright spot in the office, and have helped me through a lot of firsts here. I wish you every happiness in DC, and am so glad we got to work together. Stay awesome! - V
Created Text For URL [www.dispatchlive.co.za/news/2020-02-28-ex-soldier-jailed-for-life-for-murder-of-girlfriends-sister-in-shooting-rampage/]
You just love to see an easy fix you were paranoid about
"1:35pm. Time for chores. Then I'll quickly do the review and then go over the first part of the /wdg/ intro video.
2:05pm. Done with chores. Let me start the review.
During the first week, I managed to get the first half of [Spiral v0.2](https://github.com/mrakgr/The-Spiral-Language/tree/v0.2) into an usable state. If I only wanted a language that does partial evaluation that would be most of it done already, but I have quite a bit more left to go.
Surprisingly I am learning [webdev now](https://www.youtube.com/watch?v=0pThnRneDjw). Before I can begin work on the typechecker, I need to figure out how language servers work and as it turns out everything on the VS Code side has evolved from a direction I am not used to. I spent 10 days diving into the API jungle and looking into various .NET language plugins before realizing that I am not making much progress and switching gears. I need to do it from the ground up. So far I've been starting it from the other end, and it has lead to much wasted time and effort.
I've always thought that at the end of my journey I would have ended knowing everything programming-wise so I suspected I would have to touch this at some point, but the fact that I am starting to learn this now is definitely a surprise to me. I definitely did not think that giving my language editor support would lead to this. Still, even more than just learning servers, I feel like I can gain a lot from this.
In 2016, I put a lot of effort into learning how to make desktop GUIs, and even did a graphical poker game, but it was a huge disappointment because just how much effort GUIs take. Doing the game + RL agents was something like 500 LOC. The GUI actually added 1000 LOC to that which was ridiculous. In 2019 one of the reasons I gave Pharo a shot is to satisfy my craving for interactive experience, but I could not satisfy all my desires as I did not like the thought of having to implement Spiral in Pharo. Fundamentally Pharo did not sit right with me as I want to do programming in a statically typed functional language with great type inference much like F# rather than a primitive, dynamic OO one like Pharo. Having great UI support is one thing, but I really want static types with Hindley-Milner type inference when I am writing a 4.5k LOC language that I frequently modify.
It might turn out that where both desktop GUIs in .NET and Pharo failed me, the web will give me what I want. I'll write my language in F# as intended, have VS Code for editor support, and when I get back to having to chart progress for my RL agents or do a short game the web will be there as a separate service. Once Wasm gets GC I'll seriously consider changing my high level target from .NET to it. I can also take this as the first step in learning how to interface intelligent agents with the wider world.
Also somewhat ironically, learning webdev will definitely increase my employability. And just as good as they will be for just myself, being able to show other people graphical projects will definitely be a great advantage in garnering interest for them. The disadvantage of course is that I am going to have to spend a few months learning and exploring the field. But I wanted to be graphical from the start. That I got stuck to the command line with Spiral was an accident and a consequence of how poor desktop development is.
At this exact moment, I've just finished going through the **Essential Typescript** book (it is pretty good), and will move to learning HTML and CSS. After that I'll get back to studying ASP.NET. The short term goal is to learn how servers work from the ground up, and since their evolution is intimately tied with other parts of web development I can't really skip learning those other things. I've already tried that and got in trouble.
2:50pm. I think this is good enough. Let me start the video.
2:55pm. Focus me, focus.
3:10pm. How annoying. That Udemy course is paywalled. Is there something on Coursera?
3:20pm. There is really a whole bunch on Coursera. Everything on Udemy is always paywalled.
3:25pm. There seems to be stuff on Edx as well.
...Ok. Let me go for videos for the rest of the day.
https://www.youtube.com/results?search_query=html
I'll go with Youtube.
https://www.youtube.com/watch?v=UB1O30fR-EE HTML Crash Course For Absolute Beginners
I guess I'll see what this guy has to say. He is the one that made that intro video.
4:10pm. Uf, there was a second round of the chores. I am still at the start of the video only. Let me resume.
4:30pm. https://youtu.be/UB1O30fR-EE?t=1314
The stuff he is showing here in the Chrome tools is pretty interesting. All this is quite useful for somebody wanting to do interfaces and such.
5:50pm. Done with that video. I've been focused throughout, but now I feel tired.
https://www.youtube.com/watch?v=pQN-pnXPaVg HTML Full Course - Build a Website Tutorial
This is another thing on the same theme. Since I already covered the same material, let me see what this guy says. I'll save the CSS video for later.
6:20pm. Phew, done with lunch. Let me watch that vid for a bit.
6:25pm. It is so slow. Forget it. I am done for the day here.
It is time for some fun."
Summit to fuck everyone <3 love you team ! (Tes bras sont tres gros Mathieu)
“Essentially” this is not a good bye, but see you later “for sure”!!!
Your physical presence will be missed soooo much, but the print you left on the team (and company) will be remembered for a loooong time! I will always think of you and your positive attitude when the shit hits the fan on the project bc you always smile and keep calm (even if on the inside this is not the case). On the other hand I’m very happy for you and what comes ahead of you! Wishing you lots of success at your new job, love and happiness for eternity in your marriage and lots of good and positive people around you!!!
Good luck!!! Hugs, Svetlana
First day of trying: Minimal success
I'm honestly not sure what even the group use-case of doing all of this is, or if it is actually doable. We did no tech reviews. Dave just mentioned in class that you can directly interface with the CLOUD and we got excited. What is so hard about keeping a database of text files on your machine for THREE WEEKS to do a project? This serves NOTHING for the end-user and will not be part of the final project in any way.
Anyway. I promised I'd try to get it working by Friday afternoon. Which is today. Lots of love, David
Stephen-Rog
Dear David-Rod,
From first Intrepid lunch to talking about sailing to slogging through NU SAIL together to a thousand small, interactions when passing each other in the hall...to our last lunch (well, last with you as an Intrepid employee), you've always put a smile on my face, warmed my heart and challenged me to be a better product person and leader. While I'm sad you're leaving, I'm happy you're bringing the amazing uniqueness that is you to a new place. They're lucky to have you.
Yours truly,
Stephen-Rog
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
scripts/build/installer/macros.nsh: Drop empty 'gui' folder in standalone
FFF this into the first wx-begone merge, whenever we're ready for that ;)
Co-authored-by: Infernio [email protected]
Welp, we are perpetually Instruction PAge Faulting, but we think we've mapped everything correctly, but honestly, who really knows because Zig sucks and pointers in Zig are hell so we have no idea where to begin. Shoutout to @3PIV to helping with this hell.
Gave Edmund II a mom and a wife that doesn't fuckign exist goddamnit i spend two fucking hours trying to get her to work nad i just can't fucking get her to work and i spend so much time trying to get this one character to work i am going to fucking rip my dick off and choke on it