Programming thread

[y a t s]

Anyone have a tutorial on isolating unreal engine signatures. I am looking for FName_ToString for ue4SS

If I'm understanding the question correctly, maybe try objdump -CT to dump the symbols from the binary then grep for it? For windows, you would want to use dumpbin instead.

 

[${Sandy}]

Can someone explain to me why in the mother fuck I would ever use

const niggerlicious = (arg) => {}

instead of

function divineProvidence(arg) = {}

I've run into this stuff a few times before and both of them are functions. I skipped a few sections on freecodecamp and the lessons I'm doing right now want me to write my functions using the first method but it just seems utterly fucking niggerlicious.

Edit: Is it so you can use a variable as a function, instead of creating a function and assigning the outcome to a variable?

 

[y a t s]

Can someone explain to me why in the mother fuck I would ever use

const niggerlicious = (arg) => {}

instead of

function divineProvidence(arg) = {}

I've run into this stuff a few times before and both of them are functions. I skipped a few sections on freecodecamp and the lessons I'm doing right now want me to write my functions using the first method but it just seems utterly fucking niggerlicious.

Arrow functions are primarily used for anonymous functions and callbacks. They're just a compact way of writing out functions for things like EventListeners. Functions are treated like any other object in JS, so there's nothing stopping you from assigning them to a variable like you do with the const. This sort of behavior in JS makes it so that there are a thousand different ways, each of varyingly dubious quality, of writing the various parts of your program. It's what makes JS beautiful but often painful to read.

Here's a quick example from an old repo on my github:

socket.addEventListener("close", (event) => {
    console.log("[SNEED] Socket has closed. Attempting reconnect.", event.reason);
    setTimeout(() => { socket = new WebSocket(SOCKET_URI); }, SOCKET_TIMEOUT);
});

Nice and compact

 

[macrodegenerate]

Can someone explain to me why in the mother fuck I would ever use

const niggerlicious = (arg) => {}

instead of

function divineProvidence(arg) = {}

I've run into this stuff a few times before and both of them are functions. I skipped a few sections on freecodecamp and the lessons I'm doing right now want me to write my functions using the first method but it just seems utterly fucking niggerlicious.

Edit: Is it so you can use a variable as a function, instead of creating a function and assigning the outcome to a variable?

Niggerlicious is a Lambda function assigned to a variable the way you have written it. If you have an understanding of how input should be structured, you can use interchangeable lambda functions to alter behavior. For example:

const niggerlicious = (arg) => {console.log(arg + "'s code is niggerlicious")}
const divineProvidence = (arg) => {console.log(arg + "'s code is divine")}
function qualityMessage(username){
    let qualityFunction = niggerlicious
    if(username === "tDavis") qualityFunction = divineProvidence
    qualityFunction(username)
}

Will decide which function is assigned to a variable. Then that variable is invoked as a function. If you are not Terry calling qualityMessage, niggerlicious is stored and will execute. If you are Terry, the variable will be overwritten with divineProvidence and it will execute.
Edit: a more practical example would be:

const makePizzaFunc = (quantity) => {console.log('Null just made ' + quantity + ' pizzas using an oven.')}
const dispenseGelatoFunc = (quantity) => {console.log('Yats just dispensed ' + quantity + ' large gelatos from the machine.')}
const shipCokeFunc = (quantity) => {
    console.log('Andy just snorted ' + quantity + ' lines of coke')
    if(quantity > 2) console.log('STAY BACK!')
}
const ops = {'makePizza':makePizzaFunc,'dispenseGelato':dispenseGelatoFunc,'shipCoke':shipCokeFunc}
function doSomething(action,quantity){
    ops[action](quantity)
}

doSomething executes a different function based on the argument action. The actions are keys in the object ops with a corresponding lamda function for each.

 

[${Sandy}]

Arrow functions are primarily used for anonymous functions and callbacks. They're just a compact way of writing out functions for things like EventListeners. Functions are treated like any other object in JS, so there's nothing stopping you from assigning them to a variable like you do with the const. This sort of behavior in JS makes it so that there are a thousand different ways, each of varyingly dubious quality, of writing the various parts of your program. It's what makes JS beautiful but often painful to read.

