awful programming: feature flags and suffering

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1115 »

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Beamed posted:

god, don't work with rust futures yet

i've worked with them quite a bit already, and the company i'm contracting for uses futures .1. plus i'm just kinda interested in tracking the development.

obviously i wouldn't do it for a professional thing but i'm fine with it for a toy project.

thinking about it more, i'm not sure that futures are what i need. i think if i went that route i'd need to integrate the event loop into the "cpu." which would be a good exercise but also a big distraction. i'm having a hard time modeling it so i think i should just proceed synchronously and switch to threads when i need it.

DONT THREAD ON ME fucked around with this message at 18:34 on Aug 18, 2018

# ? Aug 18, 2018 18:03

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 10:35

Workaday Wizard: Oct 23, 2009; by Pragmatica

futures make me feel dumb. the theory is very simple but in practice the many layers of futures and closures make my brain freeze. the worst thing for me is trying to figure out how to deal with cancellation, failure, or early termination.

i can�t wait for async!/await!

# ? Aug 18, 2018 18:56

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

Schadenboner posted:

Mind you, I don't especially want to be a programmer

you have learnt everything you need

# ? Aug 18, 2018 18:58

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

vs 2017 (and maybe earlier versions I don't remember) tries to remove "this" from references as being redundant and I hate it because I always want it to be explicitly clear what's being done. like yeah OK intellisense will tell you but I gently caress myself up with this stuff so why make it harder?

# ? Aug 18, 2018 19:30

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Shinku ABOOKEN posted:

futures make me feel dumb. the theory is very simple but in practice the many layers of futures and closures make my brain freeze. the worst thing for me is trying to figure out how to deal with cancellation, failure, or early termination.

i can�t wait for async!/await!

it helps a lot to have worked with them a good deal in other languages.

failure is simple: you simply map or flat map over your future the way you might map over Result or Option. It's exactly the same as those two cases and it's where futures are really shine.

Of course if you always deal with Option/Result by using match then this won't be as familiar.

Cancellation and early termination (not sure what you mean by early termination exactly) are a lot harder and not really something I've dealt with, Scala futures didn't support cancellation. I think futures in general don't handle this concept cleanly.

# ? Aug 18, 2018 19:34

Shaggar: Apr 26, 2006

cancellation is super easy you just check the cancellation token and/or register a method on the token to fire when cancellation is requested.

# ? Aug 18, 2018 19:39

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?

Symbolic Butt posted:

I don't recall if it goes through historical stuff like lisp-2 namespaces, but it definitely puts you into a place to understand what tef is rambling about

Lisp-1 vs Lisp-2 isn�t that big a deal

in a Lisp-2, the same symbol can have a variable binding and a function binding, eg

code:

(defun foo () nil)
(setf foo t)

will give foo two values�a function that returns nil, and the value t�and which one you get when evaluating foo depends on context

a Lisp-1 behaves like you�d expect from other languages where foo would only have one binding, the value t

a few people insist that to be a Lisp is to be a Lisp-2, everyone else just rolls their eyes

Common Lisp and emacs Lisp are Lisp-2 while Scheme and Dylan are Lisp-1, so it�s obviously not all that constraining

# ? Aug 18, 2018 19:48

Ellie Crabcakes: Feb 1, 2008; Stop emailing my boyfriend Gay Crungus

Lisp is for sex perverts and communists.

# ? Aug 18, 2018 19:53

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

sounds good to me

# ? Aug 18, 2018 19:54

Ellie Crabcakes: Feb 1, 2008; Stop emailing my boyfriend Gay Crungus

Not like regular sex perverts who like to dress up like nuns and have their balls stepped on. Like, seriously dark "dead chicken and entire Menudo discography" sex perverts

# ? Aug 18, 2018 19: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?

MALE SHOEGAZE posted:

so i'm working on generating interrupts for my emulator now. i can implement it synchronously and i'm sure it will work fine, but i'm very tempted to run the cpu in its own thread and send interrupts to it. this seems to better match how the machine would actually work. am i right here or am i just making excuses to play with futures?

does Rust or the platform you�re running on support something like queues or thread pools? those would be an even better choice than parking the CPU on a thread

then you could run every emulated device on its own queue or thread as well

# ? Aug 18, 2018 20:09

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Shaggar posted:

cancellation is super easy you just check the cancellation token and/or register a method on the token to fire when cancellation is requested.

i don't think i'm really sure what we're talking about.

if we're talking about cancelling a future from the consumer end, e.g,

code:

val future1: Future = { ... }
val future2: Future = { ... }

if future1.isCancelled()  {  // or some other reason to cancel future2
   future2.cancel() // you can't do this with a future
}

That's not really a future, that's more of a promise.

However, if you have a reference to the promise that created the future, or some other mechanism for controlling the output of the future, then yes, you can cancel it, and then the future will resolve to an error which you handle monadically.

eschaton posted:

does Rust or the platform you�re running on support something like queues or thread pools? those would be an even better choice than parking the CPU on a thread

then you could run every emulated device on its own queue or thread as well

yep that's what i meant. i need to take a break and figure out how i want to handle IO. Rust has facilities for drawing a basic window and accepting keyboard input but it might be more interesting to to _just_ do the CPU in Rust and maybe ffi into it from a language with better support for UI stuff (ie swift).

DONT THREAD ON ME fucked around with this message at 20:50 on Aug 18, 2018

# ? Aug 18, 2018 20:47

Shaggar: Apr 26, 2006

cancellation tokens are a c# thing

# ? Aug 18, 2018 20:51

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

like, it's not as if a future or a promise or whatever has a strict definition so it's kinda hard to discuss this stuff. some futures you can probably cancel but that wouldn't be a future to me.

DONT THREAD ON ME fucked around with this message at 21:03 on Aug 18, 2018

# ? Aug 18, 2018 20:59

Mahatma Goonsay: Jun 6, 2007; Yum

so are futures kind of like promises in js?

# ? Aug 18, 2018 21:12

FlapYoJacks: Feb 12, 2009

Powerful Two-Hander posted:

vs 2017 (and maybe earlier versions I don't remember) tries to remove "this" from references as being redundant and I hate it because I always want it to be explicitly clear what's being done. like yeah OK intellisense will tell you but I gently caress myself up with this stuff so why make it harder?

You're in a class, you don't need "this".

# ? Aug 18, 2018 21:21

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Mahatma Goonsay posted:

so are futures kind of like promises in js?

honestly i'm not sure. they are related and have similar apis but the semantics could be totally different. js is single threaded but afaik the browser can handle asynchronous requests so i have no idea what that means for javascript promises.

in scala, promises are like the producer end of a future, and a future is in fact a subclass of promise. so you create your promise, setup the success/failure/cancellation/whatever handlers, and then that becomes a future. the main difference imo is that a future cannot be manipulated directly, you can map over it and produce new values but you can't go back and cancel it or alter it.

however, scala also has concepts like the IO monad which are a lot like futures but different importantly in that an IO is not run until "the end of the world", wheras a future will be executed immediately in a thread pool. completely different semantics but mostly identical api.

# ? Aug 18, 2018 21:29

Beamed: Nov 26, 2010; Then you have a responsibility that no man has ever faced. You have your fear which could become reality, and you have Godzilla, which is reality.

Mahatma Goonsay posted:

so are futures kind of like promises in js?

not in terms of how you interact with them at all, either ES6 promises or deferreds.

especially working with Typescript and C# so much at work, going home to Rust futures feels.. clunky.

# ? Aug 18, 2018 22:54

Fiedler: Jun 29, 2002; I, for one, welcome our new mouse overlords.

Powerful Two-Hander posted:

vs 2017 (and maybe earlier versions I don't remember) tries to remove "this" from references as being redundant and I hate it because I always want it to be explicitly clear what's being done. like yeah OK intellisense will tell you but I gently caress myself up with this stuff so why make it harder?

that's one of the configurable style options. just pick the style you want and then have vs fix it everywhere for you automatically.

# ? Aug 18, 2018 23:33

suffix: Jul 27, 2013; Wheeee!

MALE SHOEGAZE posted:

so i'm working on generating interrupts for my emulator now. i can implement it synchronously and i'm sure it will work fine, but i'm very tempted to run the cpu in its own thread and send interrupts to it. this seems to better match how the machine would actually work. am i right here or am i just making excuses to play with futures?

from what i've heard - although having a separate cpu thread that gets interrupts and accesses peripherals would be a reasonable design in theory, in an emulator you eventually end up with specific timing requirements to match the real hardware, like hsync interrupts that must happen with cycle perfect timing interlaced with the screen drawing, so it's easier to do everythin in one thread

# ? Aug 18, 2018 23:58

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

MALE SHOEGAZE posted:

tail call elimination is apparently an unsolved/potentially unsolvable problem w/r/t lifetimes/borrowing so fully embracing functional would probably be a bit weird.

but i agree. i want the language to succeed since i'm investing in it. member functions are probably the part of OOP people actually want, (even though they're orthogonal to OOP), and rust provides them without most of the bad stuff. it seems like a reasonable tradeoff to me.

tail call elimination is blocked by the llvm calling convention they picked, i thought?

# ? Aug 19, 2018 00:06

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

ratbert90 posted:

You're in a class, you don't need "this".

i know but I like it being there. idk it's like it's making it more explicit or something. also yes you should know you're inside a class but when the application mixes class and static methods at random it's kind of helpful.

full disclosure:a good chunk of that random mixing is due to me depending on either a) how much I knew what I was doing at the time because I make poo poo up as I go along and b) whatever I thought made sense for that particular day of the week

basically I'm terrible.

# ? Aug 19, 2018 00:07

FlapYoJacks: Feb 12, 2009

Powerful Two-Hander posted:

i know but I like it being there. idk it's like it's making it more explicit or something. also yes you should know you're inside a class but when the application mixes class and static methods at random it's kind of helpful.

full disclosure:a good chunk of that random mixing is due to me depending on either a) how much I knew what I was doing at the time because I make poo poo up as I go along and b) whatever I thought made sense for that particular day of the week

basically I'm terrible.

instead of �this� you could just adopt a case convention.

# ? Aug 19, 2018 00:11

tinaun: Jun 9, 2011; tell me...

case conventions suck because i want all my identifiers written in non latin scripts

# ? Aug 19, 2018 00:29

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

ratbert90 posted:

instead of “this” you could just adopt a case convention.

i know what you're saying is all correct but let me just wallow in my own filth here ok?

# ? Aug 19, 2018 00:33

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

also jfc I can't remember a case convention anyway because the brain cells I had for that died years ago along with the ones that could do proper algebra

# ? Aug 19, 2018 00:41

FlapYoJacks: Feb 12, 2009

Powerful Two-Hander posted:

i know what you're saying is all correct but let me just wallow in my own filth here ok?

Strive to be better.

# ? Aug 19, 2018 00:43

