/dpt/ - Daily Programming Thread

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

Other urls found in this thread:

sandpile.org/x86/drx.htm
wiki.osdev.org/CPU_Registers_x86#Debug_Registers
twitter.com/SFWRedditImages

Do they plan to fix this or is it nailed to D's coffin? Because I'd really love D without a STW GC

First for COBOLT

Cobalt*

Supplementary tomato anime.

You can use D without GC right now.

60/40 want the GC gone.
Also /dpt/ wildly overreacts about GC's obtrusiveness.
But as the other user said, @nogc is your friend.

Think they're working on switching it out for Sociomantic's GC, which runs in a separate thread

Maki is the only tomato

How practical is it really?

It's as easy as malloc and free

user, I don't have anything much against the GC.
Well if D goes full RAII it'd be even better but how about making the GC better?
>60/40 want the GC gone.
what?

What always puzzles me is:
>Go is great!

Please, Gotards are the official laughing stalk of /dpt/

Fucking parameter packs in c++ templates drive me nuts.
Please tell me this can be implemented better:
#pragma once
#include
#include

template
class test_array {
public:
template
explicit test_array(Args&& ...args) : sizes{std::forward(args)...}, data{size() ? new T[size()]{} : nullptr}
{
}

template
size_t ix(Args&& ...arguments) {
std::array args{std::forward(arguments)...};

size_t index{};
for (size_t i = 0; i < Rank; i++) {
index += args[i] * std::accumulate(sizes.cbegin(), sizes.cbegin() + i, size_t{1}, std::multiplies());
}
return index;
}

size_t size() const {
return std::accumulate(sizes.begin(), sizes.end(), size_t(1), std::multiplies());
}

std::array sizes;
T* data;
};

>but how about making the GC better?
Thats counter-productive when the community is leaning towards a nogc future.

But the GC isnt even bad, even for being STW.
You can also do GC.disable/enable anytime you want. Or just use malloc/free and std.container.array

>Some people read these

this is why C is never going away

just kill yourself instead. it's easier than trying to finish that.

im building shared libraries using cmake and gcc, is there any way to disable generating .a files? i dont need them and they just take my screen space when browsing output directory

>enable GC back
>Immediate stw

>this is why C is never going away
No. C will never go away because all language can interface to C

variadic templates are not for humans, give up.

>dont .enable on performance critical sections
>never have an issue
with concurrency and parallelism it shouldnt be a problem though.
But if youre that apprehensive then just stick with c/++, desu.

>C++
I'd rather kill myself or stop programming.

Sounds complicated, I won't optimize it before switching to A* from BFS and seeing that I really need it. Premature optimization is the root of all evil.

Also, seeing that you're much more experienced Python programmer, and I'm way more familiar with C, in your opinion, how much Python is bigger, harder to master than C is? Currently, I have the C standard and I like reading it from time to time, I think that combined with the C puzzle book (1982) I will become quite deeply familiar with the language.

the command to generate a shared library is
gcc -shared -o libfoo.so inputfile1.c inputfile2.c inputfile3.c obj1.o staticlib1.a # etc

chances are for a small project you probably don't need cmake. just specify your source dependencies manually with a regular makefile, it'll be way faster

Then i guess if you really wanted to you could just use it as a better C environment with UFCS and functional support.

C++ has UFCS?

>better C
Is thare any guide/website for that.

>the command to generate a shared library is
>gcc -shared
it's that easy? holy shit

There's literally no reason to learn programming.

> laughing stalk

I have never liked c++ but I just wanted to program multi dimensional array in c++.

I think he was talking about D.

Clojure, Haskell, or Elixir tonight, lads?

point stands irregardless :^)

???
To avoid being a jobless neet?

>tonight
A 30 minute intense masterbation session about pure languages

thats not what i was asking for, i want gcc to not generate that .a file, whenever i create dll/so file theres always an .a, i dont want it

I should probably add 'after the masturbation'.

I just wish Clojure had pattern matching...

Rust doesn't have this problem

Anybody tried this? Will it make me a better programmer?

No, but striped socks will

> imperative language
> twenty fucking seventeen

If you're a programmer, you're on a fast track to become a jobless neet.

it doesn't generate a .a file

$ cat testlib.c
int important_function(int a)
{
return a*2;
}
$ gcc -fPIC -shared -o libtest.so testlib.c
$ ls libtest.*
libtest.so
$ ls *.a
ls: cannot access '*.a': No such file or directory

test

What if there was a Rust based language that doesn't have stupid shil like borrow checker? It'd use RAII and have zero cost itererators etc

>What are you working on, Sup Forums?

Going back and trying to understand Prolog a bit more

it's called unsafe

> Prolog
I still have nightmares.

itd still be a half-breed monstrosity

Can't be worse than C++

it must be fucking cmake, but im not gonna write makefile for 250 cpp files tho

It unironically is though.

Nice try, herb sutter

(Reposting)

(You)
I caught it turning null literally immediately after object construction:
RamfsFile ctor 2, vtable: 0xc01145bc
alloc_inode 0xc0911020 vtable: 0x00000000


RamfsFile ctor:
RamfsFile::RamfsFile(u64 ino, RamfsInstance *instance) : RamfsInode(ino, instance) {
printk

Enterprise incompetence/laziness is amazing.

>Current state of C++

kek this is sad

if your code is properly modularized, writing makefiles will be super easy

if it isn't modularized to the point where you could shit out working makefiles in 10 minutes or less, it means your code sucks

>Current

why are you writing a kernel in c++?

set an early write watchpoint for the address then continue the debugger

it'll trap whenever it gets zeroed

Well, C is a lot more nuanced than Python, which be tricky to learn. However, Python has a lot more concepts to learn. All in all Python is probably much easier to master than C, simply because is more primitive than Python and thus requires a lot more experience to handle things, especially if the program gets large.

It is not really hard to switch to A* from BFS if you see out your code correctly. A general program structure would be.
# node.py
class Node:
# Used for handling nodes in a tree
def __init___(self, element):
# Set g, h, f, parent and children to default values
def addchild(self, node):
# Add child to node
def setParent(self, parent):
# Set parent for node

# tree.py
class Tree:
# Used to store the actual tree and nodes
def __init__(self, root):
# Set root node of the tree

def __contains___(self, item):
return self.contains_aux(self.root, item)

def contains_aux(self, node, item):
# Use recursive algorithm to find element in the tree

# tree_search.py
class TreeSearch:
def __init__(self, puzzle_initial_state):
# Set the currently selected node (for expansion) of the tree to an initial state
# Create a tree object to store all the states
# Create a variable to store open and closed states
def solve(self):
# Expand each element in open to check if the puzzle is solved


Now it is a matter of creating a class for your BFS or A* to inherit from TreeSearch and defining a method expand_node to calculate the f, g and h values of each node and ordering it so that solve will get the smallest f value.

D atleast did this better than c/c++ does:
int x,y; // x and y are ints
int* x,y; // x and y are pointers to ints
int x,*y; // error, multiple types
int[] x,y; // x and y are arrays of ints
int x[],y; // error, multiple types

I've never seen that book so I can't comment on how good it is. What do you mean by "better programmer"? That could mean a few things. I recommend The Pragmatic Programmer, but that focuses on the more software engineering side of things. The Practice of Programming by Kernighan and Pike is very good, it focuses on general programming techniques but it does a lot on C since C has a lot of unique features about it. If you are extremely lucky you could find a copy of Elements of Programming Style by Kernighan and Plauger which mainly a predecessor to The Practice of Programming and makes a lot of comments on Fortran and PL/I, but later chapters are more general. And there is also Expert C Programming, but my copy of the book has not been delivered to me yet, so I don't have it or know much about it.

As said here C is very basic and making large projects can be difficult, that's why a lot of people C++ instead of C since C++ provides a lot more abstractions to make programming easier.

On one hand yes, on the other everyone is used to the trap that the syntax is in C++ and C and it might be confusing for newcommers.

It's an improvement, but it's not the best way things could be.
int[3][6] arr;
arr[5][2]; // final element of array - confusing
The only style I haven't seen played with in any language is this, you could consider it a variant of "declaration follows usage".
int x;
*int ptr1, ptr2;
int[3][6] arr2d; // arr[2][5]

>why are you writing a kernel in c++?
Why not?

I have tried setting a watchpoint, but the problem is that when I connect gdb to qemu to set the watchpoint, the bug vanishes! Even though nothing changed except now I just have a debugger attached.
And of course the bug comes back when I don't attach a debugger.
It also vanishes when I disable KVM, and it doesn't happen in bochs at all.

Is this a qemu bug? I'm not sure if it is, because removing a function call in my code causes the bug to also disappear without changing the address that the object resides at (0xc0911020), and of course I've spent hours investigating why the existence of the somewhat unrelated function call causes the bug to arise, and can't find anything.

But what I've caught here is pretty weird.

You can also do:
int x = 4,y, z = 9;

COBOL
niggers

then compile in a write trap into your kernel, do the debugger's job for it

sandpile.org/x86/drx.htm
wiki.osdev.org/CPU_Registers_x86#Debug_Registers

I don't know how it relates to your bug but everytime I had a bug that vanished under a debugger it turned out to be an uninitialized variable which the debugger was zeroing out.

Last night I read about this language called Tcl. It looks pretty comfy and powerful, should I learn it /dpt/?

This is why I prefer C.

Demonstrate an implementation in C then.

Why would the debugger zero anything out?

No. Learn guile instead or Stallman will come to rape you while you are sleeping, just like he did with the gdb developers.

because C variadic macros are so elegant, right?

Yeah, variadic macros are the best. Fuck sepples.

Well I use C and c++ for different things, c++ for pc and C mostly for embedded stuff.

What is that supposed to be and what is Rank

I don't know but gdb does that for uninitialized variables, that's why I had the bugs occur without a debugger but the moment I attached gdb the bug would vanish. Again, I don't know how that related to your program other than the bug vanishes under gdb but perhaps it's worth looking into.

If you're going to write a shitty implementation of something and then put in a comment telling others to fix it, its better not to write anything at all.

struct array {
void *contents;
size_t size_in_bytes;
};

heheheheheheheeh

hahahaha

It's supposed to be a multi dimensional array.
So you can do stuff like.
#include "multi_array.h"
int main(int argv, char** argc) {
multi_array ma_4d(3u, 5u, 3u, 2u); // Create an array of size 90
multi_array ma_3d(2u, 4u, 3u); // Create an array of size 24
multi_array ma_2d(5u, 5u); // Create an array of size 25

// ma_3d.ix(0u, 2u, 1u) == 12
// ma_4d.size() == 3u
// ma_4d.size() == 2u
// ma_2d.size() gives a compiler error
}


your struct does something completely different though.

(You)

>but the problem is that when I connect gdb to qemu to set the watchpoint, the bug vanishes!


Haven't read your posts because TLDR so don't know if this applies but this is a classic symptom of a race condition. Is something yanking the object away from elsewhere?

>it doesn't happen when I have a debugger attached!
>it doesn't happen in release builds!
>it doesn't happen on my machine!
etc.

why do you need a variadic template for something with always two template arguments? I don't get it

The variadic arguments apply to the constructor arguments, not the class template.

It is a multithreaded kernel, but I don't have any other threads running, nor are there more than one thread touching the code where the bug resides.
I've even tried disabling the scheduler alltogether and just ran the test code in the boot thread and the bug still arises.

databases are pretty neat.

struct array multiarray;
multiarray.size_in_bytes = sizeof(int *)*3*5*3*2;
multiarray.contents = malloc(multiarray.size_in_bytes);
// Create an array of size 90
// And here is how to treat it as a 4D array:
multiarray.contents[1*3*2*1] = malloc(sizeof(int));

Add uint8_t dimension to struct. Problem solved

How bad can it be?
My dad did it and I survived that.

again, register a debug ISR and set up the debug registers to trap on write to the vtable address

that should catch your bug as it occurs

I think I will do that.

what's the recommended IDE for Rust?

firefox