Here's a quick example from an old repo on my github:

socket.addEventListener("close", (event) => {
    console.log("[SNEED] Socket has closed. Attempting reconnect.", event.reason);
    setTimeout(() => { socket = new WebSocket(SOCKET_URI); }, SOCKET_TIMEOUT);
});

Nice and compact

So you can pretty much use either of them interchangeably?

const niggerlicious = (arg) => {console.log(arg + "'s code is niggerlicious")} const divineProvidence = (arg) => {console.log(arg + "'s code is divine")} function qualityMessage(username){ let qualityFunction = niggerlicious if(username === "tDavis") qualityFunction = divineProvidence qualityFunction(username) }

This is the best javascript function that has ever been written.

I'm gonna go back over this in the morning when my mind is fresh. Thank you guys.

 

[Creative Username]

So you can pretty much use either of them interchangeably?

Once I ran into a really weird problem with an arrow function where I had to use a regular function. I don't remember much specifics. Just be aware that there may be edge cases.

 

[macrodegenerate]

So you can pretty much use either of them interchangeably?

If you use var instead of let or const yes. You should be using let or const though along with exporting functions.

 

[sadrefrigerator]

So you can pretty much use either of them interchangeably?

No, there are a few difference that you have to deal with occasionally.

Arrow functions cannot be accessed before declaration.
Arrow functions do not create their own context for "this". This was a bigger issue back when classes were more popular, specifically react based class components. Nowadays classes aren't used as much so you'll run into this less. For example, if you pass in a function as a handler in a class, "this" will no longer point towards the instance of the class (I think it'll be the event object but I'm not sure). You can get around it by manually binding "this", wrapping in the handler function in an arrow function, or declaring the handler as an arrow function.

 

[Kosher Salt]

Can someone explain to me why in the mother fuck I would ever use

const niggerlicious = (arg) => {}

instead of

function divineProvidence(arg) = {}

There's a difference.

Note that, due to being wrapped in the function, test does not escape into the global scope even in the 2nd example, but it does escape the braces it's defined within, unlike const test.

 

[macrodegenerate]

There's a difference.

View attachment 6004518

Note that, due to being wrapped in the function, test does not escape into the global scope even in the 2nd example, but it does escape the braces it's defined within, unlike const test.

Could you check if that's a const local scope/var global scoping issue? I hear let is like that

 

[Kosher Salt]

Could you check if that's a const local scope/var global scoping issue? I hear let is like that

Yes, the difference is their scope. A variable defined with let or const has block scope - it will only be in scope inside of the braces where it's defined. A variable defined with var has function scope - once it's defined, it will be in scope anywhere within the function where it's defined. A function defined with function also has function scope, but JavaScript has something called "hoisting" which means that it is actually defined at the top of the block where the function definition is, so it can be used "before" it's defined.

I.e. the top example here tries to use test before it's defined, but the lower example does not, because the function definition is hoisted.

 

[Belisarius Cawl]

A function defined with function also has function scope, but JavaScript has something called "hoisting" which means that it is actually defined at the top of the block where the function definition is, so it can be used "before" it's defined.

Hoisting. What a strange design mistake. Just think: if not for a dumb marketing ploy, we could be natively coding Scheme in web pages now.

 

[Rusty Metal Skull Gun]

My favourite piece of trivia about Javascript is that it's so cobbled together, it was considered easier to accommodate its eccentricities at the assembly level than it was to fix the language (https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS).

 

[Kosher Salt]

My favourite piece of trivia about Javascript is that it's so cobbled together, it was considered easier to accommodate its eccentricities at the assembly level than it was to fix the language (https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS).

Of all the things you could pick on JavaScript for, "convert 64-bit float of the type used in Javascript to native 32-bit signed integer" wasn't something I'd have expected.

(Why the fuck does it say "fixed-point" when it actually means integer? And why the fuck does it say that the instruction can generate an exception, and then proceed to tell me absolutely nothing about what exact conditions will trigger the exception?!)

 

[y a t s]

Why the fuck does it say "fixed-point" when it actually means integer?

