Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does serdi support named pipe input/output ? #38

Closed
davidandreoletti opened this issue Sep 19, 2022 · 5 comments
Closed

Does serdi support named pipe input/output ? #38

davidandreoletti opened this issue Sep 19, 2022 · 5 comments

Comments

@davidandreoletti
Copy link

Sample bash program:

mkfifo in;
mkfifo ou;
(serdi -i "Nquads" -o "NTriples" in > out) &;
write_to in &; // write_to is any program capable of writing to a named pipe
read_from out &; // read_form is any program capable of reading from a named pipe
@drobilla
Copy link
Owner

Please stop abusing issues to ask seemingly random questions you can answer yourself. Issues are for, well, actual issues.

@davidandreoletti
Copy link
Author

davidandreoletti commented Sep 19, 2022

@drobilla You should open Github Discussion (discussion tab), otherwise, I see no other alternative to reach you out for quick questions that might benefit other users. I agree this kind of question should not be raised in the Issues section.

Some other suggestions:

  • Updating serdi man page / README with other examples (named pipe, standard input, etc) would be useful. There is no mention of being able to read from standard input for example.
  • Redirecting users to some discord channel (if exists) or stackoverflow tag to check if the question is was asked.
  • List of OS providing serdi / libserd package .

PS: The answer to the ticket's question is yes for everyone else.

@drobilla
Copy link
Owner

No offense, but I'm not actually interested in lazy drive-by questions. I do my best to support people who have done their due diligence and encounter an issue, but that's all. I appreciate real feedback, even on superficial things, but I do not appreciate armchair stuff that acts like my time has no value.

Updating serdi man page / README with other examples (named pipe, standard input, etc) would be useful. There is no mention of being able to read from standard input for example.

AFAIK there is nothing particularly special about named pipes. serdi will read from and write to more or less whatever, like most UNIX-style utilities, because that's a pretty fundamental concept of UNIX command lines. The help output says "Use - for INPUT to read from standard input", and besides, this too is a widespread convention. I have a hard time imagining anyone actually trying to do something with the software wouldn't at least try that, even if they didn't notice the help text.

This project has been around for more than a decade and it's never come up, so...

Redirecting users to some discord channel (if exists) or stackoverflow tag to check if the question is was asked.

It doesn't.

List of #37

People running some distro or package system don't generally look to project homepages to find out if a package exists. This is just another thing I would have to maintain which adds almost no value. Every packaging system I'm aware of has facilities for this, which are inherently correct and up-to-date. Most distros even have online ones.

@davidandreoletti
Copy link
Author

davidandreoletti commented Sep 20, 2022

The help output says "Use - for INPUT to read from standard input",

I did not find it in Archlinux v0.30.16-1 generated on Jul 15 2022.

I do not appreciate armchair stuff that acts like my time has no value.

Your time has value, as much as mine. We could have saved a little of each other time updating the doc. I was willing to provide a PR but given how the discussion has turned out, I pretty certain you would not accept the PR.

That being said, serdi is excellent. I thank you for it - genuinely.

@drobilla
Copy link
Owner

Your time has value, as much as mine. We could have saved a little of each other time updating the doc. I was willing to provide a PR but given how the discussion has turned out, I pretty certain you would not accept the PR.

This ticket was a question you could have - and apparently later did - easily answer yourself. It is your second such ticket on this project. Now, you've piled in a bunch of other things in the comments, and proceeded to use my response to this pattern of time wasting tickets as an argument for why I won't accept PRs for some completely unrelated thing that hadn't even been mentioned when I checked your behaviour?

Yeah... no, that's not how any of this works. Do better. The first time around, all you got was ellipses and a question mark. Now... well, here we are. There isn't a third level: zero tolerance instaban from here on out.

Repository owner locked as resolved and limited conversation to collaborators Sep 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants