/dpt/ - Daily Programming Thread

Old thread: What are you working on, Sup Forums?

Other urls found in this thread:

gist.github.com/anonymous/5d69c61bf663dfa97ae895a0b661a9ff
en.wikipedia.org/wiki/Dorodango.
en.cppreference.com/w/cpp/thread/thread/thread
twitter.com/NSFWRedditVideo

>circuit analysis
I just wanted to program...

Daily reminder that there's no distinction between web programming and desktop programming anymore, and that it therefore doesn't make any sense to keep both /wdg/ and /dpt/. They should both be merged.

It's completely relevant to a computer science cursus. If you'd rather be a code monkey just drop out.

t. freshman

dumb frogposter

But user, DPT stands for daily programming thread, not desktop programming thread.

Oh shit I just got called for a second interview guys, this is it, my chance to escape the freelancing hellhole.

Wish me luck.

>What are you working on, Sup Forums?

Learning Solidity so I can make my own ICO.

Let's make /dpt/ discuss relevant tech only

So, what about Javascript?

...

How come frogposters always fit the stereotype?

>cryptopyramid shit
Not programming.

>web shit
Not programming.

...

>What are you working on, Sup Forums?
Imageboard web client in C++. Trying to find an infinite loop for the past while.

Dumb frogposter.

1) Let the universal set S = {x, ...} for infinitely many unique x.
2) Let the set successor operator Suc(A) = A U {x} for any subset A of S and any element x of S not in A.
3) Observe that A U (B U C) = (A U B) U C for any sets A, B, and C.
4) Observe that for disjoint sets A and B, |A U B| = |A| + |B|.
5) Observe that for n in R, n = |Suc^n({})|, where ^ is the self-composition operator, not the exponentiation operator.
6) Observe that 10 = |Suc^10({})| [by premise 5] = |{a} U {b} U {c} U {d} U {e} U {f} U {g} U {h} U {i} U {j}| [by definition 2] = |({a} U {b} U {c} U {d} U {e}) U ({f} U {g} U {h} U {i} U {j})| [by premise 3] = |{a} U {b} U {c} U {d} U {e}| + |{f} U {g} U {h} U {i} U {j}| [by premise 4] = 5 + 5 [by premise 5] [QED].

what the fug
it doesn't work for the input "ABCBE"
use std::env;

fn main() {
let in_chars: Vec = env::args().skip(1).collect();
let mut tmp_chars = Vec::new();

for in_char in in_chars {
if tmp_chars.contains(&in_char) {
println!("{}", in_char);
return;
}
tmp_chars.push(in_char);
}
println!("nothing...");
}

Just fuck off to reddit. Your kind isn't welcome here.

...

Alright, I'm leaving now

(You)

What are you even trying to do?

You never split "ABCBE" into chars.

>return;
You probably meant break; ?

so many books to read
epubs and pdfs
at least 4000 pages
curse you ADHD
can't stop refreshing threads to actually get anything done
ruby pickaxe or the art of exploitation?
decisions decisions
fuck, end my misery

Mistakes I just caught:
5) n should have been in N, not in R
6) Just before reaching "= 5 + 5" I forgot to show that the two terms were both equal to the |Suc^5({})| by definition 2

Is it worth applying higher derivatives of motion like jerk, snap, crackle, and pop in games? Or should I just stick to velocity and acceleration.

I bet you also posed that image unironically

This one seems to work better:
gist.github.com/anonymous/5d69c61bf663dfa97ae895a0b661a9ff

You probably also have this issue of splitting "abcde" into character. I ditched that and fixed just .

I'm retarded, my bad. I was iterating over an array of strings instead of the string itself.
This seems to work:
use std::env;

fn main() {
let input = env::args().skip(1).next().unwrap();
let mut chars = Vec::new();

for chr in input.chars() {
if chars.contains(&chr) {
println!("{}", chr);
return;
}
chars.push(chr);
}
println!("nothing...");
}

How do I make this Rust code prettier? (Note: I specifically do not want to have a separate manager for every resource type, or to limit it to a predefined set of types).

struct ResourceManager {
loaders: HashMap>,
map: HashMap
}

impl ResourceManager {
fn new() -> ResourceManager {
ResourceManager {
loaders: HashMap::new(),
map: HashMap::new()
}
}

fn register_loader(&mut self, ext: &str, loader: F)
where F: Fn(&Path) -> Option + 'static {
let ext = OsString::from(ext);
assert!(self.loaders.insert(ext, Box::new(loader)).is_none());
}

