/dpt/ - Daily Programming Thread

Old thread: What are you working on Sup Forums?

Other urls found in this thread:

wikiwand.com/en/Text-based_user_interface
pastebin.com/xKQwsKcy
twitter.com/SFWRedditVideos

What am I looking at here?

N3\/\/ 7R34|) \/\/|-|3N???

programming super scalable programs for clustered systems in Chapel
and basically you are fucking stupid

I was talking to someone a few threads ago about opcode bits in instruction encoding, and they mentioned RISC-V using 7 bits, instead of my 6. However, the two most significant bits actually tell if the instruction is compressed, and then act as the opcode if it is.
This seems retarded.
Not only do you _LOSE_ opcode space (32(5 bits)+4(compressed) opcodes), it also seems awfully myopic for future expansion, as this is the lowest I've seen a RISC architecture go with opcodes, and MIPS has 6 bits, and AFAIK is slowly running out of space to expand.
This also invalidates this criticism given of MIPS in the RISC-V design document(lack of opcode space), as they've done it to themselves.
Can someone correct me on this?

Threadly reminder that dlang-chan is not dead; she's going to have her GC tumor removed (eventually); and she's super duper cute and easy to prototype in! Say something nice about her, /dpt/!

She can, but they'll be Siamese twins.

It does, but as said: they're too functionally different. I'd like both tuples and multiple return values. But they, at least I have one of them.

>tfw too stupid to write something as simple as a brainfuck interpreter in C
got it to print "Hello World!" but it fails miserably on the prime example
fucking loops man

someone post the most recent pro/g/ramming challenges

Wait, so what would equivalent code like this look like in D?
fn return_tuple() -> (i32, char, f64, &'static str) {
(123, 'b', 3.21, "Hello World!")
}

fn main() {
let (_, b, pi, hello_world) = return_tuple();
println!("{}, {}", pi, hello_world);
}

I have a function returning a single tuple which contains an integer, a char, a double and a string literal and i call the function, destructuring the tuple, ignoring the integer.

looks like a really big IC

Tuple!(int, char, double, string) returnTuple() {
return tuple(123, 'b', 3.21, "Hello World!");
}

void main() {
auto stuff = returnTuple();
foreach (item; stuff) {
write(item, " ");
}
}

>ignoring the integer.
Oh shit I didn't read that part

looks like ethernet transformer

It's basically pattern matching.

Fuck yall niggahs


Jk im not black. Read like it for a secobd didbt it? I have star ocean on.

You know who you are. Drink and a snack on me.

Also, I have a star ocean on.

This isn't equivalent tho, he ignores the first element, has no loop and prints everything in a single call with a custom formatting string.

>A tuple is the same thing as a struct or record
Rate this statement on its truthfulness

is it a bad idea to make a gui that displays directly through the framebuffer without appropriately interfacing with the window manager?

Yes, I'm aware of that now. I glossed of her source like a fool. I could probably cook something that's functionally equivalent, but it wouldn't be as nice as her's.

a struct isn't even the same as a record

Depends on the language, i guess?
In Rust, for example, it's true, as tuples are essentially just anonymous structs, kind of like what lambdas are to named functions.

Asking again in this thread.

I want to learn android development and I know java already so should I use java or kotlin?

you should kys

Yes and no.
If you're using a window manager, the window manager will screw you.
If you aren't, congratulations, you just discovered the first step to writing one.

Is this good C++ code? If not, can you pls tell me how to improve

#include
using namespace std;
struct Node
{
int data;
struct Node* left;
struct Node* right;
};

/* Helper function that allocates a new node with the
given data and NULL left and right pointers. */
struct Node* newNode(int data)
{
struct Node* node = new Node;
node->data = data;
node->left = NULL;
node->right = NULL;

return(node);
}

/* Computes the number of nodes in a tree. */
void inOrder(struct Node* root);

/* Driver program to test size function*/
int main()
{
int t;
scanf("%d\n", &t);
while (t--)
{
map m;
int n;
scanf("%d\n",&n);
Node *root = NULL;
while (n--)
{
Node *parent;
char lr;
int n1, n2;
scanf("%d %d %c", &n1, &n2, &lr);
// cout

What new autism is this?

DS1287 clock chip from late 80s early 90s. These things are a self-contained RTC and battery. The batteries in these things are usually long dead so you either have to find a replacement chip (which are rare) or file away the plastic on the outside to mod in your own external battery.

a struct includes details like alignment

>kys

*Implementation defined

>PHP
just fucking kill me to dead

it's true
structs describe memory representation

First time programmer here, I want to do a simple file browser in ncurses, like an interactive "tree" program. Any advice/resource is welcome.

Tuple!(int, char, double, string) return_tuple()
{ return tuple(123, 'b', 3.21, "Hello World!");
}

void main()
{ auto tmp = tuple(return_tuple[1 .. $]);
writefln("%(%s%|, %)", tuple(tmp[1 .. $]));
}

outputs:
3.21, Hello World!

Not in the conceptual sense

People are probably going to take one look at your code and see
using namespace std;

and say no. The following is intended for those people.

THERE IS NOTHING FUNDAMENTALLY WRONG WITH THE USING DIRECTIVE.

>namespace pollution
This is only a problem if it's done in a header file.

>name clashing
This is basically not a problem if you don't call your classes excessively general names such as "string." It's especially not a problem if you capitalize your user-defined types, as this person is doing.

>muh style
The only reason this is considered bad style is because of the problems it presents when misused. It's not being misused here, so the style argument doesn't hold.

I'm trying to figure out asynchronous python because I hate myself.

write a program that can display any tree
then write a program that loads the file structure as a tree

yes in the conceptual sense

and that's why they're not records

I don't know if I can decouple this like you did without multiple calls to returnTuple().
Tuple!(int, char, double, string) returnTuple() {
return tuple(123, 'b', 3.21, "Hello World!");
}

void main() {
auto stuff = tuple!("b", "pi", "helloWorld")(returnTuple()[1..$]);
writef("%f %s\n", stuff.pi, stuff.helloWorld);
}

>I can't program in sepples so I sperg on Sup Forums about my bad style
Either program in sepples in the sepples way or leave nigger.

>#include
Pretty sure I remember having seen that and it's GNU specific. should"ve been passing through standard headers instead. scanf is in , cout is in , map is in , and I think you're set.

>struct Node
gets to be just Node in C++, unless you're referencing it before you declare it. That's a feature of the language.

define inOrder maybe?

mixing scanf and cout... well technically scanf clashes with cin and cout clashes with printf, so it's fine but it's weird. lrn2 cin>>, although iostreams are arguably bullshit, so use printf and be proud of it.

newNode could be made into a constructor and new Node(n1) used instead.

deallocate those nodes, even if it doesn't matter in that case.

map pls, no need for that extra level of indirection and this whole memory allocation.

>(char)lr why? it's a char already no?

No, they aren't called records because they don't define a type. Other than that they are the same.

>records must "define a type" in some sense that structs don't
???

wikiwand.com/en/Text-based_user_interface

A tuple is indexed, a record has fields.

A record is nothing else than syntax (syntactic?) sugar for a tuple; Once your programming language has tuples, there no need to modify the semantics to have records.

a struct and a record are the same.

I'm retarded. I don't need to call returnTuple() multiple types to decouple, but it would still be cumbersome .

>he's never actually done anything with namespaces before
>he's not had the opportunity to know how good it feels to put "using namespace [name of your namespace]" in an implementation file

They don't have a name you mean. Why do types not exist unless they are explicitely named? expressions have types, (or values if you're a faggot), and (1, "2", 3.0) can't have no type, so tuple is that type.

>A record is nothing else than syntax (syntactic?) sugar for a tuple; Once your programming language has tuples, there no need to modify the semantics to have records.

record { x : Int, y : Float } = record { y : Float, x : Int }

(Int, Float) =/= (Float, Int)

>record { x : Int, y : Float } = record { y : Float, x : Int }
wrong, they're ordered differently in memory
>(Int, Float) =/= (Float, Int)
let x = 1 and y = 2
a tuple whose xth element is an int and whose yth element is a float is the same thing as a tuple whose yth element is a float and whose xth element is an int

That's getting into specific late semantics, that is not a type in every language.

>wrong, they're ordered differently in memory
We're not talking about structs.

Anyone?

Thanks guys

Do you think it'd be fine if I didn't use pointers for structs and no new?

let x and y be constants

let T be a tuple such that typeof(T[x]) == int and typeof(T[y]) == float

let U be a tuple such that typeof(U[y]) == float and typeof(U[x]) == int

T and U are of the same type

yes. it's tuples which are syntax sugar for records.

Tuple(Int, Float) = Record { 1: Int, 2: Float }

>rephrasing your assertion in an awkward fashion using the word let somehow makes a false statement true

exactly, you can think of tuples as a special case of records

once again anime posters proven to be more intelligent than dumb posters who are probably also frogposters

You never said it was false though. You only said the other thing I said was false, which I concede, because we were talking about records, not structs. I'm not repeating the second thing I said to give it more credence, I'm repeating it to remind you I said it, because you seem to have ignored it.

Anyway, how exactly is this reasoning flawed?
let x and y be constants

let T be a tuple such that typeof(T[x]) == int and typeof(T[y]) == float

let U be a tuple such that typeof(U[y]) == float and typeof(U[x]) == int

T and U are of the same type

>frogposters
Wish we could launch them into the sun

x is not y and cannot be y

How does that have anything to do with the fact that T and U are the same type?

I am telling you, all you are doing is making this inconvenient and awkward for everyone.
Everyone knows they are different.
Here, a simple proof:

T = (Int, Float)
U = (Float, Int)

fst T = Int
fst U = Float

fst T =/= fst U
T =/= U

How the fuck does assignment work then?

>T = (Int, Float)
>U = (Float, Int)
Wrong. This assertion is inconsistent with the definitions I provided of T and U.

Read CAREFULLY:
Let x and y be integer constants.
T and U are tuples.
T's element of index x is an int.
T's element of index y is a float.
U's element of index y is a float.
U's element of index x is an int.
How are T and U not the same types?

I don't give a damn what your definitions were, I just proved that they weren't the same.

Your logic would say that sin(x) = -sin(x) because if you let y = -x then sin(x) = sin(y)

Same as records, but with the subscript operator.
T[x] = 1
T[y] = 3.0f
U[y] = 3.0f
U[x] = 1
T == U

Your argument was that records and tuples aren't the same because order matters in tuples but not in records.

My argument is that the two kinds of order you're comparing are incomparable. Ordering of fields in a tuple is not analogous to ordering of field declarations in a record. A closer analog to ordering of field declarations in a record would be ordering of declarations of variables used to store indices into tuples, and THAT order indeed does not matter, just as in records.

But if U[y] = 1 and U[x] = 3.0 it would still work?

No, but that doesn't matter. That also wouldn't work with a record.

>Your argument was that records and tuples aren't the same because order matters in tuples but not in records.
that's simply one point

>My argument is that the two kinds of order you're comparing are incomparable. Ordering of fields in a tuple is not analogous to ordering of field declarations in a record. A closer analog to ordering of field declarations in a record would be ordering of declarations of variables used to store indices into tuples, and THAT order indeed does not matter, just as in records.
No, the key here is that, if we assume tuples are a case of records,
(Int, Float)
is sugar for
(1 : Int, 2 : Float)
which IS equal to
(2 : Float, 1 : Int)
which ISN'T equal to
(Float, Int)

But they're the same type?

>Your logic would say that sin(x) = -sin(x) because if you let y = -x then sin(x) = sin(y)
Isn't he only talking about type equality? Your claim their seems a little outside his field of discussion, but I'm just butting in so maybe I'm mistaken here.

good god python is annoying when youre used to a c-esque language. Holy fuck even javascript is less annoying.

Before another points it out I'm aware of my their mistake and wish to hang myself even if it was just at typo.

>No, the key here is that, if we assume tuples are a case of records,
>(Int, Float)
>is sugar for
>(1 : Int, 2 : Float)
>which IS equal to
>(2 : Float, 1 : Int)
>which ISN'T equal to
>(Float, Int)
Yes, I agree. But that doesn't mean records and tuples aren't the same thing. Records just have names assigned to their indices. Record { x: Int, y: Float } is comparable to (1: Int, 2: Float), not simply (Int, Float); and therefore, Record { y: Float, x: Int } is comparable to (2: Float, 1: Int), not to (Float, Int). And, as you pointed out, (2: Float, 1: Int) is the same as (1: Int, 2: Float), just as Record { x: Int, y: Float } is the same as Record { y: Float, x: Int }. So, tuples and records really are the same thing.

No. They aren't.

>But that doesn't mean records and tuples aren't the same thing.
Yes it does.
When someone says "Record" that does not mean "Tuple".

In fact, a Record can also be thought of as a tuple PLUS a list of field names

Someone in another thread implied you can use M4 macros in your C programs to simulate templates.

How do I do this?

When does order not matter then? I'm very confused

>In fact, a Record can also be thought of as a tuple PLUS a list of field names
Which is just a tuple. Because names are not data.

>Which is just a tuple. Because names are not data.
Nonsense.

The order of assertions doesn't matter.
It doesn't matter whether you first say that T[x] is an int and then that T[y] is a float, or first that T[y] is a float and then that T[x] is an int. Which is exactly the same kind of order that doesn't matter with records.

You're manipulating the scenario to create a false impression.
The "order matters with tuples" precisely when you aren't considering the record interpretation, i.e.

(Int, Float) =/= (Float, Int)
This is clearly a case where order matters, and they are tuples.
This single example alone proves the case IRREVOCABLY.
Anything beyond this is meaningless bullshit.

You are instead manipulating this to interpret the tuple as a record
(1 : Int, 2 : Float)
and THEN saying order doesn't matter
Well guess what, the tuple order is what gives those fields those names in the first place

Could someone elaborate on this record type please? The way some people are writing things, it almost looks like you're talking about a hash table(also commonly referred to as a dictionary), but that can't be it... right?

>Nonsense.
Not so.
Let x and y be constants.
If you evaluate x, you get the constant value for which it stands, with no name attached.
If you evaluate "x", you get a name, but it has no relationship to the constant.
The connection facilitated between the name and the constant is illusory and abstract. It is not data.

>Let x and y be constants.
No.
Enough with your bullshit.

>(Int, Float) =/= (Float, Int)
>This is clearly a case where order matters, and they are tuples.
Record {one: Int, two: Float} =/= Record {one: Float, two: Int}

Imagine a struct, but without the implied memory layout, and the order of fields doesn't matter.

Let x and y be field names in record R.
If you evaluate R.x, you get the constant value for which it stands, with no name attached.
If you evaluate "R.x", you get a name, but it has no relationship to the constant.
The connection facilitated between the name and the constant is illusory and abstract. It is not data.

>if i take this inequality and map both sides over an isomorphism, i still have an inequality!
no shit

the fields of the same name have different types, therefore the records are different types.

>inb4 field names don't matter and everything is the same

>Let x and y be field names in record R.
No, shut the fuck up.
I am not reading these posts beyond the first line to know that it's one of these stupid fucking posts.
You're just pretending to have been a troll at this point.

pastebin.com/xKQwsKcy how do i make my implementation not be this fucking autistic and shit

Names aren't data

Learning C and I'm confused with the flow of events.
For example:
printf("Enter char\n");
char c = getchar();
getchar() is called before printf even though printf comes first. Why?

Yes, they are.

>getchar() is called before printf even though printf comes first. Why?
That shouldn't be happening. A conforming C implementation has to sequence any two statements with side effects in the order they're written. What implementation are you using?

Record {x: Int, y: Float}
"x" and "y" don't exist

Define data