@critor, I hope it's not too late and that you'll see this in time.

I understand that transferring files to/from the calculator is out of the scope of possible things.

I'd like to know if add-in languages (like Russian on the fx-CG 20) are still supported, but without a preloaded g3l I guess we have no way of knowing without transferring files. Can you at least tell us the list of built-in languages and respective versions (shown in the Version screen of the System app)?

Besides BASIC speed which can be useful for guessing the CPU speed, the only other thing I can think of that could be tested (given that you already entered the diagnostic mode) is checking if the Test Mode still exists / can be entered with the following key combination:
Press [OPTN]+[EXP]+[AC/ON]
Quickly type 5963
(I think this has to be done starting with the calc in standby state)

If yes, I'd love to see a picture of it - even if just to confirm it's the same as on the fx-CG 20.

Oh and another thing: in eActivity, when editing a document, does the STRIP option still appear on the function key menu, and does opening it show strips for all built-in apps and also Geometry, Pict Plot (and maybe 3D graphing?), etc.?

Finally, could you maybe ask someone where the Probability Sim add-in went and whether it will be making a come back? (maybe someone already deleted it from the demo calc, heh heh)

Quote from: Unicorn on February 15, 2017, 11:21:39 PMThe one thing I've found is that it takes from 15 minutes to an hour for the dotAccount two factor authentication to send me an email. Is there any reason that it takes so long?

I too have noticed that, and other people have complained. I blame it on Mailgun. The emails appear there as sent and accepted by the destination almost as soon as I submit them, but it takes some time until emails appear in people's inboxes. Perhaps one of these days I'll try to switch to an alternative service like Sendgrid.

Actually I have a redesign of the Windows client in progress, to use WPF instead of Windows Forms. I posted some screenshots earlier in this thread. But I haven't worked on that in like two months, and it's yet another thing I have not yet found the time nor motivation to continue. The fact that the UI is also apparently becoming slower and more memory intensive isn't very motivating, either, but that could be due to these being debug builds and having the Visual Studio debugger attached.

The work on Linux client lags even more behind, the fact that there are so many desktop environment configurations doesn't make development easy at all, especially for something that requires a tray icon - something most desktop environments, since a few years ago, have all agreed to disagree on how it should work.
Some have kind of dropped support for tray icons, others use appindicator - with varying degrees of functionality/compatibility - and others are meant to support just about anything but then it turns out it's really buggy. What's a left click in some turns into a right click in others, sometimes you can set a tooltip and other times you don't, or the tooltip turns into a badge, or the badge overrides the tooltip... and then there's the icon, which in some desktops appears fine and others is just a blank space.
And then there's the question of whether the distro/environment in question supports the right version of GTK with the right libs, and whether packages for certain Python dependencies are available or not, etc..
And there's the problem that it's Python, because apparently it's the only language with some support for GUI toolkits that is not C or C++ (while I have enough experience with those, I really don't want to be dealing with networking and message packing/unpacking in them). There's Mono, but guess what, there you must use GTK 2 (which surprise surprise, some distros no longer come with it either!) because the GTK 3 bindings are buggy/incomplete/focus on old GTK3 versions only. Also, it turns out I can't port much of the Windows code at all.
It's really infuriating... I could go on for hours.

@123outerme
Somehow, the forum failed to notify me about your message, and this is not a very popular topic so it took until now for me to see it 

Glad to know you find the service useful.

The battery information window you're talking about is a system activity that is only available in some devices. Clouttery hides its option when it's not available. I think some manufacturers (namely Samsung, I think?) never included it in the first place, and my generic Chinese phone running a Android 7.1 ROM very close to AOSP doesn't have it either. With it being gone from AOSP, I don't think it's coming back.

I'd like the Clouttery Android app to evolve to the point where it completely replaces that window (it can already display and log the battery temperature...), but for now it may be better to use a separate app for that kind of detailed stuff.

---

