Search
288 results for “smxi”
-
@RL_Dane @mjgardner @benjaminhollon
While wanting to avoid License debates, #BSDs are free to use #GPL code in core, they just have to follow the license. It's mainly OpenBSD that tries to get rid of all GPL, which gets slightly extreme at times, like their recent effort to rewrite #rysnc to get a non gpl version. #FreeBSD has so much #linux compat stuff running I doubt they can keep GPL out of core, but don't know. I really only pay attention to OpenBSD anymore. #doas > #sudo for sure though
-
... (#acxi con'd)
A few things acxi is NOT:
* a cd ripping tool. Check out #abcde, it does a good job for cli ripping tool.
* a media player
* a strong supporter of #nonfree #audio #codecs like #AAC or #MP3. It offers adequate, basic support, and that is it.The focus is always going to be on mainly #xiph.org #vorbis things like #flac, #opus, #ogg (to a lesser extent, since vorbis has moved all dev efforts to opus).
acxi will support the others enough to let you translate them to free codecs.
-
#inxi 3.3.25 goes out the door, last matching tables updates for cpu, disk vendor. Features gpu device id updates, various fixes, the new --config options, some documentation updates.
Some other #acxi stuff I used for inxi was the organization of sub categories in the changelog, which helps readability, and makes it easier to maintain and update.
In a sense, the recent acxi updates moved its code closer to inxi style, but also some stuff moved back into inxi that I found useful.
-
With with a faint pop, just missed Chinese New Year release, #acxi 3.6.00 goes out the door. Now to move on to do other things.
For those watching, #pinxi is moving very slowly towards next #inxi, but nothing pressing really calls for a release yet, but features/enhancements are slowly building up. Better intel/amd gpu IDs for example.
-
Last changelog and tiny fixes for #acxi 3.6.00, I think maybe I'll do it today, latest tomorrow. Nothing has changed with --taglist for a few days now, and changes have only been docs and a few tiny additions which don't matter, so maybe ok to consider it stable. Note it makes no real difference, all the dev stuff goes to main branch (called 'stable' for odd historical reasons) as soon as tested anyway, so it's really just about a tagged 'release' in github terms.
-
#acxi (con'd)
* Sync convert_file also used redundant code, now it's all neat and tidy, which made it easier to improve the --dry output options as well. Also, had never indicated if copy and mkdir were running in dry mode or actually happening, now shows 'Test mode:' where relevant for the entire process.
* Earlier in process, refactored OptionsHandler::verify_selections()(to make sure options have the data they need, or conflicting options aren't used), that had gotten really messy over time. -
This is turning into a major release for #acxi, as often happens, you sort of notice odd things when working on other features, but you can't do everything at once, so the brain notes that somewhere and then when the main feature is largely complete, attention can be put on the other less related issues. I'm finding a lot now that I'm going over various features, so 3.6.00 will be a pretty major update since so many features are polished/fixed, little things wrong, code sloppiness.etc.
-
I think this is a first, since the new #acxi --config option is easy to implement, and useful, I extended it to #pinxi/#inxi. This will be in next inxi, and is in present pinxi now.
Usually acxi lags somewhat behind inxi in terms of code and logic, but due to recent heavy spate of work on acxi, the pattern is reversed for the time being.
I don't know why it never struck me to just let users easily find what config file is active, and what configs it has, but there you have it.
-
I would complain about what a pain maintaining complicated help options, man page, changelog, and now the new acxi-values.txt dev doc is overall, but the reality is, I find that when I have to document, and more important, make sure docs are consistent and actually reflect what is going on, I almost always find little glitches.
Ongoing pre-release #acxi docs/feature additions is no exception to this rule, all kinds of odd little glitches found and fixed.
But doing code AND docs is a pain.
-
This will not impact any #acxi user who has set OUTPUT_TYPE already in configs, or who starts acxi with --outtput [type]. So it's just a corner case check to avoid horrible mess for any user who was using the old default of #ogg. But I've been thinking of switching to modern default for a while, but wanted to give it some time.
-
And, since this will be a major version release, #acxi is moving from the old default output type #ogg, which is largely in maintenance mode, to #opus. Added in a few features to avoid any users who had never explicitly set OUTPUT_TYPE in configs and aren't using --output option to exit if no explicit output type set for sync actions. it could be quite nasty if you updated and had used old default ogg, then ran with new opus without realizing. This was cleanest way to handle that test.
-
Polishing up and adding public docs to #acxi. That's a first, except for its man/changelog pages. Doing this helped detect some glitches in logic for --image and --replace-images and how man page described them vs how they were working. Those issues are now resolved.
This makes 3.6.00 release close, though I tend to not want to release until no changes happen for > 24 hours. But these are fixes now, docs, etc, --taglist/-L is stable, working well.
-
@ChristosArgyrop @mjgardner nothing, lol.
Number 1 requirement for #inxi is that it runs anywhere on any system back to Perl 5.008, which was based on running on old redhat servers mainly.
As I noted a few posts back, the time I accidentally introduced a post 5.010 feature to #acxi (state with assignment of array), I got an almost immediate bug report from someone running it on old os.
With this said, maybe in a few years I'll bump inxi to 5.010, to get say and state.
-
@packy @arnandegans I like 5.008, only thing I miss is say and state, #acxi is set to 5.010, and when I accidentally let a feature slip in that broke in 5.010 I got a bug report almost immediately, lol, which surprised me, some guy was using it on an old server.
To me, one of the biggest advantage of Perl over python is that it DOES NOT BREAK over time, and if you have to update a few things, they are easy to update.
I find the assumption that I want to rewrite code every few years rude.
-
@mykhaylo #inxi and #acxi, backend tools for those, and some for work. Not a lot at work, but I found it far better in production in any scenario where I had used shell + php before. inxi is an extreme practical extraction and reporting tool, and is in a sense exactly what perl was designed for. #acxi not as extreme. Core requirement for inxi in particular is to work on 15+ year old os/hardware, so you can run it on old servers. No other language has the feature stability of perl 5.
-
And I think this largely completes this phase of #acxi active development, unless we can find some more tagging arcana corner cases to torture the code with.
Probably the most revealing project I've done with #perl so far because this one exposed 3 distinct things, one almost certainly a true bug, 2 not. This confirms my feeling that this new feature in acxi was very hard, because I had to move perl into areas I hadn't pushed it to before, thus triggering the events.
... -
Te be slightly politically incorrect in these circles, I am just enough of a geek to think bare metal stuff is interesting, but not enough of one to then dedicate all of my life to that pursuit. #inxi is basically at this point a public service to the foss community, my giving back since I use free software top to bottom, and #acxi is a tool I make to do real things that have almost nothing to do with tech at all. I also recognize that free software itself is on a dangerous slippery slope...
-
To me, the 'marketing' of #perl would benefit greatly from focusing on the areas where it excels, it's true power and utility, which is being a practical extraction and reporting language, which is why I picked it for #inxi and #acxi, though it does more than extract in acxi, but that is part of what it does.
True native regex too, coupled with advanced complex data structures, unlike say python, where regex has to be added as a library, requiring functions to access, like php.
-
@mjgardner I find it useful to pause to reflect on things like this when I hit completion of major project, which I am doing in #acxi now, to sort of mull over what the tools are doing when pushed past areas I'd used them before. I am genuinely surprised I never hit this issue before in #inxi because it uses data structures heavily. My current sneaking suspicion is that I did hit them, and then worked around them without realizing why it failed and why fixes worked.
-
@mjgardner in this case, I can quite literally count on zero fingers the number of times I have seen php crash without trapping the error and giving me something to go on. 20+ years. I'm not blaming anything, I'm noting an event that occurred that should not have occurred, and when it occurred, should have been trapped. And always has been in the past, with everything, and both #acxi and #inxi see immense amounts of garbage data. Not excluding other causes, but don't have time to spend on it.
-
@mjgardner I refactored this chunk in #acxi to add one more data structure which I can use together with the main one, the simple one simply says, yes, this key is defined and contains an array reference, at which point I can use it in tests. That's a workaround for an issue that should never have existed however, but you can't change these long term behaviors after the fact so I have to adapt to them. But I don't have to pretend it makes any rational sense to do that, it's just going, reality..
-
@mjgardner oh, that's interesting, technically I'm using Perl 5.034, but #acxi is is set to: use 5.010;
But bugs like that shouldn't be carried over.
I think I found another bug today too, it appears bsd glob may do something really weird with scope
I have a function globber that just runs or ran: return <$_[0]>; but that was returning the data from a previous scope, not the present one, when called from two different classes/packages. That was really hard to figure out. That has to be bug. -
Fixing a bug in #acxi, I learned a valuable thing about #perl's qr//, I had assumed if I compile a regex I could use it exactly the same as what it compiled, this was not the case:
$reg = qr/somepattern/;
$test = 1 if grep {$reg} @data;
which was the bug, that is always true since $reg is something, not nothing, I thought it would exactly the same as:
$test = 1 if grep {/somepattern/} @data;
but to use qr compiled data the =~ has to be explicit:
$test = 1 if grep {$_ =~ $reg} @data;there it is
-
Running the new #acxi features through a few major stress tests, large datasets never really processed before. the new --taglist feature is coming together nicely now. -Lc is particularly useful, along with -Li, -Lc for analyzing the tagging of a large collection. Yes, of course, people somehow managed to cram windows CP-1252 characters into UTF8 vorbis comments aka tags, which crashes #perl hard, never seen anything crash perl before this. But the crash helps find the problem files fine
(con'd) -
(con'd)
if i used for -L in #acxi, only info file data generated. If i is used with a tag list option, both will be.I think this will work better.
The 'c' condensed thing will depend on if I can think of some #perl data structure or other to do that work, it's a tricky logic puzzle. info create already does a subset of that, and that was very hard to get solid and stable.
-
And #acxi is now in #slackbuilds!
https://slackbuilds.org/repository/15.0/audio/acxi/
and that was picked up quite rapidly by #repology.
https://repology.org/project/acxi/versions
I do not expect this to make any real difference, beyond maybe a few people discovering that acxi does something they find useful that might not otherwise have discovered that.
Here's to Free Audio, something not to be taken lightly or for granted, for without the tireless efforts of groups like #xiph.org and others, we would be in proprietary codec hell.
-
...
While part of me wants to find out why this odd character encoding situation crashes #perl, another part of knows that #characterencoding stuff is a big pit of misery and suffering and wasted time/life that you will never get back, so I'm just treating that crash as another way to debug tags in vorbis files.The oddest mystery is that someone managed to get a string without a COMMENT type container into a #vorbis meta data block, that's impressive, you really have to try to do that!
-
I spoke too soon, got a rare email feature request for #acxi, which was actually quite valid. Extending the supported #mp3 #tags, which of course, exposed the real mess that mp3 id3.v1, v1.1, v2.2, v2.3, v2.4 tagging really is. While nobody really has done tagging specifications or worse, implemenations, well, at least #vorbis tags are sane and consistent and don't change version to version, and transfer natively and cleanly to #opus/#ogg.
(con'd) -
Filling in the the #inxi / #pinxi sound server/api stuff. Added #aRts, #Esound/#Enlightenment Sound Daemon/esd, filled out #NAS (Network Audio System), added active/inactive detection for #ALSA.
I wanted to get the initial fixes for the standard current sound servers out as bug fixes, which was 3.3.26, and then I figured I'd fill in the rest.
Testing on old #Debian vms, #etch, #sarge, #lenny, all working fine as of today. Sarge shipped with aRts installed, with OSS+2.4 kernel, good test case..