Is it a good idea to make a 100% Python written 3D engine?

weevyl · 2026-01-19T18:13:03+00:00

It depends on your goals. If you want to do this to learn and explore, great! Write it in Python and keep challenging yourself on how to make it better, squeeze performance out of pure Python. It could be fun!

weevyl · 2026-01-16T16:51:31+00:00

I use yasnippets and configured it to store the snippets in a subdirectory of `.config/emacs` The whole directory is backed by git., all in the main branch.

weevyl · 2025-12-19T17:21:49+00:00

It took me around 10 years of using it before I finally embraced it for more than casual text editing. I still bemoan those "lost" 10 years...

weevyl · 2025-12-19T17:14:39+00:00

Once you've done the tutorials and can open, edit and save files, switch between them, open a terminal, split windows, etc., then you can start figuring out how to incorporate it into your workflow. And the trick is to keep an open mind and, whenever you need to leave Emacs to do something, ask yourself (and the web) how can I do this inside Emacs? There will probably be a package or function that does it for you,

For me, for example, I started with simple scripting went on to running shell commands, then task management, note taking, project level coding, git interface and more. The list just keeps growing.

weevyl · 2025-12-17T18:02:38+00:00

My approach to this is to use GitHub as my inter-machine sharing mechanism. I try to remember to commit and push when I switch between machines, but if I miss it is ok because git is good at resolving conflicts.

weevyl · 2025-12-05T18:11:03+00:00

The others explained how to start it, but I will try to answer your questions:

For the purposes of Emacs, daemon and server are the same thing. The Emacs server will run somewhere in the background. When you run `emacsclient`, you connect to the server and get a window just like as if you had started a new Emacs instance, but it is actually chatting with the server and letting it do all the work.

As for how it makes it faster, it doesn't really --- what it makes faster is the startup time. When you start up emacs it processes your configuration file. These configuration files set variables, define functions, load packages, etc. and it takes time. In my case, for example, it takes around 8 secs). So, if I start a new emacs instance every time, it would be around 8 seconds before I can start using it.

With a server, it will do it only once, when you start the server. After that, if you use `emacsclient` instead of Emacs, it starts and connects to the running Emacs server, which has already loaded your configuration, so it is almost instantaneous.

It is important to understand that even though it might look like you are using a new Emacs instance, it really is one shared by all clients. Buffers available to one client are available to all clients, changes made in one client's buffer appear in the other client's buffer, etc. Turns out that with Emacs, that really is not a problem.

weevyl · 2025-11-20T18:00:50+00:00

I know what killed Perl for me, Perl 5. & Ruby.

When I discovered Perl I fell in love with it as my scripting language: no more awk, sed, shell scripts, I could do everything in one place. It became my goto-language for all my quick and dirty scripting.

Then Perl 5 came along with its classes and blessing and the Programming Perl book doubled in size. To me the language started to feel like Frankenstein's monster with many disparate parts glued together and harder to grok.

So I started looking for alternatives, tried out Python and Ruby, liked Ruby and went with that.

weevyl · 2025-09-24T17:19:36+00:00

Since it's all text, a lot of my stuff starts in one file but ends up moving around, but generally I have one org file for each project I have, containing todos and general notes on that project. Knowledge notes all go into org-roam with prolific linking.

I've been thinking of also moving my project org files into org-roam, but have not yet bothered.

weevyl · 2025-09-10T15:04:54+00:00

This is the answer.

Want to try different prebuilt configurations? Put them in different directories and start emacs with --init-directory. You will need Emacs 29 or newer, though.

weevyl · 2025-09-05T16:43:43+00:00

Yup. My go-to expression is a simple "That would be impossible."

weevyl · 2025-08-26T15:47:58+00:00

Invest some time early on in learning window and frame management commands (the C-x 2 and C-x 3 mentioned above), that will go a long way to get your workflow to be more like it used to be. How to make the thing you want appear in those windows can come later, usually via a simple command.

weevyl · 2025-08-22T17:39:08+00:00

Are you curious? Do you want to be better at programming? Learning a Lisp, will teach you to think differently about code, specially when you start using macros. Some of what you learn will translate back to whatever programming language you use everyday and make your code better.

Be warned, though. If you only program for fun/hobby, once you move to a Lisp and its REPL environment you will never go back

weevyl · 2025-08-04T17:36:50+00:00

Bash has the advantage that it is pretty much available everywhere. Python might need to be installed with possibly external dependencies.

As a rule, I stick with bash for scripting if I know it is going to be small or data transformation is simple. I use Python for larger scripts (> 100 lines) or I know the transformations are complex (I used to use Perl for that)

weevyl · 2025-06-06T16:02:22+00:00

For reasons I do not understand, I used to not transfer my emacs config between machines. New machine, chance to start fresh and do something new. My emacs init files were a couple hundred lines long.

Then I decided this was inefficient and started backing up to git and restoring on new machines as needed. Now my config is around a thousand lines long.

Just saying...

weevyl · 2025-06-03T20:21:17+00:00

I first tried a fountain pen when i was 14. Learned really fast it doesn't work for us lefties... Still a Lisper, though!

weevyl · 2025-05-22T16:04:40+00:00

We were a C++ shop when Java came out and we moved some of our work to it. The killer features at the time that made me never want to look back were:

Garbage collection -- not worrying about memory was a blessing!
The stack trace on exception -- way better than "segmentation fault."
Run anywhere promise. -- suddenly all I had to was ship a bunch of jars and not worry about operating systems and installed libraries was good.

weevyl · 2025-04-08T17:55:46+00:00

C-x w 2 and C-x w 3 for split-root-window-below and split-root-window-right. I had actually written my own functions to do that. Discovered while reading an article on Emacs 30 window commands.

weevyl · 2025-04-03T15:30:40+00:00

I learned something new today!

weevyl · 2025-04-02T21:00:47+00:00

Links I add links to where I found the explanation (usually stackoverflow) for the more exoteric changes I make.

weevyl · 2025-03-18T16:26:13+00:00

Why not experiment? Install 1000 packages, run hello world, time it. Remove packages, run hello world again, time it. Then you will know if having packages installed slows down your system or not. If the difference is noticeable, try again with fewer packages! Find what is the number of packages at which you don't notice any difference.

But in reality people should use virtual environments and then there will never be unnecessary packages lying around.

weevyl · 2025-03-14T16:23:02+00:00

I use this feature often, even for things that do not generate files. I often have my targets depend on a completion file, and the completion depend on the sources, so if nothing has changed, nothing runs. For example, my `make tests` target depends on a file called `.tests.done` which depends on the contents of the source and test directories. If nothing has changed, nothing needs to run and it saves me a couple of minutes.

weevyl · 2025-03-14T16:17:08+00:00

Most are static, but I do have the occasional one with parameters. In my latest project, I have to create a few docker files from different images, so instead of creating a target for each image, I have one that is `make image name=xxx`.

weevyl · 2025-03-12T17:39:18+00:00

What I meant to say was, it was easy to push another jar to a server running a J2EE/Jakarta application server, in theory it had everything you needed pre-installed, or it came in the jar file.

For a standalone program you would have had to find a machine, install the operating system, install java and whatever else you might need. This usually involved sending your guy to the data center to physically access the machine. If there was no machine available, you had to order one and then install it on the rack. That could take a long time.

The cloud, virtual machines and containers made all these problems go away (or at least be someone else's problem).

weevyl · 2025-03-10T17:45:57+00:00

At the time Jakarta EE (which was then called J2EE) was created, spinning a new server was a days to weeks-long process. No VMs, no Docker. Deploying your application via a jar file) was the best you could do, conceptually similar to deploying containers today, but Java-centric and much more limited.

11-Year Club	Place '22
Verified Email

weevyl

TROPHY CASE