pyILPER Version 1.3.3 released

[rprosperi]

(04-14-2016 04:58 AM)jsi Wrote:  "On Windows, HOME and USERPROFILE will be used if set, otherwise a combination of HOMEPATH and HOMEDRIVE will be used."

Great, thanks for explaining this Joachim. Since HOME is not used in relevant versions of Windows, perhaps remove that to avoid the kind of issues Dave reported. It's possible HOME was used in very old versions of Windows, but it seems very unlikely anyone will be trying to run pyILPer under those versions , even if Python runs there.

Thanks.

[Dave Frederickson]

(04-14-2016 04:58 AM)jsi Wrote:  Dave, did you check the "Enable IDY frames option" in the pyILPER configuration?

Hi Joachim,

It seems that I only acquired the PIL-Box 1.6 firmware, but had not yet installed it.

All works fine now. I left the top half of the PIL-Box case off while verifying proper operation and I like the visual feedback the LED gives. Perhaps I'll further modify the case to bring out the LED, transplant the board into a clear acrylic case, or 3D print something custom.

Thanks,
Dave

[jsi]

I'd like to use the APPDATA environment variable to determine the location for the program configuration. The HOME environment variable may be used by windows programs which were
ported from UNIX and their install procedure might switch this variable.

Regards
Joachim

[rprosperi]

(04-14-2016 07:44 PM)jsi Wrote:  I'd like to use the APPDATA environment variable to determine the location for the program configuration. The HOME environment variable may be used by windows programs which were
ported from UNIX and their install procedure might switch this variable.

Regards
Joachim

I agree this is the best choice; after all it is exactly application data.

Any thoughts about the suggestion to implement the .ini file in text? Is there any binary data stored in the .ini file that would make this problematic?

[Howard Owen]

I just flashed my PIL-Box to version 1.6. (Thanks JF!) I installed the latest pyILPER on my Mac using anaconda and fired it up. After selecting the right serial port and baud rate my HP-71 is talking to pyILPER just fine.

However the terminal is acting as it did before the upgrade. After an INIT(3) and after loading the contents of the PILIMAGE.dat LIF, My VER$ is "HP71:2CDCC KBD:C RCPY:E HPIL:1B" After running PILTERM I type on my mac's keyboard and the characters don't show up on the terminal until I press attn on the 71. At that point they show up and are processed by the 71. My pyILPER version is 1.3.3.

Thanks for any help you can offer.

[Dave Frederickson]

(04-14-2016 11:48 PM)hbo Wrote:  After running PILTERM I type on my mac's keyboard and the characters don't show up on the terminal until I press attn on the 71. At that point they show up and are processed by the 71.

Isn't that exactly the problem I was experiencing? http://www.hpmuseum.org/forum/thread-599...l#pid53888

In some instructions from Christoph is a step to cycle power on the 71 after copying KEYBOARD LEX to "activate" it. Then run PILTERM.

From the pyILPER manual: If the keyboard hangs press the ATTN key twice at the HP-71 and rerun the PILTERM program from the HP-71 keyboard.

Dave

[Howard Owen]

