AxePad crashing when try to open/save a file

#41
...with five machines running Mint in our household....
I guess it is only a matter of weeks before Mint 18 is released, so an update may change the picture for you (e.g. it may fix your immediate problems, it may introduce others).

Wine has its own set of problems and frustrations (should have been called "Whine"). As it relies on its own code base, your host Linux, the Windows application you are trying to tame, and the interaction with a bunch of Windows DLLs and OCX components, it sure is a recipe for disaster.

So although you say "it can be made to work" [using Wine], that is no different from saying that LinAXEpad can be made to work on a Linux distro. It is just that there are fewer variables in the latter.

I think I've said this before, but it would be very helpful (and, I believe, beneficial to Rev Ed) if they made LinAXEpad Open-Source. A few Linux people could then fix and improve it!

Rev Ed's business model is about selling hardware, so the better the software support, the greater the hardware sales.
 
#42
I guess it is only a matter of weeks before Mint 18 is released, so an update may change the picture for you (e.g. it may fix your immediate problems, it may introduce others).

Wine has its own set of problems and frustrations (should have been called "Whine"). As it relies on its own code base, your host Linux, the Windows application you are trying to tame, and the interaction with a bunch of Windows DLLs and OCX components, it sure is a recipe for disaster.

So although you say "it can be made to work" [using Wine], that is no different from saying that LinAXEpad can be made to work on a Linux distro. It is just that there are fewer variables in the latter.

I think I've said this before, but it would be very helpful (and, I believe, beneficial to Rev Ed) if they made LinAXEpad Open-Source. A few Linux people could then fix and improve it!

Rev Ed's business model is about selling hardware, so the better the software support, the greater the hardware sales.
I agree wholeheartedly. When Windows programmes just work under WINE it's great; seamless to use and no apparent difference from running Windows. There's one Windows programme I still use that runs exactly the same under WINE as it does on Windows, and was one of the reasons I made the final switch to Mint around 2 years ago now. I still have an old Windows XP netbook, and at the moment the only reason for retaining that is for writing Picaxe code using PE, but the small screen is a nuisance, as is connecting it up to a bigger one to make it more usable. Sooner or later it will fail, which is one reason I want to make the switch away from any dependence on Windows at all if I can.

Axepad works fine, with the sole exception of the rather critical file save problem. I can work around this (in fact I do a lot of the time) by cutting and pasting the text into a text editor to save, then letting Axepad crash, restarting it with the saved text etc, etc. It's tedious, but does work. As you say, opening up Axepad so that others could have a crack at fixing the file save problem would be a great idea. I can wholly understand Rev Ed not having the resources to sort it, but I can't help but feel that whatever the problem is that makes it crash could be resolved fairly easily if a few bright individuals had a look at the code.

As Windows shifts to a different business model, rather like Google and Android, where they no longer sell a licence to use the product, but give it away and make their profit from gathering and selling your personal data (which is, in essence, how Windows 10 is starting to work) then I can see that more people might want to switch to an alternative. With some of the better Linux distros being as easy, or even easier, to install and use than Windows, and with them having bundles of extremely capable open source applications, together with the far better level of inherent security and the massively improved performance over Windows, it does seem only a matter of time before there are significant numbers of users within Rev Ed's target market that may be using Linux.

With the success of the Raspberry Pi, and that introducing Linux into the education sector on a relatively large scale, then there seems to me to be a natural synergy between having a classroom full of pupils familiar with using Linux on the Raspberry Pi and then using that to write code to run on hardware projects based on the Picaxe.
 
#43
...With the success of the Raspberry Pi, and that introducing Linux into the education sector on a relatively large scale, then there seems to me to be a natural synergy between having a classroom full of pupils familiar with using Linux on the Raspberry Pi and then using that to write code to run on hardware projects based on the Picaxe.
Yep, I'm such a cheap-skate that I don't even use a programming cable: http://captainbodgit.blogspot.co.uk/2015/05/picaxe-programming-with-pi.html
 

hippy

Technical Support
Staff member
#44
I think I've said this before, but it would be very helpful (and, I believe, beneficial to Rev Ed) if they made LinAXEpad Open-Source. A few Linux people could then fix and improve it!
Unfortunately having the source would not allow the issue to be fixed because it does not appear to be a problem with AXEpad itself but in the underlying Linux system or libraries. AXEpad works on many Linux systems but Mint seems to be particularly problematic in some specific areas. When AXEpad invokes the open or save file function, it is not really AXEpad's fault if something then blows up underneath its feet.

Having the source would only allow people to see that AXEpad is simply making the call to open or save a file it should and that there is nothing wrong in the way that is done which works on other Linux systems. Further use of the source would not be practical without access to proprietary and paid-for tools used to create the executables. That may not be how some would like it but that's the way it is.

It is unfortunate that using AXEpad does appear to be more problematic on Mint compared to other Linux distributions. Users have reported AXEpad worked on earlier Mint versions so it seems something with Mint changed. We do not know what changed or when, but it does point towards it being a problem with Mint and not AXEpad.

This is one of the reasons companies may sometimes be reluctant to support Linux; it is not that they don't wish to but that it can be so difficult and costly to do. When something changes with Linux or a distribution, another incompatible version is created, companies end up with numerous incompatible versions they are expected to support. They end up paying for the consequences of changes others have made. When a particular distribution doesn't work, suppliers get blamed and are expected to solve or work round problems within that distribution. It is not really fair to blame software which doesn't work with a particular distribution when it is the distribution that is at fault for that software not working.
 