Well, fixed-point is essentially an integer multiplied by a scalar. The FCVTZS instruction this JS variant is based on can be used to convert to either a signed int or signed fixed-point. For conversion to fixed-point, you also have to specify #fbits to indicate that scalar. A simple conversion to a signed int will leave out that extra bit of info you need to work with the fractional values. With JS, this is a bit more predictable since it's all double-precision.

The JS variant has different handling for overflowing values, as outlined here.

Javascript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences.

Armv8.3-A adds instructions that convert a double-precision floating-point number to a signed 32-bit integer with round towards zero. Where the integer result is outside the range of a signed 32-bit integer (DP float supports integer precision up to 53 bits), the value stored as the result is the integer conversion modulo 232, taking the same sign as the input float.

The Z-flag is used to determine if the original number was an integer; the other flags (N, C, and V) are always cleared. The Z-flag is set to one to indicate an integer within range, meaning it is cleared when the input number is:

• An infinity
• A NaN
• Too large for a 32-bit signed integer
• -0
• not an integer value, and rounded accordingly

This approach allows a B.NE conditional branch to be used immediately after this instruction to test if the input double-precision number is a true representation of a 32-bit signed integer.

And why the fuck does it say that the instruction can generate an exception, and then proceed to tell me absolutely nothing about what exact conditions will trigger the exception?!

That info is on a separate page in the manual that specifies the various floating-point exceptions.

 

[Kosher Salt]

For conversion to fixed-point, you also have to specify #fbits to indicate that scalar.

Well yeah, I was looking for something that would allow a scalar factor to be specified, but I didn't see any mention of it in the manual. Seems like a rather important thing that they left out.

That info is on a separate page in the manual that specifies the various floating-point exceptions.

Obviously I wouldn't expect them to re-hash the information on every manual page for instructions related to floating-point numbers, but they could've at least linked to it...

 

[Belisarius Cawl]

JavaScript only natively supporting floating point numbers isn't too bad, really. All that means is that you run into trouble when representing decimal currency, which a webshit would never have to do.

 

[${Sandy}]

Yeah, the more I work on javascript the more niggerlicious it seems.

Is it bad practice to use an anchor element to change inner.html

for example

let niggerlicious = document.getElementById("about-us-anchor");
niggerlicious.onClick = myFunction
let divineProvidence = document.getElementById("container-div");

function myFunction(){
    divineProvidence.innerHTML = "html here"
}

I'm just making a basic website template for my portfolio. I was thinking a basic landing page for a business can be really simplified by just using javascript to change the html of the page instead of redirecting you to another webpage that looks practically fucking identical.

 

[macrodegenerate]

Yeah, the more I work on javascript the more niggerlicious it seems.

Is it bad practice to use an anchor element to change inner.html

for example

let niggerlicious = document.getElementById("about-us-anchor");
niggerlicious.onClick = myFunction
let divineProvidence = document.getElementById("container-div");

function myFunction(){
    divineProvidence.innerHTML = "html here"
}

I'm just making a basic website template for my portfolio. I was thinking a basic landing page for a business can be really simplified by just using javascript to change the html of the page instead of redirecting you to another webpage that looks practically fucking identical.

You would be better served using a templating framework/engine. Look into mustache.

 

[Agent Sandoval]

Yeah, the more I work on javascript the more niggerlicious it seems.

Is it bad practice to use an anchor element to change inner.html

for example

let niggerlicious = document.getElementById("about-us-anchor");
niggerlicious.onClick = myFunction
let divineProvidence = document.getElementById("container-div");

function myFunction(){
    divineProvidence.innerHTML = "html here"
}

I'm just making a basic website template for my portfolio. I was thinking a basic landing page for a business can be really simplified by just using javascript to change the html of the page instead of redirecting you to another webpage that looks practically fucking identical.

What you want to do is pretty common. Most frameworks provide some way of leaving headers/footers/navigation as-is and dynamically loading the page content. 2 things to consider if you want to know if the magic crosses the niggerlicious line. Are you going to break the back button? Niggers break the back button. The second thing is considering if your site is still going to be manageable. If you're loading pages from a templating engine then there's a good chance it will be, if you're hard coding your pages into your JavaScript file it won't.
I think your word of the day should be AJAX.