2,216,022 events, 1,097,847 push events, 1,796,698 commit messages, 131,534,114 characters
Move dshaw to emeritus status
Due to major personal and professional changes in my life, I have to make the hard decision to step back from active involvement with the Node.js Community Committee. After my adventures with NodeSource helping bring Node.js into the Node.js Foundation, it has been wonderful to work with you all to build this committee. Helping with @nodejs/user-feedback and @nodejs/mentorship was amazing. I look forward to continuing to see you all out in the community. 💖✨
Fuck You Pablo I'm gonna destroy your fucking music app
Fuck You Pablo I'm gonna destroy your fucking music app
wrote code for navbar took me all fucking day stupid piece of shit
Sandwich's Doozy of an Update
ADDED Arcane Archives Too much shit to mention here.
ADDED AA prerequisite MysticalLib UPDATED Fish's Undead Rising
-
fixed vespa and ptera attack range being too far
-
parasites now actually latch on to their targets. yikes!
-
intestines have a high chance of containing dung (yuck!)
-
new endgame crafted bauble: Radiant Necklace, increases damage to undead by 25%
-
new item, Dreamcatcher, which can be equipped as a bauble. going to sleep with a dreamcatcher has a chance to spawn a manifestation of your nightmare when you awake. useful for a flavorful and dangerous way of farming rarer creatures
-
New Monster: Osvermis (Undead Worm Monster)
-
spawns in deserts and marshes after minedMythril
-
New Monster: Penghoul
-
spawns in extremely cold & icy biomes
-
after fullEarlyGameArmor
Large predators and minibosses that clearly have teeth now drop sharp teeth for use in bone daggers, bonetooth sword, and a few other recipes
PURGED vestigial and conflicting Multimob Spawns, hopefully eliminating some lag as entities tried to spawn and were instantly despawned/blocked by InControl
Mowzie's Lanterns moved to Beneath (after minedMythril)
THE GREAT GLOWSHROOM AND NIGHTVISION REWORK all experimental, it's all in mowziesmobs.zs. This will be even better if/when the lanterns get loottable support so I can require aether enchanting of their drops, but make them far more numerous for atmosphere.
- REMOVED all vanilla night vision potions
- can only be made through Rustic Alchemy. Require luminous residue which can be crafted from basically any glowing natural source like glowshroom, glowing coral, etc
- made twilight forest moonworms renewable by feeding the queen luminous residue
- luminous residue can be used to create the first 2 tiers of glaretorch -fixed glaretorch recipes being fixed to one position only
- fixed queen bee recipe dupe/bug WORKAROUND for rats not being tamed by animania cheese Any cheese can be turned into several "cheese chunks" which are perfect bite-sized treats for rats, but do not provide nourishment and cannot be used in place of actual cheese wedges for food recipes
Fixed all problems, added reversing for motors.
Fuck you Lucas
emptied because noone cares about this piece of garbage shit ass dum ass idiot head
Day/Night Rework (pls read desc, this is big)
Removed B3M Added Extended Days Added Nyx
Harvest Moons have a 50% chance to occur on full moon nights (include the first night). No hostile mobs (except incontrol mobs) will spawn and crops grow faster.
Full moons spawn more mobs.
You can't enchant during the day with the regular table (needs tooltips)
New lunar enchantments have varying affectiveness depending on the moon phase (cool af)
Lunar water that cures most negative affects (not plague) (needs tooltip) (nyx:lunar_water_bottle)
Added more HUD options
CONS: The sun and moon in the sky will freeze and mid day and mid night for 10 minutes. We can fix this, but it will mean shaders will NOT work at all. Harvest moons can occur on the first night (since the first night is a full moon, though this could be a cool gameplay feature for rebn. Like ooooo will i get a harvestmoon first night and make my first night easy? or will i not get one and be fucked by the increased spawn rate during a full moon??) ExtendedDays MIGHT have issues with entities that rely on day/night cycles (none atm afaik, millienare as an example which wont work) No sun/moon declination from b3m i think?? idk i barely noticed
PROS: No stupid fucking b3m crash anymore!! Sponge servers might work now! The Wings mod can work now! Harvestmoon and the lunar stuff is cool af There is a chance that the Harvest moon and Bloodmoon both occur at the same time. No fucking clue what will happen when it does occur Better UI for days/time
"11:10am. 381/551. My focus is not that high here, but I am not completely confused here unlike with the ASP.NET tutorials.
Though OO, this kind of code has a link to the root that I can follow. I can imagine myself writing something of this level of complexity.
11:25am. I am distracted with thoughts of Spiral.
I am thinking about functions, more specifically the way they can be returned from join points, if statements and put into arrays.
The fact this, though this use is allowed, there is not much utility to it. In fact, many times returning functions from join points happens by accident and it is usually a mistake.
...Hmmm...I remember. I think that in v0.09 I wanted to preserve the ability to put things like tensors into arrays.
11:25am. In that case why not dyn it and turn it into a reified join point?
That would make sure that I am not making any mistakes.
Ah, no wait. Right now the dyn behavior does memoization.
Drat. Really, functions are so troublesome.
I am going to restrict their use. In v0.2 I do not need to be as permissive as I was before.
11:30am. Yeah, in v0.09 I wanted to do as much experimentation as possible, but in v0.2 I am going to tighten the leash on the language. The focus is not power anymore, but ease of use. I need to be truthful to my design priorities.
11:35am. Let me add this TODO. That will put my heart at ease. I'll go with the assumption that functions will be restricted from here on out."
Port codecs; add benchmarks.
Porting codecs to the new NodeAssembler interfaces was straightforward.
The new codecs exist in the nodesolution "research" dirs for now, coexisting with the soon-to-be-legacy encoding package. This means we can see benchmarks of both the old and new designs within this commit. (We'll probably give up on this shortly -- when dealing with the traversal package too, it's gonna stop being reasonable -- but for now it's still possible and provides interesting information.)
And how is that performance, you ask?
Peachy.
Ballpark answers for marshalling:
- 1079ns/op for the new Node
- 1435ns/op for the old Node
- 1559ns/op for stdlib json marshal of a native map.
144% better than the operations of stdlib json is pretty acceptable. (Will more intense codegen beat that? Oh for sure. But this is without any codegen, so this is quite satisfactory.)
Note that much of that time left is probably dominated by serialization-related allocations rather than the node traversal. I didn't dive into the pprofs to verify that yet, though. This picture of the overall act of marshalling is nice to have since it's a practical end-to-end user story.
This test is also on a very small piece of data, and I expect the improvements will be further much bigger on larger or deeper-recursing structures.
And lest this be skimmed over: the excellence of doing better than stdlib's json while having pluginable codecs cannot be understated.
Pretty happy with this.
How's unmarshal? Eh. About the same as before. Remember, we chose not to do a lot of amortizations in the new 'basicnode' implementations, because although we could (and it's quite clear how to do so), the increase in memory size we'd face since go doesn't allow unions was deemed too large of a constant factor multiplier. We will see these improvements in codegen, and we can also make variants of 'basicnode' that do these amortizations in the future.
Doing a lot of thinking about how benchmarks and tests will be managed as they continue to grow in count and in variation of semantic targets. Might have to write some tooling around it. We'll see.
Analysis of leading domestic and foreign experience on higher education strategies in the context internationalization for sustainable social development: preprint (analytical materials) (Part I)
The presentation of the analytical materials outlines the theoretical foundations of higher education strategies in the context of internationalization for the sustainable development of society. The main attention is paid to the global institutional transformations, transformative strategies of higher education, the problem of quality, personally oriented strategies, multiculturalism, communication strategies of higher education. The introduction of analytical materials will help to improve the level and quality of internationalization of higher education in Ukraine, to form an outlook for stimulating and ensuring sustainable development of society, enhancing the social responsibility of higher education and strengthening its function of serving the society. For scholars in the field of philosophy and pedagogy, teachers, doctoral students, graduate students and students of higher education institutions.
Add a new file access API
The API is meant to be a replacement for commands.read_file() and commands.write_to_file().
The new API allows us to log each read and write. At the same time, it allows the callers to react to different errors that the read/write operation can result in.
It also allows the callers to log more user-friendly messages - no more messages like "writing to file foobar failed: Permission denied", that may not be understandable to a regular user. Instead, we can log more high-level messages like "Failed to set parameter X to Y: Permission denied". The actual files that were accessed can still be logged using the API, however these messages are meant to be debug messages. I.e., the 'log_func' argument to FileHandler should be something like log.debug.
The new API also allows us to test its callers in a better way and more easily, by replacing the FileOperations class with a mock implementation that doesn't access real files. Also, the API itself is very nicely testable, see the included tests.
Another advantage of the new API is that it's separate from the overcrowded 'commands' class which violates the Single Responsibility Principle.
The old API provided several features that the new API doesn't provide:
- The 'makedir' argument to write_to_file() that can be used to create directories on the path to the file being written. While having this functionality is kind of nice, it's not worth polluting the API with an extra parameter that is set to True only twice in the entire codebase (one occurence being in tests).
- The 'no_error' argument, which can be used to suppress logging error messages. The same effect (() and better) can be achieved by not providing 'log_error_func' to the new API. () The old API is kind of silly in that if no_error == True and an error happens, debug log messages about reading/writing to the file are still logged, however no messages of any kind regarding the error that happened are logged.
- The 'err_ret' argument to read_file which can be used to obtain a default value if reading the file fails. The existence of this feature is nothing but laziness to write exception handlers IMHO. It's not that hard to write exception handlers, and having them results in more readable code, so please, let's just drop this feature.
Signed-off-by: Ondřej Lysoněk [email protected]
Pagination for users
The way we're doing it is kinda unorthodox, so I should probably explain:
- Dynamically generating queries with a variable WHERE part isn't possible (at least I couldn't get it to work) (yes this means that the pagination implementation for Demon is wrong). That is because we have to keep track of the query parameters without converting them to a string (to make sure they are correctly encoded in .bind())
- The query! macro can't deal with the Option<...> values being passed in because they are compared to non-nullable columns. I dont know what causes this Which leads us to the current ridiculous solution:
- if a parameter is passed in as NULL, the "IS NULL" part of the query triggers and short-circuits the other check. The only interesting cause is display_name, where we, just like in patches, can differentiate between "None" and "value not provided". To differentiate these cases in SQL (since SQL obviously doesn't have a notion of Option<Option<...>> we need to introduce a new variable encoding this state.
Allow cross-compiling etc without forcing to the latest(and breakiest) version. This should help with recreating older builds deterministically, as proof that microsoft suck and that I'm fully complying with the GPL without injecting any malware. Fuck you microsoft. Fuck you and your slander.
git-svn-id: svn://svn.code.sf.net/p/fteqw/code/trunk@5601 fc73d0e0-1445-4013-8a0c-d673dee63da5
Secure Cell passphrase API: ThemisPP (#588)
- themispp::impl::input_buffer utility
This is how you say "AsRef<[u8]>" in C++. Yes, really.
We are going to use this bunch of templates to accept anything that can be converted into a byte slice in new Secure Cell interface.
Public interface:
- themispp::input_buffer() templates
Application code is allowed to invoke these freely. They are resilient to silly values, but until C++20 it is impossible to detect contiguous iterators reliably. Therefore is is technically possible to pass, say, std::deque<uint8_t> with inevitable probable segfault. Don't do that. (Thankfully, std::list and everything non-random-access is ruled out.)
Private interface:
- themispp::impl::input_buffer struct
- themispp::impl::input_bytes() templates
- themispp::impl::input_string() templates
These functions are going to be used by ThemisPP internally. There are dummy identity conversion to handle themispp::input_buffer() results. String functions are used only by passphrase API constructors. They are not available to general users so that they don't pass std::string wherever they want.
However, it is possible for users to provide specializations of all template functions in order to support their own custom containers. Tests provide an example of how this can be done.
Note that the implementation is hidden in themispp::impl namespace which itself is mirrored in "themispp/impl" directory. This should prevent users from accidentally including and using these definitions.
Also note the "compat" headers which are used to polyfill newer features of C++ when available. They are meant for internal use and should be used in pairs to avoid leaking magic macros to application code.
- themispp::impl::secret_bytes utility
We are going to use this little class to store secret data inside Secure Cell. It is a wrapper over std::vector equipped with autowiping. The interface is restricted by design, limiting out own stupidity when coding ThemisPP.
Use of soter_wipe() in ThemisPP in any form has a drawback: it makes application code dependent on Soter library directly. Previously only themispp::secure_rand_t (mostly unused) caused this, but now all new Secure Cell classes will trigger this. It's not an issue on Linux with its flat linker spaace, but virtually every other OS has nested linkage.
- themispp::secure_cell_seal API
Implement Seal mode of Secure Cell, in both master key and passphrase flavors. The implementation is more or less straightforward, but there is one thing which must be commented. Initially I expected that allocator-aware templates can be placed directly into "themispp" namespace:
auto cell = themispp::secure_cell_seal_with_passphrase("secret");
However, it turned out that C++ grammar requires (until C++17) the template brackets to be present at all times, even if all template arguments can be inferred. This results in silly-looking:
auto cell = themispp::secure_cell_seal_with_passphrase<>("secret");
As a result, the actual implementation goes into "impl" subnamespace and proper name is reexported via a typedef. Well... it's C++, what can I do? Assuming that we do want to keep allocator awareness.
New implementation gets a bunch of new test which verify both API and some behavior. In particular, they can be somewhat of a usage guide now. Though, they are still very much incomplete.
Note that some tests are templated over "master key"/"passphrase" type. I really don't want to duplicate this code (it's enough KLOC here) and this ensures that both Secure Cell flavors have identical API. Win-win. (Actual implementation could be templated too, but that does not save much lines of code while making the implementation much more complex.)
Also note a whole lot of "// NOLINT" comments. If we were not bound by C++03 compatibility we could have used modern alternatives, but C++03 makes it hard to write code that compiles with every standard so we use the greatest common denominator. Hence we need clang-tidy to shut up.
- themispp::secure_cell_context_imprint API
This one is easy to do: there are no overloads, simple API, there will never be a passphrase API for Context Imprint. So it's mostly copy-paste of the Seal mode. Just pay attention to the argument order in Core API. It's slightly different for Context Imprint mode.
Since Context Imprint mode does not verify message validity, there is not much that we can verify in tests. But at least we check the GIGO behavior.
- themispp::secure_cell_token_protect API
Ah! Token Protect API! The foster child of APIs in Themis which usually does not get enough attention and ends up as a second-class citizen. ThemisPP has specially obnoxious API for it, which is unique across all Themis wrappers. Well, not anymore.
Instead of doing all that "set_token()"/"get_token()" we now return the encryption results as std::pair (with a couple of better accessors bolted onto it). This also gives us nice destructuring API which has finally arrived in C++17.
Other than that, the implementation is pretty unremarkable. Mind the argument order and you'll be fine.
The tests are templatized like Seal mode to make it easier to add passphrase support later. Note that we very message and token separately.
- Mark old Secure Cell API deprecated
Yes, placement of attributes is... questionable but that's how you do it in C++. Don't ask me, I have no clue and don't want to know. There is probably a 75-page paper in C++ committee proceedings which explains in great detail why it must be done this way and absolutely cannot be done in a different, more sane way.
clang-format does not make it look pretty either. Oh well... At least this code looks ugly and definitely deprecated.
- Update clang-format rules
- Autodetect C++ standard version to prevent clang-format from fixing "> >" into ">>" in template usage like "foo<bar = >" which does not parse correctly in C++03
-
Note new API in changelog
-
Use wording "key" with old master key API
Replace whatever we were calling 'passwords' with something that looks like a key and is named like one.
- Use passphrase API in example project
Well... project... The code style here leaves much to be desired, but I'm not going to fix it up right now. Just update it to use the latest API which is appropriate here.
Sneaky bug
It seems like intel fortran complier (v18.0.1) does not like to have unallocated variables passed to subroutines optional arguments. "forrtl: severe (408): fort: (7): Attempt to use pointer V when it is not associated with a target" was given when calling MPI_Scatterv inside the scatter_vector_MPI subroutine. This is called when the code performs the standard lanczos for the the Lehmann Green's function via lanc_build_gf_nonsu2_*Orb_*Spin_c The V pointer refers to the vvinit vector which is built on the master node and then scattered among threads. The code was allocating vvinit only for master which explains the error. This is not a problem using gfortran (I tested it) and was already categorized as ifort issue: https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/557015 but apparently not fixed (the -check all flag for us is active only in debug mode). I fixed just allocating vvinit for all threads in the ED_GF_NONSU2 module I am using now but probably this is going to be an issue for any ifort lover. I would suggest to modify also the other two Gf modules if a merge is planned.
God bless Steve Lionel the almighty (which is still refusing to accept me within his linkedin bootlicker).