fn load(&mut self, path: &Path) -> &Any {
let key = path.as_os_str();

if self.map.contains_key(key) {
self.map.get(key).unwrap().as_ref()
}else {
let ext = path.extension().unwrap();
let loader = self.loaders.get(ext).unwrap();
let res = loader(&path).unwrap();
self.map.insert(OsString::from(key), res);
self.map.get(key).unwrap().as_ref()
}
}

fn get(&self, path: &Path) -> Option {
self.map.get(path.as_os_str()).map(|x| x.downcast_ref::().unwrap())
}
}

Unless you have a situation that's best modeled with such higher derivatives of motion, I'd say don't bother. And that's rare. What situation do you have that you would even need these for? Do you have a force that increases or decreases in magnitude as some other quantity varies, such as distance or time? I guess I could understand force varying with distance if you're modeling gravity, but even then, unless your game features multiple planets, I'd just use a constant downward acceleration.

>Rust code
>prettier
You can't polish a piece of shit, user

dumb frogposter

#dlink
struct list {
T first;
list ^rest;
};
list *cons(T first, list *rest) {
return mdup(struct {first, rest});
}

>self.map.get(path.as_os_str()).map(|x| x.downcast_ref::().unwrap())
This will potentially panic even if it doesn't have to. Better to use .and_then():
self.map.get(path.as_os_str()).and_then(|x| x.downcast_ref::())
This will return None on failure

Why not make ResourceManager generic and have the user supply, what he actually wants, instead of Box?

No specific situation, I just thought maybe it would make motion feel smoother.

Actually... en.wikipedia.org/wiki/Dorodango. Weird that you wouldn't know that Akari-chan, considering your dumpling-hair!

I think sticking with acceleration in most cases would actually make motion feel smoother than incorporating jerk or higher derivatives. There's actually a mathematical reason for this. Consider a circle. That's a quadratic equation -- x^2 + y^2 = r^2 -- and it's perfectly round. If you had a similar equation of any other order, it would be less round; for example, x + y = r is straight up just a line, x^3 + y^3 = r^3 is a weird bump, and x^4 + y^4 = r^4 looks like a rounded square. Beats me what's so magical about the number 2, but there you go.

>This will potentially panic even if it doesn't have to.
Why? Wouldn't `.map` simply return None if you try to pass it one? As for the inner unwrap, I want it to panic if the resource is of the wrong type, since that is always a programmer error.

>old shit
C then?

Help me /dpt/
So this is the MCVE part of my code:
class calculate
{
private:
std::thread * trd;
void start();
void join();
void measure(int inp); //some blackbox function
public :
calculate();
~calculate();
void run();
}
calculate::calculate() : trd(new std::thread[3]) {}

calculate::~calculate()
{
delete[] trd;
}

void calculate::start()
{
for(int i =0; i < 3; i++)
{
trd[i] = std::thread(measure, i);
}
}
void calculate::join()
{
for(int i =0; i < 3; i++)
{
trd[i].join();
}
}
void calculate::run()
{
start();
join();
}


Why that code can't be compiled?
GCC reporting "invalid use of non-static member function" in the trd[i] = std::thread(measure, i);
I don't understand why the function need to be static.
What is the best way to fix it. SO, and other answer online didn't give clear explanation
Please help me /dpt/

>As for the inner unwrap, I want it to panic if the resource is of the wrong type, since that is always a programmer error.
I didn't know that, so i just delegated the error handling to the caller

>Beats me what's so magical about the number 2, but there you go.
It's because 2 is the exponent n such that (sin(a))^n + (cos(a))^n is constant.

>Why not make ResourceManager generic and have the user supply, what he actually wants, instead of Box?
Because I specifically want it to support all kinds of assets, so `get` has to be tailored for it.

did you try std::thread(&calculate::measure,this,i) ?

C++ was a fucking mistake.

Also it's kind of cool that a square can be defined as the limit as n->infinity of |x|^n + |y|^n = r^n

measure is a member function, it implicitely takes a this argument. Also just measure as an expression isn't a callable value. You either need some weird shit like std::bind or idk what, or a lambda:
trd[i] = std::thread([this, i](){measure(i);});

Rewrote load a little bit to use less .unwrap()
fn load(&mut self, path: &Path) -> &Any {
let key = path.as_os_str();

if self.map.contains_key(key) {
self.map.get(key)
} else {
let res = path.extension()
.and_then(|ext| self.loaders.get(ext))
.and_then(|loader| loader(&path))
.unwrap();

self.map.insert(OsString::from(key), res);
self.map.get(key)
}.unwrap().as_ref()
}

pretty sure a function pointer is a callable value.

