4,259,828 events, 1,367,449 push events, 2,165,183 commit messages, 168,062,343 characters
test/doom.d/init.el: Updating from hlissner/doom-emacs - 437c33a8
---
+++
@@ -111,7 +111,8 @@
:lang
;;agda ; types of types of types of types...
- ;;cc ; C/C++/Obj-C madness
+ ;;beancount ; mind the GAAP
+ ;;cc ; C > C++ == 1
;;clojure ; java with a lisp
;;common-lisp ; if you've seen one lisp, you've seen them all
;;coq ; proofs-as-programs
@@ -124,6 +125,7 @@
emacs-lisp ; drown in parentheses
;;erlang ; an elegant language for a more civilized age
;;ess ; emacs speaks statistics
+ ;;factor
;;faust ; dsp, but you get to keep your soul
;;fsharp ; ML stands for Microsoft's Language
;;fstar ; (dependent) types and (monadic) effects and Z3
@@ -138,9 +140,8 @@
;;julia ; a better, faster MATLAB
;;kotlin ; a better, slicker Java(Script)
;;latex ; writing papers in Emacs has never been so fun
- ;;lean
- ;;factor
- ;;ledger ; an accounting system in Emacs
+ ;;lean ; for folks with too much to prove
+ ;;ledger ; be audit you can be
;;lua ; one-based indices? one-based indices
markdown ; writing docs for people to ignore
;;nim ; python + lisp at the speed of c
@@ -159,7 +160,7 @@
;;(ruby +rails) ; 1.step {|i| p "Ruby is #{i.even? ? 'love' : 'life'}"}
;;rust ; Fe2O3.unwrap().unwrap().unwrap().unwrap()
;;scala ; java, but good
- ;;scheme ; a fully conniving family of lisps
+ ;;(scheme +guile) ; a fully conniving family of lisps
sh ; she sells {ba,z,fi}sh shells on the C xor
;;sml
;;solidity ; do you need a blockchain? No.
@@ -167,6 +168,7 @@
;;terra ; Earth and Moon in alignment for performance.
;;web ; the tubes
;;yaml ; JSON, but readable
+ ;;zig ; C, but simpler
:email
;;(mu4e +gmail)
Define dependency on github/consul
Welcome. This is a weird one. On the face of it we're simply adding a
relationship between this module (our own fork of the consul_template
module) and a module called github/consul, by making this module
require v1+ of the consul module.
Two things are unusual about this. Firstly, the source of the
github/consul module is actually within the puppet repo - originally
at modules/consul but now moved to module_src/consul. This module is
referenced in the puppet repo's Puppetfile only with its local path, so
that the librarian install step is able to "install" the consul module
and satisfy dependencies of anything that depends on it. All that is to
say that if you try to use this consul_template module anywhere but the
github/puppet repo, librarian isn't going to be able to satisfy the
github/consul dependency. That's not wonderful, but it's a manageable
risk given how we've forked both github/consul and this
consul_template module inhouse, and we currently have only one puppet
repository.
The appropriate question to ask is why the heck are we doing this: Our fork of the consul module had puppet v3 functions defined, one of which caused errors when we tried to serve the module through a v7 puppetserver. To fix this we updated the v3 functions to be puppet v4 compatible, but in doing so hit a puppet feature where you're unable to call v4 functions in module B from module A unless module A defines a dependency on module B in its metadata.json. Hence, this.
This limitation was removed in puppet 5.5+ but at the moment we're having to support puppet-agent versions 4, 5 and 7 across the fleet while we slowly migrate everything to puppet 7. I'm hopeful that if we successfully roll puppet 7 out we can revisit this change and our module structure in general, and remove these unnecessary hacks.
Thanks for sticking with me this far. I've just had my second covid vaccine so I'm feeling a little loopy.
updated: 20210430. New:ESAI - Caffeine Kitty by abcbadq, Warak - REANIMATE by cerret & Nolanimations, fallen shepherd - ENDYMION by Soba`s & Artjoms, Igorrr - Absolute Psalm by FatBeanzoop, BlackY - ULT!MATE END by Helloiamdaan & RocKz, Camellia - Light It Up by cat_using_a_toaster, Schwank and Tanger - Emanation by Jaack, Kanaria - Envy Baby by CoolingCloset & Nolanimations, DJ Genki - LOVE SPICE LIKE U!!! by altrewin, DJ Genki - Toymatic Parade by cerret, Lektrique x Sam Lamar - Black Magic by A Jhintleman, DJ Myosuke - Collapse Of Ego by Helloiamdaan, P*Light - Nirvana by abcbadq, AJR - Bang! by BrightKnight, ikaruga_nex - HellFire by abcbadq & Timbo, USAO - USAO ULTIMATE HYPER MEGA MIX by Edmard, ReeK - Weeaboo Spookfest by Schwank, USAO - Last Kingdom by Uninstaller, Lapix - Labyrinth by Shappy & Checkthepan, Camellia - GHOST by Foxy vs. Narwhal, Camellia - Dyscontrolled Galaxy by That_Narwhal
Add files via upload
I don't understand why I can never get a function to run from a button ever, its stupidly easy too, anyway in this I removed all prompts, added 2 buttons, these buttons are supposed to replace the function of the prompts for yes and no, makes sense right? Yeah but either I have too little experience or this requires a code rewrite to get done
Fixed cabinet hinges, despite teh crashes. fuck you unity.
Whoever wrote this original code should be ashamed (#400)
This was code from a case where I was told that the official core fixed this bug already, There's a huge problem with wire, you need to get the fix in before the next release (which I was in the process of releasing) with Wire. Okay, well, the official core is going to work without a hitch, I guess I'll go grab it. And there was a problem. what I wound up getting wasn't complete and was even worse, so I had to do another emergency release to fix it.....
Having had a deep dive into how the fuck you're supposed to calculate the baud value to use, It looks to me like they didn't even TRY or THINK at any point in the process of writing that code. And, well, when you don't try to do it right and do a bunch of stuff in silly and/or naïve ways the result, you get crap.
Can you test this code out and see if it actually works? I don't want to do another release that shits on Wire, but I also don't have a dedicated wire test rig - I should have one for tinyAVR and Dx both... But I should have a lot of things that I won't have time to build any time soon.
Create Pasiphae.FUNDING.yml
SELENE was the Titan goddess of the moon. Hekaté was the Goddess of Witchcraft & magic & Pasiphaê was also an early Creten moon Goddess.
Pasiphaê (aka: Cassandra) was the 1st MOON GODDESS. She was married to Minotaur & bore a son, (half man and half BULL) Taurus. Pasiphaê, Hekaté and Seleně (also known as CASSANDRA) ALL were MOON GODDESSES.
The Seven Sisters are revered throughout the world as a beacon of light and creation for humanity. Many cultures have celebrated these celestial star beings including the Greek, Irish, Celts and the Japanese. Also the Mayans, Aztecs, Sioux, Kiowanees and the Cherokees. The Seven Sisters are celebrated all over the world! This small star cluster is revered and holds great mystery and power & is located in the rear-end of Taurus even though Plaides tries to claim the girls. No naked eye can see all 7 stars but to the highly trained eye such as mine, I'm able to see 5 of them quite clearly. The 7 sisters intelligence reflects itself into human form to help raise the vibration of humanity and accelerate consciousness in all, Nurturing the Mother principle in the whole womb of creation. The seven sisters are reflecting data in the form of light streams into this digital tool to catalyze a deep collective awakening and a higher understanding of the unified field. The gifts that are activated by the frequencies of the seven sisters are Creativity, Pineal gland awakening, access to the Akashic Records, time travel, inter dimensional viewing, precognition, telepathy, Excentuating the 6th sense and empathic clairvoyance. Also, Quantum Teleportation, traveling through the Astral planes and more!
References: Starsinger/seven7sisters prophecy www.quantumfrequencytechnologies.com
@hekate_pasiphae_selene (Instagram)
Www.facebook.com/anysoldiersgirl
⋆Cassandra Meeleus-Jansen
(520)369-6240
1365 W. Grant Rd.
Tucson, AZ 85745 - 1407
[email protected]
[email protected]
@hekate_pasiphae_selene (Instagram)
Www.facebook.com/anysoldiersgirl
Bide the Wiccan law ye must, in perfect love and perfect trust.
8 words the Rede fulfill,
and ye harm none,
DO AS YE WILL.
WHAT YOU PUT FORTH COMES BACK TO THEE
so ever mind the RULE OF THREE.
Follow this with mind & heart,
Merry ye meet & merry ye part. SELENE was the Titan goddess of the moon. Hekaté was the Goddess of Witchcraft & magic & Pasiphaê was also an early Creten moon Goddess.
Pasiphaê (aka: Cassandra) was the 1st MOON GODDESS. She was married to Minotaur & bore a son, (half man and half BULL) Taurus. Pasiphaê, Hekaté and Seleně (also known as CASSANDRA) ALL were MOON GODDESSES.
this is what not knowing how to work with git looks like
God damn i hate this boogaloo things i should really read the manual one day to know how to work with this cursed software
Add files via upload
The coronavirus that broke-out in 2019 and spread across the world has been a journey of difficulty and struggle that was not expected by any individual. The coronavirus pandemic has affected the health of millions around the world. While it has definitely caused damage to the physical health of many, its effect on mental health has also been a massive concern. Individuals are facing a range of emotions due to the unpredictable news that is being shared everyday. It is important that the data being shared by users on the internet is legit and positive as this in turn can affect others who view it. During the period of quarantine, many individuals took to social media like Twitter, Facebook, etc. to voice out their feelings on the pandemic. In this paper, we wish to analyze the emotions expressed by individuals through their tweets on Twitter. We have used the data collected from Kaggle and performed several preprocessing techniques in order to make the data suitable for modelling. We have applied Natural algorithms such as Logistic Regression (LR), Multinomial Naive Bayes, Decision Tree, Support Vector Machines (SVM) and Multilayer Perceptron algorithm to classify the sentiments associated with the tweets posted into different categories, namely, positive and negative. We have also built an ensemble model combining LR and SVM for obtaining improved results. Furthermore, we will be comparing the different models to determine the most accurate and efficient algorithm. The results provide us with the changing views of people on the pandemic and how it has affected the sentiments of individuals. This can be extended to determine the emotions felt by individuals during any other virus break-out situation and can help authorities to understand the emotions of the common public better in order to put out an effective fight against the pandemic.
Managed to preserve Forseti demo compatibility by adding 2 lines of code
Sorry, but it was easy enough to add. Still, maybe we still shouldn't consider it a future policy to preserve EE demo compatibility despite this commit (it can result in highly patchy code if we keep doing it). But I love when I can preserve compatibility between versions… What is likely is that physics changes to the Doom code aren't going happen all the time, but only when we fix bugs (where indeed, adding demo_version sucks, because it means we keep crappy code) or do enhancements like here (where luckily it was only a need for these lines).
Well at least I have a possibility to test demos of previous a Eternity version against any of my regressions with slope physics.
Update DLPack to 0.4 (#55365)
Summary: Fixes pytorch/pytorch#55090
I included the header directly, but I am not sure if we should add this as a git submodule, what do you guys think? Also regarding the implementation, in ATen lanes seems not to be supported, but from CuPy complex types are exported with 2 lanes, I am not sure wether this is correct or not. However, in PyTorch this seems to be working properly, so I forgive 2 lanes for complex datatypes.
TODO: add tests for complex and bfloat
Easy test script against cupy
import cupy
import torch
from torch.utils.dlpack import to_dlpack
from torch.utils.dlpack import from_dlpack
# Create a PyTorch tensor.
tx1 = torch.tensor(
[2 + 1j, 3 + 2j, 4 + 3j, 5 + 4j], dtype=torch.complex128
).cuda()
# Convert it into a DLPack tensor.
dx = to_dlpack(tx1)
# Convert it into a CuPy array.
cx = cupy.fromDlpack(dx)
# Convert it back to a PyTorch tensor.
tx2 = from_dlpack(cx.toDlpack())
torch.testing.assert_allclose(tx1, tx2)Thanks to leofang who updated CuPy's dlpack version and his PR served me as the guide for this one.
Pull Request resolved: pytorch/pytorch#55365
Reviewed By: ngimel
Differential Revision: D27724923
Pulled By: mruberry
fbshipit-source-id: 481eadb882ff3dd31e7664e08e8908c60a960f66
Update on "[codegen] split out backend-specific information from NativeFunction in the model"
Data model change in the codegen, which splits backend-specific information out of NativeFunction
Currently in the codegen, native_functions.yaml has backend-specific information about each operator that is encoded directly into the data model, in the NativeFunction object. That's reasonable, since the native_functions.yaml is the source of truth for information about an operator, and the data model encodes that information into types.
Now that external backends can use the codegen though, that information is technically incomplete/inaccurate. In another PR, I tried patching the information on the NativeFunction object with the additional external information, by updating the dispatch entry to contain the external backend kernel name and dispatch key.
Instead, this PR tries to split out that information. The NativeFunction class contains all information about an operator from native_functions.yaml that it backend-independent and is known never to change regardless of what extra information backends provide. We also build up a backend "index", which is basically a mapping from [backend] -> [backend-specific-metadata]. Reading in external backend metadata just involves updating that index with the new backend.
There were a few places where NativeFunction used the dispatch table directly, that I encoded as properties directly on the NativeFunction object (e.g. is_abstract). They were mostly around whether or not the operator has a composite kernel, which isn't something that's going to change for any external backends.
This has two advantages:
- We can more easily re-use the existing logic in
native_function.pyandregister_dispatch_key.pyfor both native and external backends, since they both involve a NativeFunction + a particular backend index - The data in the data model will be the same regardless of how the codegen is run. Running the codegen with a new external backend doesn't change the data inside of NativeFunction or an existing backend index. It just adds a new index for that backend.
An alternative to this split would be to augment the NativeFunction objects with external backend information at the time that we create them. So the external codegen could read both native_functions.yaml and the external backend's yaml at the same time, and construct a NativeObject with a full dispatch table (including the XLA entry), and the correct setting of structured (taking into account both yamls). One disadvantage to this approach is that NativeFunction objects now contain different stuff depending on how you ran the codegen, and you have to make sure that any changes to the codegen can properly handle all the different variants.
Removed 3 classes, which are used by the external codegen:
- ExternalBackendFunction
- ExternalBackendFunctionsGroup
- ExternalBackendMetadata
And added two new ones:
- BackendIndex
- BackendMetadata
BackendIndex contains any info that's specific to that backend, plus a mapping from operator names to backend specific metadata about the operator. One example of backend-specific info that's not operator-dependent is the fact that XLA prefers to implement functional kernels instead of out kernels (and so when they eventually mark an op as structured, they're going to mark the functional op and not the out op).
BackendMetadata contains info specific to an (operator, backend) pair. Right now, that's just (a) the name of the kernel, and (b) whether or not that operator is structured.
I wanted to get this PR up earlier so I could get feedback, but there are a few things I want to call out:
Dealing with structured.
This PR separates out the notion of structured into two bits of information:
- Does [operator] have a meta() function. This is backend-agnostic, and is represented by the
structuredproperty onNativeFunction, same as before. This is used, e.g., to decide what signatures to add toMetaFunctions.h. - Does [operator, backend] have an impl() function. This is backend dependent; even though technically all in-tree backends are forced to write impl() functions for an operator when we port the op to structured in native_functions.yaml, out-of-tree backends can decide to opt in independently. This is represented as a property on
BackendMetadata. This is used in most other cases, e.g. inRegisterDispatchKeywhen we're deciding whether or not to gen a structured or unstructured wrapper.
I also baked is_structured_dispatch_key directly into each BackendIndex. So for operators marked "structured" in native_functions.yaml, their corresponding CPU/CUDA BackendIndex entries will be marked structured, and all others (except for potentially external backends) will not.
I ended up trying to deal with structured in this change since it's technically backend dependent (XLA can opt kernels into structured separately from in-tree ops), but that may have been too ambitious: it's technically not relevant until we actually add support for structured external kernels. If it's not clear that this is the right path for dealing with structured and we want to push that off, I'm fine with backing out the bits of this PR that make structured backend-dependent.
Localizing the fact that external backends follow Dispatcher convention.
Another thing that's sort of backend specific that I didn't totally address in this PR is the fact the fact that in-tree backends follow the Native API while external backends follow the Dispatcher API. I painted over that in native_functions.py by adding a helper, kernel_signature, that takes in a native function and gives you the "correct" signature for the specified backend- NativeSignature for in-tree backends, and DispatcherSignature for out-of-tree backends. In order to make that fully useable though, we'll need NativeSignature and DispatcherSignature to have matching interfaces. I didn't bother with that in this PR, which is why gen_external_aten_fallbacks.py still has a bunch of direct references to the dispatcher API. Thinking of adding it in a later PR but wanted to see if anyone has other opinions.
Thoughts on the BackendIndex / BackendMetadata breakdown.
One thing that's annoying right now is that to query for various pieces of metadata, you call helper functions like backend_index.structured(f), which queries that particular backend and tells you if that specific NativeFunctionGroup is structured for that backend. It has to return an Optional[bool] though, since you have to handle the case where that operator doesn't have a kernel for that backend at all. So users of those helpers end up with a bunch of optionals that they need to unpack, even if they know at some point that the result isn't None. I think it would be easier instead to just store the NativeFunction object as a field directly on the BackendMetadata. Curious if there are any other opinions on a better way to model it though.
[ghstack-poisoned]
almost implemented " cp"
- "cp" - not to the end
- "copy" (the function that is used in "cp" to copy files and directories) - almost implemented
- "read_file_data" (the function that is used in "copy" to read data from files and directories) - almost implemented
- "init_chunk_data" (if non-resident attribute) - data read is not implemented (must be implemented)
Conclusion: Today I worked very hard and fucked my brain, I hope that tomorrow I will finish this shit.
Thanks for your attention
- Added matrices, descriptor pools, descriptor sets and descriptor set layouts. triangle demo now has a spinning square and no longer a triangle... Maybe I should rename the demo or, even better, delete it because the code is beginning to be an ugly mess holy crap. Going to be ridiculously hard to wrap this all in tz::gl sanely
locking/rwsem: Fix down_write_killable()
The new signal_pending exit path in __rwsem_down_write_failed_common() was fingered as breaking his kernel by Tetsuo Handa.
Upon inspection it was found that there are two things wrong with it;
- it forgets to remove WAITING_BIAS if it leaves the list empty, or
- it forgets to wake further waiters that were blocked on the now removed waiter.
Especially the first issue causes new lock attempts to block and stall indefinitely, as the code assumes that pending waiters mean there is an owner that will wake when it releases the lock.
Reported-by: Tetsuo Handa [email protected] Tested-by: Tetsuo Handa [email protected] Tested-by: Michal Hocko [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Cc: Alexander Shishkin [email protected] Cc: Andrew Morton [email protected] Cc: Arnaldo Carvalho de Melo [email protected] Cc: Chris Zankel [email protected] Cc: David S. Miller [email protected] Cc: Davidlohr Bueso [email protected] Cc: H. Peter Anvin [email protected] Cc: Jiri Olsa [email protected] Cc: Linus Torvalds [email protected] Cc: Max Filippov [email protected] Cc: Peter Zijlstra [email protected] Cc: Stephane Eranian [email protected] Cc: Thomas Gleixner [email protected] Cc: Tony Luck [email protected] Cc: Vince Weaver [email protected] Cc: Waiman Long [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar [email protected] Signed-off-by: Ratoriku [email protected] Signed-off-by: Moeeze Hassan [email protected]
feat(client): support file:* for simpler file uploads by path
holy shit code for handling file is getting more and more ridiculous. i wonder if i could refactor it somehow...
my god this is the worst pile of shit I've written in a fucking while
Add group and permissions settings to the Facts DB
Summary: This is part of a larger effort to improve the performance of native Facts in CLI mode.
Today, we insert the unix user's uid into the Facts DB's path, so different unix users will always build and connect to different DBs.
This is sound from a permissions standpoint, but it does mean most people have two DBs on their disk. One belongs to apache and gets updated by your HHVM webserver. The other is owned by your unix user (like jhemphill) and only gets updated when you run a script in CLI mode as yourself.
When you build or update the DB that belongs to your unix user, you get a terrible experience. We build the DB "in a background thread". But your CLI-mode script is probably fairly short-lived. After your script is done, we'll probably still be writing to the DB, and we'll probably need to hold your process open while we finish updating the DB.
People are wondering why their "hello world" scripts need to stay open for twenty minutes after they've printed "hello world". People ctrl+c these scripts out of impatience. It's not great.
This diff allows you to specify a group and permissions bitmask for the DB. SQLite won't let you read a wal-mode DB without rw permissions, so if you want to take advantage of Autoload.DB.Group you'll probably want to set your permissions to 0664.
After this diff, we can change the configuration so different users will be able to connect to the same DB. Then each devserver can have just one DB, usable in both CLI-standalone and CLI-server mode.
Reviewed By: fredemmott
Differential Revision: D28016712
fbshipit-source-id: 5a64d250802c9d1100abfe32c9eca7e2250fad2f
Updating: 4/30/2021 10:00:00 PM
- Added: Problem space. Shipping space. - Mark Boulton (https://markboulton.co.uk/journal/problem-space-shipping-space/)
- Added: Solving multidimensional PDEs in pytorch (https://jparkhill.github.io/SolvingDiffusions/)
- Added: Backing Up Vimwiki With Rsync (https://des.wtf/backing-up-vimwiki-with-rsync/)
- Added: To PaaS or not (https://www.shayon.dev/post/2021/119/to-paas-or-not/)
- Added: How to find a Bluetooth amp that doesn't suck · derhagen (https://blog.derhagen.eu/2021/04/29/how-to-find-a-bluetooth-amp-that-doesnt-suck.html)
- Added: The 11th Reason to Delete your Social Media Account: the Algorithm will Find You (http://simondedeo.com/?p=705)
- Added: Don't Use "Idiomatic" as an Excuse. Ship Things Instead (https://preslav.me/2021/04/30/dont-use-idiomatic-as-an-excuse-ship-things-instead/)
- Added: The faulty digital clock problem (https://andersource.dev/2021/04/29/faulty_digital_clock.html)
- Added: Mixed Boolean Arithmetic Obfuscation (https://blog.binclub.dev/006-Mixed-Boolean-Arithmetic/)
- Added: What do we mean by a “backdoor” in End-To-End Encrypted Messengers or Secure Messengers? #endToEndEncryption #e2ee (https://alecmuffett.com/article/14275)
- Added: FOCUSCAP – NO DISTRATIONS! (https://focuscap.io/)
- Added: .NET R&D Digest (April, 2021) (https://olegkarasik.wordpress.com/2021/04/30/net-rd-digest-april-2021/)
- Added: How to use markdown if markdown is not supported (https://bengtan.com/blog/how-to-use-markdown-not-supported-substack/)
- Added: How to make the most of your software engineering career - andre.schweighofer (https://andreschweighofer.com/career/how-to-make-the-most-of-your-software-engineering-career/)
- Added: The Little Things: everyday efficiencies (https://codingnest.com/the-little-things-everyday-efficiencies/)
- Added: Cryptology ePrint Archive: Report 2021/323 (https://eprint.iacr.org/2021/323)
- Added: Calendly: The $4B DocuSign of Scheduling (https://sacra.com/research/calendly-the-docusign-of-scheduling/)
- Added: Why you should spend $350 on a computer keyboard (https://avdi.codes/why-you-should-spend-350-on-a-computer-keyboard/)
- Added: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. (https://www.notion.so/Interpreting-the-emotions-in-my-journal-entries-with-NLP-6014c4cfaf7447c281f4c7824bf14401)
Generation took: 00:09:38.7846958 Maintenance update - cleaning up homepage and feed
Did a decent chunk of work. Mostly on JSON, but fleshed out grid structure and data retrieval for contact component.
Thought is we want to basically have two types of components, either we display the JSON data dynamically / arbitrary levels of nesting (like is done with skills component) or with 8 (2 col X 4 row) like is done with contact- experience can fit into the later, about the prior.
going to eat dinner now, hopefuly can continue with getting nice big chunks of work done on this later tonight and tomorrow, so this can be deployed and hosted soon