Quote:
I've created a tfdocgen package now, and modified libticonv to depend on it make install the documentation during the install process. I'll soon do this for all the others as well.
OK 
Quote:
Is it worth the trouble to try to isolate developer-oriented documentation files and bundle them into the *-devel subpackage instead? I doubt it is but I thought I'd check.
I'm not convinced either. At least, it's not a priority
Quote:
EDIT: Also, is there any extra documentation for either tilp or gfm that should be packaged? Or even for tfdocgen, I suppose?
FWIW, for both GFM and TILP, the documentation installed by the Windows (ISS) installers is a good start.
Quote:
If not, I think everything is now done from a packaging standpoint.
Good, but now, the code base is not ready (new ROM dumper, libarchive)... and it's too late for me working much on it tonight...
I'll have more time this week-end.
Quote:
EDIT 2: For the mean time I've disabled the call to desktop-file-validate in the tilp2 and gfm packages.
OK.
Quote:
I've built x86_64 and i386 versions of the packages and put them in a temporary yum repository running on my local server. The repo file for that is available here, and I've edited the first post to have more information about this.
Thanks for your work 
Bump. TILP II 1.17 was released (
http://www.cemetech.net/forum/viewtopic.php?p=202778#202778 ), though quite a bit later than originally planned
The embedded fork of minizip is not used anymore, the code base now requires libarchive. The files containing the fork of minizip remain, though.
Lionel Debroux wrote:
I'm currently a bit swamped with (academic) work at the moment, but when I have a chance to breathe, which will hopefully be this weekend, I'll update the packages in my own repo, and then see where we stand again with regards to submitting them to Fedora.
Bump!
TiLP 1.17 (and gfm) for Fedora (preferably 18, but it should work on 17 too) can now be installed via yum from
here.
rpmlint is mostly happy, although some of the documentation files seem to have the wrong file encoding. Assuming that's actually a problem, I can just add a dos2unix command in the spec files to take care of that.
Everything else seems to be working, though!
Great
I didn't receive the e-mail notification for your latest post, but it's not necessarily the fault of the MTA / MTS used by Cemetech: Yahoo! Mail can delay some messages significantly at times...
What are the exact errors rpmlint spits ? I'm supposed to have fixed most encoding issues in the main source tree.
Here are the file encoding complaints:
Code: gfm.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/gfm-1.07/README
libticables2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticables2/html/style.css
libticalcs2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticalcs2/html/style.css
libticonv.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticonv/html/clean.bat
libticonv.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticonv/README
libticonv.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticonv/ChangeLog
libticonv.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticonv/AUTHORS
libticonv.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libticonv/html/style.css
libtifiles2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libtifiles2/html/style.css
libtifiles2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/libtifiles2/html/clean.bat
tilp2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/tilp2-1.17/RELEASE
tilp2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/tilp2-1.17/README.linux
tilp2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/tilp2-1.17/README
tilp2.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/tilp2-1.17/AUTHORS
Thanks.
README.linux should definitely use LF ending, and the style.css + ChangeLog files could conceivably use LF ending as well. However, the others should stay CRLF in upstream, for Windows compatibility.
In your spec file, in addition to using dos2unix, you could remove all .bat files from the installed tree. I should probably remove them from upstream, they haven't been used for years.
Major bump!
I'm pleased to report here that the entire libti*/tilp2 stack has finally been packaged and accepted into the official Fedora repos.
Everything but tilp2 itself should be available on Fedora 21-24;
tilp2 has now been built for Fedora Rawhide as of this afternoon, but has not yet been pushed to the stable repos. This should take approximately a week to happen.
Since I appear to have become Fedora maintainer for TI calc stuff, I guess the next thing to package is tiemu?
(Alas, gcc4ti is almost certainly impossible to package officially what with the bundled gcc and binutils).
Quote:
I guess the next thing to package is tiemu?
Er... no. Just... no. Really, don't bother, look elsewhere, towards e.g. spasm-ng or tilem2, which are in a better shape and have more users
The TIEmu code base has been basically unmaintained for four years, because it is an unmaintainable mess. I last built it myself for my own computer in December 2011, and that wasn't the GDB-enabled version, with good reason.
Nobody deals with the complexity of that weird mixture of multiple patched forks of severely outdated third-party programs (GDB, Insight, etc. - that alone is a reason for Fedora to refuse packaging it anyway), sticked together by a fragile build system. Oh, and one piece of code which jumps through hoops to make GTK+, Tk, KDE and whatever event loops I forget somehow work together.
The GDB version has always been slower and more buggy than the non-GDB version used by most people - and despite the fact that keeping both versions available further increases the complexity, Romain did the right thing by mandating this: at least, the non-GDB version remains semi-usable.
ncubate_emu's GDBstub, which I ported forward to newer nspire_emu releases before it eventually became integrated to nspire_emu, and therefore its Firebird Emu offspring, is a better design. Less complexity in the program itself, more maintainability in the short and long term, more user choice wrt. GDBstub clients are obvious upsides; downsides are less obvious (less featureful ? I haven't thoroughly examined the feature aspect of the matter).
Did I mention I seldom hear users reporting that http://lpg.ticalc.org/prj_tiemu/downloads/install_tiemu.sh keeps pointing to a SVN repository which disappeared about two years and a half ago ?
The horrible state of the code base, and the already low number of users 5 years ago (which makes it thoroughly unjustifiable and insane to spend man-months cleansing the mess), are the reasons why I worked for a while on largely improving the JS emulator started by PatrickD. That is more forwards-looking for current and future users of TI-68k technology. Times have changed, and browser-based tools (or at least, a browser-based version of a native code base, obtained through e.g. emscripten) have become the correct way to propose software to many users.
If I were to restart a TI-68k emulator project now, I'd use a C or lightly C++ code base (effectively closer to what TIEmu is) and leverage the LLVM infrastructure to translate that to JS, soon WebAssembly. In 2011-2013, when I worked most on the JS TI-68k emulator, Emscripten was less of a usable technology than it became in 2014 onwards.
Quote:
(Alas, gcc4ti is almost certainly impossible to package officially what with the bundled gcc and binutils).
Yes, clearly. But at least, it's far more maintainable than TIEmu is, because we spent time preparing the EOL of GCC4TI, especially increasing portability and streamlining the build process.
In general, I prefer working on backend stuff than on GUI stuff. I'm spending most of my time programming for the TI community in libti* because of that, and because it benefits multiple clients of those libraries
Lionel Debroux wrote:
Quote:
I guess the next thing to package is tiemu?
Er... no. Just... no. Really, don't bother, look elsewhere, towards e.g. spasm-ng or tilem2, which are in a better shape and have more users
I mean, you're right (and I haven't tried to compile tiemu myself for years-- I have it installed on a couple of Windows boxes and compiled it years ago on a few Fedora workstations), but this makes me sad-- I like having a 68k emulator. Admittedly, I am in a extreme minority of TI calculator people these days.
I was only semi-seriously planning to do this-- I mean, the libraries are in the distribution now. Probably what I would do (if I can get it to work without spending a huge amount of my time on it) is stick tiemu in a copr (copr.fedoraproject.org).
I wasn't aware of more than gdb being forked and embedded, but it's not entirely surprising. At least it's possible to disable gdb.
I have considered packaging spasm-ng though.
Quote:
The horrible state of the code base, and the already low number of users 5 years ago (which makes it thoroughly unjustifiable and insane to spend man-months cleansing the mess), are the reasons why I worked for a while on largely improving the JS emulator started by PatrickD. That is more forwards-looking for current and future users of TI-68k technology. Times have changed, and browser-based tools (or at least, a browser-based version of a native code base, obtained through e.g. emscripten) have become the correct way to propose software to many users.
If I were to restart a TI-68k emulator project now, I'd use a C or lightly C++ code base (effectively closer to what TIEmu is) and leverage the LLVM infrastructure to translate that to JS, soon WebAssembly. In 2011-2013, when I worked most on the JS TI-68k emulator, Emscripten was less of a usable technology than it became in 2014 onwards.
That does sound like a much better plan (although I have to admit that I'm somewhat skeptical of the "everything is a web application" future).
Whatever happened to the JS emulator? I admit I don't really remember much about it.
I'd be willing to contribute some time to such a project, although unfortunately I don't have much of that to spare.
If I worked on any 68k-related thing in the future it would likely be trying to get the gcc4ti linker able to build flashapps. Not that this is likely to happen in the near future either (or, realistically, be of much use to anyone, but meh). I'm also not much of a frontend developer.
Quote:
Probably what I would do (if I can get it to work without spending a huge amount of my time on it) is stick tiemu in a copr (copr.fedoraproject.org).
Do you have a plan for handling bug reports, which starts with fixing issues reported years ago, some of which are severe enough to be noticed in a matter of seconds by new users of the packages, e.g. direction keys not working anymore (yet another time, after another round of changes in the Linux input stack years ago) ? I sure don't...
Quote:
That does sound like a much better plan (although I have to admit that I'm somewhat skeptical of the "everything is a web application" future).
Web applications will never replace native code entirely, for expressiveness and efficiency reasons. However, modern JS JIT engines are fast enough to emulate severely obsolete platforms such as the TI-Z80, TI-68k and TI-eZ80 series at native, or at least decent, speed. And contrast the ease of install of jsTIfied / the JS TI-68k emulator with the ease of install of fat client applications such as TIEmu / TilEm... install-less Web apps win, hands down.
Of course, when a closed-source, obfuscated application (or its developer) goes away, for whatever reason... too bad for the users who put their eggs, for convenience or simply being unaware of the pitfalls, in the closed-source app. That's why multiple of us campaigned so hard for SpiroH to do the right thing for the community. He still hasn't done so, but his creations are irrelevant now that there's Firebird Emu, which has a superior emulation core, is more portable with less effort thanks to Qt, and is open source, as should be any derivative of an open source emulator
Quote:
Whatever happened to the JS emulator? I admit I don't really remember much about it.
I did not advertise it that much, because it's not in the shape I'd have wanted it to be. However, it's usable nevertheless: it has been powering TI-Planet's online emulation of TI-68k archives for over two years, though I'm not sure how many people actually use it. It has found a bug in TIEmu and a bug in ExtGraph, after ExtGraph provided reduced testcases for fixing multiple bugs in the emulator.
The GPL'ed source code is available, without any kind of minification / obfuscation, from https://tiplanet.org/pad_ti68k_emu/ or https://tiplanet.org/pad_ti68k_emu/v12.html (the former is a symlink to the latter). Adriweb once spent maybe a couple hours building a nicer UI, http://tiplanet.org/emu68k_fork/v12.html .
The source code contains the todo list. Given enough time, I could attempt to create a Github repository filled with a subset of the older versions I saved, at least v12 and perhaps v11. Sadly, unlike multiple other projects of mine, creating a tarball / ZIP file of a coherent set of files is only a recent addition to the build script, so pairing the JS file with the relevant HTML file may take a bit of work.
Quote:
Not that this is likely to happen in the near future either (or, realistically, be of much use to anyone, but meh).
Exactly, sadly. It would have made sense in 2009-2010, shortly after we factored the signing key, but TI-68k native code programming was already pretty much dead for over two years at that time anyway. Most active TI-68k developers have switched to GCC4TI, with good reason, but a better toolchain is obviously not enough to single-handedly grow back activity in a community. The TI-68k community hasn't had its Axe - or more precisely, people did not pick up e.g. Newprog, sadly.
In 2015, TI imported the TI-68k FlashApp format into the TI-eZ80 series, but COFF is not ZDS' favorite output format, AFAICS in its documentation / the TI-84+CE compiler topic.
Lionel Debroux wrote:
Quote:
Probably what I would do (if I can get it to work without spending a huge amount of my time on it) is stick tiemu in a copr (copr.fedoraproject.org).
Do you have a plan for handling bug reports, which starts with fixing issues reported years ago, some of which are severe enough to be noticed in a matter of seconds by new users of the packages, e.g. direction keys not working anymore (yet another time, after another round of changes in the Linux input stack years ago) ? I sure don't...
...oh. I didn't realize it was that bad.
Well then. Nevermind... goodbye, tiemu.
Quote:
Quote:
Whatever happened to the JS emulator? I admit I don't really remember much about it.
I did not advertise it that much, because it's not in the shape I'd have wanted it to be. However, it's usable nevertheless: it has been powering TI-Planet's online emulation of TI-68k archives for over two years, though I'm not sure how many people actually use it. It has found a bug in TIEmu and a bug in ExtGraph, after ExtGraph provided reduced testcases for fixing multiple bugs in the emulator.
The GPL'ed source code is available, without any kind of minification / obfuscation, from https://tiplanet.org/pad_ti68k_emu/ or https://tiplanet.org/pad_ti68k_emu/v12.html (the former is a symlink to the latter). Adriweb once spent maybe a couple hours building a nicer UI, http://tiplanet.org/emu68k_fork/v12.html .
The source code contains the todo list. Given enough time, I could attempt to create a Github repository filled with a subset of the older versions I saved, at least v12 and perhaps v11. Sadly, unlike multiple other projects of mine, creating a tarball / ZIP file of a coherent set of files is only a recent addition to the build script, so pairing the JS file with the relevant HTML file may take a bit of work.
Interesting; I'll have to take a look at it sometime.
Quote:
Quote:
Not that this is likely to happen in the near future either (or, realistically, be of much use to anyone, but meh).
Exactly, sadly. It would have made sense in 2009-2010, shortly after we factored the signing key, but TI-68k native code programming was already pretty much dead for over two years at that time anyway. Most active TI-68k developers have switched to GCC4TI, with good reason, but a better toolchain is obviously not enough to single-handedly grow back activity in a community. The TI-68k community hasn't had its Axe - or more precisely, people did not pick up e.g. Newprog, sadly.
Yeah, I know. Every so often files show up in the 68k calcs' archives on ticalc.org, and every so often somebody posts about a project, but there's certainly no community to speak of.
At this point, my motivation is mainly "it would be a shame if we are never able to compile flash-apps for the 68k calculators using the community toolchain, even if maybe one person every couple of years wants to actually do this".
Quote:
In 2015, TI imported the TI-68k FlashApp format into the TI-eZ80 series, but COFF is not ZDS' favorite output format, AFAICS in its documentation / the TI-84+CE compiler topic.
Huh, I didn't know this-- then again, I haven't been very up to date on the ez80 stuff that's been going on.
I found copies of the old manuals for the Sierra C compiler and SDK (along with TIFS itself) via the Wayback Machine; figured that really should be enough information (and if not I can get TIFS running on Windows somehow or under Wine or..) to get this sort of thing working. I would really like to spend a couple of weeks next summer on this, but we'll see.
The sad thing about the 68K community is that it died several years earlier than it should have, and it was not because of TI, because it happened before the TI-Nspire became a thing. But given the circumstances in 2005 and 2006, preventing that premature death would have been impossible.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