(04-15-2016 12:15 AM)Dave Frederickson Wrote:  [
Isn't that exactly the problem I was experiencing? http://www.hpmuseum.org/forum/thread-599...l#pid53888

Yes it was Dave. I missed that. Setting "Enable IDY frames" did the trick! Thanks for pointing it out.

[jsi]

(04-14-2016 10:21 PM)rprosperi Wrote:  Any thoughts about the suggestion to implement the .ini file in text? Is there any binary data stored in the .ini file that would make this problematic?

The current development version now serializes the configuration file as JSON. It breaks compatibility with earlier versions. You have to reconfigure pyILPER again, but it is text.

See the latest commits on GitHub.

Sample configuration file :

Code:


{
   "Drive1_active": true,
   "Drive1_charset": 0,
   "Drive1_drivetype": 2,
...
   "pyilper_terminalcharsize": 15,
   "pyilper_terminalsize": "80x24",
   "pyilper_tty": "/dev/ttyUSB0",
   "pyilper_workdir": "/home/jsi/pyilperwork"
}

Regards
Joachim

[rprosperi]

(04-19-2016 03:11 AM)jsi Wrote:  The current development version now serializes the configuration file as JSON. It breaks compatibility with earlier versions. You have to reconfigure pyILPER again, but it is text.

Joachim - Thanks for making this change, I feel it's an improvement which will make it easier to understand and troubleshoot pyILPer.

By "reconfigure" do you mean reinstall? Is it best to remove & reinstall all of Miniconda, or just the pyILPer application (sorry, I'm new to Python)?

If only pyILPer needs updating, what command would do the necessary refresh to remove the prior version and establish the update? I have installed Miniconda per your instructions above and that all worked as expected.

Thank you again.

[Sylvain Cote]

(04-19-2016 02:05 PM)rprosperi Wrote:  By "reconfigure" do you mean reinstall? Is it best to remove & reinstall all of Miniconda, or just the pyILPer application (sorry, I'm new to Python)?

Robert,

Python is an interpreted language (ex. HP-71B BASIC) and thus not like a compiled language (like C).
In a compile language you distibute binaries (.EXE, .DLL, etc), in a intrepeted language you distribute the actual source code.

Joachim is suggesting that you get the updated source files from GitHub and that you manually replace the ones that you have installed with miniconda with the updated ones from GitHub.

As a software developer, I normally install a Git client (like GitKraken) and then I clone the pyILPer git repository.
After that with a compare tool (WinMerge or KDiff3) I copy over the files that has been updated.

Sylvain

[Christoph Giesselink]

IMHO you're both thinking too deep.

Of course you have to update to the latest pyILPER version first.

Because the setup file format of pyILPER changed, the new version cannot read the previous settings. So at first start the new version is using a default configuration. So you have to choose the serial port, baudrate, LIF image file names for the virtual disk drives and don't forget to enable your selected devices. By default they are off...

This is ment by "reconfigure pyILPER again".

[rprosperi]

(04-19-2016 02:52 PM)Sylvain Cote Wrote:  In a compile language you distibute binaries (.EXE, .DLL, etc), in a intrepeted language you distribute the actual source code.

I am hoping to learn to use Python solutions, not write Python code, so just asking what the normal end-user process is.

(04-19-2016 04:59 PM)Christoph Giesselink Wrote:  IMHO you're both thinking too deep.

Of course you have to update to the latest pyILPER version first.

I agree, this is what I'm asking - the proper way for a user to update the pyILPer application. Once installed, I can easily go through the initial config.

I'm not sure if the updated files in git are accessible via some form of Miniconda update command or not (e.g. if they are in some "in development" area, or in the released code area.)

[jsi]

(04-19-2016 05:44 PM)rprosperi Wrote:  I'm not sure if the updated files in git are accessible via some form of Miniconda update command or not (e.g. if they are in some "in development" area, or in the released code area.)

GitHub commits are work in progress on an unstable developer version. A commit may be a major or minor self contained developmet step of new features, of a refactoring or a bug fix. You can watch the commits (each commit has a short description) in the repository and see what happens. Comments are welcome!

The releases that are published on GitHub are regarded as "stable" and distributed over the miniconda channels.

If you like to use development versions you are warned that they are only coarse tested. I recommend to do only a side install of a development version an not to replace the stable version.

If desired I can provide a short HOWTO.

Regards
Joachim

[rprosperi]

(04-20-2016 05:10 AM)jsi Wrote:  If desired I can provide a short HOWTO.

Thank you for the clarification of the different change levels on Github.

Yes, a HOWTO would be helpful and being able to run release and interim versions side-by-side is very helpful as well. The additional testing may also provide useful feedback to you as well.

Thanks Joachim.

[jsi]

(04-20-2016 01:41 PM)rprosperi Wrote:  Yes, a HOWTO would be helpful and being able to run release and interim versions side-by-side is very helpful as well. The additional testing may also provide useful feedback to you as well.

The installation instructions of pyILPER now contain a description how to install and use development versions. User visible changes of the development versions are documented in the pyILPER manual (Miscellaneous - Change Log). All changes are documented in the history of the source code files.

Regards
Joachim

[rprosperi]

(04-22-2016 06:14 AM)jsi Wrote:  The installation instructions of pyILPER now contain a description how to install and use development versions. User visible changes of the development versions are documented in the pyILPER manual (Miscellaneous - Change Log).

Thank you Joachim, this looks remarkably simple, I will install v1.3.4 tomorrow. Thanks also for the extra effort to let the dev. version install with a different namespace, it will make using different versions trivially easy!

Update: (I made time to send quick feedback)

Dev version 1.3.4 installed and starts without any issues.

I am using PIL-Box v2.1 and connecting at 230400 Bps also works every time. Some quick throughput testing shows the loop runs at nearly the same speed as ILPer v2.2, perhaps a bit slower.

However keyboard in the remote terminal is not working, while it was OK on 1.3.3.

After running PILTERM, I see the screen clear and the cursor appears in the top-left, but commands from the PC keyboard do not seem to be processed, but device kbd is OK, and all display output appears in the terminal. FYI - I am using KBD:B LEX file from the installed FORTH ROM.

Some commands I enter on the PC keyboard are buffered, and sometimes after pressing [ON][ON] on the device, those commands are received and processed by the 71, but I have not been able to reproduce a reliable sequence to exactly characterize when and how this occurs.

I will update this post again if/when I find a reproducible test sequence.

Very nice Joachim, thanks again.

[jsi]

Did you enable the IDY frames processing option in the pyILPER configuration? It's annoying but since this PIL-Box feature is quite new I hesitate do make it default.

Regards
Joacim

[Dave Frederickson]

(04-22-2016 01:42 PM)rprosperi Wrote:  However keyboard in the remote terminal is not working, while it was OK on 1.3.3.

After numerous attempts I was able to get the terminal to work at 230K. The display is not as fast as the Printer device and the keyboard response is slow, but it works.

Verified that performance is a little slower than ILPer 2.2, but still around 1300 bytes/sec compared to 1440 for ILPer 2.2.

Dave

[rprosperi]

(04-22-2016 04:07 PM)jsi Wrote:  Did you enable the IDY frames processing option in the pyILPER configuration? It's annoying but since this PIL-Box feature is quite new I hesitate do make it default.

Damn. No. And not surprisingly, turns out that if you use the feature the proper way, it works properly. Oddly, figured this out with 1.3.3 but forgot.

What is the down-side of defaulting IDY Frame Processing to ON ?

No issues seen in terminal mode, now that I am following directions...

[Dave Frederickson]

When trying to install the developmental version I get about 5 errors like this:

Code:

C:\Users\Dave>python h:\pyilper-master\start.py
Traceback (most recent call last):
  File "h:\pyilper-master\pyilper\userconfig.py", line 101, in read
    config= json.load(f)
  File "C:\Miniconda3\lib\json\__init__.py", line 268, in load
    parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "C:\Miniconda3\lib\json\__init__.py", line 319, in loads
    return _default_decoder.decode(s)
  File "C:\Miniconda3\lib\json\decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "C:\Miniconda3\lib\json\decoder.py", line 357, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Bob, any difficulty getting a connection or slow performance with the terminal?

Dave