Progressive JPEG: Feb 19, 2003

Shinku ABOOKEN posted:

futures make me feel dumb. the theory is very simple but in practice the many layers of futures and closures make my brain freeze. the worst thing for me is trying to figure out how to deal with cancellation, failure, or early termination.

i can�t wait for async!/await!

you are the main thread and you're asking friends for help with things youre working on
the friends go off and figure it out on their own then the result is made available once they're done

sometimes those friends ask their friends to help out
other times you tell them nevermind and to stop what they're doing
and occasionally they come back and say that they couldn't do that thing after all

# ? Aug 19, 2018 01:22

Progressive JPEG: Feb 19, 2003

this analogy breaks down when you start thinking about worker pool configuration but close enough

# ? Aug 19, 2018 01:23

Workaday Wizard: Oct 23, 2009; by Pragmatica

what if i die before a friend comes back though?

# ? Aug 19, 2018 01:32

Schadenboner: Aug 15, 2011; by Shine

Shinku ABOOKEN posted:

what if i die before a friend comes back though?

That poor dog just loved Fry so much.

:cry:

# ? Aug 19, 2018 03:54

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

the talent deficit posted:

tail call elimination is blocked by the llvm calling convention they picked, i thought?

ah, i was reading an outdated RFC. looks like you're right. what I'd read previously was something from Graydon saying that TCE was possibly incompatible with lifetimes/borrowing. but perhaps things have evolved.

looks like state of the art is here: https://github.com/rust-lang/rfcs/pull/1888. postponed, looks kinda indefinite to me, but not because it's impossible

suffix posted:

