Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

C Meeting adjourned.

Uncategorized
12 9 1
  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd you deserve everything. i'm so sorry it's like this

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd ooof, that sounds super rough /∆\ sorry yo, hopefully there's some avenue for improvement? (or escape)

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd Well this is all kinds of rough...

  • @thephd Well this is all kinds of rough...

    @thephd On some level, i sympathize with demands for implementation & use experience; c++ definitely suffered during the aughts because a bunch of features got adopted without *any* implementations (and that is generally a bad idea).

    Back then, when the time came for a vote on adopting a new feature, Clark Nelson was the only person who consistently asked, "has it been implemented?", and voted against if the answer was "no".
    [...]

  • @thephd On some level, i sympathize with demands for implementation & use experience; c++ definitely suffered during the aughts because a bunch of features got adopted without *any* implementations (and that is generally a bad idea).

    Back then, when the time came for a vote on adopting a new feature, Clark Nelson was the only person who consistently asked, "has it been implemented?", and voted against if the answer was "no".
    [...]

    @thephd
    These days, i would want someone asking, "has it been taught, and did someone observe coders using it?", which seems much more doable in the age of twitch & other live streaming services.

    (That is definitely a much bigger ask for proposal authors, but it should yield more polished designs.)

  • @thephd
    These days, i would want someone asking, "has it been taught, and did someone observe coders using it?", which seems much more doable in the age of twitch & other live streaming services.

    (That is definitely a much bigger ask for proposal authors, but it should yield more polished designs.)

    @thephd That said, the idea that vendors want to block all new features *regardless* of implementation experience is... very strange. In the long run, it seems counter to their interests...?

    I don't know what to make of it.

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd frustrating experience to go through, sorry it all ended up going that way 🫂

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd A friend of mine recently showed a proposal about variadic macros, that you had invited her to a C standard meeting over. Was that thing shelved again too ?

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd closures seem like a pretty obvious feature and I'm surprised C still doesn't have them natively after all these years
    We got compile-time type inference before we got closures, somehow

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd thank you for fighting for people who want to write C like it's no longer the 90s

  • C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

    Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.

    -- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.html

    Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.

    All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.

    I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.

    But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.

    Maybe I'll be a more effective advocate next meeting. Who knows.

    I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.

    Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.

    Brutal to have to live with it and deal with.

    I'll figure something out, eventually.

    @thephd urgh, rough, sorry ypu have to deal with that

  • oblomov@sociale.networkundefined oblomov@sociale.network shared this topic on

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @dmoonfire @FranklinFrank anyone can write bad code, even ai! 😆

    What's going on is, people start giving work to ai thinking it gives back tested code
    Like being relieved from working at all, ai gives that delusion
    What will happen is, we'll be relieved from working, but from getting money too

    read more

  • @tarta Questa è una striscia a fumetti italiana composta da tre vignette, con uno sfondo giallo chiaro. La vignetta superiore mostra un pendio boscoso con un sentiero tortuoso, e contiene il testo: "NELLE ULTIME SETTIMANE HA PIOVUTO MOLTO E I SENTIERI SULLA COLLINA DIETRO CASA SI SONO RIEMPITI DI FANGO." La vignetta centrale raffigura una persona e un cane ricoperti di fango; la persona chiede: "C'ERA FANGO SUL SENTIERO?" mentre il cane risponde: "FORSE-". La vignetta inferiore mostra la stessa persona e lo stesso cane in piedi su fango solidificato, etichettato "FANGO SOLIDIFICATO", con il testo: "MERCOLEDÌ HO FATTO L'ERRORE DI FERMARMI A GUARDARE IL PANORAMA E SIAMO SUBITO DIVENTATI DEI PERSONAGGI DEL SUBBUTO." Inoltre, la vignetta centrale include il testo: "LUNEDÌ SIAMO TORNATI A CASA CON PARECCHI CHILI DI FANGO ATTACCATI AGLI STIVALI E ALLE ZAMPE."

    Una striscia a tre vignette con testo in italiano raffigura personaggi dei cartoni animati in situazioni fangose. La vignetta superiore mostra un personaggio in piedi su un mucchio di fango vicino a un cancello, che sta parlando con un robot; le caselle di testo recitano: "VENERDI LA QUANTITÀ DI FANGO ACCUMULATA SOTTO GLI STIVALI È DECUPLETA" e "ORA COME FACCO A INFISSARE LA CHIAVE NELLA SERRATURA?". La vignetta centrale presenta un personaggio che tiene in braccio una creatura simile a un maiale e una lumaca, entrambi nel fango, con un testo che dice: "INVECE DOMENICA IO E LA CANA ERAMO COSI SPORCHI DI FANGO, CHE PER ERRORE HO MESSO PETTORINA E GUINZAGLIO A UN CINGHIALE INFANGATO E DI PASSAGGIO" e "INSOMMA, LUCY! COSA SONO TUTTE QUESTE STORIE PER TORNARE A CASA?" insieme agli effetti sonori "SQUECH SQUECH". La vignetta inferiore ha uno sfondo verde, un personaggio che tiene una scopa vicino a un cancello, e un testo che dice: "PER FORTUNA LA CANA HA TROVATO DA SOLA LA STRADA DI CASA" con gli effetti sonori "DRIIIIIN", "SNORT...", e "TAATATATTI". Tutte le vignette utilizzano un disegno a linee semplici su sfondi marrone chiaro o verde per mostrare ambienti fangosi con dialoghi ed effetti sonori.

    Fornito da @altbot, generato localmente e privatamente utilizzando Qwen3-Vl:8b

    🌱 Energia utilizzata: 1.647 Wh

    read more

  • read more

  • read more

  • Le passeggiate fangose delle ultime settimane.

    read more

  • Inflazione elettrica, minaccia per l’AI-merica

    L'inflazione elettrica, spinta soprattutto dai data center, sarà sempre più centrale per gli esiti elettorali statunitensi. La Cina invece pare non avere problemi di colli di bottiglia. E l'Italia? Buona fortuna

    https://phastidio.net/2026/02/18/inflazione-elettrica-minaccia-per-lai-merica/

    read more

  • Moldavia: la “strategia di sopravvivenza” contro l’assedio della guerra ibrida russa


    @news
    L’11 giugno 2025, l’aeroporto internazionale di Chișinău non sembrava un normale scalo europeo, ma un’arena di scontro politico. Tra urla e spintoni contro la polizia di frontiera, decine di passeggeri appena rientrati da Mosca hanno trasformato l’area arrivi in un

    read more

  • read more
Post suggeriti