Search
77 results for “zirias”
-
And now, the full docs for #dos2ansi v2.0 are available online as well:
https://zirias.github.io/dos2ansiIMHO manpages are an awesome documentation format. And with a little bit of "responsive" #CSS, they're well usable on a mobile as well -- I wished the typical "online man" sites would do something like that 😉
-
Released: #dos2ansi v2.0
https://github.com/Zirias/dos2ansi/releases/tag/v2.0The real "visible change" is documentation. #showansi now got a manpage as well, and the one for #dos2ansi improved a lot. Also better build instructions and some updates/corrections in the README. With these docs, you can hopefully make it do exactly what you want 😉
Also, the build system (my own homebrewn #GNU #make framework) got lots of improvements and fixes.
https://github.com/Zirias/zimk/ -
I'm planning to create a release #dos2ansi v2.0 soon, which will have more or less the feature set of v1.8, but with complete and helpful documentation for everything. Main work left to do for that is to add more text to the manpages 😉
At least, the tool I wrote for generating docs now has everything I'll need for that!
-
Here's a quick demo how the new documentation generation in #dos2ansi works 😎
https://github.com/Zirias/mkclidocScreenshots:
- Input format (on github)
- help (-h) output (on #Windows)
- manpage (on #FreeBSD)Might make sense to add some #HTML output as well, e.g. for the Windows binary package... 🤔
-
#dos2ansi v1.8 released!
https://github.com/Zirias/dos2ansi/releases/tag/v1.8There's some major rework inside adding support for seekable streams, which was necessary to implement the logic detecting #SAUCE even when the preceding DOS EOF character is missing.
Quite some improvements to the #showansi script as well, now comes with "fontsets" (explained in the comments in these and the config file) 😎
Plus added a manpage. Wanted a single source of truth (shared with the help output) and didn't find a good tool for that, so I quickly came up with my own:
https://github.com/Zirias/mkclidoc
It's bundled with dos2ansi now. Can produce man in both classic troff and BSD mandoc. The default choice is based on `uname` for now, tested on #FreeBSD and #Debian. -
I just released #dos2ansi v1.7, which includes one final bugfix: Quoted output of #SAUCE metadata should use proper "shell-style" quoting, so it can be directly consumed by #showansi, which it does now. Plus #showansi got a (tiny) bit of optimization.
https://github.com/Zirias/dos2ansi/releases/tag/v1.7
Well, just after releasing, I found more stuff to tackle. No, not new bugs at least.
But more weirdly broken ANSIart files. Example:
https://16colo.rs/pack/root0297/FU-B%26B.ANSThis one *has* SAUCE metadata, but it's not properly "hidden" behind a DOS EOF character (0x1a), which means even 'type' on a real DOS machine will output the SAUCE gibberish below the pic 🙈
So, there *might* be a v1.8 adding more heuristics to detect and parse more broken SAUCE ... 😂
-
Yet another revision, #dos2ansi v1.6.3
https://github.com/Zirias/dos2ansi/releases/tag/v1.6.3--- brings yet another subtle bugfix in #showansi: To set the title with an escape sequence, it uses "printf %b" with its \-notation for control characters, so literal backslashes in the title must be escaped as well 🙈
Apart from that, added nice "portability bikeshed":
- Removed the dependency on 'sed' again, quoting/escaping strings for 'eval' *can* be done in pure #POSIX #shell script.
- Added proper detection of the POSIX shell to my #zimk build system, along with variables to override the choice. Used that to generate the shebang for #dos2ansi. Really an awesome way to write /bin/sh without writing /bin/sh 😂 (rumors say there *are* POSIX systems with the compliant shell in a different path ...)
Screenshot: Yet another file with "weird" title from #SAUCE
-
And now there's even #dos2ansi v1.6.2: https://github.com/Zirias/dos2ansi/releases/tag/v1.6.2
The good thing is: The issues I'm fixing here are getting more and more obscure 😂
First I noticed #xterm doesn't accept all #utf8 for its '-title' option, no matter what. But it *does* support the escape sequence to set a title, so, why not use this instead.
Having added support for that (and also optionally for setting the window size using an escape sequence), I had a look at quoting again. Indeed, #showansi failed for e.g. file names containing #shell special characters.
Therefore added a *safe* quote function. The downside is, it requires #sed now. Well ....
Screenshot shows both improvements, I picked a "maximum weird" file name and used a file that has an 'ö' in its title 🥳 -- in the showansi debugging output, you can see the quoting in action 🤯
-
#dos2ansi v1.6.1 (a pure bugfix/service release):
https://github.com/Zirias/dos2ansi/releases/tag/v1.6.1* Fix possible crash (🙈) when querying for font or codepage on a file with a non-text #SAUCE type.
* Try to parse something meaningful even out of partially broken SAUCE dataYep, the possible crash was the reason to create a release even for a pretty "small" bugfix. 🙄 Chances are nobody would have noticed though, the SAUCE *display* was not affected, only the machine-readable query (-q).
Screenshot: The "offending" file. It even had literal ",1" written in the month field of the SAUCE date, but obviously meaning January here 😂
-
#dos2ansi v1.6:
https://github.com/Zirias/dos2ansi/releases/tag/v1.6* Fix cursor movement again, it never wraps or scrolls.
* Many smaller improvements to the #showansi script
* Add an example configuration using scalable fonts from https://int10h.org/oldschool-pc-fonts/ instead of the default bitmap fontsScalable fonts are a tradeoff here. You get freely configurable sizes and correction of aspect ratio. You lose pixel-perfect (perfectly sharp) display. You can't have both, unfortunately.
Screenshot shows scalable fonts 😉
-
There was still room for improvement ....
From "just needs a little #script to turn #dos2ansi in a nice ANSIart viewer" to a ~400-lines "monster" in 8 days ... 😂
It *should* work well with any #POSIX #shell. I hope so. 🙈
https://github.com/Zirias/dos2ansi/blob/master/src/bin/dos2ansi/showansi.in -
It's done, #dos2ansi v1.5 is here:
https://github.com/Zirias/dos2ansi/releases/tag/v1.5Apart from supporting all the cursor movement and screen erasing sequences that were needed for that silly file I found, there's now also support for the screen mode setting from ANSI.SYS (with non-text modes silently ignored).
There are also tons of little improvements to the "showansi" script, which should now work very well as a generic DOS ANSIart viewer picking reasonable defaults (and making it easy to override them if really necessary).
Example screenshot includes rendering this silly file again 😂
Have fun, and if you need some files to display, have a look at https://16colo.rs/
-
Just released dos2ansi v0.4, with lots of #DOS #codepage s supported and a testmode to display them.
The next nice feature would be to use the actual terminal capabilities if output goes there. Very simple on *nix-like systems (#Linux, #FreeBSD, ...), just link #curses and use the termcap functions.
Thinking about #Windows again, either I keep relying on #UTF8 support (since #win7 IIRC? and still a bit buggy) and #ANSI sequences support (since #win10) .... OR I attempt to use the native #Console #API there (using special functions to write in #UTF16 and other special functions to set colors, which would require a major refactoring first 🙄)
-
New pre-release of dos2ansi: v0.2
* Works on #Windows, win32 binary (cross-compiled on #FreeBSD) attached
* Selectable input #codepage (so far only #cp437, #cp850 and #cp858)
* Selectable output format, #utf8, #utf16 or #utf16le, with or without #BOMStill a few things to add, e.g. use #termcap/#terminfo or Windows Console API for "color output" when applicable ... we will see 😎
-
@cobbpg @jos1264 Just look at the size of the JVM. If the benchmark is your typical #C64 hand-written assembly code, this certainly qualifies for "bloat" 😈
Regarding features, yes, #kickassembler has an insanely powerful macro language, actually more like a full-blown scripting language in disguise. That makes it quite popular among demo coders, for example.
What it lacks (at least for my "taste") is a linker. Defining your memory map in a "linker script" and then just filling segments (including e.g. #zeropage) in individual modules, leaving the hard stuff to the linker, is a whole new level compared to traditional toolchains more similar to what you had on the real machine.
I can easily use whatever language I like to precalculate my triangulated sprite flight paths or whatever ... but I can't replace a linker with external tools 😂
-
@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).
That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).
Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.
-
@lobocode They're just very different.
#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...
Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").
#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).
-
@mos_8502 Probably because (even 😏) tex is more readable (and, of course, more verbose) 😉
The only thing that still forces you to use (a limited subset of) #roff (with some macro package) is authoring manpages that should work "everywhere" (read, systems without #mandoc support) 😉
Of course, still an interesting thing to cover. I guess "power users" (having to typeset stuff a lot) would actually like the pretty terse syntax.
-
@dawnraad There are dozens of solutions. If you really want to still use physical #floppy disks, a 1541 can be hooked up to a PC, nowadays typically using some USB adapter (there are several available), but if you have an old PC that still has a parallel port, a quite simple cable with just a few resistors and diodes would do as well (there are manuals to build one). For software, I'd recommend #OpenCBM with that.
Most people nowadays prefer to emulate the floppy instead. The "cheap" solution is called #SD2IEC ... working somewhat well, but failing with software trying to directly program the 1541 (like custom fastloaders as used in many games and demos). A very comfortable solution would be the 1541-Ultimate-II+, which offers perfect 1541 emulation plus several other goodies like ethernet (push your software with FTP, launch it remotely using telnet) 😎
-
@dani Haha 😎
I'm running a (heavily configured) #fvwm3 here. This screenshot was just for demonstration that #dos2ansi and #showansi don't depend on any configuration, so this was a completely unconfigured X session in #Xephyr, which by default runs #twm.
You can even see the test mode in #xterm can only use 8 colors (because this is what the default xterm #terminfo entry announces), still the #xterm windows launched by #showansi have full color support, they explicitly set the terminal name to "xterm-256colors".
-
Not having added anything to #dos2ansi for a while now, I'd say v2.0 is the "final" version for now. I initially wanted that for v1.0, and it's amazing how many weird files, edge cases, and also ideas for improvements you can discover for something that "simple" 🙈
I have ideas for future development, like provide the core functionalities as a shared library, like add some config file for dos2ansi itself as well (instead of just for #showansi), maybe even more ... but all of that can wait, it's IMHO "complete" as it is.
A #Debian package is attached to the release on github, and a #FreeBSD port is added ... anyone wants to help make it available in more repositories? 😎 Would be most helpful if the fonts it uses by default are packaged as well and can be set as dependencies ...
https://repology.org/project/dos2ansi/versions -
#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?
Well, both excel and both suck, just in different areas. 🙈
When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.
gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...
bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.
-
And now, my little documentation generation tool can also produce manpages in #HTML format (this will be useful for the #Windows version of #dos2ansi) 😎
Using simple/minimal semantic markup, the "manpage style" is entirely left to #CSS
Screenshots:
- Desktop unstyled
- Desktop bright mode
- Desktop dark mode
- Mobile dark mode -
Now working on adding a manpage for #showansi as well. I noticed I need to add features to my "mkclidoc" tool in order to get something meaningful here ...
First step, added support for cross-references 😎 -- next thing needed will be documenting related files...
Next #dos2ansi release will probably just be nice and complete documentation!
-
Meanwhile:
* Added a #Debian (amd64) package to #dos2ansi v1.6 release (on Github)
* Updated the #FreeBSD port here: https://people.freebsd.org/~zirias/patches/0001-converters-dos2ansi-Add-new-port.patch
* There's of course still the #Windows binary attached to the releaseMight push the FreeBSD port to official ports later ....
Screenshot: Random #showansi rendering ... 🙈
-
Just noticed the #showansi script from #dos2ansi is now "smarter" than the renderer on 16colo.rs 😂
When there's no (#SAUCE) metadata indicating the font to use, but the canvas after rendering turns out to be exactly 80x50 or 80x43, it just *guesses* that's most likely the VGA50 or EGA43 mode and picks that font 😉
(Of course, this "smartness" can be disabled with the "-S" flag)
Compare to this: https://16colo.rs/pack/avpack16/frg-ans2.ans
