Re: More issues with RC2


markjmeans
 

Hi Andrew,

 

  1. Open Office is a glaring example of why being unconcerned about OS guidelines is somehow a reason to not be concerned about a given OS’s guidelines. Open Office does honor the default page format in Windows; and it supports multiple cultures; and it supports multi-OS. I have felt for some time now that PCGen considers Windows as something that needs no particular attention to standard Windows patterns and practices and is mostly only supported because Java happens to support it. The responses to this and other issues I’ve brought up in the last several months do little to assuage that feeling. It may simply be that there are no Windows centric developers to take on the mantle to assure that Windows guidelines are honored with conditional compilation code segments where appropriately divergent from Unix-isms. I completely understand that this is a volunteer project. But everyone in the PCGen development team is surely aware that this project appears to be in a slow death (fewer and fewer volunteers) precisely because Windows users (the largest desktop segment) is going to Hero Lab and other software due to the perceived buggy nature or usability issues (deserved or not) of PCGen. I don’t want that to happen. I would like to see what is probably the projects largest user segment to be so happy with the core usability of PCGen that we attract many new volunteers. That extends to the code team as well. From what I’ve seen so far that the new formula parser is evolutionary. But to get new volunteer coders you must first get their attention. And that becomes more difficult as the audience declines.

 

  1. The issue with this is not that a homebrew is broken. It is that PCGen gives no useful error message to tell someone WHERE it is broken. In my case, this homebrew is little more than a huge multi-set and commenting out all the lines in the PCC file to find out which line is causing the issue is something that no other homebrew user *should* have to do. The error message for the load failure should be enough to find out what the issue was. In this case, after uninstalling PCGEN and reinstalling and making sure to select the _universal and the other _xxx entry the error did not recur.

 

  1. As for the source. Like I said I know very little about Java programming, and less about the specific coding in PCGen. For me to spend, probably hours, digging through PCGen to understand its internal structure enough to submit a PR for the code is ridiculous on its face. The chance that I could even attempt to identify a fix that would not have unintended consequences without such study is presumptuous at best.

 

As for the remainder of your comment… Try developing two different programs, pascal and C, at the same time. The languages are so close in syntax you quickly get mired in the peculiarities of the two and spend a lot of time bug-fixing and referring to API docs. This is not efficient coding. Efficient coding is 100+ lines of debugged functioning code per hour per developer, not 700+ lines of code per month per developer. As an example, in the summer of 2005 I started writing a Windows XP application that was ready for deployment in 9 months. It had over 100,000 lines of code (comprising modules written in VB, C++, and 8051 assembler), not counting auto generated code from UI creation tools I used. And not counting the code from the early parts of the project that were deleted or replaced as it was being developed. There was only myself and one other developer working on this project. I produced 95+% of the VB code (the bulk of the application), perhaps 10-15% of the C++ code (high level USB driver interfaces, the other guy did the low level part). You need a singleness of mind and concentration to produce debugged code at that rate. My primary focus now is C# programming on multiple projects with a huge combined code base, and I am the only developer. I cannot afford to get distracted by a similar syntaxed and structured language. Now if PCGen had been written in Cobol, RPG, Fortran, LISP or ASSEMBLER (all of which I have programmed in), then that would be something else entirely as they are all completely different coding syntax and style and could never be confused with C++, C# or Java.

 

As for JIRA, I wanted to post on the forums first (specifically the null error message issue and the font issue) to see if anyone else (not developers) encountered the same problem. Anyone with JAVA SDK development tools checking it might not encounter the same error if the problem was related to the JRE set installed in windows installer version of PCGen. But I suppose there are so few Windows users who subscribe to the forums or perhaps all other Windows users just all the data sets (by default). I don’t know. Either way, a confirmation of an error on a non-JDK installed machine could have identified the problem. In my case, while the null error went away when I uninstalled and reinstalled (as I identified above) this is not confirmation of the cause since I have not again uninstalled and reinstalled without selecting _universal to confirm that the problem returns since it is completely irrelevant if _universal should not be able to be deselected in the first place.

 

