/dpt/ - Daily Programming Thread

if you want efficient code use a proper language

You shouldn't care about efficiency (at least not from base language constructs) in Python.

Alternatively you could do this:
for (index, value, ) in enumerate(values):
pair = (value, values[index + 1])

But you have to also account for the case where you're at the end of the loop so that it doesn't try to access past-the-end element which will throw IndexError exception.

>JavaScript/React/React-Native
Leave.

I've had to spend a fair amount of time spelunking around that literal hellhole, wasyerkweshun

There's two stages I'm alternating between
>Man, fuck Python.
>Why do I have to put up with this shit?

>Man, Python surely has everything
>Boy, did that code almost write itself

God damn it, Python, be consistent, why the tough love.

Learn Perl or Ruby and be blessed by scripting languages that are just as fluid to use as Python without the retarded limitations of "everythings a tuple!"

You'll never get great performance out of a scripting language though, unless you use something like jruby or cython, which is basically cheating as you've left the confines of the language.

Too late, already took 3 projects in python this semester in uni.
However I need to ask you, how difficult is Perl to learn, coming from C/C++ (and soon I might even say Python)?

for (int i = 0; i < 100; i++)
{
bool rFizz = i % 3 == 0;
bool rBuzz = i % 5 == 0;
bool rFizzBuzz = rFizz && rBuzz;

string sFizz = "Fizz";
string sBuzz = "Buzz";
string sFizzBuzz = sFizz + sBuzz;

if (rFizzBuzz) { Console.WriteLine(sFizzBuzz); }
else
{
switch (rFizz)
{
case true: Console.WriteLine(sFizz);
break;
default: Console.WriteLine(i);
break;
}
switch (rBuzz)
{
case true: Console.WriteLine(sBuzz);
break;
default: Console.WriteLine(i);
break;
}
}

Attached: 1523336869515.jpg (411x411, 49K)

Can someone point me out which one of theses are "babys first ride without heels"?
I already somewhat made these one marked. I'm learning C.

Attached: any progress is better than none.jpg (1920x1080, 582K)

why?

Attached: 512IjuTNc-L._SX402_BO1,204,203,200_.jpg (404x500, 46K)

chip-8 is popular

It might be better to ask this one-on-one but I might as well say it here
I've literally asked this question probably 3 or 4 times in the last 3 or 4 months here so might be familiar...
I've gotten good and maybe even great answers regarding it but none that either:
>solved it fully
>or if it did solve it fully it didn't make sense to me and I didn't realize it solved it fully

All I want is to make an application that you can resize while rendering
>IE resize while never once seeing the buffer out the edge of the screen
Most commercial,, professional, and major open source programs seem to be capable of this,
Most all personal or hobbyist programs never seem to be capable of this (I have no idea why).
I want to make a professional looking program like that.

Two examples of what I'm talking about:
>gamedev.stackexchange.com/questions/127691/how-to-stop-sdl-from-freezing-the-rendering-while-resizing-the-window
SDL Complaint
>gamedev.net/forums/topic/488074-win32-message-pump-and-opengl---rendering-pauses-while-draggingresizing/
OpenGL Complaint

I want to know the following:
>1)If this is a problem that is solvable, please tell me why or why not
>I've never once looked that low-level (OS nor Graphics backends) so I just want to know why.

>2) What's the way to solve this? Is it within my means?

>3) Is the solution -really- a perfect solution? I've seen many people suggest solutions that have various problems
>(IE minimizing the buffer but not getting rid of it entirely OR you got rid of it but there's a ton of flickering (I forgot why but it doesn't matter))

If (you) or anybody else knows without a shadow how to answer these questions,
I beg you to have a one-on-one conversation with me or at least give me good resources.
I feel like this is something that could take a solid month of understanding and work to solve without proper guidance.

Perl will take all of an afternoon to learn, you just have to leave the Type mindset.

Scalars ($), Arrays (@), Hashes (%). Number, not a number.
There you go, you've learned the entire type system.
my $thing1 = "4H";
my $thing2 = "8A";
say $thing1 + $thing2; #Prints 12 with warnings
say $thing1 . $thing2; #Prints 4H8A with warnings
my @arr = (1, 2, 3, 4);
say $arr; #prints "4", the number of elements in the array
say $arr[0]; #prints 1
say \$arr; #prints the memory address of the array (reference)
etc.
It looks goofy because you end up with all these sigils everywhere (such as derefencing an array my @arr = @{ $_[0] };) but it follows its own rules, and once you stop thinking in terms of types and instead thinking in operators and scalars it's quite natural.

if you are making a video game the short answer is don't bother trying. Graphics buffers are allocated at a certain size, so you can either allocate a bigger buffer than you need which wastes space or you can reallocate buffers as you resize which is choppy and slow. So you'd be wasting alot of resources on a very non-essential feature

Link?

Is this with OpenGL, or just some regular WPF/WinForms/UWP thing? 3D or?
If it's with OpenGL, what library are you using for interaction?
Are you double buffering and calling swapbuffer?
Have you tried using postredisplay?
What's your resize function look like?
I've been writing a lot of OpenGL lately and not really experienced that issue.

Also you're using shaders and not fixed pipeline right?

You guys have any fild dumps for noobs? I just started with python

Nice, now I have to learn bitwise operation too.

Trying to make heads-from-tails in a code base older than me.

Viewports have nothing to do with framebuffer allocation

if you want to resize a 100x100 window to 1000x1000 smoothy you need to have a 1000x1000 framebuffer allocated, which means you'd be wasting alot of memory if you used it at 100x100 most of the time

I plan on making both tools and videogames in the future

>non-essential feature
It seems relatively essential if you're making a working man's application that needs to be resized regularly
It would become very annoying very fast if you couldn't see what you were doing while moving or resizing

It just bothers me immeansely

>Is this with OpenGL, or just some regular WPF/WinForms/UWP thing? 3D or?
I don't think I've ever used WPF/WinForms/UWP

What I have used are:
>SDL (Currently)
>SFML
>GLFW + OpenGL
And this problem applies to all 3 from what I can recall.

>postredisplay
Don't know what that is, but I'm willing to try anything and/or abandon all my currently used dependencies
if I can guarantee the problem solved while maintaining the ability to draw to the screen whatever I want (In a 2D space anyways)

>What's your resize function look like?
I don't feel like pulling up all my old projects and stuff
I'm fairly certain all the information you need is within those 2 links
I don't think it has anything to do with my personally defined resize function if that's what you're asking

It's a windowing issue, most likely regarding win32/windows api from what I've heard

well you linked gamedev forums so I assumed you were making a video game. You'll notice video games operate at a fixed resolution. If you are making tools or applications the rendering process is done by the operating system, not you

>React
bump

Get started with project euler. You should be able to solve some of the early problems, though it ramps up quick. It's a good website to visit every now and then.

I just linked to 2 relevant threads out of the dozens hot off of Google (2nd one has a nice discussion)

>If you are making tools or applications the rendering process is done by the operating system, not you
What do you mean by this exactly?

Are you talking about using a pre-made tool like Qt, are you referring to:
>making your own window following the windows api
>using something like the .NETframework
>or something else entirely?

I'm not afraid of using something different, though I'd greatly prefer if it's not a radical departure of what I want to do (have my own graphics, design the abstractions myself).

onthedl.ddns.net/PROGRAMMINGROULETTE/index.html

>What do you mean by this exactly?
when you make a application usually you use the GUI features provided by the operating system, which have no problems resizing themselves in any way you want. When you make a video game you allocate an OpenGL context or whatever, and you allocate that at a fixed resolution. You can use certain techniques to program your game in a way that let you resize it smoothly on the fly, they just take resources and effort so it's not really worth bothering for a feature that isn't important to video games

It's not 1983 anymore, framebuffers are very cheap. Switching viewport sizes between 5k and 1280x800 is nearly instant on the project I've been working on, and the only delay comes from the OpenGL context releasing control on being fullscreen.

>I'm fairly certain all the information you need is within those 2 links
Well one of them is using fixed functions, which is never a good sign, and the second one from the way its described and the fact they immediately mention trying to thread off the OpenGL context means they're *probably* using a fixed pipeline too.

Are you using a fixed pipeline, or shaders?
Fixed pipelines mean that every time you resize the window, the viewport doesn't have time to be updated in the draw call until after the CPU recalculates everything and pushes it over to the GPU again (sloooooow). It also means this occurs synchronously, so you get that stuttery effect (if not just the viewport staying at one size until you release the mouse)
If you're taking proper advantage of asynchronous opengl calls then depending on the amount of logic between draw calls and how you've written your resize function, there should be little to no noticeable shift.

Games like to operate at fixed resolutions because then you can do all kinds of lovely mipmap generation and silly clipping manipulations to squeeze out performance. Your FOV doesn't need to have its clipping distance at 10000.0f at 800x600 since anything that far out wouldn't be big enough to take a pixel anyways. You can just as easily write a runs-like-shit game that prioritizes resizing viewports instead.

>coworkers talks to me before I've had my coffee

Attached: 1526754443971.png (250x246, 68K)

>It's not 1983 anymore, framebuffers are very cheap
most games have many more buffers than the frame buffer allocated and optionally pre-computed graphics data as you pointed out
Not saying it's impossible, just impractical seeing it's not a useful feature in a video game

>Well one of them is using fixed functions... the second one... they're *probably* using a fixed pipeline too.
>Are you using a fixed pipeline, or shaders?

>Fixed pipelines mean... (sloooooow)
>the amount of logic between draw calls and how you've written your resize function, there should be little to no noticeable shift.

Interesting observation

Are you referring to using OpenGL 2 and stuff? I'm not using it in any of my programs no.
In my OpenGL program I'm using as modern OpenGL as I can get.

But at the moment I'm not using OpenGL at all, just SDL (I'm sure SDL calls OpenGL indirectly)
I literally have a helloworld-tier program in SDL

How do we stop them?

youtube.com/watch?v=Eps-4alpQaw

Attached: kwgydsa4ejy01.jpg (1024x768, 223K)

Actually scratch that last part:
>I literally have a helloworld-tier program in SDL
I'm using someone else's example code for now...

This is "my" program:
ghostbin.com/paste/htm63

Sorry I'm getting confused by all this talking

How the Corp-Brewed Java taste?

Well sure, but viewport size and framebuffers aren't inherently linked anymore. I suppose OpenGL will probably default to using the window size if you're not using FBOs,
It's a moot point, either way.

Do you have lots of things like DrawRectangle or FillPolygon or whatever?
Or anything that says "begin" and "end" like glBegin or glEnd?
Most (if not all) openGL tutorials out there love to use ancient, ancient, deprecated GL calls as openers because wrapping your head around all the 3D camera matrix rotation perspective change bullshit is a lot to take in, let alone doing that on top of a shader and having to also understand how a GPU renders everything in parallel, and with a cherry of now having to understand how the CPU actually talks to the GPU.
If you don't know the answer to "are you using shaders" then it's probably "no", which means CPU-side fixed functions, which would verymuchso make smooth resizing impossible.

You're redrawing the entire framebuffer CPU-side every single draw call, then having to pass that off to the GPU. Yeah, interrupting that with the window resize is gunna lock your viewport up cause you're not able to make drawcalls or update the framebuffer
CPU side, fixed pipeline calls -> CPU has to calculate everything, in sequence, line up all the OpenGL calls for the GPU, send all the data to the GPU, then flush all the OpenGL commands for the GPU to actually do things
GPU side, programmable shader calls -> CPU sets things up once, gives them to the GPU, and doesn't have to recalculate anything it doesn't need to every draw call, which means you have a whole 16.67ms for the CPU to do things like update vertex info, mess with textures, deal with window resizing, whatever.

Also save yourself the hassle and just use GLFW or Freeglut so you don't have to deal with the insanity or using WIN32 APIs, if the tutorial you're using insists that you have to deal with windows handles directly then it's very, horrifyingly old

>Well sure, but viewport size and framebuffers aren't inherently linked anymore
not hard linked by requirement no, you just generally want your framebuffers to be the size of the window for efficiencies sake, that was my point
and using fixed function calls has no impact on resizing the window or not, all you need to do is keep rendering when you get the resize frame message from the OS

Fixed function will have an impact on trying to smoothly resize with the window because now your context thread is competing with itself over trying to draw and update things against trying to handle with OS messages and resize the window it has a handle to
I mean I'm sure it's perfectly possible, it's just super unnecessary to try and do.

You could probably jam a display() call at the end of the resize function so you always redraw but I imagine that would make resizing really stuttery

I am setting up a security camera system on the cheap using some old webcams from my camwhore days. I am writing it in python and I wanted to try out some OOP techniques for mulitple cameras.

However, I don't understand this shit at all.

I also don't understand multi-threading, and I am becoming concerned with how retarded my house is going to look with usb cords taped on the walls.

Anons, please.
Name something cool I could do with all these cameras so I have the will to fight through these bumps

Attached: 1468348033936.jpg (750x653, 106K)

>camwhore days
post bussy

well the whole thing is super unecessary to do so it's a moot point anyway, fixed function or modern doesnt make a difference though, you're still queueing up things to draw, fixed is just less efficient (but if you're at the point where you're using fixed what you're doing is probably so simple it doesnt even make a difference)

past tense baka.

why do you need multithreading for that

>You're redrawing the entire framebuffer CPU-side every single draw call, then having to pass that off to the GPU.
>your context thread is competing with itself over trying to draw and update things against trying to handle with OS messages and resize

Is it possible that:
>you can edit the program yourself so I can see tangible results
or:
>I can either keep in contact with you IE in case you're right I can get instructions more clearly

>int*
why do brainlets do this

so a function can change it?

why do bigbrains do this
>int&&

I don't know if I do, but my current set up with 3 cameras has a loop for each camera. I guess I could run a different instance of the program for each camera, but it would be hard to control them all at once like that.

he means mentally visualizing the pointer as a seperate type "int*" , rather than being a single-indirected pointer to that type "int *"

just do async io

Well, Perl is dynamically typed, so yeah.

A lot of the syntax also reminds me of PHP, which I didn't know can also be used as a scripted language in its own right.

I mean, "fixed is just less efficient" is putting it very lightly. It's the difference between spending 30ms on draw calculations and calls and 0.1ms on rebinding a uniform on the GPU and saying "OKAY GO"

You tease

It would take me a bit to get you something that would actually compile or make sense compared to what you have.
Look up using Vertex Buffer Objects, Vertex Attribute Objects, and shaders.
The less time your CPU spends calculating draw calls the more time it has to try and resize viewports and mess with window sizes. Making direct GL calls even through a framework is very very sensitive to logic flow, so just play with it. You should be able to resize a window with a spinnan cube without serious issue regardless.

im reading through the docs.

Seems confusing but less confusing then multi-threading.

>It's the difference between spending 30ms on draw calculations and calls and 0.1ms on rebinding a uniform on the GPU and saying "OKAY GO"
You still need to send all your drawing commands to the GPU every time you draw a frame you know

yeah, this. if you end up having to declare multiple pointers on one line it looks retarded.

This is just example code stolen from someone else

I don't want to deal with the insanity of using WIN API

I feel like that's what I may have to physically do in the future if I can't get a tangible proven answer though

Are there languages that do:
*int

instead?
This seems like something Jonathan Blow would obsess over

If you're using SDL maybe you should look at the SDL documentation for resizing windows?

Currently building my own programming Distro based off debian. What should i name it?

Its gonna run neovim by default, everything is vim keybindings. Minimal. i3wm and ranger OFE, URxvt terminal and bash shell. Reccomend any additions, changes, but more importantly a name for this OS.

Names i figured out so far (These are also logos atm):
- 智
- 安

Which with a programmable pipeline means glBindBuffer, glDraw[typeofthingthegpushoulddraw], glFlush
Which takes all of 100ns
Because now the GPU is doing all the draw calculations instead of the CPU, so the only thing you have to do CPU side is make any relevant updates to VBOs or uniforms (which can be done and updated entirely between draw calls) and then rebind+call draw

WIN32 API calls means you're either doing something insane or are reading ancient documentation
SDL, GLFW, and Freeglut all offer convenient bindings to WIN32 API calls for window handling that you never have to worry about, you just hand them a callback function for when it happens.

Golang has postfix type notation, so you can have things like var x *int

>This seems like something Jonathan Blow would obsess over
for as much as he proclaims to hate C++ his language retains alot of retarded shit from it

Pascal
type
PInteger = ^Integer;

Explain what aspects

It's changing a lot fast so I'll forgive you if something you're complaining about isn't accurate

Attached: thinking-face_1f914.png (120x120, 17K)

>You tease
I am reformed.

Hoe into housewife transformation complete.

I think you have a fairly distorted view of the costs here, iterating through all your drawable objects, binding their state and drawing them still has significant overhead

semicolons
punctuation soup of operators and qualifiers everywhere

It really doesn't, the biggest overhead in GL 3.3+ is texture mapping and large VBO updates, both of which can be significantly mitigated with asynchronous glMapBufferRange and PBO calls

Bind+draw is practically free, especially when you start leveraging instancing and program switching

Gitlab never supported Mercurial tho.

Attached: bdd6e373ca6ac56a836653f14566e743.jpg (3600x3096, 2.35M)

Semicolons are useful because they let you actually choose how you want to format things.
There are a few situations where they're also more transparent, ike when you're dealing with keywords or functions or macros you haven't dealt with before.
Not a big deal either way.

Punctuation soup may or may not be accurate.
It's difficult to assess that not having actually written in the language before.
Every language looks confusing when not having programmed in it.

Would anyone be kind enough to post some working C++ code that simply reads the contents of a text file into an array of strings? No matter what I do, or what code I copy and paste from stackoverflow I can't get this to work. At this point I just want to see that it's possible more than anything...

Attached: 1463639700222.png (1366x768, 1.01M)

It's not in the realm of manipulating vertices individually, but iterating over and binding the state of thousands of objects isn't free

In particular, fixed functions mean to rotate something about itself I have to:

// All has to be done in the draw call unless you're a genius at managing an uncheckable matrix stack
glPushMatrix
glBind(the thing)
glTranslate(move to center)
glRotate(rotate it however)
glTranslate(back to where it should be)
glDraw(the thing)
glPopMatrix
Rinse repeat for everything that needs to be rotated around its model center

vs

// Literally anywhere in the program
glm::mat4 RotatedModelMatrix = glm::rotate(ModelMatrix by whatever)
glUniform4f(bind to model matrix uniform in shader)

// In the actual draw function
glBind(the thing)
glDraw(the thing)

Hence "practically"
Everything already lives on the GPU and you have pointers to them in the form of your VBOs, it's the equivalent of sending an int with a command over the bus vs 6 dozen commands and their associated data

>Semicolons are useful because they let you actually choose how you want to format things
Compulsory semicolons are completely pointless. There is no reason why a language shouldn't interpret an end-of-line as a semicolon

this is a jai function call according to google

sum :: (x: float, y: float, z: float) -> float {
return x + y + z;
}

operators like :: and -> also have no fucking reason to be there

sure it's not a big deal and doesn't really hamper your ability to program, but if you're designing a new language what's the point if you aren't going to at least clean up the syntax

Dumb question. How do websites like My Anime List and IMdB work (specifically, how do they display a unique webpage for each movie/show)?

The simplest and least elegant solution would just be to have a webpage for each and every show, but then that would take an inordinate amount of space (1.7 Million shows times a 1KB page is approximately 2 PB, and that's on a conservative estimate)

If I want to make a similar website, how would I create those webpages? My thought process right now involves creating a tool that stores a show's information as a json file, then make a function that converts a json file into an html-friendly webpage (because all I'll be doing is simply filling up information on a webage once I have the basic 'skeleton' of the webpage down).

Any tips/reading for doing stuff like this? Should I ask /wdg/?

Attached: Screen Shot 2018-06-12 at 6.22.14 PM.png (1362x910, 1.1M)

>There is no reason why a language shouldn't interpret an end-of-line as a semicolon
Go does this, actually. It's quite nifty, and lets you retain control of doing things like if result, err := somefunc(); err != nil {

>unique
If by you mean they all have a distinct URL: Model View Controller. The pages are all a shared template, basically, and each "unique" page has data floating around that just gets filled into the right spots.
If by you mean they all look visually distinct: They don't, so that's not a real question

I need to use OpenGL and I dont know a single shit about graphics, any good place to learn?

The : operator means you are declaring a variable
The :: operator means you are declaring a function
It's consistency

You need :: so that when you are declaring a function either anonymously or within the scope of something else
(IE not a typical global function) you can easily differentiate between a function call vs a function definition

>The arrow also has no fucking reason to be there
The -> operator is kind of a nice touch imo
it's obviously the same idea as C++'s > operators

You could be right that it is unnecessary though.
Best example of why I can personally think of it ---might--- be necessary to differentiate something similar to:
sum() float x{}
vs
sum::() -> float {}

...but I'm stretching that... Maybe there's a Functional reason why it's like that?

>no reason why a language shouldn't interpret an end-of-line as a semicolon
It's consistent and transparent what's happening with a semicolon
It's only 1 extra character too

open.gl/ (Personal favorite because it uses GLUT instead of GLFW/SDL, which makes Khronos documentation easier to use)
learnopengl.com/
opengl-tutorial.org (Particularly good at explaining Model/View/Projection matricies)

gitlab.com/DrRoach/NetworkAPI

Attached: 1526308529040.gif (303x307, 1.24M)

Learning Scala for work. sbt makes no sense so I caved and set up Intellij.

>It's consistent and transparent what's happening with a semicolon
its consistent and transparent what's happening with a new line aswell
it's "only 1 character" but it's one character at the end of every line of code you type
it's that sort of attitude that leads to this sort of verbose punctation soup

anyone?

>IMdB
It's literally in the name — they use a database. Then they have software that pulls records from the database on-the-fly and builds a webpage.

name it after your waifu

Here you go... I tried commenting it to help you understand what's going on at each step.
Basically, the trick is that you have to know (or at least overestimate) the amount of lines you are going to read. If oyu don't have a set size, or don't want to vastly overestimate space, I recommend using vector

Anyway, here's my code:
#include
int main()
{
int arrsz;
std::ifstream inputFile("/* filepath */ );

//read in an integer, which represents how many lines we'll read
std::string currLine;
getline(inputFile, currLine);

arrsz = atoi(currLine.c_str());
std::cout

Attached: Screen Shot 2018-06-12 at 6.33.38 PM.png (624x268, 38K)

Okay. That's what I thought they did, just wanted to make sure.

Thanks user!

Fudged the formatting. Take two:
#include
int main()
{
int arrsz;
std::ifstream inputFile(/* filepath */ );

//read in an integer, which represents how many lines we'll read
std::string currLine;
getline(inputFile, currLine);

arrsz = atoi(currLine.c_str());
std::cout

>Programming Distro
>i3wm
>Not dwm
Other than that, sounds neat. Include CMUS and I guess MPV as optional install features?
Also give the option to use emacs and set everything to use emacs bindings vs VIM bindings. Might as well play both fields.