from what i've heard - although having a separate cpu thread that gets interrupts and accesses peripherals would be a reasonable design in theory, in an emulator you eventually end up with specific timing requirements to match the real hardware, like hsync interrupts that must happen with cycle perfect timing interlaced with the screen drawing, so it's easier to do everythin in one thread

yeah i was kinda worried about that. i'm pretty torn on implementations. the threaded model gets me more excited so imna run with that for now.

DONT THREAD ON ME fucked around with this message at 11:56 on Aug 20, 2018

# ? Aug 20, 2018 11:37

gonadic io: Feb 16, 2011; >>=

MALE SHOEGAZE posted:

yeah i was kinda worried about that. i'm pretty torn on implementations. the threaded model gets me more excited so imna run with that for now.

You could also incorporate different threads into your execution state model directly instead of having the running code run threads natively

# ? Aug 20, 2018 12:17

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

gonadic io posted:

You could also incorporate different threads into your execution state model directly instead of having the running code run threads natively

i think this is maybe a bit like integrating the futures executor directly into the cpu loop, which is the model i'm considering atm. the idea being that when the "machine" (which i'm separating from the CPU) issues interrupts to the cpu, the cpu returns a future which is fulfilled when the interrupt is complete. which i think makes sense conceptually but since an interrupt request will be processed as soon as the currently executing instruction completes (on the 8080 at least) it's pretty major overkill.

e: i'm way overcomplicating this and just need to proceed with the dang tutorial.

DONT THREAD ON ME fucked around with this message at 12:51 on Aug 20, 2018

# ? Aug 20, 2018 12:35

gonadic io: Feb 16, 2011; >>=

MALE SHOEGAZE posted:

i think this is maybe a bit like integrating the futures executor directly into the cpu loop, which is the model i'm considering atm. the idea being that when the "machine" (which i'm separating from the CPU) issues interrupts to the cpu, the cpu returns a future which is fulfilled when the interrupt is complete. which i think makes sense conceptually but since an interrupt request will be processed as soon as the currently executing instruction completes (on the 8080 at least) it's pretty major overkill.

i meant more having your state be

struct State { machine: Machine, cpu: Cpu }
struct Cpu { running_interrupt: Option<InterruptState> }

i.e. having no processing happening between explicit state transitions

e: I guess wrapping it in a future and then having your futures executor be in your run loop would be the same thing since the future is just codified state without the executor doing anything

# ? Aug 20, 2018 12:53

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

gonadic io posted:

i meant more having your state be

struct State { machine: Machine, cpu: Cpu }
struct Cpu { running_interrupt: Option<InterruptState> }

i.e. having no processing happening between explicit state transitions

e: I guess wrapping it in a future and then having your futures executor be in your run loop would be the same thing since the future is just codified state without the executor doing anything

ah yeah, gotcha. i've been avoiding that design intentionally because i'm trying to get comfortable with non-functional approaches

# ? Aug 20, 2018 13:05

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

you know you're in for a good day programming when you open up the code you need to debug and the first thing you see is

code:

result = None
for key, value in data.items():
    if key == 'butt':
        result = value
if result:
    result.poop()

# ? Aug 20, 2018 20:04

JawnV6: Jul 4, 2004; So hot ...

if you get an interrupt and have a long-running instruction pending retirement, do you blow it out intending to re-execute or delay the interrupt until all pending instruction boundaries retire?

# ? Aug 20, 2018 20:14

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

JawnV6 posted:

if you get an interrupt and have a long-running instruction pending retirement, do you blow it out intending to re-execute or delay the interrupt until all pending instruction boundaries retire?

From the 8080 book:

quote:

When the CPU recognizes an interrupt request from an external device, the following actions occur:

(1) The instruction currently being executed is completed.
(2) The interrupt enable bit, INTE, is reset =O.
(3) The interrupting device supplies, via hardware, one instruction which the CPU executes. This instruction does not appear anywhere in memory, and the programmer has no control over it, since it is a function of the interrupting device's controller design. The program counter is not incremented before this instruction.

So we delay the interrupt.

# ? Aug 20, 2018 20:39

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 10:35

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

this thread made me look into that emulator101.com page and now im designing UIs for a debugger in ANSI C.

thx, thread

# ? Aug 20, 2018 20:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1115 »