p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

redleader: Aug 18, 2005; Engage according to operational parameters

echinopsis posted:

the answer would be “get out of pharmacy where I have to deal with humans”

ah, then probably some Business Languages Used For Business. java or c# (the latter is popular in nz), python, golang, php. pick one, make a web thing in it, add features to the web thing. add a database to the web thing, and use this as an opportunity to learn sql (don't just use the ORM or whatever that the language comes with). js is always useful because they'll inevitably end up doing something to a front end.

# ? Feb 16, 2024 07:54

Adbot: ADBOT LOVES YOU

# ? Jun 12, 2024 15:51

Logflat Badness: Sep 17, 2020

if someone doesnt make a haskell-like that transpiles to lua im going to make everyone on my block see through transparent

-> DO NOT RECOMMEND ME AMULET <-

# ? Feb 16, 2024 08:04

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

the lengths people are willing to go to in order to avoid using 1-indexed collections never ceases to amaze

# ? Feb 16, 2024 08:07

Tunicate: May 15, 2012

Internet Janitor posted:

the lengths people are willing to go to in order to avoid using 1-indexed collections never ceases to amaze

Tunicate posted:

So teach them MATLAB

# ? Feb 16, 2024 08:24

Athas: Aug 6, 2007; fuck that joker

Internet Janitor posted:

the lengths people are willing to go to in order to retain basic human dignity never ceases to amaze

# ? Feb 16, 2024 10:00

Soricidus: Oct 21, 2010; freedom-hating statist shill

Internet Janitor posted:

the lengths people are willing to go to in order to avoid using 1-indexed collections never ceases to amaze

1-indexed collections are annoying in a language that�s primarily used as an embedded scripting engine inside larger codebases, where the native objects you�re interacting with are probably still indexed from 0

# ? Feb 16, 2024 10:29

Athas: Aug 6, 2007; fuck that joker

1-indexing is also annoying whenever you need to do multidimensional index arithmetic. You have to add and subtract 1 all the time to get the modulo operations working right. When the indexes don't matter, there is little difference between 1-indexing and 0-indexing, but when they do, 0-indexing is better. The only exception I have found is the index arithmetic for mapping perfectly balanced binary trees onto arrays, where 1-indexing is weirdly enough nicer.

# ? Feb 16, 2024 11:52

Zlodo: Nov 25, 2006

Soricidus posted:

1-indexed collections are annoying in a language that’s primarily used as an embedded scripting engine inside larger codebases, where the native objects you’re interacting with are probably still indexed from 0

This. And it is also annoying in every other conceivable situation

# ? Feb 16, 2024 13:04

Zlodo: Nov 25, 2006

Let's not confuse programming language users with such exotic mathematical concepts as "zero"

# ? Feb 16, 2024 13:06

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Logflat Badness posted:

-> DO NOT RECOMMEND ME AMULET <-

amulet.rocks posted:

A simple, functional programming language in the ML tradition

amulet.rocks posted:

code:

