Notices by pistolero (p@fsebugoutzone.org), page 2
-
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Thursday, 21-Nov-2024 10:06:16 JST pistolero @Yoruka @ins0mniak If you wanna repeatedly do that riddle about the two gatekeepers that always lie and one that always tells the truth, maybe. Apparently it has no trouble making shit up, I've seen it do that.
It's not even really useful as a duck because it will argue your premise instead of helping you, even if you want it to help you think something through. I tried to poke it when someone had hooked it up to a bot here, right? So I asked it about the loli question, it told me that it depends on what the rules decided by the community were, I said I set the rules, it told me to ask a mod, I told it that I run the site, it just refused to help in any capacity. I ran the Facebook LLaMA locally, it dutifully produced useless babble at me the same as any other chatbot. I would really like for it to be useful but I haven't seen it yet. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Thursday, 21-Nov-2024 10:06:14 JST pistolero @Yoruka @ins0mniak
> I use it to train my vocabulary in English sometimes
That's actually a pretty good use, I think.
> it does always fail me when I ask about coding in Assembly or C.
Trained on Python/JS, so as expected. A non-coder asked it to make her some SVG and it wouldn't even produce syntactically correct XML. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Thursday, 21-Nov-2024 10:06:13 JST pistolero @sysrq @Yoruka @ins0mniak :chad: -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Thursday, 21-Nov-2024 09:52:11 JST pistolero @GhostOfMoshe @JustViolet @UnCL3 @cosmonautkatyusha @dcc @diejewdie @lolocaustianity @rrandy @william_travis IT'S TIME :streetshitter420::cofe::hulk:
This is excellent, speedy. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Thursday, 21-Nov-2024 06:05:26 JST pistolero @lanodan @Yoruka @ins0mniak Oh, yeah, I mean, you could do a dependency tree in awk. You could possibly translate a makefile into a shell script with sed. mk is nicer, but I don't think that'd be hard to reimplement if you had to. The only trick would be wildcard targets, right, like GNU make has globbing and mk has regex targets. Worst-case, I think the 90-95% case for most makefiles, you implement in a page of Perl.
I read an interview with Bill Joy some years back (and it was decades-old at the time) and someone was asking him what he thought about makefiles and he said that it was the stuff that used to be written down and tacked to the wall next to the machine, so it was good to have it in a file for distribution. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Thursday, 21-Nov-2024 05:56:29 JST pistolero @snacks @ins0mniak @knapjack @lanodan @lonelyowl13 @vic I would like to be helpful but I had the same experience as everyone else. I think the rule of thumb is more or less the opposite of how you do it with a regular function: with `f(x,y)`, you want x to be the parameter that changes least often, so for `y x f`, you want to define f such that the top of the stack is the least likely to change. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:54:50 JST pistolero @Yoruka @ins0mniak
> its cargo system which is very convenient
I must have been using a different cargo system for Rust. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:54:48 JST pistolero @Yoruka @ins0mniak Only if your model of writing a makefile is based on the GNU toolchain and autotools. Ten or fifteen lines of build targets versus an entire terrible rubygems-like monster, and then dependency hell? I mean, I had to uninstall Rust and reinstall it because the new version couldn't cope with the old version being installed at build-time and if I didn't have the new version, cargo fucked itself, and if I couldn't get cargo to stop fucking itself, then I couldn't get Firefox to build. It's like an ouroboros combined with the human centipede. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:50:54 JST pistolero @phnt @djsumdog @ins0mniak @vic Basically any language is memory-safe. Elixir is memory-safe, bash is memory-safe, awk is memory-safe, Ruby, Python, Perl. Very few CVEs are memory-safety-related any more anyway. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:20:51 JST pistolero @phnt @NonPlayableClown @djsumdog @ins0mniak @teratology @vic
> Yeah, someone that does statistics and does not use R is an instant red flag.
Seconded. Even I had to learn a little R. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:18:55 JST pistolero @lanodan @ins0mniak @lonelyowl13 @vic
> Can't you ignore win32 with something like cygwin though?
If you want to ship cygwin.dll with your code, yeah. That tends to be frowned on. I don't know if WSL does some voodoo to make it work, but Windows has a lot of subtle incompatibilities in their sockets library.
> (And also get make that way, or grab plan9port for mk)
If I was grabbing plan9port anyway, I'd just make the code use dial instead of sockets. (Berkeley sockets were a mistake and we will never stop paying for them.) -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:15:54 JST pistolero @lanodan @ins0mniak @knapjack @lonelyowl13 @vic
> Like pretty sure I could jump into Ruby real fast, after all quite worked like that for Elixir and Perl to me.
Yeah, they're pretty similar in terms of primitive operations and how you architect your programs. (I was actually kind of disappointed that the structure of an Elixir program looked so close to Ruby. Erlang is weird; Elixir is not weird.) -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:13:58 JST pistolero @lanodan @ins0mniak @lonelyowl13 @vic
> even though it kind of seems to push Plan9-isms on everyone
Ha, it feels too Linux-y to me!
> but I meant just stuff like creating binaries for {x86_64,arm32,arm64}-{linux,windows} rather easily,
That is what I meant also, except {x86_64,arm32,arm64}-{linux,windows,plan9}.
> which seems doable in C without code changes but getting all those targets to work can be quite a chore.
You end up with #ifdefs and a stupid build system and coping with all the stupid winsock idiosyncrasies. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:12:07 JST pistolero @lanodan @ins0mniak @knapjack @lonelyowl13 @vic Like, really, it's about as natural as pipes. It's almost an implicit pipe. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:06:40 JST pistolero @lanodan @knapjack @ins0mniak @lonelyowl13 @vic
> I've yet to be comfortable with the stack-based paradigm of Forth,
It's really not as hard as it looks. You just write a lot of Forth for a couple of months, and suddenly it seems way easier than anything else. You don't have to name anything, you know? "Take this, do this, then do this", it comes out easy to write and easy to read. Forth people report that they used to do a lot of stack-manipulation when they started, lots of dup over rot swap, but then after a while you notice that your code requires almost none, and at least empirically, I can say that is the case: you don't plan it, just you get used to the language and then everything starts being on the stack in the place where you need it to be. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 17:00:41 JST pistolero @lanodan @ins0mniak @lonelyowl13 @vic
> usually it boils down to the toolchain not being gnu+ass when you want to cross-compile.
This is actually exactly the reason Revolver is Go instead of C: it was the easiest option if I wanted to produce code that could run without changes on x86-64 Plan 9 and ARM Linux. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 16:59:40 JST pistolero @vic @ins0mniak @lanodan @lonelyowl13 I'm fine without the defaults and I don't really mind the iota stuff; I did a lot of Limbo. What I do mind is the lack of macros: it's really nice to have lambdas, it's kind of sucky to have to repeat myself. I get the concerns about preprocessor abuse but if you look at the "Coroutines in C" paper, you can't do that kind of thing in Go. (Go has coroutines but what I mean is that without some kind of macro system, you have to hook into the compiler directly to avoid repeating yourself.) Like, the provisioning stuff in CofeSpace, I had a stack of undoable actions, right, "Create the database" was paired with pushing "Drop the database" onto the undo stack so that if something failed down the line, it'd pop things off the undo stack one at a time and this is pretty obviously the correct structure for something like that, but everything that should have been one line was six or seven, like "do this, if it succeeds, do this, and if it fails, execute the undo stack and return". In a C macro, you could drop two blocks in and have the macro handle the repetitive bits of the control flow, and Go doesn't have something nice like that. (At this point, there's so much "if err != nil {" that if they did add a preprocessor, everyone would cover their entire codebase in indecipherable macros and they want a compiler that you can use at large companies, and I begin to suspect that you can't make a language that is good for both large teams of interchangeable cogs and also good for 1-5 hackers to hack some shit together with.)
Something I miss from Limbo is typed tuples. So, Go you've got to do a struct, right, but in Limbo you could use tuples as an ad-hoc data structure and not have to name/allocate/etc. a bunch of shit. This is especially painful with channels. In Limbo, you can have "x := chan of (string, int)" where Go wants you to do a struct.
> Channels could be a little more intuitive on some of the edge cases like sending to vs reading from a closed channel.
Yeah; I end up just using the I/O primitives, like they seem to want to steer you in that direction and just to use channels for synchronization primitives. So it panics when you look at a channel wrong, and that's fine.
> I haven't touched generics,
I don't think they were really needed. They look fine, like, just fine; interfaces handled everything I wanted generics to handle. (If I have a gripe, it's that the compiler doesn't seem to let me get too creative with interfaces, so I had to "type XList []*X" instead of satisfying the sort interface by defining "func (xs []*X) Len() int". It seems there are a lot of types you have to make to keep the compiler happy; see previous remarks about tuples in Limbo.)
> I guess it's the least bad option for the kind of stuff I like to do.
I would just go back to doing normal programs in C if they had added a stupid fuckin' analytics snitch in the compiler. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 15:39:37 JST pistolero @vic @ins0mniak @lanodan @lonelyowl13 I'm doing mostly Go nowadays and there are a lot of things that irritate the shit out of me; it has a lot of niceties, though. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 15:39:08 JST pistolero @lonelyowl13 @ins0mniak @lanodan @vic Ha, I don't think anyone's even attempting it. You see Forth and C and stuff like that but most people aren't interested in building simple, useful languages. Even most C compiler authors don't know how to keep things simple. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 20-Nov-2024 07:55:20 JST pistolero @GhostOfMoshe @JustViolet @UnCL3 @cosmonautkatyusha @dcc @diejewdie @lolocaustianity @rrandy @william_travis This is fun!
uk_subs--1--07--party_in_paris.mp3