I finally found some motivation to work on this project again. I had some ideas for features that were starting to be kind of hard to implement using the current database system (a simple key-value store with buckets, see https://github.com/boltdb/bolt ), so I'm currently on day three of rewriting a significant portion of the server to work with relational databases instead, using SQL queries. This should also make it easier to scale the Clouttery server to work on multiple machines by using a database with replication support.
I'm thinking of using https://www.c*ockroachlabs.com/ (access that URL after removing the asterisk, because the forum apparently censors the substring(0,4) of C*ockroachDB  ). If that doesn't work out, the SQL I've been writing should be compatible with PostgreSQL.
Most things already work even if not especially optimized, but I still need to test the hell out of this and ensure the server is as secure as before, before pushing it to production. And most importantly, write code to migrate the data from the current Bolt database to the new one...

Thanks for letting me know you have a sub-4.0 Android device, if there are enough people with such devices it might make sense to develop a client for such old versions. It'd be great if people with an interest in adding such devices to Clouttery posted here, so I can have a better idea of how common this situation is...

BTW, in the topic of old devices - if you have a Windows Mobile 5.x or 6.x device (with touchscreen) I have also built a simple client for that OS. It's incomplete and unreleased, because I only developed it as far as I needed for my purposes, but if anyone is interested I can make it available or even turn it into a more complete client.

USB Type C and USB 3 require support from the SoC or eventually from a separate interface connected to it through a high-speed bus. It's much more than just playing with connector sizes like when you go from a 2.0 standard A connector to miniUSB or microUSB.
Since none of the cheap single-board computers on the market right now support USB Type C (and I don't think any support USB 3 in the sub-$50 range, either), it's probably going to be a couple of years before we see hobbyist projects using Type C.

Quote from: DJ Omnimaga on January 13, 2017, 04:52:13 PM
@gbl08ma worse than this, there are rumors that a new Prizm with zero add-in support is coming out soon >.<

I guess people who want to be able to run custom software on their own calcs that is not Casio's slow-as-molasses basic, will just choose TI instead. I find TI's software to be way less user friendly, and the hardware specs on their non-Nspire lines are way worse, but if that's what it takes...
The Casio calculator community has always been much smaller than the one for TI calcs: there are fewer users and fewer projects. I find the Casio calcs to be much nicer to program than Z80-based TI ones (more memory, you can use C and even parts of C++ without issue...), and easier than Nspire ones (no need for calculator "jailbreaking"). But the set up and learning curve is way worse: you have to set up a SDK (or in the case of the Prizm, a "development environment" that basically revolves around some fork of libfxcg, or if you want to be 5 years in the past, Simon's hacked together stuff), figure out how to program in C (vs. using Basic on a TI calc which already gives decent performance), etc. In that aspect the classic TI calcs are easier - you don't even need a computer.
To sum this paragraph up, I find Casio and Nspire calcs to be easier to develop for if you already know how to code and have some experience around a command line, be it Linux or not. TI's non-Nspire are better to get random strangers into programming.

Such a move against 3rd-party software can alienate some customers, even those that would not care about calc games and such things. I remember that back in high school few people installed add-ins/games, and the people who did, often forgot about them - after all, if you have a smartphone and are already well trained in hiding it during class, what's the advantage? However, if at the time of choosing between two models/brands, word had spread that one of them didn't allow games or whatever, I can totally see people going for the one that supported them even if they ended up making zero use of that "feature" throughout their high school years - just because it seems appealing at the beginning.

Fortunately the "niche" of attracting young people to learn programming and introduce them to the Von Neumann and Havard architectures (i.e., basically learning how today's computers perform their magic) seems to have been more or less fulfilled by cheap SBCs like the raspi, or the desire to build yet another Android game. The hard task is getting those SBCs into the hands of people, or getting users to know that yes, they too can make apps, that it's not a superhuman-exclusive activity, that computers are not TV and allow for more than content consumption.
In other words, calcs getting more and more closed down is not the end of the world, except maybe if your main goal was to cheat in exams. But everyone, including calc makers, must keep in mind that some people will always find a way.

Oh my gosh this just turned into a huge rant...  but all of this highlights the importance of recognizing independent development and I think things like the CW project awards are a great way to do that.

Of all the projects that won the monthly project award, there's only one that doesn't target TI calculators, which is the Internet on Casio Prizm one. I'm not complaining but I couldn't help but find some humor in this, in the sense that project never even went beyond much of a "thought experiment" attached to a single-commit git repo, but it was so interesting and exciting that it still won the monthly award for July. The reason why it never progressed further, and now comes the sad part of the funny part, is that Juju's effort was hampered by yet another bricked Prizm - and because of the incessant bricking stories and other problems, other Prizm developers have pretty much lost interest in the platform, myself included.
In retrospective, I think this sad story perfectly sums up the Prizm development scene over the last couple of years.

As kind of an homage, and also because I don't have a TI-84+ or 84+CE and thus can't properly judge the other winners (and I think it would be unfair to decide solely based on forum posts, as the competition is quite tough), I guess I'll vote for the "TCP/IP on Prizm dream". It makes for a good "else case" for people who can't decide among the other ones

It runs on Android 4.0.3 and up.
In the future, if there's enough interest I can always build a "lite" client that runs on older Android versions, at the expense of having little to no features (such version would only be for sending battery information, so it's easier for people to keep old devices alive if they so wish for whatever reason).
But for now I see no reason to go through the additional effort to support Android 2.x.

Quote from: DJ Omnimaga on January 06, 2017, 11:29:20 PM
EDIT: Also a bug report on the Android client: If I clear my notifications, they re-appear just two seconds later, fully intact.

Yes, I have noticed this sometimes happens. It may be worse with faster connections. It should be easier to clear them for once if you go back to the home screen of your device (so the app isn't in the foreground), then clear the notifications from the Android notification center. That way it won't re-sync before sending the information about cleared notifications.

I have not yet identified why this happens, as I'm explicitly checking whether there are new cleared notifications (and sending their status) before fetching the current notifications. Perhaps there's a code path I am not aware of.

That is really strange. I never experienced that problem on any of my (and my friends') Windows 10 machines, just the standard SmartScreen warning.

Were you trying to download over HTTPS? Because if yes, your ISP should not be able to interfere (besides dropping the connection altogether, which may be the cause of the "connection reset" error). Get a better ISP, I guess...

Another month has passed and I barely had time to touch Clouttery. Unfortunately, it doesn't seem things will change any time soon - hopefully, by the end of this month, I'll have some more time. Here are the few changes since my last post:

• The Android app had a few minor adjustments, mostly cosmetic. Make sure you have the latest version, 0.9.4
• On Android devices, Clouttery now collects battery temperature. Clients don't show it in the history graphs yet, but you can see it in the Web Console graphs: https://clouttery.xyz/manage
• The Clouttery website (and some other Segvault websites) now support HTTP/2, yay!

Additionally, I just created a Matrix room for Segvault. This is highly experimental. The idea is that users and developers can get together to discuss Segvault and TNY network projects, and maybe do a bit of "self-service support" too.
Why Matrix? Well, it does everything we need, signing up for an account is not mandatory, it's more powerful than IRC, not a closed platform like Skype/Discord/Telegram/etc., you can use it without installing more software, and it integrates well with Slack - which we were already using internally, so the Matrix room just appears as yet another channel on Segvault's Slack.
Here's the link: https://riot.im/app/#/room/#segvault:matrix.org

Sorry for the lack of updates, uni is keeping me very busy. I'm slowly porting the Windows client from Windows Forms (which while not deprecated, is quite outdated) to WPF. WPF should be better suited to the high amount of UI elements in the devices window, and hopefully it will reduce the UI "lag" (all those redrawing flashes you see when the window opens or is resized). I'm also taking the opportunity to redesign the tray window, to look more modern and touch-friendly.

Without further ado, here are two screenshots of the screens that are already converted:



(note that both images are at 150% scaling because of my DPI settings)


Once in a blue moon, I work a bit on the Linux client. But it has a lower priority than implementing new features on the server and other clients, as not too many people seem to be interested in it.

Yes, since the last update, it now uses Google Play Services. I'm unsure of how it behaves if installed on a device without them - let's see if I don't forget to test. I can make builds without the Play Services and distribute them through parallel channels, but I don't feel like maintaining multiple build flavors and distribution methods.
For those who can't install through Google Play, the APK is still kept up-to-date at https://clouttery.xyz/static/android/Clouttery.apk , but I no longer issue notifications about app updates, so you'll have to keep up yourself. However, I would much prefer if people installed through Google Play as that aggregates the statistics (and increments the installs counter), and also gives me access to crash dumps (not that there have been any, so far).

There's a minor Clouttery Android app update, that pretty much doesn't affect existing users: one can now sign in with one of the Google accounts configured on the device, without having to type usernames or passwords.

Should get approved by Google in a few hours. The update was approved by Google right as I was writing this post

I have noticed that of the 18 app installs, there were 5 uninstalls... I wonder what can be done to make the app/service correspond better to the expectations of new users.

Time for a quick update.

The server, and the Web Console, have been updated. The main change is that the new billing system has gone live, as you can see by going into Settings -> Billing in the Web Console ( https://clouttery.xyz/manage/settings/billing ). In order to help beta-test this system, some changes were made to the accounts of the existing users.

1. Everyone was moved into the new "Unlimited" plan, which is just like the old "Segvault Insider" plan, except it costs $5 per month.
2. Before you panic, a 100% off coupon was issued to everyone.

In practice, what this means is that beta-testers will still get Clouttery for free, for life, but they will be "billed" on a monthly basis. Every month, an invoice for $5 will be generated... and immediately paid by the 100% discount coupon. Or at least, this is what is supposed to happen. Everything was very well tested before pushing to production, but there's nothing like testing on a live system.

This also allows beta-testers to test a bit of the billing interface, including the invoice viewing page. You can also add a credit or debit card to your account, but since we're still testing Stripe, it is still in test mode. So you can only use the fake card numbers listed at https://stripe.com/docs/testing. If you're really in the mood for helping us, you can try to trick the system into accepting an invalid fake card, like 4000000000000069. Or you could add many, many different payment methods and make the system unbearably slow, or break it.