Re: [Xastir-dev] Anyone working on patches: Consider merging "master" before continuing
On 2019-06-16 14:07, Bill Vodall wrote: > Hey Curt, > > You mentioned that it's now possible to run Xastir on Android - how > about firing up one of these sweet little Android TV boxes. The $60 > ones have 4 GB RAM. For $30 they come with 2 GB RAM - would that > work if we don't load Klingon? > > https://amzn.to/2MPjR6N > > The tech just keeps getting better and better. > > Bill > > PS. I think this is the info about running on Android: > > http://xastir.org/index.php/Android_via_GNUroot_and_XSDL The AllWinner chip in that box (an H6) isn't the best thing to use for Linux or Android (being derived from Linux). Support for the USB and PCIExpress is flaky. You're probably better off with a Raspberry Pi or a BeagleBone even if they do have less RAM. ___ Xastir-dev mailing list Xastir-dev@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev
Re: [Xastir-dev] Proposal to change project coding standards: Please vote!
On 2019-05-01 09:58, Curt Mills wrote: > Please don't be shy about voting! There are 118 people on the Xastir-dev > list and I've only seen 3 votes, including my own. > > If you're a C-coder and have an reasoned opinion we'd like to hear it and > see your vote. Anyone who's contributed in the past or plans to contribute > in the future, please vote. If you only look at the code sometimes and wish > it more readable/understandable for you, please vote. > My opinions: 1) tabs-only, no spaces 2) aligned braces 3) always use braces even when optional I like using tabs without allowing the tabs to be converted to spaces because I can dynamically change the indentation depth by simply setting the tabstop width. For most of the top level indentation I can widen the tabstops to make the code easier to scan and then, for reviewing deeply nested code, I can shrink the tabstops to get more text into view. Of course I also code in an extra wide xterm so depth of nesting isn't always a problem. At least with the tabs I can go all the way down to a single space if I needed to or I can widen it to any large number. The file never changes (the tabs are in the file already) and anyone viewing the file can see how many space width they want while actually coding. ___ Xastir-dev mailing list Xastir-dev@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev
Re: [Xastir-dev] More fun with Cygwin - automake complaint
On 2016-07-10 15:23, Jason KG4WSV wrote: > > >> On Jul 10, 2016, at 5:06 PM, davidf4 wrote: >> >> The joys of using a product that may or may not be updated.. > > Do very many still use Cygwin? > > I would have thought the availability of free virtualization would have > killed it off by now, especially for applications like xastir. > > But the Microsoft appears to be reinventing the Cygwin wheel, so maybe I'm > just out of the loop. > > -Jason I use both virtual machines and Cygwin. Cygwin is useful for some basic functionality without having to spin up an entire virtual machine. I use it a lot for scripting, making small C programs, using certain tools like Image Magick, and for getting some daemons (like sshd) running on Windows machines. I use virtual machines for very heavy operations like cross compiling, testing large daemons (e.g. Apache), and other situations for which Cygwin won't work. Having Xastir pop up in a near-native window on Windows instead of having to have a whole virtual machine is quite handy. ___ Xastir-dev mailing list Xastir-dev@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev
Re: [Xastir-dev] Any idea what libraries provide this?
This actually came up sometime in 2007 because of the gcc changes. One solution was in the following thread: https://gcc.gnu.org/ml/gcc/2007-03/msg01099.html Summarized as: #if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__) #define ELIDABLE_INLINE extern inline #else #define ELIDABLE_INLINE inline #endif Of course change extern to static for the current problems (apparently there was going to be another change to gcc that would affect 'extern'). On 2016-07-09 15:39, Tom Russo wrote: > On Sat, Jul 09, 2016 at 03:25:16PM -0700, we recorded a bogon-computron > collision of the flavor, containing: >> Bingo! >> >> Now someone who has a lot more brains than me will need to figure out how to >> enforce this change for Cygwin systems... > > Something else to try. > > Replace "inline int" with "static inline int" on those two lines, instead > of removing "inline." Does it still compile on Cygwin? > > If so, then this is something we can do for all systems, without > special-casing Cygwin. > > There was apparently a change in how GCC handles inline functions some > time ago, and perhaps this issue is a reflection of it. That it still > compiles > fine on real operating systems may just be luck. > >> -Original Message- >> From: Tom Russo [mailto:ru...@bogodyn.org] >> Sent: Saturday, July 09, 2016 2:20 PM >> >> Perhaps the declaration as inline is what's causing the problem. Try >> removing the inline qualifier from the two function declarations (main.c, >> line 5174 for no_data_selected, and maps.c, line 231 for max_i) and see if >> that helps. >> >> > ___ Xastir-dev mailing list Xastir-dev@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev
