2,906,302 events, 1,439,505 push events, 2,401,207 commit messages, 182,232,332 characters
redis fix 2?
redis fix 3?
redis fix 4?
try this
try this next
try hacking redis adapter again
try hacking redis adapter again
will this fix it?
better amber redis websocket patch
remove extraneous puts
change incorrect comment, explain how patch works in comment
fiber.yields for better execution
subscribe once and on the fly
oopsies signed jsilver
avoid namespace concerns
weird code but will this work
please sir, infer my type
keep subscribe channel open forever
take out fiber yields and subscribe in on message... will be in loop i think
trying this
oopsie 2
test
choose function to activate better
if i understand crystal-redis right this should work
fix
try this
try this
try this
happy wise thinking programmer zen choice: register callback FIRST then subscribe
will this wakeup websocket beat thread
try something
better
tests for redis adapter
might need this
might need this 2
show heartbeat
remove dead sockets
fix
lengthen deadbeat socket interval
debug
use Fiber.yield
bug fix hang fix
recover if the subscriber breaks
dont loop in loop
a good patch wit some consideration... dont get stuck anywhere
better?
remove race condition
reset to 2am last night
this might have been the only issue
keep forgetting to do this
autoselect adapter, subscribe early
this is beginning to become hard
please help i am trapped inside a computer program
setup adapter early
initialize and subscribe early
dont load pubsub adapter yet
cleanup
get tests passing... ready to merge
make tests fast
attempt subscribe when registering message handlers
remake subscription block fiber if subscribing no longer works without block
make logs faster, remove unneeded puts, use logging mechanism for faster logging
add logging to find out why sockets are left closed and undeleted
nicer client socket
we probably do need to yield in these websocket loops so pings can occur
remove spam logging i added
sleep the beat interval when waiting for pongs, this allows fibers to catch up and all pongs to get received, correct me if i'm wrong
apparently, HTTP::WebSocket itself from Crystal core lib is doing a loop do... for its block/event loop and since im now using fibers we have to yield for the pings to come and go properly... also testing this
[debugger] Add cross-platform status.
Currently, the status values have some undesirable properties: (1) Some status values are returned via IPC as zx_status_t constants. We avoid using zx_status_t in cross-platform code, so these are integers. Then the frontend has to interpret these values. (2) Sometimes, it's desirable to include a better error message with a failure. (3) If we port the debug_agent, zx_status_t will not be usable.
Adds a new cross-platform Status structure to deal with these problems. A zx_status_ and an errno interface are provided. These are self-describing and also allow custom error messages.
The intent is to replace all zx_status_t in cross-platform code with this class and also serialize it to the frontend. This currently just changes the ProcessHandle and its users as a proof-of-concept. When all users are complete, we should be able to remove the calls to Status::platform_error().
This uses the "debug" namespace. "debug_ipc" is ugly and annoying to type, and doesn't even make any sense in the shared/ directory. We could have "debug_shared" or "debug::shared", but that seems unnecessarily long. I'm thinking we should convert everything in shared/ to "debug".
Change-Id: I4b972cf5fc5c61c2e8ec9abe617c94650dc56257 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/551889 Reviewed-by: Dangyi Liu [email protected] Commit-Queue: Brett Wilson [email protected]
Add option to overwrite all tags.
In my opinion this is strictly better than the current code that semi-replaces tags but also kinda doesn't. This way no out-of-date info is left hanging around and if you're using tags for this generated info then it's basically impossible to use them for their original purpose anyway.
However, I want to consider and test things more before I make this the default option.
Please don't manually ghost people for no reason, mob delete code handles this for you, and it actually cleans shit up. god I hate bee
Okay, fine. I can't return _ as a value. Fuck you too, golang
fuck you here you go
give me criticism i wrote this at 2 am
Implement DFS iterator
The old libyang1-cpp implemented this in a kind of weird way: it created a vector of DataNode classes and returned that to the user. This always seemed kind of weird to me, because DataNode::tree_dfs seemed like it would return something iterable (something that .begin and .end), but not necessarily a collection (like vector).
It turns out that wrapping the LYD_TREE_DFS_BEGIN isn't a simple task.
The macro itself is a for loop which defines some control variables.
Then there is the LYD_TREE_DFS_END macro that controls the iteration.
The problem with this macro is that it's really a "for-each" loop, that
gives you a variable. However, I don't want a loop. I need "something
that gives me the next node in the DFS algorithm". In other words, I
need to break from macro loop, return elem to the user, and when the
user calls operator++ on my iterator class, resume the loop. This is
however not possible, because of how the macros are implemented - you
can use break, but you can't resume again (AFAIK).
There a lot of solutions for this:
- Write my own DFS logic - this way I don't need to wrap the macro and
all my problems are solved. Downside is I write something that's been
already written by the C-api.
1.5) Try to reverse engineer the macro, use clever
breaks here and there, maybe expand it to actual code and save its control variables - this way I could use the original code. However, it seems pretty messy. It's more like a hack than a solution to me. And I'm not sure if it's even a real solution (not sure if it's possible). - Use the libyang1-cpp solution - just complete the for-each loop and return a std::vector. This is the simplest solution requires the least work and works pretty well. It kinda goes against my intuition in that it returns a collection and not an iterator. A tweak would be to wrap the vector in a custom iterator class. But the vector would still be there. Another downside is that you ALWAYS construct all of the DataNode instances. This might not be so bad, since the classes are small, but it's still an issue.
- Create an iterator class that holds std::vector<lyd_node*> and create DataNode instances and demand, when the user uses operator*. This is a bit cleaner solution. Not sure how much I gain from this. If the user does actually want all the DataNode instances (which they probably will a lot of the time), then it's just a useless optimization.
- Use C++20 coroutines to
pausethe macro for-each in the middle of each iteration. This is a bold solution. It would mean to figure out how coroutines work (but it's not like it's such complex thing, especially for this use-case). In my small research, I found out that I would need to create agenerator. This solution is pretty cool I would say. However, the problem with C++20 coroutines is that even though C++20 supports them, there isn't much library support for them. That means that I would probably need to import a 3rd-party library like "cppcoro" (or implement the stuff on my own, which is probably not a good idea, because I'm not that big of a C++ mastermind).
After a discussion with Honza and Tomas, I have chosen version number 1. The solution is the cleanest, I don't create unneeded objects. The only downside is that I don't reuse the C macro, which is fine. It's not like the DFS algorithm will change.
The algorithm inside DfsIterator is basically a copy of the LYD_TREE_DFS_BEGIN and LYD_TREE_DFS_END macros. There are some differences:
- The algorithm is now an actual iterator, not a for-loop. The user can use operator++ to advance the iteration and operator* to retrieve the element.
- Support for
LYD_TREE_DFS_continueis removed. There is no need to support this, because there's no loop inside the algorithm logic. The user can usecontinuein their own loop as they would when iterating over any other container.
The code also tracks the validity of collections and iterators. When a subtree associated with a collection or an iterator gets unlinked, all collections and iterators are invalidated. If a collection goes out of scope before an iterator does, the iterator is also invalidated.
Change-Id: If0fbd8d3574408444c4ef8bebc276c30be525a67
I hate my life
height = 50; was a debug line that i left in and spent 20 mins trying to fix ffs
Jump Start MySQL
Preface: This book is an introduction to the basic concepts of working with a Relational Database Management System (RDBMS)—specifically, the popular, open source RDBMS MySQL. Like others Jump series, it aims to give you a head start in your understanding of the chosen technology. You’ll learn the basics quickly, in a friendly, (hopefully) pain-free way, and have a solid foundation to continue on in your learning.
Who should read this book: This book is aimed at those interested in working with data and want to learn how to use MySQL. To get the most out of some parts of this book, you should have some previous programming experience, although no specific language is required.
Create 5:Create dictionaries
Work on project. Stage 1/5: Create dictionaries Project: Food Blog Backend Hard 41 minutes 175 users solved this problem. Latest completion was 2 minutes ago . Description Your great-grandmother asked you to copy "to these computers" all the recipes that she had been collecting in her notebook for several decades. You think that this task can be a good opportunity to practice your skills and build a tool that would collect the data in a database. It will allow you to create a database of recipes that you will be able to use in the blog with the great-grandma's recipes. You started by writing down the names of the ingredients and measures that Grandma used. It also may be good to assign different dishes to different times of the day. It's time to create a database and dictionaries!
Below is a diagram of the database tables. PK means the Primary Key.
Theory SQLite3 is a relational database management system. You can use it for free; it is licensed as Public Domain. The system implements most of the SQL standards. For this project, we will use the basic SQLite3 functions.
First, import the sqlite3 library:
import sqlite3 To connect your script to an SQLite database, use the connect() method from the sqlite3 library and create a database cursor with the cursor() method:
conn = sqlite3.connect(data_base_name) cursor_name = conn.cursor() To execute an SQL query, use the execute() cursor method. This method will return an object that contains the result of the query. For example:
result = cursor_name.execute(SQL_query_as_string) Another two important methods are close() and commit(). Remember that you need to confirm the SQL queries with the commit command. Otherwise, the data will be lost. At the end of your code, disconnect your database. Both methods are related to the database connection:
conn.commit() conn.close() If you need more information, the SQLite Tutorial will help you!
Objectives Create a database. Pass the name of the database to the script as an argument. Create a table named meals with two columns: meal_id of an integer type with the primary key attribute, and meal_name of a text type and with the unique and not null attribute. Create a table named ingredients with two columns: ingredient_id of an integer type with the primary key attribute and ingredient_name of a text type with the unique and not null attribute. Multi-word ingredients are out of scope, you don't need to implement their support in your script. Create a table named measures with two columns: measure_id of an integer type with the primary key attribute, and measure_name of a text type with the unique attribute. Populate the tables. Those tables are the dictionaries for the Food Blog system, you need to fill them once for the rest of the stages. data = {"meals": ("breakfast", "brunch", "lunch", "supper"), "ingredients": ("milk", "cacao", "strawberry", "blueberry", "blackberry", "sugar"), "measures": ("ml", "g", "l", "cup", "tbsp", "tsp", "dsp", "")} Tests do not check the output. You can print anything you want. Tests will check only the database file that your script will create. Do not add other items to the dictionaries. This may affect the test results in this and the next stages
blacklisted spam cmd from sandys server because fuck you
Merged CMake repository with official, up-to-date oomph-lib repository.
--> Merged branch 'main' of
https://github.com/PuneetMatharu/squashed-cmake-oomph-lib
into the current feature/convert-to-cmake-build-system branch. Resolved
a tonne of merge conflicts in the validate.sh scripts and other changes
made since commit 91298e7. Added all the CMakeLists.txt files but kept
most of the Autotools stuff alive so that I can slowly (and safely)
transition the files out.
--> Lost the version information through the merge but also agreed with MH (unless he changes his mind) that the CMake version of oomph-lib should becomes v2.0.0, so for now, I'll start at v1.5.0.
--> The build and installation is now automatically parallelised with the new support for Ninja build system through CMake. I recorded a 10x(!!!) speed-up on my MacBook Pro compared to the default build/install time (i.e. if I don't supply the --jobs arguments, which I never remembered to do before) with the Autotools build system and a 5x speed-up when the Autotools build is run with 10 jobs (which is what Ninja used).
--> Added CTest support for running demo_drivers. This will allow us to easily parallelise, and control the level of parallelisation, of the self-tests. Regular expressions (regex) can also be used to easily filter out tests for the user. It also stores the previously failed tests so that they can be rerun and their output can be logged to directly to the screen. It allows stores the "cost" of each test so that (if the build/Testing/ directory isn't deleted between self-tests) it can reorder tests so that the quickest or longest tests can be run first (I forget which way around it is).
--> Formatted src/ and demo_drivers/ headers and sources using clang-format according to the C++11 standard (which the modernised library will ship with). The only "breaking" difference should be that double angle- brackets no longer require a space between them in C++11. However, this should save tonnes of headache with confusing formatting changes in future pull requests.
--> Added a .cmake-format.json file to provide a specification to the cmake-format pre-commit hook for formatting CMakeLists.txt and *.cmake module files.
--> Changed the way that the library is built and consumed; after building, the targets are exported within the oomph:: namespace. Demo drivers then find the oomph_lib package using find_package(...) then linked with executables as, e.g. oomph::poisson. The oomph::generic library is forwarded automatically through the transitive (PUBLIC) dependency.
--> Retired the old oomph-lib way of adding template headers (which can't be compiled with the library) to the library. The .template.h and .template.cc files have become .h and .tpp files, respectively. The .tpp file is then included at the bottom of the .h file.
This creates a particularly big name change for the meshes in
src/meshes, where the header and templated implementation are given
in .template.h and .template.cc files, respectively.
--> The src/meshes library is also now a "header-only" library (or INTERFACE library, in CMake-speak). As a result, I've merged all of the plain .cc files in src/meshes into their .h counterparts (relevant, e.g., for cylinder_with_flag_domain.cc and topologically_rectangular_domain.cc).
NOTE: All domain classes should be defined inside(!) their header,
and not in a separate source file. This is because no files are
compiled by this INTERFACE library (in CMake-speak), so they would
have to be included separately like a header.
-----------------------------------------------------------------------
**Important:**
Whenever a member function is defined inside a header and not in a
source file, it should be prepended with the "inline" keyword otherwise
this can (but not always) lead to very confusing "duplicate symbol"
linking errors. To err on the side of caution, make sure you stick to
this rule! This was especially important for TopologicallyRectangularDomain
as it was compiled into the biharmonic library; at linktime, an
executable that used this library found the symbols for this class'
member functions through both an #include of the mesh/domain file and
through the linked biharmonic library, leading to duplicate symbols.
-----------------------------------------------------------------------
--> Updated README.md to describe how to build/install the library.
--> Renamed oomph_lapack.h to oomph_required_lapack_routines.h so that oomph_lapack.h can be used as the combined header.
--> Creating empty replacements for debug.h and stat.h in oomph_arpack/ if they can't be found. It seems like this is already done, so should be harmless...
--> Replaced
#include "src/generic/Qelements.h"
with
#include "../generic/Qelements.h"
in a few src/ directory files to emulate the folder structure after
the project has been installed.
--> Deleted oomph_metis_from_parmetis_3.1.1.h which was just a copy of metis.h. Now oomph_metis_from_parmetis_3.1.1.h is used as a combined header that includes metis.h.
--> Changed the location that combined headers are installed to. Instead of being placed in the folder of the Makefile.am, it's placed in the build/ directory (i.e. binary directory in CMake speak) but up one folder, e.g.
--> Renamed the bin/ directory to scripts/ to avoid any possible future confusion or conflicts with a bin/ directory in CMake-speak (i.e. where user executables are typically installed).
--> Updated matrices.cc to delete a few array variables properly, by using "delete[]" instead of just "delete".
--> Added support for SuperLU 5.2.2 (the latest version). I haven't removed support for the old version, as this version needs test-driving first, despite passing all the same demo_drivers tests as with the old one.
This did, however, break three of the demo_drivers:
navier_stokes/unstructured_fluid
solid/three_d_cantilever
shell/plate
The first two were easily addressed by upping the relative error
tolerance (used by fpdiff.py) marginally to 0.2 and 0.4, respectively.
The third one produced an absolute error of around 1.0e-09 but a relative
error of 4%. Need to up the "numerical zero" threshold value to fix this
issue.
--> Removed dummy malloc.h build in oomph_parmetis_*
--> Changed some (likely unchanged)
#include <config.h>
statements in some src/ headers (i.e. polar_fluid_traction_elements.h,
polar_stress_integral_elements.h, and helmholtz_geometric_multigrid.h) to
#include <oomph-lib-config.h>
as they were very likely just missed out in a glob change.
--> Removed src/mesh_smoothing/mesh_smooth{.cc,ing.h}. The first, because it was empty (and therefore useless for the CMake system), and the second, because it duplicated mesh_smooth.h. I've avoided using mesh_smoothing.h as the name because that is the name of combined header associated with the library. There shouldn't be any clash, but I've done it to be on the safe side incase anyone meddles with the location that combined headers get placed in with the CMake machinery and accidentally causes it to overwrite the actual header.
--> Added a basic (but more helpful) oomph-lib-config.h. Currently it just contains some version information and a definition of INT_SIZE; this can be used (in the future) to set the size of the integers used to store matrix indices. Adding 64-bit integer support would be a very helpful addition (particularly for the space-time machinery! ahem).
--> Added a bumpversion.cfg to handle version bumping. It updates the CMake version and adds a Git commit and tags it with the new version. A much more reliable way to make sure version changes are made across the board.
--> Added a TODO-LIST.md to store a list of the future tasks for this project.
--> How to precompile a mesh using an object library in demo_drivers/solid/simple_shear/CMakeLists.txt
How to symlink an executable to the scripts/ directory in meshing/mesh_from_xfig_triangle/CMakeLists.txt
--> Need to integrate any new oomph-lib stuff into the CMake build.
--> Need to sort out external_distributions.
--> Need to update shell/plate validate.sh script to allow the test to pass when the up-to-date SuperLU sources are used.
--> Need to fix failing MPI tests on MacOS. Rupinder managed to confirm that all self-tests (bar one, which needs to be fixed - the one that's in mpi/distribution/two_d_unstructured_adaptive_poisson) pass on Linux.
--> Need to get all demo drivers passing with a "destruct test"; this should really be done with a GitHub Action. (Will likely just steal and modify one that has already been (beautifully written) by Jonathan D.)
--> Fill in additional helpful documentation in README.md.
--> Optional (TBD): Add clang-tidy support to add some modernisation to the library, e.g. add "delete", "final", and "override" keywords to replace the use of "broken virtual" functions (with "delete"). These additions will allow us to detect errors at compile-time instead of run-time.
--> Add CPack support for packaging up the library (e.g. creating a tarball).
--> Tidy up the repository, e.g. consistent formatting and helpful comments everywhere.
--> Complete the unit-test support, i.e. for the files in tests/; not to be confused with the integration tests in demo_drivers.
--> Add CDash support to create a dashboard of all of the tests using the produced DartConfiguration.tcl file.
--> Need to update fpdiff.py parameters for the clamped_shell demo_driver after it has been changed in the original repo.
--> Support for up-to-date external_distributions.
Credit to Rupinder for helping with beta testing the project on Linux and helping spot some issues early on.
Current records for build and install time:
- 5-year quad-core 2.5GHz MacBook Pro: 3 minutes 35 seconds.
- Rupinder's PC (running Linux): 53 seconds (!!!). That's pretty damn fast if you ask me...
[PROF-3425] Bootstrap profiling native extension
My current plan is to use the profiling native extension to:
-
Enable use of libddprof, a (native) shared library which allows datadog profilers to share common code.
One of the main advantages of this library is that it will include its own profile encoding implementation, which will enable us to drop profiler's dependency on the
google-protobufgem. Right now, we need to tell customers to manually it when onboarding, see https://docs.datadoghq.com/tracing/profiler/enabling/?code-lang=ruby, which is annoying. -
Call Ruby VM APIs that are otherwise unavailable or costly when called from Ruby code.
But in this commit, I decided to scale it way, way, way back to just the basics: add an empty native extension, and the scaffolding to load and test it.
Thus, I hope that by releasing the next version of dd-trace-rb with the empty native extension we can to validate the approach, or otherwise root out corner cases that we may have missed.
Furthermore, I'll point out that if our plans of a "big gem" go forward, having this kind of non-trivial addition on the gem is supposed to be the norm, not the exception ;)
EVEN SO, because this is a non-trivial change, here's my notes on possible concerns, in Q&A form:
Q1: Will requiring customers to compile a native extension during
gem install ddtrace cause issues?
A1: No, because of our dependencies. dd-trace-rb currently has
two dependencies: ffi and msgpack. Both of those gems rely on
native components, and neither of them (as of this writing) ships
pre-compiled extensions (*except on Windows), as can be seen on
rubygems.org:
This fortunate state of affairs means that customers already need to have a working setup for building native extensions, and so our addition of a native extension does not make it any harder for them to onboard.
Q2: Will this cause problems for Windows users?
A2: The ffi and msgpack gem ship precompiled binaries for
Windows, so the reasoning from A1 doesn't apply to these users.
For Windows, it's possible that customers that previously were getting by without needing an environment to build Ruby native extensions will no longer be able to install dd-trace-rb. But:
gem install railson Windows pulls at least one native extension that needs to be compiled, so if you can't build dd-trace-rb, you can't installrailseither- Recent versions of
msgpack(since 1.4.2, from 2021-02-01) don't provide binaries either. This means that, out of the box, even before this change,gem install ddtracefails on Windows if you don't have a build environment, because rubygems tries to download the latest version ofmsgpack. (Rather than picking an older version that ships a precompiled build.)
So my assertion is, I don't believe we'll have any customers that A) run on Windows and B) don't have a setup for building native extensions.
BUT, if this assertion turns out to be wrong, we have the option
of doing the same thing that ffi and msgpack do: ship
prebuilt versions of ddtrace for Windows users.
Q3: Should we provide precompiled versions of the gem right now instead? A3: Precompiled versions of the gem introduce complexity into our release process (now we have several artifacts, that may need to be generated on multiple machines); it also may pose compatibility issues, given our Ruby 2.1 to 3.0 support Matrix.
So, given the fortunate state we're in (see A1), I think we should avoid them as much as possible.
Q4: Why write the extension in C and not Rust? A4: The Ruby VM APIs and headers are written in C. They cannot be directly used from Rust (e.g. a few things are actually implemented as preprocessor macros), and thus, to write an extension using Rust, we'd need to rely on community-built bindings that translate the Ruby VM headers into Rust.
I've investigated the state of these bindings, and the only two that are still maintained are:
Unfortunately, there don't seem to be a lot of gems using them and support for older Rubies, 32-bit OSs and Windows seems spotty. So... not in a great state at the moment for our usage.
The second issue is that using Rust pushes us into needing to provide binary builds through rubygems.org -- we definitely can't assume that customers will have a working Rust compiler around.
We plan on implementing libddprof (the profiling shared library) using Rust, but because it doesn't need to talk to Ruby VM APIs (we'll wrap them with some C code in this profiling native extension), we don't need to worry about bindings, and also we get a bit more flexibility on binary builds, since we don't need to link to the Ruby VM.
Q5: Can you use dd-trace-rb without the native extension?
A5: Yes...ish. The extension must get build during gem install,
but we handle any issues that may happen while loading it.
So, if you're working on the gem, or the extension gets built
but doesn't load properly, there should be no impact to the rest
of the library; only the profiler will refuse to work.
New alpha items (#539)
- New alpha items
Added 4 items from the metal detector room but im missing one of them
Added 2 new pets i dont think they are 100% right and we are missing uncommon and leg
-
i did a lil grinding and found the 4th scavenged thingy
-
found items on the ah and also found an npc with some
updating flamebreaker armor to the alpha version
- found the new pet
it doesnt have perks and might be scuffed in pv
- added a wiki link
thx jani
- New item from the raffle v2 event thingy
thx gravy!
-
Create YOGGIE.json
-
added uncommon and leg armadillo and new reforge stone stats
reforge stone is kinda scuffed rn cos moulbemoment and cos i dont have leg/mythic price
also lets hope i didnt fuck up anything
- found on ah
"1pm. A few chapters of Hero King and I will resume, even if that is just to take a nap.
1:15pm. Ok, let me stop reading here. It is time for that nap. I'll step away from the screen for a while. Yesterday I spent time thinking about what I am going to do today, but that planning all involved finishing up the upside down RL experiments. Now I need to switch gears. I started playing around transformers just for a bit a week ago, talked myself out of it, but now they will be explored thoroughly.
I need to gather my motivation for this next part first.
2:50pm. I am back.
There are two challenges in front of me:
- Understanding transformers to the point where I can reimplement all of their pieces on my own and even extend on them.
- Actually integrating them with the game.
I need to to do this one at a time. First I should figure out how the native PyTorch transformer layers work and plug them in. They won't work well, but it will give me a chance to integrate them with the game. After that I'll be able to experiment with my own specific improvements to them.
https://arxiv.org/abs/2003.06898 Provably Efficient Exploration for Reinforcement Learning Using Unsupervised Learning
Let me read papers for a bit. Transformers and unsupervised learning are the next great step for me. After I deal with them, and I should be done in the next two months, I will have completely my RL journey for the time being. For the first time in 6.5 years, my goals will be able to take some distance from directly programming. So just do it.
Despite the progress in ML for the past decade, architectural innovations are not that frequent. Transformers have been discovered years ago, and there weren't any improvements on the original architecture apart from moving LN around. There is no way this will be the end of the story as they are n^2, but it goes to show how frequent the true innovations in the field are.
I can afford to sit back and the let community itself digest the improvements.
3:05pm. That paper is a useless mismash of terms.
https://arxiv.org/abs/1806.04640 Unsupervised Meta-Learning for Reinforcement Learning
Let me take a look at this.
After this I'll take a look at the transformer vids by Lennart again. I need to get into this.
3:30pm. Forget these papers, they are a waste of time as usual. Let me watch the vids for a bit. Then I'll play with the transformer layers.
https://www.youtube.com/watch?v=kpqG7O1dbTk Transformer - Part 6 - Decoder (1): testing and training
They aren't long, let me take a look at the Decoder again.
https://www.youtube.com/c/YannicKilcher/search?query=transformer
Some of the transformer vids by Yannic might be of interest to me as well. I'll go for them. Right now I do not feel like diving into programming and want to immerse myself into the subject first. Before a subject can be at the front of your mind, it should be at the back of your mind first.
4:05pm. I am not paying attention to the video by Lennart at all, and I do not have full grasp on it. I am being lazy.
Let me go for some videos by Yannic. I need to pump myself up further.
I always have to go through these motions. But I need to persevere. Even if I feel lazy, I should persevere. I will get into it when I start programming. I just need to get to that start.
Forget about the time. Even if it takes me a month or two it is fine.
https://www.youtube.com/watch?v=-buULmf7dec Decision Transformer: Reinforcement Learning via Sequence Modeling (Research Paper Explained)
Let me listen to some of these videos.
https://youtu.be/-buULmf7dec?t=111
I had not heard about this paper here. Here they do beam search over the trajectories. That might be more realistic than UDRL. And props to him for mentioning Schmidhuber's paper.
5:10pm. https://www.youtube.com/watch?v=R5DiLFOMZrc TransGAN: Two Transformers Can Make One Strong GAN (Machine Learning Research Paper Explained)
Let me watch this next.
5:20pm. It is boring.
https://youtu.be/P_xeshTnPZg Perceiver: General Perception with Iterative Attention (Google DeepMind Research Paper Explained)
Let me try this.
5:45pm. Had to take a break. This is so boring, let me finish the Perceiver video and I am done for the day.
6:30pm. Done watching vids. Hrrmmmmm...
I could have just done some programming at 1pm and it would have set me forward half a day. Instead i wasted this time. But it is not just about planning. What I am missing here is the desire to open a script and do some simple experimentation.
I need to regret not doing anything today. I need to want not to do the whole thing which is a mountain of work. I need to want to make the simplest possible step, open up a python script file and pass in some random inputs to the transformer layers. Figure out how the masks work, figure out what the arguments are. Figure out all of that. To do this I need a willingness to learn.
I need to think about this on the side - even if this kind of daydreaming seems pointless, I need to believe in the smallest possible step. I need to not think that this kind of work needs to be done, but that it needs to be done right now. I need to put the entire weight of my ego and identity behind it.
It is hard switching gears, just after a recent failure. Seriously fuck upside down RL.
Just how do biological brains do their learning? Right now we understand nothing. Brains are everywhere and yet we cannot see what goes on inside of them.
6:35pm. https://www.youtube.com/watch?v=MpdbFLXOOIw Supervised Contrastive Learning
Cross entropy is the most widely used loss function for supervised training of image classification models. In this paper, we propose a novel training methodology that consistently outperforms cross entropy on supervised learning tasks across different architectures and data augmentations.
Maybe I'll take a look at this tomorrow. This seems interesting.
https://www.youtube.com/watch?v=3qxJ2WD8p4w LambdaNetworks: Modeling long-range Interactions without Attention (Paper Explained)
How many times will the n^2 problem of transformers get solved?
6:40pm. Let me close here. Tomorrow, I won't do anything great. I won't say I will figure out transformers top to bottom. What I will do is instead play with them as I should have today. I am going to gather my will and do it, or I will keep spending my days in bed until I feel like doing it.
That is the way it is going to happen. Transformers and curriculum learning is what will beat poker. I might miss my deadline of being a few weeks away from that superhuman player by a bit, but it is going to happen either way. Had the UDRL worked, I'd have solved a lot more than just the immediate problem, but nevermind that.
Eventually some real insights on how the brain works will come out and that will push things forward. I won't be able to break to the 4/5 realm in ML on my own. But that does not matter, I am going to bring this sordid story of me making a ML player for 6.5 years to an end soon."
fuck you its going in discord rpc until its fixed.
Upsolve TopCoder TCO-2021-Round-3-DIV-1-250: AnnoyingPasswords
failed systest in-contest ~ +8m [upsolve] 220.53/250 (AC - resubmission)
Analysis: WA (failed systests)
- integer overflow! shit, fuck, fuck, fuck fuck!
return (int)result%MOD;- instead of
return int(result%MOD;) - or instead of plain
return result%MOD;
- instead of
- didn't catch w/ maxtest => NEVER RECAST TO INT, ONLY AFTER FINAL COMPUTATION!!!!!!!!!!!!!!!!!!!!!!!!!!!
- RETURN RECASTS AUTOMATICALLY! => USE RECAST IN FORM OF TYPE(VAR)!
- NEVER (TYPE)VAR
Signed-off-by: Karel Ha [email protected]
drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
This API is entirely unnecessary and I'd love to get rid of it. If userspace wants a single timeline across multiple contexts, they can either use implicit synchronization or a syncobj, both of which existed at the time this feature landed. The justification given at the time was that it would help GL drivers which are inherently single-timeline. However, neither of our GL drivers actually wanted the feature. i965 was already in maintenance mode at the time and iris uses syncobj for everything.
Unfortunately, as much as I'd love to get rid of it, it is used by the media driver so we can't do that. We can, however, do the next-best thing which is to embed a syncobj in the context and do exactly what we'd expect from userspace internally. This isn't an entirely identical implementation because it's no longer atomic if userspace races with itself by calling execbuffer2 twice simultaneously from different threads. It won't crash in that case; it just doesn't guarantee any ordering between those two submits. It also means that sync files exported from different engines on a SINGLE_TIMELINE context will have different fence contexts. This is visible to userspace if it looks at the obj_name field of sync_fence_info.
Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical advantages beyond mere annoyance. One is that intel_timeline is no longer an api-visible object and can remain entirely an implementation detail. This may be advantageous as we make scheduler changes going forward. Second is that, together with deleting the CLONE_CONTEXT API, we should now have a 1:1 mapping between intel_context and intel_timeline which may help us reduce locking.
v2 (Tvrtko Ursulin):
- Update the comment on i915_gem_context::syncobj to mention that it's an emulation and the possible race if userspace calls execbuffer2 twice on the same context concurrently. v2 (Jason Ekstrand):
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
v3 (Jason Ekstrand):
- Move the dma_fence_put() to before the error exit
v4 (Tvrtko Ursulin):
- Add a comment about fence contexts to the commit message
Signed-off-by: Jason Ekstrand [email protected] Reviewed-by: Daniel Vetter [email protected] Signed-off-by: Daniel Vetter [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Game diary infrastructure done
This is the world's jankiest CMS to write blogs for games. It's funny cause I might use it that much, but it's mine and I love it.
Could use some slightly better tooling but it's quick to setup at least.
protocol: add a packet_client_error() API
Since the protocol change detailed in 2d103c31c2c (pack-protocol.txt: accept error packets in any context, 2018-12-29) we can emit "ERR" packets in any context that requires a response. Add an API for emitting one, and following that up with a die().
Despite the protocol change in 2d103c31c2c we have not made wide or consistent use of the "ERR" packet in practice. So e.g. if a client supplies unknown arguments under HTTP the client will report a cryptic error about not being able to read the "acknowledgments" section header.
This is because the remote side simply died, and we are not connected to the server's STDERR.
Even when we are connected to STDERR (e.g. under ssh://, or file://) our output is some combination of racy, inconsistent or redundant, as subsequent fixes and tests will demonstrate.
If we were being paranoid here we would only emit these ERR packets to clients that understand the spec change detailed in 2d103c31c2c. I'm not doing that, because:
-
In practice we supported this for a long time, it just wasn't specified. See a8073289793 (connect.c: add a way for git-daemon to pass an error back to client, 2008-11-01) and d78e5aecf93 (pack-protocol: document "ERR" line, 2011-10-04). I.e. Even when we start using this to emit errors to v0/v1 clients they'll grok it.
-
If they don't they're not much worse off, we'll still emit a die() message for now, and if and when we stop doing that it's only going to be ancient clients that are impacted. In practice they probably don't support most of the feature likely to emit these errors in practice, e.g. filters.
This is the first time since d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) that I've found myself slightly missing GIT_TEST_GETTEXT_POISON. As noted in the packet_client_error() comments we've got a tricky case here where we'd like to translate messages to the user, but not the messages on the wire. We'd ideally have some way to specify the language over the wire, but for now let's use LANG=C there.
Signed-off-by: Ævar Arnfjörð Bjarmason [email protected]
CODE_OF_CONDUCT CONTRIBUTING LICENSE README example dot_editorconfig CODEOWNERS FUNDING bug_report config feature_request PULL_REQUEST_TEMPLATE main dot_gitignore dot_gitpod bzr cli clipboard compfix completion correction diagnostics directories functions git grep history key-bindings misc nvm prompt_info_functions spectrum termsupport theme-and-appearance oh-my-zsh _adb _ag alias-finder aliases cheatsheet termcolor ansible ant apache2-macports arcanist archlinux asdf autoenv autojump _autopep8 aws battery _bazel bbedit _bedtools bgnotify _boot2docker _bower bower branch brew _bundler bundler cabal cake cakephp3 _capistrano capistrano _cargo cask catimg colors _celery chruby chucknorris cloudapp cloudfoundry _codeclimate _coffee coffee colemak-less colemak colored-man-pages executable_nroff colorize command-not-found common-aliases compleat composer copybuffer copydir copyfile cp _cpanm dash debian deno dircycle direnv dirhistory dirpersist django dnf _dnote _docker-compose docker-compose _docker-machine docker-machine _docker doctl dotenv dotnet droplr drush eecms emacs executable_emacsclient ember-cli emoji-clock emoji-char-definitions emoji-data emoji update_emoji emotty emotty_emoji_set emotty_floral_set emotty_love_set emotty_nature_set emotty_stellar_set emotty_zodiac_set encode64 _extract extract _fab fancy-ctrl-z fasd fastfile fbterm _fd fedora firewalld _flutter flutter forklift fossil _frontend-search frontend-search fzf _gas _gatsby _gb gcloud _geeknote geeknote _gem gem executable_genpass-apple executable_genpass-monkey executable_genpass-xkcd genpass gh git-auto-fetch git-escape-magic git-extras git-flow-avh git-flow git-hubflow git-lfs git-prompt gitstatus _git executable_update git-completion gitfast _hub github gitignore _asadmin globalias gnu-utils go golang package gpg-agent _gradle gradle grails grc grunt gulp hanami helm heroku executable_update-from-upstream history-substring-search hitchhiker hitokoto homestead _httpie httpie ionic _ipfs isodate iterm2 jake-node jenv jfrog jhbuild _jira jira jruby jsontools jump kate keychain _kitchen _knife knife_ssh kops kube-ps1 kubectl kubectx prod stage lando _artisan laravel laravel4 laravel5 last-working-dir _lein lighthouse lol lxd _port macports magic-enter man marked2 mercurial _meteor meteor microk8s minikube mix-fast _mix mongocli mosh mvn mysql-macports n98-magerun _nanoc nanoc ng nmap node _nomad npm npx _nvm oc _security music osx spotify otp _pass paver _pep8 per-directory-history symlink_per-directory-history percol perl perms phing _pip pip pipenv pj please _pm2 pm2 _pod postgres pow _powder _powify profiles pyenv _pylint pylint python _rails rails rake-fast rake rand-quote rbenv rbfu _react-native react-native _rebar _redis-cli _repo repo _ripgrep _ros rsync ruby _rust _rustup rvm safe-paste _salt _samtools _sbt sbt _scala _scd executable_scd scd screen _scw sdk _sfdx sfffe executable_proxy executable_ssh-agent executable_ssh-proxy shell-proxy shrink-path singlechar _spring sprunge ssh-agent stack sublime-merge sublime sudo _supervisorctl _supervisord supervisor suse svcat svn-fast-info svn _swift swiftpm symfony symfony2 systemadmin systemd _task taskwarrior term_tab _terminitor _terraform terraform textastic textmate thefuck themes _thor tig timer _tmux-cssh tmux _tmuxinator tmuxinator torrent transfer _tugboat ubuntu _ufw _universalarchive universalarchive urltools vagrant-prompt _vagrant vagrant _vault vi-mode vim-interaction virtualenv virtualenvwrapper vscode vundle _wake wakeonlan _wd wd web-search wp-cli _xcselv xcode _yarn yarn yii yii2 yum Makefile z zbell _zeus zeus zoxide zsh-interactive-cd NEWS _n-kill n-aliases n-cd n-env n-functions n-history n-kill n-list n-options n-panelize executable_znt-tmux n-help n-list-draw n-list-input znt-cd-widget znt-history-widget znt-kill-widget znt-usetty-wrapper zsh-navigation-tools zsh_reload zshrc 3den Soliah adben af-magic afowler agnoster alanpeabody amuse apple arrow aussiegeek avit awesomepanda bira blinks bureau candy-kingdom candy clean cloud crcandy crunch cypher dallas darkblood daveverwer dieter dogenpunk dpoggi dst dstufft duellj eastwood edvardm essembeh evan fino-time fino fishy flazz fletcherm fox frisk frontcube funky fwalch gallifrey gallois garyblessington gentoo geoffgarside gianu gnzh gozilla half-life humza imajes intheloop itchy jaischeema jbergantine jispwoso jnrowe jonathan josh jreese jtriley juanghurtado junkfood kafeitu kardan kennethreitz kiwi kolo kphoen lambda linuxonly lukerandall macovsky maran mgutz mh michelebologna mikeh miloshadzic minimal mira mlh mortalscumbag mrtazz murilasso muse nanotech nebirhos nicoulaj norm obraun peepcode philips pmcgee pygmalion-virtualenv pygmalion random re5et refined rgm risto rixius rkj-repos rkj robbyrussell sammy simonoff simple skaro smt sonicradish sorin sporty_256 steeef strug sunaku sunrise superjarin suvash symlink_macovsky-ruby takashiyoshida terminalparty theunraveler tjkirch tjkirch_mod tonotdo trapd00r wedisagree wezm+ wezm wuffers xiong-chiamiov-plus xiong-chiamiov ys zhann check_for_upgrade executable_changelog executable_install executable_require_tool executable_theme_chooser executable_upgrade uninstall