Programming thread

[Ledj]

It's never an argument about whether programs written in it have more / worse errors than programs written in other systems programming languages. Notice that?

Well, sure, but other systems programming languages almost never get used except in small / niche areas; any claims about their superiority remain conjecture because they don't ever reach the same amount of use across projects of the same scale. Rust is gaining a little momentum, but D / Ada / et. al are doomed to relative obscurity.
It'd be nice to see a widely adopted, major OS written in something other than C, and it'd be interesting to see an industry standard graphics library not written in C. No one wants to do it; maximum portability, exposure, and library support trump everything, and thus C remains the fulcrum language and everything else just wraps / accommodates it. C is the systems equivalent of Javascript (although nothing is as bad as Javascript, so please don't take that too literally). Until people are really ready for a violent change, it seems C will maintain dominance indefinitely, and every new systems language will always have to include an advertisement about how seamlessly it interops with it. (See: Rust, Nim, Zig)

Edit: And I forgot to mention, it's that very interoperability that catapulted C++ into the popular state it has maintained for decades. It didn't force entire rewrites of codebases to support it.

 

[Marvin]

Well, sure, but other systems programming languages almost never get used except in small / niche areas; any claims about their superiority remain conjecture because they don't ever reach the same amount of use across projects of the same scale. Rust is gaining a little momentum, but D / Ada / et. al are doomed to relative obscurity.
It'd be nice to see a widely adopted, major OS written in something other than C, and it'd be interesting to see an industry standard graphics library not written in C. No one wants to do it; maximum portability, exposure, and library support trump everything, and thus C remains the fulcrum language and everything else just wraps / accommodates it.

But again, that's more x86 calling conventions than C itself.

Using dlopen to grab a shared library and grab some function pointers from it isn't interfacing with C if the library itself isn't written in C. (which it may or may not be)

 

[Ledj]

But again, that's more x86 calling conventions than C itself.

I'm not sure I get your point; calling conventions are arbitrary, and so the ubiquity of C's calling convention at a systems level is itself proof of its widespread use. If C stopped being used so frequently, there would be no reason to continue using those calling conventions except for backward compatibility (and just the saner environment of not having to reconcile countless proprietary calling conventions).

 

[Marvin]

I'm not sure I get your point; calling conventions are arbitrary, and so the ubiquity of C's calling convention at a systems level is itself proof of its widespread use. If C stopped being used so frequently, there would be no reason to continue using those calling conventions except for backward compatibility (and just the saner environment of not having to reconcile countless proprietary calling conventions).

In Guile Scheme, you can use its bindings for dlopen to open up a compiled ELF library. You can grab function pointers from that and call them, just like ordinary functions. Those remote pointers could've been written in C, Java, Perl, anything.

I usually call those "C" functions directly in the guile interpreter. I've never actually dealt with any of guile's C headers.

A lot of people interpret a C header function specification as a shorthand for how you would call a function pointer loaded from a shared library using dlopen. But that's not really what's happening, necessarily. It's a common shorthand that's really determined by the machine code and assembly code underlying it.

What's happening is some assembly sequences are executed that don't actually touch C. They might've been written in C, but they also might've been written directly in assembly. And there's no way of knowing and it doesn't actually change how the code is written or used.

They might touch C though, but only in the mundane way that either of the caller or the callee were implemented in C. (Just as they might be written in Java or perl or whatever)

If tomorrow they tried to swap out C for another language, the calling conventions would remain, but they wouldn't be in place because C dictated them, but just because the existing binary interfaces exist.

 

[cecograph]

But again, that's more x86 calling conventions than C itself.

Using dlopen to grab a shared library and grab some function pointers from it isn't interfacing with C if the library itself isn't written in C. (which it may or may not be)

Genuine question: what about the layouts of data structures I want to exchange with the library (the rest of the ABI)?

 

[Marvin]

Genuine question: what about the layouts of data structures I want to exchange with the library (the rest of the ABI)?

The basic structure of calling other functions on Linux is defined in this document, I think.

If the caller wanted to pass in a pointer to a block of data on the stack, how that data is laid out depends on the library. The layout of C structures used by C libraries would be defined by headers and thus by the C compiler.

Though there's certainly data in C libraries that can't be logically represented by the C type system (and thus isn't expressed in headers) and needs to just be transmitted by gentleman's agreements on both ends. So for example, enums expressed as bitfields in integers.

 

[awoo]

This is a bit cliche but I've always respected the attitude Knuth describes in his "advice to young people"

My thinking: The code written in what is trendy, be it the JS framework of the year, is quickly forgotten, while Knuth seems to be expressing the sentiment of Thucydides (pretty lofty but admirable):
“I have written my work, not as an essay which is to win the applause of the moment, but as a possession for all time.”

 

[cecograph]

The basic structure of calling other functions on Linux is defined in this document, I think.

If the caller wanted to pass in a pointer to a block of data on the stack, how that data is laid out depends on the library. The layout of C structures used by C libraries would be defined by headers and thus by the C compiler.

Though there's certainly data in C libraries that can't be logically represented by the C type system (and thus isn't expressed in headers) and needs to just be transmitted by gentleman's agreements on both ends. So for example, enums expressed as bitfields in integers.

Since @Ledj mentioned them, it's worth noting that graphics libraries like OpenGL don't cater first to C, in this respect. If you think that the OpenGL API was written for C programmers, it just looks totally fucking insane. It only makes sense when you realise it's designed to be used in a context where no-one can make any assumptions about how to aggregate data, so everything has to be done using simple handles, buffers and state machines. It's painful to use in that respect, but completely trivial to write foreign bindings for.

 

[awoo]

Here's something funny I can across. I was wondering if I could order a physical copy of the Intel x86 manual which is like 4 or 5 volumes several hundred page manuals, and this is the first thing I see on their site https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html

Normally I overlook this kind of thing but I couldn't help but laugh this time. Yeah I'm sure that several black folx working on a 3D printer or something is what the people who designed these ISAs look like. Maybe it's true with diversity hiring. I just know I've been to several job fairs with Intel hiring, and the actual engineers are all white middle aged guys, with the occasional white middle aged woman. The picture reminded me of this meme

 

[Kosher Dill]

I was wondering if I could order a physical copy of the Intel x86 manual which is like 4 or 5 volumes several hundred page manuals

Jesus. One volume used to suffice.

https://www.amazon.com/dp/0135332257

 

[awoo]

Jesus. One volume used to suffice.

https://www.amazon.com/dp/0135332257

but we now have another 20 years of instruction extensions

like when I do cat /proc/cpuinfo there's this long list of flags, which I recognize some of. "fpu" tells me I have a floating point unit, hooray!

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

 

[Bongocat]

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

is this the programmer's version of lorem ipsum?

 

[Whatevermancer]

My coworker just nuked my REST server for testing and replaced it with his own implementation. All my hard work is null and void, and I'm sad. On the other hand, it's fair, cause he's the one who's actively using it, and not me.
Also his code is unreadable.

Thanks for reading my blog post.

 

[world of shit]

My coworker just nuked my REST server for testing and replaced it with his own implementation. All my hard work is null and void, and I'm sad. On the other hand, it's fair, cause he's the one who's actively using it, and not me.
Also his code is unreadable.

Thanks for reading my blog post.

Either way, you get paid. Now he owns it, and owns the consequences. Be happy

 

[Whatevermancer]

Either way, you get paid. Now he owns it, and owns the consequences.

True, true.

 

[stares at error messages]

Today I discorded you can call python with heredoc.

#!/bin/bash

python3 - <<EOF
print('Hi from python')
EOF

 

[Bongocat]

sorry if this is very noobish question, but search engines are giving me very strange results on this. Can I write "one time" multiline bash scripts from within the console? Like if I want to write a small script to loop over all the files in a directory and process them with some program, how would I do this without explicitly making a file and giving it execution permissions.

I can write scripts fast, but having to hop to the file system, even if it's within the terminal, slows me down greatly.

 

[byuu]

sorry if this is very noobish question, but search engines are giving me very strange results on this. Can I write "one time" multiline bash scripts from within the console? Like if I want to write a small script to loop over all the files in a directory and process them with some program, how would I do this without explicitly making a file and giving it execution permissions.

I can write scripts fast, but having to hop to the file system, even if it's within the terminal, slows me down greatly.

You can just separate lines with a semicolon instead of a newline.

for i in *.rar; do unrar $i; done

 

[Bongocat]

You can just separate lines with a semicolon instead of a newline.

for i in *.rar; do unrar $i; done

very cool, though now my 'pie in the sky' version. Is there a way I can write more complicated scripts in say... a vim scratch buffer and then execute those without messing with files? Just having them automatically go to a temp file where I don't have to worry about them (but can recover if need be) would be ideal. I just hate making files manually. Adds extra steps, clutters up the workspace.

I could probably roll that myself, but I'd much prefer an existing tool since I imagine there's a lot of edge cases.

 

[byuu]

very cool, though now my 'pie in the sky' version. Is there a way I can write more complicated scripts in say... a vim scratch buffer and then execute those without messing with files? Just having them automatically go to a temp file where I don't have to worry about them (but can recover if need be) would be ideal. I just hate making files manually. Adds extra steps, clutters up the workspace.

You can just hit ctrl+x followed by ctrl+e to open the current line in your $EDITOR (or press v if you use vi mode instead of the default emacs mode)