2,061,974 events, 1,028,428 push events, 1,645,823 commit messages, 118,597,346 characters
2020-01-07 Programmer's Notes
Tonight's big build (libcfbammsscf) has been started. That won't be done until the wee hours of the morning. But I'm compiling the 2.12 Java code right now, have already recompiled the Ram library and RamLoader executables for C++ that were affected by CFLib signature changes, and am just doing a "clean room" build of libcfcore, libcfbammsscf, libcfbamcustmsscf, and the msscfcli executable for C++.
I just like to dot my I's and cross my T's before a release. I'll even rerun my tests one more time before shipping, though they won't change 'cause the code didn't change. This is just a sanity check to make sure I didn't miss anything.
I have the CFCore/MssCFGelCompiler working for the creation of the GEL runtime objects. The runtimes won't work without debugging, but I won't be dealing with that until after I have a 2.12 BAM C++ parser written so I can load Business Application Models to generate; I'm certainly not going to hand-code a model in raw C++ to put off that onerous migration task.
I have a couple of things to do before I kick over to working on the C++ BAM parser. I need to switch over to object updates returning void in C++; the signature says they return an instance, but they often return NULL, so you can't use the APIs the way you did with Java's original version. That will mandate a full-stack C++ build.
The most important thing is to rework the Java GEL compiler and runtime to use the new CFCore model; you can't even compile the Java code any more. That means back-porting some new CFLib objects and method changes to Java as well.
Then I need to work on the custom Java BAM parser, because the CFBam 2.12 model has changed to eliminate obsolete concepts, so the custom code for it will be broken. But I need to do that now so that I have a fixed and updated version of the Java parser to port to C++.
Once I can actually manufacture 2.13 code with the Java version, I'll be ready to resume my C++ work for CFCore/MssCF and the custom BAM parser port. Once I have the parser ported to C++, I can start debugging the C++ GEL runtimes (after debugging the BAM parser -- one step at a time!)
When C++ and Java versions of MssCF produce identical 2.13 code, I'll be ready to start enhancing both variations with a replacement for the format verbs that I made obsolete (there was no way to implement them in C++ because C++ doesn't have a common base object in its class hierarchies.)
Ideally I should get to a point where I can manufacture 2.13 code that looks like 2.12 code, save for the version numbers, using either the Java or C++ versions of MSS Code Factory, and will be ready to begin the shift to 2.12 being the production version, 2.11 being internal, 2.10 going obsolete, and 2.13 being the new development version.
Someday I should retrofit my architectural changes for C++ back to the Java architecture, but I won't consider doing that until I'm developing 2.13. Eventually 2.13 should produce architecturally equivalent versions of C++ and Java code, with virtually no difference in the manufactured APIs that aren't mandated by language differences.
I figure it will take the rest of the year to get that far... if I stay busy all year. If I slack off, it won't happen until 2021.
command: cache display-hidpi-scale property
This is a gross hack for the shitty design of how VO properties are handled (which was fine with MPlayer, but became increasingly a shit tub with mpv's VO thread).
The problem here is that console.lua reads display-hidpi-scale on every render, but which may take a long time for video timing and vsync blocking. It will also block the core, making osc.lua unable to react to window resizing quickly enough.
This should be solved by not using the "classic" blocking VOCTRL mechanism, and instead side-stepping it with something that doesn't require any waiting (like for example the "fullscreen" property does).
But this require more thinking and work my "brain" can handle at the moment. So for now add a shitty hack that will cause a lot of problems, and which will have to be replaced later. Most importantly, it'll break theoretic support for multiple screens with different DPI, or runtime DPI changes. Possibly could affect the Cocoa backend; the X11 isn't dynamic enough by nature, and other backends do not implement this.
hell yeah
I am feeling decent about the refactoring and classes and renaming and general cleanliness of the code. Let me know your thoughts. I want to still implement manual traversal and making the view pane scale in size to the input argument. Once I have the manual traversal down. I think it would be cool to "hide" the treasure and allow a user a finite number of "digs" to try and find the treasure which could be passed in as args. Then the question how do we make it a game that is challening but doable but also with some level of objectives.
So like maybe a "warm" "cold" "coldest" "hot" based on the distance from the treasure so its like a metal detector? lmao so its like we give hints but its still a chance a user could lose if they don't dig right and then the difficulty gets harder if you only have like 2 digs and we will only indicate "Warm" which is if the distance is less than 2 blocks away. why the fuck am I still typing right now.
Change Name fuck you error todo la concha de tu madreeeeeee porque al pelotudo de android studio no le gustaba posdata usar guion bajo, nombres en ingles, minusculas, y la PUTA PALABRA WIDGET AL FINAL
Version 0.60
- Added option to customize Good Morning, Good Afternoon, Good Evening and Good Night messages
- Added GC.compact once every 2 hours to compress the leftover spaces by garbage collector. Supported from Ruby 2.7.
- Little performance improvements.
"10:15am. Really slept long, but this is supposed to be my vacation so whatever.
Let me rant a bit.
A very abridged version of my learning trajectory in 2019 went NNs -> CFR -> this. It is really at that last point that I started to accept some of my doubts about formal theorem proving. Unlike classical logic which is pretty much a direct enemy of reason and understanding, constructive logic might have something to say about actual reality.
Nonetheless, PLL's answer is really quite apart from my simple model of imagining a number, imagining a bigger number and then repeatedly halving it until it is smaller than the first one. And then mentally verifying that it holds for all cases.
I can't shake off the feeling that while PLL's answer would get me closer to a formal proof, it would actually get me further away from understanding.
And this is what I am going to accept.
Formal proofs might be programs, but they are not understanding. The actual, simple, unproven program that I made is actually closer to understanding than anything else.
10:25am. This is why I suffered for so long, and why I am going to banish this weight looming over me.
I made an extreme effort to get good at theorem proving for a very middling return. I really should take that as an indication of something.
10:30am. Just what can I realistically expect understanding to be for CFR, and for deep learning? What can I expect to see? If there are proofs about it, would wrapping them in some bigger program really provide the resolution that I seek?
The doubts eat away at me until I can bear it no longer.
2019 really was a tragedy. My belief in math really got shattered.
I watched Wildberger - that bastion of lucidity's videos, and wondered: just how much effort would it take to do the equivalent of what he is doing there for deep learning and for CFR, the things I am actually interested in? He says that pretty much nothing is known about higher dimensional geometry and my heart sinks.
Deep down, I suspect the answer - literally no human can do this. If those much better at math than me cannot do it, then maybe the answer is not necessarily to just wait 10-1000 years until somebody gets it.
10:35am. I am going to pass the keyboard to the me who understood the self improvement loop from the inside.
I am going to start playing God and start treating ML itself as both science and understanding.
In the future, there will be better algorithms, but I've discovered many principles for how to build robust models which I've yet to really apply as I've considered them to be hacks.
So far I've been treating deep learning as if it were something to be debugged. If I focused harder and dove deeper into it, I would get the necessary understanding to see where the steps forward lie. This methods which was very effective for me for discrete algorithms, utterly falls apart for continuous ones.
10:40am. Right now, there are many worse programmers than me who nevertheless apply the correct principles when it comes to ML while I do not.
I am going to make these last few entries that last word on this. I am going to stop talking and thinking about math.
It is time that I get on with the policy of transcendence.
I did my responsibility towards mathematics. Now it is time I ditch the training weights. I've been tacking them on and on until I could barely move. I had enough of this burden of confusion.
It is time little by little to bring out my full power. I am not going to hold back anymore.
11:05am. The language will be done eventually and my work will slip into more important parts.
Right now, I feel that there is no real need to hurry. It is enough to take some time to heal and imagine how my new principles will work for me. I need to learn to enjoy the future that is coming. I need to indulge a little in it, in order to create the right motivation.
I need to move from being a character defined by my failures, to a character defined by my victories once more.
11:10am. The fundamental reality is that there exists 4-5 layer neural net out there somewhere that could make me millions of dollars in poker or something else.
My expression of understanding from here on out will be to find it. My understanding will be the application of correct principles and the fusion of science and learning into a single program. That is what my new notion of understanding will be.
11:15am. This whole episode really does remind me of the time I was bad at roguelikes. I would create a character, proceed to play it like Diablo and then promptly get killed. Before I became a trader and learned patience, I could never really slip into the right strategic mindset.
I want it. I want to find my power. The expression of understanding is the search itself. ML is not like a regular program. It is a living thing. I do not need to understand search, but do it and interact with it instead. That is what understanding is.
11:20am. This desire of wanting power is the most natural thing in the world. But to achieve good results it is really important to channel it in the right way. Because only if you have the principles aligned with the needs of reality can you create the right flow for both work and learning.
Let me take a break here. It makes no sense to start now.
Instead let me have food, do the chores and then I will do some programming when I feel like it.
That is the way to go for the time being. I have my allowance.
Today, I think I will aim at least to get the outer and the inner patterns out of the way. I've been working on some design bits on the side. This shouldn't be too hard to resolve."
Remove the bundler version selector
I do like the idea of bundler being able to lock its own version, but this implementation is not the right way to do it in my opinion.
I aim to reimplement this inside bundler in the near future, but it needs to be done in a more user friendly way that properly informs the user about what's going on, and never raises when not necessary.
But for now I think we should remove this code from rubygems because this is causing more problems than benefits and it's being counterproductive.
Make CNs pretty. Sort of.
I hate swing (or layouts at least).
Do some hacky stuff to make names look presentable.
Don't display issuer if a cert is self-signed - just say self signed instead.
Add some hacky code to display a silly message on the button every now and then.
Do something awful with inheritance to use someone's code in ways they never intended (I mean strictly speaking, they could have used final ...)
PWAs and Fighting Against App Stores
- Speaker : Gabriel Poça
- Available : first day, second day
- Length : 30 minutes
- Language : English
This talk is about what we can do with the open web. There are two parts to it.
The first part is smaller and philosophical. I'll talk about the open web and its importance. My purpose is to show how broken the mobile world is, and how dangerous the play store and app store are. How we've been in this situation before, and what we should be doing to avoid getting into it again. These stores are not open platforms, but most people cannot choose not to use them. There have been plenty of antitrust lawsuits filed against Apple and Google but nothing seems to change. Shouldn't we stop feeding the giant before it gets too big?
The second part of this talk is more technical. I'll show what's available on the web right now, and why it's probably enough for most of your apps. We'll talk about deploys, notifications, offline support, media access, file system access, etc. There's a lot in there. We will go over the good and the bad, clarifying the limitations of each technology. I'll talk about what's to come and to which platform. I also show what you can do right now to leverage both web and native technology while you wait for support on the web.
The information in this talk is based on real life experience building PWAs for many years now.
Gabriel Poca
I don't have a fancy title to show of. I'm a developer and my work goes from hiring to cloud infrastructure. For the past two years I've been focused on building the infrastructure for UTRUST (https://utrust.com/), which is a payment gateway for blockchains. I write a lot of Elixir and JavaScript. I care about the social impact software has, and how the choices we make today impact other people and the next generation.
- Blog: https://gabrielpoca.com/
- Company: https://subvisual.co/
- GitHub: https://github.com/gabrielpoca
PWAs and Fighting Against App Stores
- Speaker : Gabriel Poça
- Available : first day, second day
- Length : 30 minutes
- Language : English
This talk is about what we can do with the open web. There are two parts to it.
The first part is smaller and philosophical. I'll talk about the open web and its importance. My purpose is to show how broken the mobile world is, and how dangerous the play store and app store are. How we've been in this situation before, and what we should be doing to avoid getting into it again. These stores are not open platforms, but most people cannot choose not to use them. There have been plenty of antitrust lawsuits filed against Apple and Google but nothing seems to change. Shouldn't we stop feeding the giant before it gets too big?
The second part of this talk is more technical. I'll show what's available on the web right now, and why it's probably enough for most of your apps. We'll talk about deploys, notifications, offline support, media access, file system access, etc. There's a lot in there. We will go over the good and the bad, clarifying the limitations of each technology. I'll talk about what's to come and to which platform. I also show what you can do right now to leverage both web and native technology while you wait for support on the web.
The information in this talk is based on real life experience building PWAs for many years now.
I don't have a fancy title to show of. I'm a developer and my work goes from hiring to cloud infrastructure. For the past two years I've been focused on building the infrastructure for UTRUST (https://utrust.com/), which is a payment gateway for blockchains. I write a lot of Elixir and JavaScript. I care about the social impact software has, and how the choices we make today impact other people and the next generation.
- Blog: https://gabrielpoca.com/
- Company: https://subvisual.co/
- GitHub: https://github.com/gabrielpoca
Added Sound Feedback for Mod Building and Fuck you 7zip
7.1.Stripe Invoices{Creating & Paying the Invoice}
The first two important objects in Stripe are Charge and Customer. Let's talk about the third important object: Invoice. Here's the idea: right now, we simply charge the Customer. But instead of doing that, we could add invoice items to the Customer, create an Invoice for those items, and then pay that Invoice. To the user, this feels the same. But in Stripe, instead of having a charge, you will have an Invoice full of invoice items, and a charge to pay that invoice. Why do we care? Well first, it let's you have detailed line-items - like two separate items if our customer orders 2 products. And second, invoices are central to handling subscriptions. In fact, you'll find the Invoice API documentation under the subscription area. But, it can be used for any charges.
Creating & Paying the Invoice Let's hook this up. First, instead of creating a Stripe Charge, create a Stripe InvoiceItem. But all the data is the same. Below that, add $invoice = \Stripe\Invoice::create() and pass that an array with customer set to $user->getStripeCustomerId(). Finally, add $invoice->pay(). Let's break this down. The first part creates an InvoiceItem in Stripe, but nothing is charged yet. Then, when you create an Invoice, Stripe looks for all unpaid invoice items and attaches them to that Invoice. The last line charges the customer to pay that invoice's balance. Usually, when you create an Invoice, Stripe will charge the customer immediately. But, if you have web hooks setup - something we'll talk about in the second course - that will delay charging the user by 1 hour. Calling ->pay() guarantees that this happens right now. Ok, go back and try this out. Find a great and high-quality product, and add it to the cart. Checkout using your favorite fake credit card and fake information. Looks like it worked! And since this user already is a Stripe customer, refresh that customer's page in Stripe. Check this out! We have two payments and we can see the Invoice. If you click that, the Invoice has 1 line item and a related Charge object.
Tip
If all charges belong to an invoice, you can use Stripe's API to retrieve your customer's past invoices and render them as a receipt. This now gives us more flexibility. Since sheep love to shop, they'll often buy multiple products. In fact, let's go buy some shears, and some Sheerly Conditioned. If we checked out right now, this would show up as one giant line item for $106.00 on the Invoice. We can do better than that.
12.1.Pretty Card Formatting
The old, embedded form had a couple of nice formatting behaviors - like automatically adding a space between every 4 card numbers. Fortunately, Stripe has us covered once again here. Go back to the documentation and scroll down - they eventually reference something called jQuery.payment: a neat little JavaScript library for formatting checkout fields nicely. It even provides validation, in case you want to make sure the numbers are sane before sending them off to Stripe. I've already downloaded this library into the web/js directory, so all we need to do is include it on the page and point it at our form. At the top, add a new script tag and set its src="js/jQuery.payment.min.js". The asset function is an optional helper function from Symfony - nothing magic going on there. Then, down below... try to ignore the ugly indentation that I should have fixed earlier, and say $form.find(). We need to find the credit card number input. But don't worry! I planned ahead and gave it a special js-cc-number class. I also added js-cc-exp and js-cc-cvc. Fill in .js-cc-number and then call .payment('formatCardNumber') Repeat this two more times for js-cc-exp with formatCardExpiry and formatCardCVC. Don't forget to update that class name too. Try it out! So sweet! The card field gets pretty auto-spacing and even more importantly, the library adds the slash automatically for the expiration field. It also limits the CVC field to a maximum of 4 numbers. So custom forms are a little bit more work. But they fundamentally work the same. Before we finish, there's one big hole left in our setup: failing gracefully when someone's card is declined.
Worldview: add GLText command (#291)
Adds a new <GLText /> command which is API-compatible with <Text />. Instead of overlaying DOM nodes on top of Worldview, the text is rendered in GL so it can participate in occlusion. Rendering in GL is also much faster than managing many separate DOM elements; see the GLText docs page for a performance demo.
All the necessary characters are rendered into a texture atlas using a signed distance field representation, then all characters from all children are drawn in a single draw call. More implementation details are explained in GLText.js.
Many thanks to the following resources/implementations/references which were helpful in informing this implementation!
- Valve: Improved Alpha-Tested Magnification for Vector Textures and Special Effects
- Mapbox: Drawing Text with Signed Distance Fields in Mapbox GL
- Otto Chrons: Text rendering in OpenGL
- Stack Overflow: Better Quality Text in WebGL
- https://github.com/mapbox/tiny-sdf
- deck.gl TextLayer
- mapbox-gl-js GlyphManager
- https://github.com/dy/font-atlas-sdf
Added stories/screenshot tests and docs page demo. Unfortunately the code is not too easily amenable to unit testing (other than perhaps the font atlas memoization).
This PR is purely additive, so doesn't necessitate a major version bump. The GLText command might eventually replace Text, but we'd like to get some mileage on it first — we'll be testing it in Webviz, and would love for any external users to give it a try as well. A few areas for improvement would probably need to be addressed before deprecating the DOM-based Text command: solid rectangular background instead of outline (or at least improved visibility at small sizes); highlight ranges to replace browser-native ⌘F; hitmap support.
Re-land "[lldb/CMake] Change how we deal with optional dependencies"
Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite.
The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang.
This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
New top level navigation in Dagit, rework of pipeline scope
Summary: This is a fairly significant rework of the Dagit navigation. A new left-hand "VSCode-style" sidebar replaces the top nav, which used pretty valuable real-estate. The "Explore" tab has been replaced by a "Pipelines" tab and the pipeline selector is within the Explore UI. The URLs have changed a bit, and the solid query is stored in the URL so that it's easy to share "views" of a pipeline and they're compatible with the browser's back button.
The Execute tab has been replaced by an execution Playground tab with a single set of saved tabs. (Previously each pipeline had it's own saved documents). The execution tab is no longer dark-themed by default (we'll probably add light/dark mode support to the entire app rather than colorizing just Execute in a dark theme.)
Minor sidenotes:
-
The solid query bar now only "commits" your typing when you press "+", "return", autocomplete a solid, or blur the field. This resolves jank when you highlight the field and immediately type "*".
-
The new UI binds Ctrl/Cmd+E to the "soft dagit reload" (we can't use Cmd+R for obvious reasons unfortunately).
-
Dagit now stores the list of pipelines in React Context because they're used in odd places and are a pain in the ass to re-org. I expect this will also come in handy when we build an "Open-Quickly" UI.
Future Todos:
This diff excludes some of the more experimental changes that we initially incorporated into the new navigation. Eventually, we want to unify the "solid query" concept and the "solid subset" used for execution so that you can view a set of solids in the Pipeline tab and click "Execute This View" to transfer that pipeline+query+mode to a new Playground session. This was mostly working but should be implemented via backend support for the solid query syntax.
We also want to explore blending the pipeline selection and the solid query into a single concept, and potentially allowing the query to select composite contents so that the entire Explore view could be represented via a query that is built/modified as you click around and drill down.
Screenshots!
{F76602}
{F76603}
Test Plan: Run updated snapshot tests
Reviewers: alangenfeld, prha, schrockn
Reviewed By: alangenfeld
Differential Revision: https://dagster.phacility.com/D1763
1097 date pickers (#1118)
-
style(html): Whitespace cleanup
-
feat(css,js): Add date picker JS and CSS assets
-
feat(forms): Add datepicker classes to advanced search HTML forms
-
feat(html): New datepicker JS include
-
feat(html): Add datepickers to search pages
-
feat(html): Add datepickers to PACER docket page for entry filters
-
feat(html): Replace date placeholder default format
I admit it. I put the old format because I know it's better, and I did it to our user's determent. This, finally, fixes that, both owning up to the bad UI decision and admitting defeat the poorly optimized, overly conservative, change resistant society in which we live (America).
- fix(html): Adjust date picker configuration
This addresses several issues:
-
assumeNearbyYear=true would mess up dates like 2001-01-09 by assuming that 2001 was a...month? Or something. It was bad. By removing this configuration, we now fail to parse such dates (which is annoying), but at least we don't parse them wrong.
-
forceParse=false would allow people to input bad dates, or at least dates that didn't match our desired formatting. So let's make sure always parse.
-
endDate=0d will make it so you cannot select dates in the future.
-
disableTouchKeyboard is needed because on a small screen when the keyboard came up, it'd make it so you couldn't touch the calendar. And if you tried to touch the calendar, you'd close the input box. It was impossible to complete and very annoying, so this fixes that.
- fix(dates): Stop reformatting people's date fields to our format
Update README.md
Hey man, I tried to follow the guide, but ended up getting a bit stuck.
The Metasploit handler kept instantly closing on me when I used 'set payload windows/meterpreter/reverse_tcp'. A while back I had the same issue with another exploit, ended up trying out the shell, which worked. Same in this case, it got me in!
I then checked your video, turns out you actually did the same. So I felt like giving your guide some love. I hope you see the same value as I do in stating the exact "msf" commands.
Anyway, have a great day and thank you so much for your exploit. Thanks to people like you I'm actually getting the hang of this stuff :)
Update README.md with Emscripten instructions
Emscripten is pretty low on our priority list at the moment, but we'd love to get a web UI back some time in the future.
In the mean time you can enjoy sharing your games via the web thanks to @Daft-Freak