>>103600977
that's called pragraphs, nigger>>103600810
I need it because coroutines are basically continuations anyway, might as well do the entire thing.

>Isn't it the opposite? that you can more easily copy the stack if it's in the heap?

That's right but the problem is primitive functions implemented in C won't get captured by a continuation even if I have a virtual machine with an explicit stack, and if I find a way to capture it I can just capture the whole evaluator state without bothering with a machine and manual stack management.

if (is_fn(car(expr)))
    fn = car(expr)
    args = cdr(expr)
    for all args, args[i] = eval(args[i])
    env = nest(env)
    for all variables, bind(env, variable_names[i], args[i])
    for all expr in fn.body, eval(expr)
if (is_primitive(car(expr)))
    // eval args
    primitive.func(env, args)  // C function call with C stack

The primitive function call on the native stack can't be captured. At least not without some heavy wizardry?

>That's the kind of stuff you need to do in assembly.

That's fine. I was hoping someone would have done this before so I could read and study source code.

>You could maybe memcpy the C stack from C

That's my idea.

>but you need to fiddle in the dark about the start and end of the section you need to copy.

Yeah. My idea is to use some GCC builtins to get the frame pointers when delimiting and when capturing, and using those. I'll also need to save many of the registers according to platform ABI.

>Besides, you need to modify RSP and RBP anyway.

Those are all trivial... I'm worried about pointers into the stack. Looks like I'll need to scan the entire stack like an array of longs and update everything that falls within range to point at the new values somehow. This looks wrong>>103567993
>>building Flutter
stopped reading there>>103601737
I will make a ton of Linux desktop apps in Flutter and there's nothing you can do to stop mevulkan sure has some gems

VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT

>>103602393
>what if we let our zoomer OOP fag juniors design our C API.
>what could go wrong?>>103602438
behold

VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT

>>103601733
>the problem is primitive functions implemented in C won't get captured by a continuation even if I have a virtual machine with an explicit stack
Right, I hadn't thought of that. That's the kind of thing that make you think that writing a native compiler is easier in the long run than writing a virtual machine. So much friction everywhere.

I don't really understand continuations. But if what you need to do when creating a continuation, is copy the entire "logiacl" stack from the current function until the bottom of the stack, VM stack and C stack alike, I guess you could do it like this basically:

at the first call to the C function of your interpreter, save RSP in the VM struct as the bottom of the stack
when you make native calls the C stack will grow
when you need to do the copy, you copy your heap stack somewhere and you copy the C stack from the current RSP until the "bottom" RSP, and also saved the current RSP as well as every register
then lisp code is evaluated and mutate the stack. when you need to restore the stack, you copy the heap stack that you saved and you copy the saved C stack bytes in between the "bottom" RSP and the saved current RSP at the time you copied the stack, then restore the registers

>I'm worried about pointers into the stack.
I'm trying to think of a problem but can't find one. If you do the thing I've written above, after saving the stack and after restoring it, anything put on the stack by native code will be stay in place or respectively be moved back at the same place, there is no relocations. It's not the same situation as a moving GC. If you moved back the native frames somewhere else and resumed execution, that would be a problem because there could be heap allocated objects, local variables or registers containing pointers to the old place where the frames used to be.this is a PENIS number generator...

unsigned int r( unsigned long long int *s ){
 *s += 1;
 unsigned long long int x = ((*s * 0xbfad23521) ^ (*s * 0xfeefbaaf));
 x = ((x >> 3) ^ (x << 7)) * (1 | (*s ^ 0x16716761));
 return x ^ (x >> 32);
}

>>103598146
Option 2.
As a consumer, I very likely will have to handle different topics in different ways and having callbacks dedicated to it instead of some sort of switch case filtering the topics is annoying.

>Down side is we need to set up and maintain many topics and that number will grow over time
my gut says the same problem exists in 1. You'll still have to maintain some sort of topic identifier so your consumers can discard what they dont care aboutWhat are some non-trivial projects I can do entirely in Compiler Explorer? (only inputs are command line arguments and non-interactive stdin, only outputs is stdout, stderr, and exit value). So far my only idea is a glob/regex matcher.>>103593244
Try having a project with more than one source file and build configs.
AI at its current state can't take into account your project/API/lang version, build system, whole project context, current issue/goal.
Until you can tell AI (simple diagnostic. yes, simple): "why is X clipping", "fix indefinite loop when doing x", "find and fix any issues in path management in argument handling or file/folder loading if there were to be a space or non-latin lang characters or malicious relative paths and give a report about the changes using asciidoc"
Or (generative): "add contact us menu item to the About menu button, using the program global style and have it display a popup of our social media found at "class name" which provides emails and social media name plus description, link, and icon. add a friendly intro/welcoming message and our logo on top to explain when and why to contact us. Extract the embedded resources using {res} class"
Until then, AI is no more than technical debt and a shitty rubber duck that costs money where you put more effort into feeding the context until you figure it out yourself while typing.
It's great at pasting snippets, I'll give it that. Too bad that's not enough to justify the massive slow down in my workflow or sending my code to microcock and big AI just to optimize a regex pattern.>>103567216
Any anons with android experience? what should I start with if I want to write an application, views or jetpack compose? From the little bit of research I did jetpack seems to be the current thing and google is pushing it hard. However, UI and code being mingled together, I don't know, just feels wrong. I guess it's just a habit from GTK, where ui definition and code were separated.>>103605772
>non-trivial projects I can do entirely in Compiler Explorer
none
>glob/regex matcher
that's hardly non-trivial>>103591048
No. AI is complete shit at coding. If you can use AI to do your entire job then a shitty pajeet could've done your job years ago.>>103607333
Unironically a web interface with a native shell that communicate via a JS channel or navigation handler or special url handler is good enough for most needs.
When was the last time you used a native looking app with a bunch of native buttons and checkboxes that wasn't from f-droid or a built-in app?

Installing a 1 GB (compressed) IDE, another GB for SDK, another GB for an older SDK, another GB for a future SDK
Learning to use the IDE, only to have it change fundamentally the next update
Learning the build process (won't happen KEK)
Getting depressed over animations
Updating library versions
Writing code in a specific way because of years of 'fixing' attempts to corelibs
What you see is not what you get
Different screen sizes

Hell no. Not in a 'native' android way.

/dpt/ - Daily Programming Thread

What are you working on, /g/?Previous thread: >>103521394

< Go back

What are you working on, /g/?

Previous thread: >>103521394