type function 'n :+ 'k begin
  Z      :+ 'n = 'n
  (S 'n) :+ 'k = S ('n :+ 'k)
end

let rec append (xs : vect 'n 'a) (ys : vect 'k 'a) : vect ('n :+ 'k) 'b =
  match xs with
  | Nil -> ys
  | Cons (x, xs) -> Cons (x, append xs ys)

# ? Feb 16, 2024 13:09

Nomnom Cookie: Aug 30, 2009

rjmccall posted:

the basic problem you�re going to face is the question of what the hell state all the rust functions are in if they throw because of some random memory access that rustc doesn�t recognize as a potential source of a panic

if you don�t need to handle exceptions originating within rust functions then it�s a whole lot easier because then rust sees it as originating from a call like any other panic. i don�t know if rust knows that c functions can panic but it can�t be that hard to teach it

yeah the issue is that some kernel APIs can throw and you the caller are expected to be ready to catch. anything bubbling out of your driver is supposed to crash the system so i have no qualms about crashing immediately if rust code panics, but i want to be able to unwind through rust frames and then halt unwinding--ideally i would have a gubbins that takes a closure returning T, wraps the closure in the moral equivalent of a catch, runs the whole mess, and returns Result<T>. basically std::panic::catch_unwind except without my use case being explicitly UB

# ? Feb 16, 2024 14:44

Grum: May 7, 2007

echinopsis posted:

I�ve been suggested to learn react which I know is ultimately js/html but it�s to get some poo poo done. i�ll get my head round it. a concept with me making crimecommitter was pure js but when i�ve been reading about react seems like I can focus a bit more on the mechanics and less on it fundamentally displaying anything. but i�m just rambling now

doesn't work this way. the problem react solves is to allow facebook to a throw huge number of engineering teams, with limited ability to coordinate their changes due to the number of people involved, at facebook dot com. you take on that complexity when you decide to use react. you agree to hundreds of little implicit usage contracts that you need to keep straight in your head at all times and can only be learned by loving each one up at least one time

# ? Feb 16, 2024 14:57

Sapozhnik: Jan 2, 2005; Nap Ghost

react by itself is straightforward-ish although it requires the use of a transpiler and bundler and other nonsense like that. these are things you are going to want on a larger project anyway but for small-scale dicking around it is a needless hassle. i guess there are some workarounds that pull in the jsx transpiler at run time from a script tag which you could use if you don't really care.

the bigger problem with react is that it doesn't have any good integration with promises, which is, you know, an important feature to have in a web ui toolkit. so you get a bunch of absolutely atrocious third party garbage on top of react instead of treating promises as a first class concept within react itself. oh and also hooks are godawful and the stuff that react had before was better.

sorry mr cloudflare sir i'll remove the angle brackets around the word script so that i don't look like an evil hackerman

# ? Feb 16, 2024 17:59

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

there's always preact

# ? Feb 16, 2024 18:02

Sapozhnik: Jan 2, 2005; Nap Ghost

right, the 1:1 hipster clone of react that solves none of the actual underlying problems but hey you get props and state as parameters to render() and you can define attributes called "class" instead of having to rename it to cssClass or whatever. react and preact are definitely the least-bad options for web development, and they have become ubiquitous for a reason (because the alternative is some flavor of MVCrap or other) but they have some glaring issues nonetheless.

(i use preact)

# ? Feb 16, 2024 18:04

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

I thought it supported promises :shrug:

# ? Feb 16, 2024 18:14

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I�m pretty sure preact supports promises; we�ve moved to it for a bunch of our high-traffic sites. React is a ZIRP phenomenon, like k8s, and is only a good choice if

* you are just getting started and are building something simple, so the examples and component ecosystem do a lot of work for you
* you have a large development team that you need to keep largely decoupled, including a bunch of people to work on performance because it has a lot of traps there
* you actually have a scenario where React Native will save you work and still meet your product goals

we have most of those things and I�m still a little down on React. the world needs to generate more HTML, and use clever things like Turbo.js/morph/whatever if they want the user experience of incremental update

# ? Feb 16, 2024 18:27

syncathetic: Oct 21, 2010

Nomnom Cookie posted:

yeah the issue is that some kernel APIs can throw and you the caller are expected to be ready to catch. anything bubbling out of your driver is supposed to crash the system so i have no qualms about crashing immediately if rust code panics, but i want to be able to unwind through rust frames and then halt unwinding--ideally i would have a gubbins that takes a closure returning T, wraps the closure in the moral equivalent of a catch, runs the whole mess, and returns Result<T>. basically std::panic::catch_unwind except without my use case being explicitly UB

There's a(t least one) crate that claims to implement what you want: https://crates.io/crates/microseh/0.2.0 . I think it's intended to be used in userland instead of the kernel, but I'd bet all you'd need to change are the headers in the c file. Regardless, I'm pretty sure it's actually relying on undefined behavior at the moment. RFC 2945 allows rust functions to be delcared extern "c-unwind" but states unwinding through through extern "c" (or extern "system" as used in the crate), is undefined behavior and will become an abort in a later release. If handled_proc in that crate were changed to extern "system-unwind", I think you would be okay. That said, you would still have to be very careful about what you capture in your closure - it's undefined behavior to unwind through a frame that has pending destructors. As a workaround, you could modify the bound on the closure to require it to be Copy, which precludes it capturing anything with a destructor (and also all the other things that aren't Copy).

# ? Feb 16, 2024 18:58

Cybernetic Vermin: Apr 18, 2005