#45
Thanks for that added information, hippy, although it does beg a fairly obvious question. Picaxe source code, as opened or saved by Axepad, is just a standard text file. In fact I get around the save problem in Mint by using Gedit to paste the text from Axepad into, then saving the text file with a .bas extension. Many hundreds of Linux programmes open and save text files, yet none that I've found crash when doing so with Mint.

So, the obvious question is, what does Axepad do when invoking a file save that is slightly different to, say, Gedit, Notepad or any other text editing programme?

There is a hint of a suggestion that it has something to do with the way that the full file path might be described, as sometimes Axepad will save a file OK (I've yet to work out the exact conditions when it works OK), and once it has saved it OK once in that session it continues to do so OK as long as you don't try and save the file with a different file name. As soon as you do that it inevitably crashes. I can't find anything documented with relation to Mint handling text files any differently to any other distribution, but clearly there must be something subtle happening, probably associated with the way the path to a file is remembered (or not remembered).
 
Last edited:
#46
Unfortunately having the source would not allow the issue to be fixed because it does not appear to be a problem with AXEpad itself but in the underlying Linux system or libraries....
Thanks for the explanation Hippy.

Yes, Linux can be a frustrating moving target, and there may well be a need to keep some aspects of certain application software "closed-source". But even issuing a simple list of [Linux] dependancies would be useful, as it may allow the user to add and/or upgrade packages in an attempt to get AxePad to work.

I suspect the solution to the Mint problem is quite easy, if only we knew where to look. As Jeremy says, it's only the simple bit concerning file access that seems to be the problem.

I've had similar weird problems on a Windows network where pupils with low access priveliges have not been able to run the Picaxe editor on a newly installed computer, until a staff user has run it for the first time. Either files or registry seem to have to be written to initially, before low level users can then open, run and access certain functionality.

Another possibility for AxePad on Linux might be to provide a core closed-source library covering the protected aspects of AxePad (although I have no idea which parts of the system are secret) with an API allowing developers to create their own application, adding their own functionality.

Just what the potential Picaxe user base for Linux is, I guess only Rev Ed can say. But when I started work supporting a local school 7 years ago, they were wall-to-wall Windows. During the last 7 years, many of the Windows computers have been replaced by Macs, Linux desktops & thin clients, iPads and Android tablets. And the Computer Science department also use RaspberryPi.

You have to make it really easy for schools to use your products on a range of platforms. If it is too tricky (actually, if it is just a little bit tricky), they will just drop it.
 
#47
Sorry for raking up an old thread, but for those having Axepad file save problems, accepting that Axepad is an end-of-life product, I just thought that I'd add that the file save/crash problem seems to have been resolved with the latest release of Linux Mint, 18.1. I've been using this for a few days, whilst playing about with VS Code, and today decided to load Axepad to see how it would work. The answer is that it seems to work flawlessly, which is odd, as it used to crash all the time under Mint 17.3 and 18.0. Still, if anyone is still interested, it looks like something has changed in Mint 18.1 that now make file handling work properly.
 
#48
Yes, this is weird. Although Mint seems to follow Ubuntu LTS (so 18.x is based on the April 2016 release rather than the newer October 2016 version) I didn't seem to have your problem when I was still running Lubuntu 16.04.
However I do get problems with other things that were working in the past, but get broken on recent releases (the mouse pad on my ASUS is one example).
 
#49
In my case, going from Mint 18.0 to Mint 18.1 broke the graphics resolution on my work bench PC. Took me the best part of a day of faffing around to fix it!

I've no idea why, but Mint 18.0 would happily accept an edited xorg.conf file to set the resolution (my old 19" monitor doesn't return the EDID correctly, as some old VGA monitors don't) yet Cinnamon locked up with 20 mins of disk thrashing when I did the same with Mint 18.1. After about three goes at getting it to work, much internet searching and looking through the Mint forums, I couldn't find a solution.

I did find that xrandr worked to change the resolution correctly, but only for that session; log out and back in and the resolution turned back to vanilla VGA, 640 x 480. In the end, I decided to try adding the xrandr commands at the end of the /etc/mdm/Init/Default and now have 1280 x 1024 resolution back again.

There's nothing in the Mint 18.1 documentation that mentions any changes to the way X windows works, or the fact that xorg.conf no longer works, which is another illustration of how things change from one distro release to another without most users knowing.
 
Last edited:
#50
In my case, going from Mint 18.0 to Mint 18.1 broke the graphics resolution...
Its a bit naughty of Mint to carry out such drastic changes on a ".1" version release (...or maybe its a new bug).

You probably know this, but Ubuntu derivatives should still work with xorg.conf files as long as they are now placed in: /etc/X11/xorg.conf.d/xorg.conf
Or if you don't have an xorg.conf.d directory, you can just use /etc/X11/xorg.conf

I've just checked that this works on Lubuntu 16.10 by adding this file on my system and playing around with my touchPad setting. But obviously I can't replicate your display config.
 
#51
I tried the usual /etc/X11/xorg.conf and it crashed, badly, although that's where I had the modified xorg.conf file in Mint 18.0 and it worked fine. I didn't try shifting it to /etc/X11/xorg.conf.d, maybe that would have worked.

By default, Mint doesn't have an xorg.conf file now, so it needs to be created to make changes like this, and I just replicated the copy of the file I had from when I modded Mint 18.0 to work with the same display resolution. I'll have a look and see if creating xorg.conf in the next folder down gets it to work, but right now it seems happy enough just running the xrandr commands during initialisation.
 
Top