Mark

 

 

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Andrew Maitland via Groups.Io
Sent: Saturday, December 15, 2018 5:05 PM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

Hi Mark,

1) Not being a program meant to be specific to a particular OS, I'm not overly concerned about this. A "critical" or "blocker" bug is classified as - Did it break the program or did we lose major core functionality? I wouldn't release an RC3 for a mere glitch for Windows not being able to figure out the program is an RC2 vs. RC1. I am going to do an RC3 for several fixes/features that were discovered missing that I feel should make the 6.08.00 release, but not because Windows has issues. If you felt this is important enough to warrant concern why haven't you opened a bug for it?

2) I don't control HOMEBREW sources, anything I cannot control is irrelevant to our release schedule. We have a support team on Discord and here to assist you update your out-of-date set. FEAT is an illegal tag, and should have been converted to ABILITY back in 6.06.00 if not sooner. The team focuses on things we control and manage. If you want support for your homebrew, ask for the help, and we will gladly tell you what you need to update/change/convert to be compliant with the current version.

3) As #1 states, we are an OS Neutral Program. Coding in OS specific settings requires folks who have the knowledge. I have *NEVER* had an issue creating PDFs nor printing them, and I have been using PCGen for 17 years. Merely set your paper settings in the preferences and you'll be fine.

To tag onto Stefan's comment, if you won't do the code, at least point out a source that our team can reference to tackle the issue. I've always held to a principle of point out the problem and a potential solution if possible. I wasn't aware that cross-training in multiple languages was considered a detriment. And for actual bugs, we have a BUG tracker system located here --> https://pcgenorg.atlassian.net where all the issues can be discussed or solutions presented.

Cheers,

Andrew

On 12/14/2018 10:30 AM, markjmeans wrote:

  1. The Windows uninstall entry in Windows > Settings > Apps & Features lists PCGen as �6.08.00RC1� as the product name and shows nothing for program title or version number. What is expected is that the program name, version number and publisher name fields be defined correctly in the installer so that the uninstall process follows Windows guidelines and is intuitive to Windows users. In my opinion this is a critical bug that should delay release until resolved. However, it should be a very simple one to fix. It�s a 30 second task using Microsoft installer projects within MS Visual Studio and I will assume it�s nearly as simple using the nullsoft installer that PCGen uses (but I have no experience with nullsoft installer projects). Whomever wrote the installer project should examine the project properties and correct them. This fix alone should require an RC3 version before going ahead to full release.
  2. A homebrew set that loads in RC1 will not load in RC2. See attached homebrew files. The error log does not indicate specifically what is wrong, i.e. doesn�t say which campaign is unable to load.

10:46:09.847 INFO main Main:138 Starting PCGen v6.08.00 RC2

10:46:09.967 INFO main LanguageBundle:134 Initialising language bundle with locale en_US.

10:46:19.673 LSTWARN main CampaignFeatToken:56 FEAT has been deprecated, use ABILITY: and put CATEGORY: entries in the LST file

10:46:51.613 SEVERE Thread-2 SourceFileLoader:248 Failed to load sources

pcgen.persistence.PersistenceLayerException: You must select at least one campaign to load.

��������������� at pcgen.persistence.SourceFileLoader.loadCampaigns(SourceFileLoader.java:482)

��������������� at pcgen.persistence.SourceFileLoader.execute(SourceFileLoader.java:244)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:72)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:40)

��������������� at pcgen.gui2.util.SwingWorker$1.run(SwingWorker.java:160)

��������������� at java.base/java.lang.Thread.run(Unknown Source)

�

And while not a problem with RC2 specifically, there is a long standing problem with PCGen and the paper format. PCGen should detect the OS culture settings and if it is US/English, should set the paper size to Letter instead of A4. I don�t know how many sheets of paper I�ve wasted because of this.

�

�

 

Virus-free. www.avast.com

Join main@pcgen.groups.io to automatically receive all group messages.