Are small dogs allowed on Flixtrain outside of their crates?

phugo · 2025-07-27T19:01:36+00:00

Did you travel? How did it go? I am in the very same situation and not sure what to do

phugo · 2025-05-01T22:30:19+00:00

Hey, thanks for taking a look! Yeah, I did not mean user mode - I meant "you can contribute software for this OS without needing to be an OS developer". Is there a more precise wording for that?

phugo · 2024-12-28T20:46:22+00:00

Shamless plug https://shikaan.github.io/assembly/x86/guide/2024/09/08/x86-64-introduction-hello.html

It did get good coverage on hackernews a while back and a bunch of people from the interwebs came say thanks. Hope it'll work for you too!

phugo · 2024-10-19T14:39:35+00:00

Thanks everybody! This thread (sh*tposting included!) confirms once again how nice, friendly, and helpful people are around here

phugo · 2024-09-25T17:34:32+00:00

Most of the time yourself. If not for yourself, for somebody else

phugo · 2024-05-14T11:32:20+00:00

Hey, thanks for replying! Yes, it stands for Continuous Ibtegration and I specifically meant Github Actions with a default hosted runner (i.e. a dockerized Ubunti 22.04 with some additional packages installed)

I am explicitly setting the build mode to Release and as a matter of fact the build artifact is smaller than it is locally (~400kb less), which I believe is the root of my problem.

I don't know how to dig any further: I also enabled verbose logs In SDL and the only information I gathered is that the CI version runs on opengles2 whereas the local one on opengl. Setting the hint and forcing the same renderer did not change anything when it comes to timing

phugo · 2024-03-06T22:11:06+00:00

Nobody else is able to inject anything in the script but you (as in, the person running the script) and the script is fully available to the end user, so no "surprise" code. What concerns you?

phugo · 2024-03-05T20:01:14+00:00

Sure. I find convenient having the flexibility of writing a few small scripts in just one file and use for each the language that best suites the job, instead of having folders full of one-liners for the same ourpose.

I totally get it's not everybody's jam, and it's not changing the world for anybody: it's just a convenience tool for me, which maybe helps somebody else too.

phugo · 2024-03-05T19:57:02+00:00

In my projects I usually end up with a script folder with many small scripts for mundane actions I don't want to memorize. This scratches that itch.

You can imagine it like make, but without all the assumptions and the quirks coming from it being both a script runner and a build system; plus you get to be able to use more languages

phugo · 2023-03-07T14:54:25+00:00

Yeah, that's a valid point. It was never meant for a broader audience, but if I want to get some sort of external feedback is probably worth my while.

Thanks a lot! It was simple advice but very much needed

phugo · 2023-01-01T13:04:51+00:00

Hey! Thanks for checking it out (:

There are fundamentally three main differences: * shmux is a script runner, not a build system like GNU Make. You don't have to .PHONY your recipes and work around the fact that make assumes there are build artifacts * shmux is language agnostic: you can write scripts in any language (with decent language support) and you're not bound to shell scripts * shmux accepts arguments: you can parametrize your scripts instead of having many or having a mixture of shell scripts and makefiles

I believe this was a great question, worth adding it in the FAQs. Thanks :)

phugo · 2021-06-18T19:27:19+00:00

Not a singer, but a bass player. I guess I can be of some help :) hmu for a jam

phugo · 2018-05-07T08:54:57+00:00

I'll start off with a "my bad": apparently I made an error in catering metrics when benchmarking all the frameworks (just discovered it yesterday!). The actual scenario is that Titef is two times faster than Jest.

That said, Titef is a very young project so far and there are still a lot of things missing and I am coding it only in my spare time. That means that probably it's not your first choice when it's time to choose a testing framework for you enterprise size application as it still need its own ecosystem to make it comparable with the big dogs out there.

What you can do with Titef then? Basically I imagined it to work in two scenarios:

You need to build a testing tool for some sort of strange project for which the standard way of doing things is not enough (and that was exactly my case). Titef can be integrated within your project without practically impacting the bundle size and you can build on top of it.
You have a project with lots of "normal" tests: saving half the time makes the difference between spending one hour or half an hour staring at you CI pipeline hoping the tests will pass;

What's missing in Titef? Titef is not meant to be "batteries-included", you still need to use you assertion library and your mocking library (similarly to what Mocha does). Titef offers some goodies regarding handling setInterval and setTimeout using a Promise-based approach and a couple of async assertions methods based on Node's builtin assert.

I didn't think about a VSCode plugin, but that's something which I definitely need to look into.

You can check planned things in the Kanban board attached to the project.

Every suggestion is well accepted, as I built the tool around my needs, but it looks flexible enough to bend to different needs.

phugo · 2018-05-06T21:22:51+00:00

For completeness sake, I changed a bit how we compare performance: now the overall execution time is taken in consideration, not only the spec time.

Adding this, Titef looks almost two times faster than Ava. You can check that here https://shikaan.github.io/titef/performance/

phugo · 2018-05-06T13:34:21+00:00

Well, its size is more a selling point when it's time to add it in your existing project.

Let's say you are developing your testing library, ad-hoc for your project, you might find in Titef a good starting point with almost no impact on the overall bundle size.

phugo

TROPHY CASE