a member function pointer needs an object to call it on. It's not the same as a regular function pointer.

so I have two separate haskell "packages" I'm trying to integrate, but if I init the cabal sandbox in one, how can I pull in the other? Do I need to install one of the two globally?

Oh wow, this works.
can you explain why this works, but not in the original code?

The example where I learn thread, always use the function name directly.
It also listed as example in
en.cppreference.com/w/cpp/thread/thread/thread

not him but member functions as necessarily a separate concept from free functions were a mistake, shit like this is why member functions should be implemented as free functions with runtime type overloading and ufcs

He wants dynamic types because he writes horribly coupled code and wants to be able to manage resources of any type anywhere without passing around a bunch of generic managers.

yeah but f1 and f2 are standalone functions ;^)

>Sepples was a mistake
don't need to tell me, friend

>Rewrote load a little bit to use less .unwrap()
That definitely looks nicer, but then you don't know what exactly failed. By the way, why can't I do this?
fn load(&mut self, path: &Path) -> &T {
let key = path.as_os_str();

if self.map.contains_key(key) {
self.map.get(key).unwrap().as_ref()
}else {
let ext = path.extension().unwrap();
let loader = self.loaders.get(ext).unwrap();
let res = loader(&path).unwrap();
self.map.insert(OsString::from(key), res);
self.get::::(path).unwrap()
}
}

It complains that "field expressions may not have generic arguments". Why does this happen, and is there any alternative?

if a is an object of class A, a.f(2,1) is basically shorthand for A::f(a,2,1) (I think, I'm no C++ expert)

Use PathBuf instead of OsString, then you don't need any to_os_str anywhere. You can also use and_then in get.
self.map.get(path).and_then(|x| x.downcast_ref())

I'd love it if that were the case.

Oh god.
I wanted generics in C but not like this.
>#dlink
>mdup
>^
get this garbage out of my sight
scrap your toy compiler m8 this is utter trash

>being able to manage resources of any type anywhere without passing around a bunch of generic managers
>horribly coupled code
How exactly are the two related? What's wrong with trading off some compile-time checking for convenience simplicity in usage?

url = document.getElementsByClassName("commentmetadata")[0].getElementsByTagName("a")[0].href;

if (url) {
window.location.href = url;
}

This is my greasemonkey script for redirecting link from comment page (lhtranslations). Werks fine as a hack.

Question is, what's the "enterprise" or "professional" tier write up of this hack?
I want to see what the difference is, if anyone can write up a mockup psudo code

ResourceManager::get::(self, path).unwrap()

Break a leg, user.

The bad part is being able to manage resources of any type anywhere. Not wanting a more convenient way of doing it, but wanting to do it at all. Code decoupled properly has no shared mutable state. If different modules have to communicate, they communicate through ONE shared mutable object, outside any of them, that functions like a query stream.

>all kinds of assets
Stop this nonsense. Your program should not work on anything that walks in the door. Your door should have a bouncer that tells the ugly and the poor to fuck right off. Metaphorically speaking.

map.get(key) returns a &Box, you need to downcast it to &T. This compiles:
fn load(&mut self, path: &Path) -> &T {
let key = path.as_os_str();

if self.map.contains_key(key) {
self.map.get(key)
} else {
let ext = path.extension().unwrap();
let loader = self.loaders.get(ext).unwrap();
let res = loader(&path).unwrap();
self.map.insert(OsString::from(key), res);
self.map.get(key)
}.and_then(|v| v.downcast_ref::()).unwrap()
}

>Use PathBuf instead of OsString
Thanks. I will look it up.

>you can also use and_then
I could, but I want it to panic if downcast_ref fails, because that's always a result of a programmer error.

it's kinda fun doing all the truth table stuff

Good catch, but now it complains about something else.

Have you read your SICP today?

Don't get fizzbuzzed

>query stream
By which I mean a message queue.
I forgot the name of it.

about what? My Rust Playground doesn't have the imports so I can't see the error. Show pls?

The fact that you can do much better. Most parts of the code don't need to know anything about asset paths and loading, they just want references to assets of specific types. Loading assets is always a result of switching scenes or streaming new parts of the scene. For instance, you load level 10, which requires the entities/Goblin.lua script, which requires the models/Goblin.fbx model asset. The rest of the code just sees an entity with a reference to a model. These references aren't actual Rust references with lifetimes, they're something like the hash of the asset's path with the ability to use a placeholder or skip whatever needs the asset if it's not loaded (this can be used for asynchronous asset loading, for example). The engine will have a generic asset manager type and an internal instance for each engine-defined asset type, as well as exposing it and allowing the user to plug their own logic into the loader subsystem with references to user-owned asset managers.

Did you try ?

>map.get(key) returns a &Box, you need to downcast it to &T.
Well, shit... I forgot the other branch of the match. The entire thing should just be this, now that I think of it:
fn load(&mut self, path: &Path) -> &T {
let key = path.as_os_str();

if !self.map.contains_key(key) {
let ext = path.extension().unwrap();
let loader = self.loaders.get(ext).unwrap();
let res = loader(&path).unwrap();
self.map.insert(OsString::from(key), res);
}

self.get::(path).unwrap()
}

Thanks, user.

Alright, let's troll.
I program professionnaly in Java. Guess what industry I work in.

hm yeah doesn't seem to work, do you happen to know why you can pass it like that to the std::thread constructor?

So what is a sane bit array size, and what is a sane minimum allocation size? You can make it much smaller if you know the distribution of memory allocation requests too, but I don't have that data.

The search would work like such: you have one bit array for each allocation size. So if you can allocate between 1gb and 64b, that gives 30-6+1 = 25 bit arrays, where each bit array is 2x larger than the previous. The largest bit array has the smallest units of memory, and its storage is 50% of the total bit array storage. So for 8gb of ram, the largest bitarray is (8G/64)/8 bytes. Total 32mb, I apparently divided by 8 twice in the example.

It would be very fast however. Checking if a dword is all zero is done in one cycle (possibly less with vector instructions). If you set 0 - full 1 - free, then search in the appropriate bit array, then you can search 64 blocks per cycle. So if it's 99% full, you need to do (log(0.5)/log(0.99))/64 cycles. There's your coefficients.

As said, it could be optimized further, but I don't see how it's a fundamentally hard problem.

The Java industry?

>The bad part is being able to manage resources of any type anywhere
Still waiting for you to explain why it's bad.

>Code decoupled properly has no shared mutable state
How does having many mutable shared resource managers instead of one reduce the amount of mutable state?

Starbucks

You can, I think, (based on ) you just need a couple ampersands because this is C++: &A::f(&a,2,1)

You still need OsStr(ing) for the extension for the loader part, but I cleaned the rest up a bit.
struct ResourceManager {
loaders: HashMap>,
map: HashMap
}

impl ResourceManager {
fn new() -> ResourceManager {
ResourceManager {
loaders: HashMap::new(),
map: HashMap::new()
}
}

fn register_loader(&mut self, ext: &str, loader: F)
where F: Fn(&Path) -> Option + 'static {
assert!(self.loaders.insert(OsString::from(ext), Box::new(loader)).is_none());
}

fn load(&mut self, path: &Path) -> &Any {
if !self.map.contains_key(path) {
let loader = self.loaders.get(path.extension().unwrap()).unwrap();
self.map.insert(path.to_owned(), loader(path).unwrap());
}
self.map.get(path).unwrap().as_ref()
}

fn get(&self, path: &Path) -> Option {
self.map.get(path).map(|x| x.downcast_ref::().unwrap())
}
}