does anyone know what the guarantees of the exceptions in the nt kernel actually are? i was kind of prepared to imagine "knows how to release known relevant locking primitives but is unimaginably slow and does not care about leaking memory" levels of error handling, which i imagine you could fake your way into in a number of ways. but perhaps they are exercised more than i imagine?

# ? Feb 16, 2024 19:11

Nomnom Cookie: Aug 30, 2009

syncathetic posted:

There's a(t least one) crate that claims to implement what you want: https://crates.io/crates/microseh/0.2.0 . I think it's intended to be used in userland instead of the kernel, but I'd bet all you'd need to change are the headers in the c file. Regardless, I'm pretty sure it's actually relying on undefined behavior at the moment. RFC 2945 allows rust functions to be delcared extern "c-unwind" but states unwinding through through extern "c" (or extern "system" as used in the crate), is undefined behavior and will become an abort in a later release. If handled_proc in that crate were changed to extern "system-unwind", I think you would be okay. That said, you would still have to be very careful about what you capture in your closure - it's undefined behavior to unwind through a frame that has pending destructors. As a workaround, you could modify the bound on the closure to require it to be Copy, which precludes it capturing anything with a destructor (and also all the other things that aren't Copy).

thank you very much for the pointer! This morning I did some digging and figured out that the try impl in std boils down to LLVM's catchpad and friends--so in theory that should work with SEH? but I came up with questions about how unwinding actually works on windows as "the unwinder" seems to maybe be an OS facility on windows that rust already leans on? in that case who is unwinding in the kernel? lots of unknowns! but I think I know enough at this point to start up a windows guest and crash it

given that from what I've read it's a pretty limited set of kernel APIs you should expect to receive an exception from, one option i'm considering is doing really gnarly and horrible things to deal with those APIs and present a nice safe interface to e.g. probe and lock userspace buffers. solving the general case isn't in scope so rn i'm pretty confident that i can do something even if the result leans on UB and is only validated for specific rust/msvc/windows combinations

edit: especially if what i come up with can only handle very carefully written closures inside the try, i will not try to expose that to clients lol

# ? Feb 16, 2024 20:15

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

my memory from reviewing the clang work a few years ago is that the llvm representation for seh regions is not just the normal windows eh stuff

figuring this stuff out is greatly complicated by the fact that a lot of documentation talks about normal windows exception handling as seh. there are some commonalities around like the unwinding process but also a lot of essential differences

# ? Feb 16, 2024 21:18

pseudorandom name: May 6, 2007

by "normal windows exception handling" do you mean C++ exceptions?

because AFAIK, SEH is the Windows exception mechanism, and Microsoft built their C++ exceptions on top of SEH

# ? Feb 16, 2024 21:32

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

yes, that�s what i mean by the basic propagation being the same. iirc, though, the code patterns for entering try regions and catching exceptions are substantially different, and that�s also reflected in compiler ir

# ? Feb 16, 2024 22:59

redleader: Aug 18, 2005; Engage according to operational parameters

Sapozhnik posted:

right, the 1:1 hipster clone of react that solves none of the actual underlying problems but hey you get props and state as parameters to render() and you can define attributes called "class" instead of having to rename it to cssClass or whatever. react and preact are definitely the least-bad options for web development, and they have become ubiquitous for a reason (because the alternative is some flavor of MVCrap or other) but they have some glaring issues nonetheless.

(i use preact)

vue is good, although they have been bitten by React Fever and have introduced react-style hooks and poo poo in vue 3. so maybe i should say vue was good

# ? Feb 17, 2024 02:57

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

NT should have implemented an equivalent to the Common Lisp condition system in the kernel and userspace, all the other mechanisms are really subsets of it anyway and it�s just so much more flexible

# ? Feb 17, 2024 09:34

Nomnom Cookie: Aug 30, 2009

eschaton posted:

NT should have implemented an equivalent to the Common Lisp condition system in the kernel and userspace, all the other mechanisms are really subsets of it anyway and it�s just so much more flexible

do whatever the gently caress you want as long as its in the ABI doc imo

# ? Feb 17, 2024 20:36

Nomnom Cookie: Aug 30, 2009

putting the stable ABI in userspace is something windows got extremely right and linux completely hosed up btw. the only reason linux does it that way is because that's linus's span of control and its better than nothing, but putting that strict of a back compat requirement on how many syscalls you make and what they do is a terrible idea

