Jarkko Sakkinen
jarkkogenerated documentation starts to look a bit like actual documentation after fixing all the clippy::pedantic errors.i was not aware of this flag until some sent a PR fixing a few of these. not that experienced with the language yet..
only thing that is left is two integration tests for examples in order call this 0.1, i.e. test_sz_to_rzm and test_rz_szm but I need a. stable and idiomatic way to point out to the executables. I guess I could make this happen by injecting stuff through build.rs, right?
after that is sorted out it is good for what i needed it originally for (my serial terminal), i’ll set up github runner for CI (tests + clippy), make the crate release and call it a day. after that not going to do proactively do anything to it except review and merge pull requests.
1
0
1
Jarkko Sakkinen
jarkko
0
0
1
Jarkko Sakkinen
jarkko
0
0
0
Jarkko Sakkinen
jarkkoLet's consider MIDI export.
Since an instrument can change per step (instrument is one of the note parameters), in the worst case scenario you would need 48 * 8 = 384 MIDI tracks to export a single 8 track pattern. This sort of gives perspective on the complexity of this instrument.
#Ableton and #Bitwig have a sort of solution for this: drum rack. So if you had a plugin that can play polyend instrument then you would need 8 instances of drum rack each with in worst case 48 instances of that plugin and choke group spanning all of the instances. I.e. in worst case you would be running 8 drum racks and 384 instances of the plugin. Pitch could be changed with generated pitch automation. More feasible than 384 MIDI tracks but still somewhat exhausting.
Did not realize how complex problem it can be to do 1:1 correct export of a tracker project until I started to actually think of it :-) As odd as it sounds it would easier to implement software clone of the tracker than to implement a DAW export of a tracker project.
0
0
3
0
0
0
I.e. you have a piped process tree and outside service to keep track of things...
2
0
0
1
0
0
So you mean like (words can mix up stuff):
#include <sys/stat.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
int main(int argc, char **argv)
{
char *line = NULL;
struct stat sb;
size_t len;
int fds[2];
pid_t pid;
ssize_t n;
if (pipe(fds) < 0) {
perror("pipe");
exit(1);
}
pid = fork();
if (pid < 0) {
perror("fork");
exit(1);
}
if (pid == 0) {
dup2(fds[1], STDOUT_FILENO);
close(fds[0]);
close(fds[1]);
if (fstat(STDOUT_FILENO, &sb) < 0) {
perror("fstat");
exit(1);
}
printf("child: st_dev=%u, st_ino=%llu\n", sb.st_dev, sb.st_ino);
} else {
dup2(fds[0], STDIN_FILENO);
if (fstat(fds[1], &sb) < 0) {
perror("fstat");
exit(1);
}
printf("parent: st_dev=%u, st_ino=%llu\n", sb.st_dev, sb.st_ino);
close(fds[0]);
close(fds[1]);
n = getline(&line, &len, stdin);
if (n < 0) {
fprintf(stderr, "Unexpected EOF\n");
exit(1);
}
fwrite(line, n, 1, stdout);
free(line);
wait(&pid);
}
exit(0);
}
? With M1 generation MacBook Pro I get:
$ ./test
parent: st_dev=0, st_ino=9204210306621897207
child: st_dev=0, st_ino=9204210306621897207
Jarkko Sakkinen
jarkkojos näin tehtäisiin, saataisiin parempaa laatua vähemmällä ajankulutuksella ja paineella, ja ihmiset saisivat parempaa tunnustusta käytännön sorvauksesta. vaikka työroolit aiheuttaa budjettiin lisäkustannuksia, koska silloin tekemisestäkin pitää maksaa parempaa liksaa, niin työtuntisäästöt vastaisivat varmasti useampaa kuin yhtä henkilötyövuotta per tutkimushanke. tässä ehkä katsotaan liikaa suoraa kustannusta, eikä mietitä epäsuoria kustannusvaikutuksia tarpeeksi.
1
0
1
Jarkko Sakkinen
jarkkowell, returned back safe #neovim. i did like experimenting with #helix tho and am going change my neovim configuration based on that. I’ve used vim for 25 years so pretty hard to get out of old habbits.
Some glitches that would need to be fixed before I would try it again:
- Doing quick changes to tabbing was too much effort compared to something like
set ts=2 sw=2 et. Creating a.helixdirectory for upstream projects in not always even an option. - I don’t like multiselect, totally useless and confusing feature to me, and the whole philosophy is based on this concept. I generally do not want the text editor to be too symbol aware to the point that it gets in the way. This is actually why I never got into Emacs. It is way too smart editor for me :-)
- I was not able to format (
gq) email paragraphs when responding withaerc. - No remote editing so not very nice to use with
tmux. I usually open my files from command-line, not from the editor. - Probably just user incompetence but I did not know how to exist from that stupid multi-select once I had done search replace. So I exited the whole editor after every single search-replace.
In producing code it is not very important how fast you can write the code because 95% of time goes to QA anyway and making first functional version to actually work with real workloads. So personally I think that new editors optimize a local maximum that does not help to deliver all that much as you might first think.
2
0
1
Jarkko Sakkinen
jarkko@harrysintonen For uneducated person on these attacks like me, the best protection has been to stick to text based email clients :-) Haven’t had an issue to separate a phishing email from legit when I read all my email previously with mutt and these days with aerc.
I would have no chance to survive from these or notice them if I used Outlook/Thunderbird or similar :-)
0
0
0
0
0
1