>Most parts of the code don't need to know anything about asset paths and loading, they just want references to assets of specific type
Having one resource manager vs many has no impact on this.

>These references aren't actual Rust references with lifetimes, they're something like the hash of the asset's path
What's the big advantage of looking up the asset repeatedly using an improvised reference?

>Still waiting for you to explain why it's bad.
It's bad because it forces you to do stupid stuff like this or pass parameters everywhere.

>How does having many mutable shared resource managers instead of one reduce the amount of mutable state?
Because different subsystems can have access to only a subset of the resource managers.

>How does having many mutable shared resource managers instead of one reduce the amount of mutable state?
By not having mutable shared resources.
All the mutable resources in each manager are restricted to it, and communication about those resources is carried out through the message queue.
This communication may influence the way any number of those managers mutate their resources, but does not directly involve mutation of any resources in and of itself, except the message queue.

>akari poster becomes a mentally ill rust shill

who did this to you??

>Only one person can like akari

>It's bad because it forces you to do stupid stuff like this
So it's bad because it's stupid? Nice argument.

>or pass parameters everywhere.
How does having one resource manager instead of many force you to pass parameters everywhere?

>Because different subsystems can have access to only a subset of the resource managers.
That doesn't change the amount of shared mutable state in any meaningful sense.

>>Only one person can like ______
>implying this is not the case
>rejecting the concept of waifus
>on Sup Forums
literally leave

please don't insult akari poster

Embedded software.

>Sup Forums tries to write a type-agnostic resource manager in Rust. You won't believe what happens next!

Make me