- 314 parentssshhhhhh, the Rust Evangelism Squad will hear you.
- In a similar vein there is https://www.youtube.com/@ExploringtheUnbeatenPath
- I prefer to use vite - you get handling of imports without needing a separate bundler step, but you get hot reload as well. I find it is a nicer experience, YMMV but it is good to have alternative options:
The react install isn't normally there if I start light - but it shows that the path to throwing in a framework is smooth. Typically combined with:FROM node:19.1.0 WORKDIR /project/vite_project RUN npm init -y RUN npm install react react-dom RUN npm install -g esbuild RUN npm install vite EXPOSE 8081 CMD ["npm","run","dev"]
Obviously there is something to a bundler step happening in the background, but it is fast enough (and implicit) so it doesn't get in the way of rapid prototyping.#!/usr/bin/env bash docker build -t vite_play -f Dockerfile.vite emp/ - I guess that I'm not the target audience for this - I like grep as UI on top of lsof, maybe in combination with less, and I've always found it fast and easy to use.
For people that are the target audience of this, I'm curious - what do you like about putting the information into a gui and using a mouse instead of a keyboard?
- This is a nice idea, I was jsut wondering how to do that.
Another approach (if it is supported by the adaptor) is to configure WoL so that it does not need a magic packet. Some adaptors can be configured to wake on any "directed packet".
I have a linux server sitting downstairs that I might play around with. It would be nice if the sleep support featured a timer and integration with the system cron daemon. Then it could wake on a directed packet or when there is a scheduled task.
- > It's easy to write things like this when you're at the wrong end of the Dunning-Kruger bathtub
Amusingly, only the most simplistic graphs of the Dunning-Kruger efect would portray it as matching a bathtub curve. In particular the rather slow slope of confidence rising as competence improves is dramatically (and significantly) different from the sharp drop-off of false confidence. Rather than two steep sides, there is a marked asymmetry.
I suspect that you may have misunderstood the author's point though. Even if you swap the arguments as you suggest, you still run into this problem described in the link that the author provides:
i.e. his complaint is that if he initialises the buffer to zeros and reads N bytes into it there is the possibility that zeros after the N bytes are overwritten.When used on a text mode stream, if the amount of data requested (that is, size \* count) is greater than or equal to the internal FILE \* buffer size (by default the size is 4096 bytes, configurable by using setvbuf), stream data is copied directly into the user-provided buffer, and newline conversion is done in that buffer. Since the converted data may be shorter than the stream data copied into the buffer, data past buffer[return_value \* size] (where return_value is the return value from fread) may contain unconverted data from the file. For this reason, we recommend you null-terminate character data at buffer[return_value \* size] if the intent of the buffer is to act as a C-style string.This is distinct from the problem of not getting enough information back if you swap the argument order, and as it matches his decription in the text before the link I would assume that the swapped arguments are actually a typo rather than a misunderstanding of the API.
- You seem to be making a lot of assumptions, and it's unclear how much direct experience you have of being in a bad situation where the day-to-day job does become saying no.
Some examples that you may be unfamiliar with:
* Working with a manager who is a former dev that likes to micromanage the decisions that their team makes.
* Working on a team that is driven / owned by a product owner who doesn't understand as much engineering as they think that they do.
Neither of these situations are examples of healthy functioning organisations, but they do occur. They are not an exclusive list either, just some random examples from personal experience.
Shooting down ideas may be a symptom of somebody being a prick, or it may indicate that they know why the idea will break the system (even if it closes a ticket or gets a particular feature finished). The ability to propose an alternative can be restricted by just how batshit insane the demand is.
It's not that you are wrong when you say that an engineer should respond "This doesn't work, but how about this?". But that characterization is incomplete - sure it works in theory, but there are many places where it does not work in practice.
- You don't know what their job was, or what kind of engineering decisions they were having to work around. You don't know what kind of corporate hieracrchy they were stuck in, or what effect it had on what they were building. Without knowing any of those things it is a bit premature to be making character judgements.
- In my experience I've found it easier to write Python code. The set of basic types is a little larger, and the core builtins cover more of what I need to do. Lua is a bit more fiddly and verbose, which leads to a more difficult development process (in my opinion). Why would you argue that they have the same level of difficulty?
- Nice idea, as python is much easier to write code for than lua so should fit game scripting well.
But, the examples are not the kinds of things that I would care about before trying to put this into a game engine. It needs a different set of examples.
* How hard is it to call into a C function from a hook in the py code?
* How hard is it to wrap / unwrap values from their py representation to C?
If you want people to embed the interpreter into an engine then show that it is clean/easy to do the embedding, rather than showing that the interpreter can execute code. I would assume that it executes python, but need to know how well it embeds.
- It's been more obvious that they are losing against SEO in the past few years. When searching for programming results it is rare for an authoritative source to be be above w3schools or geeksomethinggeeks. Even with a specific query for something that is not a beginner tutorial you have to wade through that shit to even get to stackoverflow answers.
Either google engineers have really started to dig w3schools or they don't eat their own dogfood any more.
- > Computers can't learn from their mistakes. Humans can.
So.... Machine Learning is a thing.
> That's the whole point behind bans, is it not?
No, it may be one point behind imposing bans but it is not the whole (only) point. People can also learn from watching other's make mistakes. Bans communicate to people other than the person getting banned that something is unacceptable.
In this case it seems to communicate that "but it is not a person it's a bot" will not be a srong enough reason to break their rules and escape a ban.
- As a former CS professor with some experience of curriculum design: looks quite reasonable. Personally I would have moved some of the material on compilers and architecture into the earlier part of the course (instead of putting them in the advanced section) but balancing content distribution against time is tricky.
The selection of areas and materials is broad enough to teach a reasonable chunk of CS. The individual course quality looks good from a quick skim.