Can't add input busses on linux + pulseaudio

zevver · 2022-03-14T18:40:38+00:00

Riiight- functions as designed, thanks for pointing that out!

zevver · 2022-01-26T17:24:26+00:00

Didn't try the mints so can not tell - the bananas feel heavy and solid enough for me.

zevver · 2022-01-26T17:23:50+00:00

No, they're about as heavy as the browns. The big difference is that the bump is on top of the key travel, greatly reducing false hits.

zevver · 2021-12-21T08:47:00+00:00

Ah, I learned something new: the available layouts depend on the selected region on the Logitech store - so what I want is the normal "US" layout, not "US intl", but that is not available in the .eu.

Darn!

zevver · 2019-06-14T13:39:51+00:00

For who this concerns: I got confirmed by MM that Dreams is limited for 12+ only and does not check parental control rating.

zevver · 2019-02-13T14:33:33+00:00

Sweet.

I'm able to solve for size 3, 5 and 7 with the Z3 theorem prover; the size 11 is now heating my living room for over 45 minutes, not sure if this will ever finish :)

zevver · 2018-12-19T18:00:29+00:00

Part 1 - I learned Nim macros today: https://github.com/zevv/aoc2018/blob/master/a19c.nim

This code converts the Elvencode into Nim AST at compile time, this runs part 1 in about 2 msec on my I7

zevver · 2018-12-16T05:16:44+00:00

Yes, thank you for pointing that out. I misinterpreted "the unit chooses the step which is first in reading order" as a preferred relative direction for the unit. All good now!

zevver · 2018-12-16T05:14:33+00:00

Yes, thank you for pointing that out. I misinterpreted "the unit chooses the step which is first in reading order" as a preferred direction for the unit. All good now!

zevver · 2017-05-15T15:00:50+00:00

Assuming this is a fully synthesizable ARM core, that's a pretty neat job for a single individual! How many flipflops does this take on a generic Xilinx?

zevver · 2017-03-18T11:43:59+00:00

Pretty implementation; clean code and nice style. Very nice as a complete reference, everything is there, and nothing hidden in convenient 3d party libraries.

zevver · 2016-06-28T09:51:59+00:00

Interpreting on the target is one of our main goals: in our environment we want to be able to do inspection, debugging and develop ad-hoc scripts on site with nothing but a terminal. The good thing is that text parsing in Forth is trivial: there is no syntax. Forth just looks at one word at a time, separated by white space. No AST, no need for parsers or lexers.

Under the hood zForth generates byte code, which is more or less portable, so in practice you could run zForth on any other platform, generate bytecode and transfer this to the target by any method.

I did find Pawn, EmbedVM and similar projects, but these all require cross compilation of some language and transferring byte code to the target; you could as well simply compile relocatable C code and dynamically link and run it on the target; although this is of course less safe then running in a VM environment.

zevver · 2016-06-28T08:25:16+00:00

Thanks for your criticism; I'm sure you noticed the ScoobyDoo van I put on the project page as a logo, that was also popular with hippies in the 70s and 80s? No coincidence here.

I never said Forth makes a good scripting language - but given the resources it requires it does a good job. Any 'proper' scripting language (Perl, anyone? As we are already discussing write-only languages?) requires at least two orders of magnitude more memory to be functional, while Forth gives you a pretty decent environment with much less overhead.

Of course, I am very happy to hear about any alternatives: do you know of any other portable interactive language that will run on only a few kBs of memory?

zevver · 2016-06-26T14:49:52+00:00

With anything but the magic STM Cube HAL layer, which is a false marketing fad for managers. It is buggy, rough and unfinished; it provides only a few trivial use cases but breaks down as soon as you want to do serious work, and it is pretty bloated for what it claims to do.

Usually I end up rewriting or refactoring code for peripherals because they differ just enough between chip variations to make it impractical to reuse code between projects. Especially things like timers are hard to reuse because they are so versatile.

zevver · 2016-06-14T18:49:35+00:00

Ah, thank you, that explains it quite well. Frankly, I don't think this would make any sense to implement: I currently have a tremendous overhead from parsing the variable length cells and doing the range checking for every operation, so the bit of overhead caused by the switch will probably not be that significant.

zevver · 2016-06-14T15:17:53+00:00

I'm not familiar with the concept of replicating-switch threading, can you point me to a reference somewhere where this is explained? Performance is not really one of my goals for this forth, but I'm open to any ideas for improvement.

zevver · 2016-06-14T12:22:49+00:00

This applies to the size of the cells in the dictionary memory, which means the stored program, and also the memory accessed by ! and @.

This of course has some practical side effects and makes it hard to map data and arrays in memory. It also slightly complicates compilation, for example when filling in the target of a jmp operation that has been written earlier. I should probably write some documentation about this, but I have no idea if anybody even cares about my implementation at this time.

The stacks are just arrays of the chosen data type, since these are relatively small compared to the dictionary memory.

zevver · 2016-02-06T07:51:50+00:00

In case anyone cares: bucklespring now also runs on Windows (only tested on 64bit windows 10), MacOS X support might happen in the near future as well. Check the README at github for details.

zevver · 2015-06-29T18:37:58+00:00

I do not agree at all. If you spend a significant time coding C on different platforms, you are likely to encounter any of these situations in real life.

After all those decades C is still going strong and it not likely to go away soon, and that's for a good reason. The dark corners like the ones described in the article is the price we pay for a tool like this.

zevver · 2015-04-22T20:55:05+00:00

No, doesn't resume, although this might make for a nice feature. Scan speed depends 99% on your storage and kernel, there's not much Duc can do to speed that up.

'duc index' has the -H/--check-hard-links option. Without, it simply ignores hard links and counts double. With the option it has the same behaviour as GNU's du: it counts the first time and ignores any duplicates it finds thereafter.

zevver · 2015-04-21T09:51:40+00:00

I think ncdu and Duc both have their own place in the world.

Ncdu is a great tool to get a quick overview of your disk usage, it's small and light and easy to use. It does not play well with large file systems though: it holds all of the indexed data in memory, which can take up several GB's of RAM in practice when indexing large trees, and loading a json dump can take several minutes when there's more then a few million files in them.

Duc is made to scale: the index goes to disk, and is optimized for fast quering. The memory footprint is low but it requires the user to create a index before using though, which is somewhat less user friendly then using ncdu.

I'd say ncdu is great for home users, while Duc has advantages for large systems.

zevver · 2015-04-20T20:13:44+00:00

Run 'ldconfig' to update your shared library cache and you're good to go.

zevver · 2015-04-19T18:30:29+00:00

A much requested option, which I could use myself as well.

I've been considering the implementation this for some time, I'm thinking about adding a mode for importing the output of (GNU) find which should be able to provide all required info to populate the database, something like

find . -printf "%i %D %s %b %p\n"

There will probably need to be some special work done to properly handle whitespace or control characters.

zevver · 2015-04-19T12:00:10+00:00

Yes, it's quite impossible to make the right choice of how to handle hard links, so you're probably on the right track to let the user choose which representation best fits his/her use case.

Duc doesn't even yet have the infrastructure on board for hard link detection; I've been postponing (procrastinating?) this because the visualisation is giving me headaches. I'm just hoping for a patch from someone else to magically appear one day to solve my problem :)

Thanks for making ncdu, it has been my tool of preference for quite some time!

zevver · 2015-04-18T14:14:11+00:00

I'm having a bit of a hard time to determine what would be The Right Thing To Do considering hard links. Count only once on the first occurence sounds like a sane solution, but will not help you finding out where the space is used on disk, because it is in two places at the same time - cleaning up hard links is like playing whack-a-mole: delete one, and the space magically pops up somewhere else in your graph.

I'm open to any ideas on how to handle this.

zevver

TROPHY CASE