# ? Feb 17, 2024 20:39

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

macOS puts the stable kernel ABI in user space too, I believe. you have to use the stdlib, there�s no supported direct syscall interface

# ? Feb 17, 2024 21:17

redleader: Aug 18, 2005; Engage according to operational parameters

that's because macos also has linux brain

# ? Feb 17, 2024 22:55

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

didn't the go team have to figure that out the hard way about macos

where by "hard" I mean they could've looked it up or asked, but instead just did whatever because they�re special

# ? Feb 18, 2024 01:02

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

redleader posted:

that's because macos also has linux brain

no, it has the opposite, whatever that is (reliable suspend?)

# ? Feb 18, 2024 01:16

invlwhen: Jul 28, 2012; please do your best

eschaton posted:

NT should have implemented an equivalent to the Common Lisp condition system in the kernel and userspace, all the other mechanisms are really subsets of it anyway and it�s just so much more flexible

https://web.archive.org/web/20030218034509/http://www.research.microsoft.com/research/dtg/davidhov/pap.htm

# ? Feb 18, 2024 01:32

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

invlwhen posted:

https://web.archive.org/web/20030218034509/http://www.research.microsoft.com/research/dtg/davidhov/pap.htm

quote:

Given a correct Registry, the system runs correctly.

well then!

# ? Feb 18, 2024 01:34

BobHoward: Feb 13, 2012; The only thing white people deserve is a bullet to their empty skull

redleader posted:

that's because macos also has linux brain

er, no? at least not with respect to this

the linux kernel ABI is explicitly stable. linus torvalds personally shits all over everyone who tries to introduce patches which break it. applications can do direct syscalls in complete saftey, they'll still work 20 years from now if torvalds is still alive and running things

the macos kernel ABI is explicitly unstable. want to make a syscall? go through libSystem or one of the other system libraries apple ships alongside the kernel. if you try to make a direct syscall you do so at your own risk, the kernel's ABI can and does change without notice

# ? Feb 18, 2024 02:28

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

pokeyman posted:

didn't the go team have to figure that out the hard way about macos

where by "hard" I mean they could've looked it up or asked, but instead just did whatever because they�re special

they assumed syscalls were a stable abi because they�re stable on linux, yes. and then they based the goroutine implementation design around the idea that calling into c was relatively unimportant because they could wrap everything above the syscall layer in pure go

# ? Feb 18, 2024 03:37

Nomnom Cookie: Aug 30, 2009

only the smoothest brains on our golang boys . spikes slide right off and we go straight to shipping

# ? Feb 18, 2024 05:12

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

�Jony, SHUT THE gently caress UP! It's a feature alright - in the kernel. If a change results in user programs breaking, it's a feature in the kernel!� -timb

# ? Feb 18, 2024 05:21

Kazinsal: Dec 13, 2011

for anyone curious as to how by-design unstable the direct syscall interface for windows is, go here https://j00ru.vexillium.org/syscalls/nt/64/ and click "show all"

some of those syscall numbers change every release

# ? Feb 18, 2024 05:25

Nomnom Cookie: Aug 30, 2009

rjmccall posted:

they assumed syscalls were a stable abi because they�re stable on linux, yes. and then they based the goroutine implementation design around the idea that calling into c was relatively unimportant because they could wrap everything above the syscall layer in pure go

i already thought of golang as the just ship it language based on the ecosystem so learning this about the golang team has hardened that bias into rock solid prejudice. i will never again be able to conceive of a golang developer wanting to know what will happen before they ship when they could ship instead

# ? Feb 18, 2024 05:26

Adbot: ADBOT LOVES YOU

# ? Jun 12, 2024 15:51

Nomnom Cookie: Aug 30, 2009

Kazinsal posted:

for anyone curious as to how by-design unstable the direct syscall interface for windows is, go here https://j00ru.vexillium.org/syscalls/nt/64/ and click "show all"

some of those syscall numbers change every release

they should be randomized at boot specifically to gently caress with people who think theyre hardcore and don't want microsoft interfering with their god given right to assemble whatever horrible mess of SYSCALL instructions they desire into an exe

# ? Feb 18, 2024 05:29

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »