Re: [M100] Building VirtualT

[Ken Pettit]

Hi Peter,

Actually, it has always been a free download since version 0.4 in 2004.  
But anyone who wishes to pay me a yearly $1000 maintenance fee is 
certainly welcome!  ;)


Documentation update?  Oh yeah, programs usually have documentation, 
huh?   Hadn't really given that much thought.


I was thining more like bug fixes, addition of REXCPM memory support 
(curtsey of Steve Adolph), some TPDD updates to support 8.3 file format 
(for running CP/M eventually), and addition of a "Midnight" theme.  I 
find as I get older that my eyes are more and more light sensitive, and 
trying to read Black on White or Black on Grey is challenging.  So I am 
adding a feature to make all dialog boxes, menus, etc. White on Black.  
I have about half of the windows / dialog boxes updated so far.


Ken

On 3/25/20 3:45 PM, Peter Noeth wrote:


Ken,

No problem, I realized that VirtualT was likely no longer supported 
once it became a free download.


At the time I was doing some development on my main computer and using 
VirtualT cause I had to refer to so many other PC files  I have and on 
the internet (I often just use my T102). I use a program I wrote for 
my original M100 (1986) to transfer files between the T102 and PC. So 
when I saw that VirtualT could transfer BASIC files from its 
environment to the PC in ASCII format (like a SAVE"xxx",A on the 
T102), I used that to save the program to the PC directory my T102 
files are in.


It was when I used my file transfer program to load the program into 
my T102, when I discovered the bug in VirtualT.


Thank you for adding the fix to the current build. I look forward to 
v1.8 when it is available.


BTW, Are you planning on completing some of the other features v1.7 
eluded to (like cassette support), or just remove them from the 
feature set and freshen up the documentation?


Regards,  Peter


Message: 16
Date: Wed, 25 Mar 2020 06:49:35 -0700
From: Ken Pettit mailto:petti...@gmail.com>>
To: m100@lists.bitchin100.com 
Subject: Re: [M100] Building VirtualT
Message-ID: <5e7b616f.6010...@gmail.com 
>

Content-Type: text/plain; charset=utf-8; format=flowed

On 3/25/20 12:23 AM, Peter Noeth wrote:
> Does that include bug fixes from v1.7?
>
> I sent Ken a PM back a while ago describing a bug I found, but got no
> response.
>

Sorry about that Peter, I don't even recall seeing this email or knowing
about this bug.  For a while there, my email client was dropping some
emails from the list into the SPAM folder.  it still does for a couple
of members on the list (I can't figure out why), so if I forget to go
check it every so often, things can get missed.

As far as fixing the bug, I can look into it with the next release.

Ken

Re: [M100] Building VirtualT

[Peter Noeth]

Ken,
No problem, I realized that VirtualT was likely no longer supported once it
became a free download.

At the time I was doing some development on my main computer and using
VirtualT cause I had to refer to so many other PC files  I have and on the
internet (I often just use my T102). I use a program I wrote for my
original M100 (1986) to transfer files between the T102 and PC. So when I
saw that VirtualT could transfer BASIC files from its environment to the PC
in ASCII format (like a SAVE"xxx",A on the T102), I used that to save the
program to the PC directory my T102 files are in.

It was when I used my file transfer program to load the program into my
T102, when I discovered the bug in VirtualT.

Thank you for adding the fix to the current build. I look forward to v1.8
when it is available.

BTW, Are you planning on completing some of the other features v1.7 eluded
to (like cassette support), or just remove them from the feature set and
freshen up the documentation?

Regards,  Peter


Message: 16
Date: Wed, 25 Mar 2020 06:49:35 -0700
From: Ken Pettit 
To: m100@lists.bitchin100.com
Subject: Re: [M100] Building VirtualT
Message-ID: <5e7b616f.6010...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 3/25/20 12:23 AM, Peter Noeth wrote:
> Does that include bug fixes from v1.7?
>
> I sent Ken a PM back a while ago describing a bug I found, but got no
> response.
>

Sorry about that Peter, I don't even recall seeing this email or knowing
about this bug.  For a while there, my email client was dropping some
emails from the list into the SPAM folder.  it still does for a couple
of members on the list (I can't figure out why), so if I forget to go
check it every so often, things can get missed.

As far as fixing the bug, I can look into it with the next release.

Ken

Re: [M100] Building VirtualT

[Kevin Becker]

Fedora is usually very up to date.  It is version 1.3.5 which seems to
be the latest stable release on fltk.org
[kevin@tk421 virtualt]$ dnf info fltk
keybase
  21 kB/s | 3.3 kB 00:00
Installed Packages
Name : fltk
Version  : 1.3.5
Release  : 2.fc31
Architecture : x86_64
Size : 2.3 M
Source   : fltk-1.3.5-2.fc31.src.rpm
Repository   : @System
>From repo: fedora
Summary  : C++ user interface toolkit
URL  : http://www.fltk.org/
License  : LGPLv2+ with exceptions
Description  : FLTK (pronounced "fulltick") is a cross-platform C++ GUI
toolkit.
 : It provides modern GUI functionality without the bloat,
and supports
 : 3D graphics via OpenGL and its built-in GLUT emulation.


On Wed, 2020-03-25 at 12:51 -0500, Bert Put wrote:
> Hi, 
> I'm not sure that the distro is as important as the version of FLTK
> that comes with it.  Some  distros distribute older versions of
> packages than what the developer built their application with. 
> Anyway,  just my 2 cents worth. :-)
> Cheers, Bert
> 
> 
>  Original message 
> From: Ken Pettit  
> Date: 3/25/20  12:44  (GMT-06:00) 
> To: m100@lists.bitchin100.com 
> Subject: Re: [M100] Building VirtualT 
> 
> 
> Hi Kevin,
> 
> 
> 
> Okay, thanks.  Guess I'm going to have to spend some time tonight
> getting a Fedora VM up and running (or downloaded).
> 
> 
> 
> Ken
> 
> 
> 
> On 3/25/20 8:55 AM, Kevin Becker wrote:
> 
> 
> 
> >   
> >   I get the same error. To be clear, I did not exactly follow
> > Brian's instructions as I did not compile FLTK. I just
> > installed
> > it from the Fedora repos.
> >   
> > 
> >   
> >   
> > 
> >   
> >   On Wed, 2020-03-25 at 08:17 -0700, Ken Pettit wrote:
> >   
> > >  Hey Kevin,
> > > 
> > > 
> > > 
> > > Turns out I don't have a system on which the build fails,
> > > so
> > > it's hard for me to test if I fixed it.
> > > 
> > > 
> > > 
> > > I noticed in Brian's GNUMakefile, he added the --ldflags
> > > option
> > > to the fltk-config line.  This is adding additional
> > > library
> > > support, and the error "DSO missing..." usually means
> > > there is a
> > > missing library option.
> > > 
> > > 
> > > 
> > > I have added the '--ldflags' to the GNUMakefile on
> > > SourceForge. 
> > > Can you do a 'git pull' and see if that fixes the
> > > problem?
> > > 
> > > 
> > > 
> > > Thanks,
> > > 
> > > Ken
> > > 
> > > 
> > > 
> > > On 3/25/20 7:43 AM, Kevin Becker
> > >   wrote:
> > > 
> > > 
> > > 
> > > >   
> > > >   FWIW I can compile Brian's source on Fedora 31 using
> > > > the
> > > > distro packaged version of FLTK with no issue but
> > > > your
> > > > official sourceforge version errors out.
> > > >   
> > > > 
> > > >   
> > > >   /usr/bin/ld:
> > > > /usr/lib/gcc/x86_64-redhat-
> > > > linux/9/../../../../lib64/libfltk.so:
> > > > undefined reference to symbol
> > > > 'XRenderQueryExtension'
> > > >   /usr/bin/ld: /usr/lib64/libXrender.so.1: error adding
> > > > symbols: DSO missing from command line
> > > >   collect2: error: ld returned 1 exit status
> > > >   make: *** [GNUmakefile:124: virtualt] Error 1
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:
> > > >   
> > > > >  Hey Guys,
> > > > > 
> > > > > 
> > > > > 
> > > > > Okay, I have fixed this bug (in src/file.cpp). 
> > > > > The
> > > > > de-tokenizer was not testing for quoted strings. 
> > > > > I pushed
> > > > > the changes to the git repo here if anyone wants
> > > > > to pull it
> > > > > and compile prior to an official VT 1.8 release:
> > > > > 
> > > > > 
> > > > > 
> > > > > git clone https://git.code.sf.net/p/virtualt/code
> > > > > virtualt
> > > > > 
> > > > > 
> > > > > 
> > > > > Ken
> > > > > 
> > > > > 
> > > > > 
> > > > > On 3/25/20 12:23 AM, Peter
> > > > >   Noeth wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > >   
> > > > > > Does that include bug fixes from v1.7?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > I sent Ken a PM back a while ago describing
> > > > > > a bug I
> > > > > >   found, but got no 

Re: [M100] Building VirtualT

[Bert Put]

Hi, I'm not sure that the distro is as important as the version of FLTK that 
comes with it.  Some  distros distribute older versions of packages than what 
the developer built their application with.  Anyway,  just my 2 cents worth. 
:-)Cheers,     Bert

 Original message 
From: Ken Pettit  
Date: 3/25/20  12:44  (GMT-06:00) 
To: m100@lists.bitchin100.com 
Subject: Re: [M100] Building VirtualT 


Hi Kevin,

Okay, thanks.  Guess I'm going to have to spend some time tonight
getting a Fedora VM up and running (or downloaded).

Ken

On 3/25/20 8:55 AM, Kevin Becker wrote:


  
  I get the same error. To be clear, I did not exactly follow
Brian's instructions as I did not compile FLTK. I just installed
it from the Fedora repos.
  
  
  
  
  On Wed, 2020-03-25 at 08:17 -0700, Ken Pettit wrote:
   Hey Kevin,

Turns out I don't have a system on which the build fails, so
it's hard for me to test if I fixed it.

I noticed in Brian's GNUMakefile, he added the --ldflags option
to the fltk-config line.  This is adding additional library
support, and the error "DSO missing..." usually means there is a
missing library option.

I have added the '--ldflags' to the GNUMakefile on SourceForge. 
Can you do a 'git pull' and see if that fixes the problem?

Thanks,
Ken

On 3/25/20 7:43 AM, Kevin Becker
  wrote:


  
  FWIW I can compile Brian's source on Fedora 31 using the
distro packaged version of FLTK with no issue but your
official sourceforge version errors out.
  
  
  /usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libfltk.so:
undefined reference to symbol 'XRenderQueryExtension'
  /usr/bin/ld: /usr/lib64/libXrender.so.1: error adding
symbols: DSO missing from command line
  collect2: error: ld returned 1 exit status
  make: *** [GNUmakefile:124: virtualt] Error 1
  
  
  
  
  
  
  
  
  On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:
   Hey Guys,

Okay, I have fixed this bug (in src/file.cpp).  The
de-tokenizer was not testing for quoted strings.  I pushed
the changes to the git repo here if anyone wants to pull it
and compile prior to an official VT 1.8 release:

git clone https://git.code.sf.net/p/virtualt/code
virtualt

Ken

On 3/25/20 12:23 AM, Peter
  Noeth wrote:


  
Does that include bug fixes from v1.7?


I sent Ken a PM back a while ago describing a bug I
  found, but got no response.


The problem occurs when transferring a BASIC
  program from VirtualT to the PC in ASCII format. The
  bug concerns any BASIC program that uses embedded
  ASCII characters with the value greater than 127d
  directly in PRINT statements. When these characters
  are used (for example, the downward pointing triangle,
  167d A7h), the ASCII character value is not preserved
  in the saved output file, but instead a BASIC keyword
  is substituted. 


For example (+ character is really 167d, input with
  the keyboard sequence [CODE]_ ):
A program containing the line:
11510 PRINT@280,"++";


 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";


I am not sure if the keyword GOTO is the actual
  substitution, as I am away from my "development"
  computer and can verify, but it illustrates the basic
  problem. Likely, as BASIC keywords are probably
  represented as values higher than 127d, and the
  routine in VirtualT to save a file on the PC in ASCII
  format is not setting a flag to track the occurrences
  of the " character pairs and interpret any characters
  within as ASCII characters and not BASIC keywords.


Regards,


Peter



     Message: 10
     Date: Tue, 24 Mar 2020 13:27:39 -0700

Re: [M100] Building VirtualT

[Ken Pettit]

Hi Kevin,

Okay, thanks.  Guess I'm going to have to spend some time tonight 
getting a Fedora VM up and running (or downloaded).


Ken

On 3/25/20 8:55 AM, Kevin Becker wrote:
I get the same error. To be clear, I did not exactly follow Brian's 
instructions as I did not compile FLTK. I just installed it from the 
Fedora repos.



On Wed, 2020-03-25 at 08:17 -0700, Ken Pettit wrote:

Hey Kevin,

Turns out I don't have a system on which the build fails, so it's 
hard for me to test if I fixed it.


I noticed in Brian's GNUMakefile, he added the --ldflags option to 
the fltk-config line.  This is adding additional library support, and 
the error "DSO missing..." usually means there is a missing library 
option.


I have added the '--ldflags' to the GNUMakefile on SourceForge. Can 
you do a 'git pull' and see if that fixes the problem?


Thanks,
Ken

On 3/25/20 7:43 AM, Kevin Becker wrote:
FWIW I can compile Brian's source on Fedora 31 using the distro 
packaged version of FLTK with no issue but your official sourceforge 
version errors out.


/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libfltk.so: 
undefined reference to symbol 'XRenderQueryExtension'
/usr/bin/ld: /usr/lib64/libXrender.so.1: error adding symbols: DSO 
missing from command line

collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:124: virtualt] Error 1




On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:

Hey Guys,

Okay, I have fixed this bug (in src/file.cpp).  The de-tokenizer 
was not testing for quoted strings.  I pushed the changes to the 
git repo here if anyone wants to pull it and compile prior to an 
official VT 1.8 release:


git clone https://git.code.sf.net/p/virtualt/code virtualt

Ken

On 3/25/20 12:23 AM, Peter Noeth wrote:

Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got 
no response.


The problem occurs when transferring a BASIC program from VirtualT 
to the PC in ASCII format. The bug concerns any BASIC program that 
uses embedded ASCII characters with the value greater than 127d 
directly in PRINT statements. When these characters are used (for 
example, the downward pointing triangle, 167d A7h), the ASCII 
character value is not preserved in the saved output file, but 
instead a BASIC keyword is substituted.


For example (+ character is really 167d, input with the keyboard 
sequence [CODE]_ ):

A program containing the line:
11510 PRINT@280,"++";

 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";

I am not sure if the keyword GOTO is the actual substitution, as I 
am away from my "development" computer and can verify, but it 
illustrates the basic problem. Likely, as BASIC keywords are 
probably represented as values higher than 127d, and the routine 
in VirtualT to save a file on the PC in ASCII format is not 
setting a flag to track the occurrences of the " character pairs 
and interpret any characters within as ASCII characters and not 
BASIC keywords.


Regards,

Peter


   Message: 10
   Date: Tue, 24 Mar 2020 13:27:39 -0700
   From: Ken Pettit mailto:petti...@gmail.com>>
   To: m100@lists.bitchin100.com 
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
>

   Content-Type: text/plain; charset="windows-1252"; Format="flowed"

   Hey Guys,

   Steven Hurd also converted the SourceForge.net cvs repo to a 
git repo.

   Both he and I have been making updates to that repo.  I am working
   toward a VT 1.8 release.

   Ken

Re: [M100] Building VirtualT

[Kevin Becker]

I get the same error. To be clear, I did not exactly follow Brian's
instructions as I did not compile FLTK.  I just installed it from the
Fedora repos.
On Wed, 2020-03-25 at 08:17 -0700, Ken Pettit wrote:
> Hey Kevin,
> 
> 
> 
> Turns out I don't have a system on which the build fails, so it's
> hard for me to test if I fixed it.
> 
> 
> 
> I noticed in Brian's GNUMakefile, he added the --ldflags option
> to
> the fltk-config line.  This is adding additional library support,
> and the error "DSO missing..." usually means there is a missing
> library option.
> 
> 
> 
> I have added the '--ldflags' to the GNUMakefile on SourceForge. 
> Can
> you do a 'git pull' and see if that fixes the problem?
> 
> 
> 
> Thanks,
> 
> Ken
> 
> 
> 
> On 3/25/20 7:43 AM, Kevin Becker wrote:
> 
> 
> 
> >   
> >   FWIW I can compile Brian's source on Fedora 31 using the
> > distro packaged version of FLTK with no issue but your
> > official
> > sourceforge version errors out.
> >   
> > 
> >   
> >   /usr/bin/ld:
> > /usr/lib/gcc/x86_64-redhat-
> > linux/9/../../../../lib64/libfltk.so:
> > undefined reference to symbol 'XRenderQueryExtension'
> >   /usr/bin/ld: /usr/lib64/libXrender.so.1: error adding
> > symbols: DSO missing from command line
> >   collect2: error: ld returned 1 exit status
> >   make: *** [GNUmakefile:124: virtualt] Error 1
> >   
> > 
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> >   On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:
> >   
> > >  Hey Guys,
> > > 
> > > 
> > > 
> > > Okay, I have fixed this bug (in src/file.cpp).  The de-
> > > tokenizer
> > > was not testing for quoted strings.  I pushed the changes
> > > to the
> > > git repo here if anyone wants to pull it and compile
> > > prior to an
> > > official VT 1.8 release:
> > > 
> > > 
> > > 
> > > git clone https://git.code.sf.net/p/virtualt/code
> > > virtualt
> > > 
> > > 
> > > 
> > > Ken
> > > 
> > > 
> > > 
> > > On 3/25/20 12:23 AM, Peter Noeth
> > >   wrote:
> > > 
> > > 
> > > 
> > > >   
> > > > Does that include bug fixes from v1.7?
> > > > 
> > > > 
> > > > 
> > > > I sent Ken a PM back a while ago describing a bug I
> > > >   found, but got no response.
> > > > 
> > > > 
> > > > 
> > > > The problem occurs when transferring a BASIC
> > > > program
> > > >   from VirtualT to the PC in ASCII format. The bug
> > > > concerns
> > > >   any BASIC program that uses embedded ASCII
> > > > characters with
> > > >   the value greater than 127d directly in PRINT
> > > > statements.
> > > >   When these characters are used (for example, the
> > > > downward
> > > >   pointing triangle, 167d A7h), the ASCII character
> > > > value is
> > > >   not preserved in the saved output file, but
> > > > instead a
> > > >   BASIC keyword is substituted. 
> > > > 
> > > > 
> > > > 
> > > > For example (+ character is really 167d, input with
> > > > the
> > > >   keyboard sequence [CODE]_ ):
> > > > A program containing the line:
> > > > 11510 PRINT@280,"++";
> > > > 
> > > > 
> > > > 
> > > >  is saved in the ASCII format output file as:
> > > > 11510 PRINT@280,"GOTOGOTO";
> > > > 
> > > > 
> > > > 
> > > > I am not sure if the keyword GOTO is the actual
> > > >   substitution, as I am away from my "development"
> > > > computer
> > > >   and can verify, but it illustrates the basic
> > > > problem.
> > > >   Likely, as BASIC keywords are probably
> > > > represented as
> > > >   values higher than 127d, and the routine in
> > > > VirtualT to
> > > >   save a file on the PC in ASCII format is not
> > > > setting a
> > > >   flag to track the occurrences of the " character
> > > > pairs and
> > > >   interpret any characters within as ASCII
> > > > characters and
> > > >   not BASIC keywords.
> > > > 
> > > > 
> > > > 
> > > > Regards,
> > > > 
> > > > 
> > > > 
> > > > Peter
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  Message: 10
> > > > 
> > > >  Date: Tue, 24 Mar 2020 13:27:39 -0700
> > > > 
> > > >  From: Ken Pettit 
> > > > 
> > > >  To: m100@lists.bitchin100.com
> > > > 
> > > >  Subject: Re: [M100] 

Re: [M100] Building VirtualT

[Ken Pettit]

Hey Kevin,

Turns out I don't have a system on which the build fails, so it's hard 
for me to test if I fixed it.


I noticed in Brian's GNUMakefile, he added the --ldflags option to the 
fltk-config line.  This is adding additional library support, and the 
error "DSO missing..." usually means there is a missing library option.


I have added the '--ldflags' to the GNUMakefile on SourceForge.  Can you 
do a 'git pull' and see if that fixes the problem?


Thanks,
Ken

On 3/25/20 7:43 AM, Kevin Becker wrote:
FWIW I can compile Brian's source on Fedora 31 using the distro 
packaged version of FLTK with no issue but your official sourceforge 
version errors out.


/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libfltk.so: 
undefined reference to symbol 'XRenderQueryExtension'
/usr/bin/ld: /usr/lib64/libXrender.so.1: error adding symbols: DSO 
missing from command line

collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:124: virtualt] Error 1




On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:

Hey Guys,

Okay, I have fixed this bug (in src/file.cpp).  The de-tokenizer was 
not testing for quoted strings.  I pushed the changes to the git repo 
here if anyone wants to pull it and compile prior to an official VT 
1.8 release:


git clone https://git.code.sf.net/p/virtualt/code virtualt

Ken

On 3/25/20 12:23 AM, Peter Noeth wrote:

Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got 
no response.


The problem occurs when transferring a BASIC program from VirtualT 
to the PC in ASCII format. The bug concerns any BASIC program that 
uses embedded ASCII characters with the value greater than 127d 
directly in PRINT statements. When these characters are used (for 
example, the downward pointing triangle, 167d A7h), the ASCII 
character value is not preserved in the saved output file, but 
instead a BASIC keyword is substituted.


For example (+ character is really 167d, input with the keyboard 
sequence [CODE]_ ):

A program containing the line:
11510 PRINT@280,"++";

 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";

I am not sure if the keyword GOTO is the actual substitution, as I 
am away from my "development" computer and can verify, but it 
illustrates the basic problem. Likely, as BASIC keywords are 
probably represented as values higher than 127d, and the routine in 
VirtualT to save a file on the PC in ASCII format is not setting a 
flag to track the occurrences of the " character pairs and interpret 
any characters within as ASCII characters and not BASIC keywords.


Regards,

Peter


   Message: 10
   Date: Tue, 24 Mar 2020 13:27:39 -0700
   From: Ken Pettit mailto:petti...@gmail.com>>
   To: m100@lists.bitchin100.com 
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
>

   Content-Type: text/plain; charset="windows-1252"; Format="flowed"

   Hey Guys,

   Steven Hurd also converted the SourceForge.net cvs repo to a git 
repo.

   Both he and I have been making updates to that repo.  I am working
   toward a VT 1.8 release.

   Ken

Re: [M100] Building VirtualT

[Ken Pettit]

Hi Kevin,

I've seen this before.  Probably a package I installed on my local 
machine at one point that took care of this issue.  I would have to 
clone Brian's git repo to see if there are any differences in the makefile.


I'll look into it.  Thanks!
Ken

On 3/25/20 7:43 AM, Kevin Becker wrote:
FWIW I can compile Brian's source on Fedora 31 using the distro 
packaged version of FLTK with no issue but your official sourceforge 
version errors out.


/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libfltk.so: 
undefined reference to symbol 'XRenderQueryExtension'
/usr/bin/ld: /usr/lib64/libXrender.so.1: error adding symbols: DSO 
missing from command line

collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:124: virtualt] Error 1




On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:

Hey Guys,

Okay, I have fixed this bug (in src/file.cpp).  The de-tokenizer was 
not testing for quoted strings.  I pushed the changes to the git repo 
here if anyone wants to pull it and compile prior to an official VT 
1.8 release:


git clone https://git.code.sf.net/p/virtualt/code virtualt

Ken

On 3/25/20 12:23 AM, Peter Noeth wrote:

Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got 
no response.


The problem occurs when transferring a BASIC program from VirtualT 
to the PC in ASCII format. The bug concerns any BASIC program that 
uses embedded ASCII characters with the value greater than 127d 
directly in PRINT statements. When these characters are used (for 
example, the downward pointing triangle, 167d A7h), the ASCII 
character value is not preserved in the saved output file, but 
instead a BASIC keyword is substituted.


For example (+ character is really 167d, input with the keyboard 
sequence [CODE]_ ):

A program containing the line:
11510 PRINT@280,"++";

 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";

I am not sure if the keyword GOTO is the actual substitution, as I 
am away from my "development" computer and can verify, but it 
illustrates the basic problem. Likely, as BASIC keywords are 
probably represented as values higher than 127d, and the routine in 
VirtualT to save a file on the PC in ASCII format is not setting a 
flag to track the occurrences of the " character pairs and interpret 
any characters within as ASCII characters and not BASIC keywords.


Regards,

Peter


   Message: 10
   Date: Tue, 24 Mar 2020 13:27:39 -0700
   From: Ken Pettit mailto:petti...@gmail.com>>
   To: m100@lists.bitchin100.com 
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
>

   Content-Type: text/plain; charset="windows-1252"; Format="flowed"

   Hey Guys,

   Steven Hurd also converted the SourceForge.net cvs repo to a git 
repo.

   Both he and I have been making updates to that repo.  I am working
   toward a VT 1.8 release.

   Ken

Re: [M100] Building VirtualT

[Kevin Becker]

FWIW I can compile Brian's source on Fedora 31 using the distro
packaged version of FLTK with no issue but your official sourceforge
version errors out.
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-
linux/9/../../../../lib64/libfltk.so: undefined reference to symbol
'XRenderQueryExtension'/usr/bin/ld: /usr/lib64/libXrender.so.1: error
adding symbols: DSO missing from command linecollect2: error: ld
returned 1 exit statusmake: *** [GNUmakefile:124: virtualt] Error 1



On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:
> Hey Guys,
> 
> 
> 
> Okay, I have fixed this bug (in src/file.cpp).  The de-tokenizer
> was
> not testing for quoted strings.  I pushed the changes to the git
> repo here if anyone wants to pull it and compile prior to an
> official VT 1.8 release:
> 
> 
> 
> git clone https://git.code.sf.net/p/virtualt/code virtualt
> 
> 
> 
> Ken
> 
> 
> 
> On 3/25/20 12:23 AM, Peter Noeth wrote:
> 
> 
> 
> >   
> > Does that include bug fixes from v1.7?
> > 
> > 
> > 
> > I sent Ken a PM back a while ago describing a bug I found,
> >   but got no response.
> > 
> > 
> > 
> > The problem occurs when transferring a BASIC program from
> >   VirtualT to the PC in ASCII format. The bug concerns any
> > BASIC
> >   program that uses embedded ASCII characters with the
> > value
> >   greater than 127d directly in PRINT statements. When
> > these
> >   characters are used (for example, the downward pointing
> >   triangle, 167d A7h), the ASCII character value is not
> >   preserved in the saved output file, but instead a BASIC
> >   keyword is substituted. 
> > 
> > 
> > 
> > For example (+ character is really 167d, input with the
> >   keyboard sequence [CODE]_ ):
> > A program containing the line:
> > 11510 PRINT@280,"++";
> > 
> > 
> > 
> >  is saved in the ASCII format output file as:
> > 11510 PRINT@280,"GOTOGOTO";
> > 
> > 
> > 
> > I am not sure if the keyword GOTO is the actual
> >   substitution, as I am away from my "development" computer
> > and
> >   can verify, but it illustrates the basic problem. Likely,
> >   as BASIC keywords are probably represented as values
> > higher
> >   than 127d, and the routine in VirtualT to save a file on
> > the
> >   PC in ASCII format is not setting a flag to track the
> >   occurrences of the " character pairs and interpret any
> >   characters within as ASCII characters and not BASIC
> > keywords.
> > 
> > 
> > 
> > Regards,
> > 
> > 
> > 
> > Peter
> > 
> > 
> > 
> > 
> > 
> >  Message: 10
> > 
> >  Date: Tue, 24 Mar 2020 13:27:39 -0700
> > 
> >  From: Ken Pettit 
> > 
> >  To: m100@lists.bitchin100.com
> > 
> >  Subject: Re: [M100] Building VirtualT
> > 
> >  Message-ID: <5e7a6d3b.4020...@gmail.com>
> > 
> >  Content-Type: text/plain; charset="windows-1252";
> >   Format="flowed"
> > 
> >   
> > 
> >  Hey Guys,
> > 
> >   
> > 
> >  Steven Hurd also converted the SourceForge.net cvs
> > repo to
> >   a git repo.  
> > 
> >  Both he and I have been making updates to that repo. 
> > I am
> >   working 
> > 
> >  toward a VT 1.8 release.
> > 
> >   
> > 
> >  Ken
> > 
> >   
> > 
> > 
> >   
> > 
> 
> 
> 
>   
> 

Re: [M100] Building VirtualT

[Ken Pettit]

Hey Tom,

The fix I just checked in only does simple quote detection with direct 
ASCII value save to the host.  To implement something like a C style 
escape sequence feature, I would probably add two new Menu items for 
this.  Something like "Save Escaped" or "Save C Style" and "Load 
Escaped", etc.  That way it is clear what you are doing and doesn't 
break existing functionality.


One other bug I know of with VT's load and save features in ASCII mode:  
it doesn't work with PC-8201 emulation.  The tokens are different, and 
so is the representation of floating point numbers. I recall when I 
added this feature (like maybe 16 years ago, litterally), I spent a 
couple of days trying to figure out the tokenization / detokenization 
for PC-8201, but never got there.


Ken

For something li

On 3/25/20 1:04 AM, Tom Wilson wrote:
Yeah, I experienced the same thing. At the very least, the 
de-tokenizer needs to scan for quotes and set an "inQuote" flag when 
it hits a quote and export those as their ASCII value, not their token 
code. However, it would be really nice if we could get some sort of 
hex tokens, such as \xFF, so the files would be 8-bit safe and we 
could construct BASIC programs on the PC without having to hack in 
extended ASCII codes after the fact.






Tom Wilson
wilso...@gmail.com 
(619)940-6311
K6ABZ


On Wed, Mar 25, 2020 at 12:23 AM Peter Noeth > wrote:


Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got
no response.

The problem occurs when transferring a BASIC program from VirtualT
to the PC in ASCII format. The bug concerns any BASIC program that
uses embedded ASCII characters with the value greater than 127d
directly in PRINT statements. When these characters are used (for
example, the downward pointing triangle, 167d A7h), the ASCII
character value is not preserved in the saved output file, but
instead a BASIC keyword is substituted.

For example (+ character is really 167d, input with the keyboard
sequence [CODE]_ ):
A program containing the line:
11510 PRINT@280,"++";

 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";

I am not sure if the keyword GOTO is the actual substitution, as I
am away from my "development" computer and can verify, but it
illustrates the basic problem. Likely, as BASIC keywords are
probably represented as values higher than 127d, and the routine
in VirtualT to save a file on the PC in ASCII format is not
setting a flag to track the occurrences of the " character pairs
and interpret any characters within as ASCII characters and not
BASIC keywords.

Regards,

Peter


   Message: 10
   Date: Tue, 24 Mar 2020 13:27:39 -0700
   From: Ken Pettit mailto:petti...@gmail.com>>
   To: m100@lists.bitchin100.com 
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com
>
   Content-Type: text/plain; charset="windows-1252"; Format="flowed"

   Hey Guys,

   Steven Hurd also converted the SourceForge.net cvs repo to a
git repo.
   Both he and I have been making updates to that repo.  I am working
   toward a VT 1.8 release.

   Ken

Re: [M100] Building VirtualT

[Ken Pettit]

Hey Guys,

Okay, I have fixed this bug (in src/file.cpp).  The de-tokenizer was not 
testing for quoted strings.  I pushed the changes to the git repo here 
if anyone wants to pull it and compile prior to an official VT 1.8 release:


git clone https://git.code.sf.net/p/virtualt/code virtualt

Ken

On 3/25/20 12:23 AM, Peter Noeth wrote:

Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got no 
response.


The problem occurs when transferring a BASIC program from VirtualT to 
the PC in ASCII format. The bug concerns any BASIC program that uses 
embedded ASCII characters with the value greater than 127d directly in 
PRINT statements. When these characters are used (for example, the 
downward pointing triangle, 167d A7h), the ASCII character value is 
not preserved in the saved output file, but instead a BASIC keyword is 
substituted.


For example (+ character is really 167d, input with the keyboard 
sequence [CODE]_ ):

A program containing the line:
11510 PRINT@280,"++";

 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";

I am not sure if the keyword GOTO is the actual substitution, as I am 
away from my "development" computer and can verify, but it illustrates 
the basic problem. Likely, as BASIC keywords are probably represented 
as values higher than 127d, and the routine in VirtualT to save a file 
on the PC in ASCII format is not setting a flag to track the 
occurrences of the " character pairs and interpret any characters 
within as ASCII characters and not BASIC keywords.


Regards,

Peter


   Message: 10
   Date: Tue, 24 Mar 2020 13:27:39 -0700
   From: Ken Pettit mailto:petti...@gmail.com>>
   To: m100@lists.bitchin100.com 
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
>

   Content-Type: text/plain; charset="windows-1252"; Format="flowed"

   Hey Guys,

   Steven Hurd also converted the SourceForge.net cvs repo to a git repo.
   Both he and I have been making updates to that repo.  I am working
   toward a VT 1.8 release.

   Ken

Re: [M100] Building VirtualT

[Ken Pettit]

On 3/25/20 12:23 AM, Peter Noeth wrote:

Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got no 
response.




Sorry about that Peter, I don't even recall seeing this email or knowing 
about this bug.  For a while there, my email client was dropping some 
emails from the list into the SPAM folder.  it still does for a couple 
of members on the list (I can't figure out why), so if I forget to go 
check it every so often, things can get missed.


As far as fixing the bug, I can look into it with the next release.

Ken

Re: [M100] Building VirtualT

[John R. Hogerhuis]

On Wed, Mar 25, 2020 at 1:19 AM Tom Wilson  wrote:

>
> On Wed, Mar 25, 2020 at 1:09 AM John R. Hogerhuis 
> wrote:
>
>>
>>
>> On Wed, Mar 25, 2020 at 1:05 AM Tom Wilson  wrote:
>>
>>> Yeah, I experienced the same thing. At the very least, the de-tokenizer
>>> needs to scan for quotes and set an "inQuote" flag when it hits a quote and
>>> export those as their ASCII value, not their token code. However, it would
>>> be really nice if we could get some sort of hex tokens, such as \xFF, so
>>> the files would be 8-bit safe and we could construct BASIC programs on the
>>> PC without having to hack in extended ASCII codes after the fact.
>>>


>> It might be useful, but you wouldn't be able to load such a program back
>> into a Model T, at least without a well though out escape/quoting mechanism.
>>
>
> Yeah, this would be entirely for exchanging data between VirtualT and a PC
> based editor.
>
> I keep thinking of how the Commodore community did it...a long time ago,
> the magazine writers standardized a set of {token codes} for all the key
> combos that printed graphic symbols. So when we saw a listing with
> something like {Shift P}, we would hold shift and press P.
> I was actually thinking of writing a program to tokenize and de-tokenize
> stuff using the Graph, Code, and Graph/Code+Shift codes... but I want to
> get my Star Trek port done first. =)
>
>
Well we did establish a mapping between Model 100, 102 and Unicode (UTF-8)

http://bitchin100.com/wiki/index.php?title=Unicode_Mappings

-- John.

Re: [M100] Building VirtualT

[John R. Hogerhuis]

On Wed, Mar 25, 2020 at 1:11 AM Tom Wilson  wrote:

>
>> I guess the question becomes, what do you want it to do?
>>
>> What does the Model 100 ROM do when you save that program as ASCII?
>>
>> If it keeps those bytes as binary for VT to do the same behavior it would
>> have to understand whether it's detokenizing a token, a string, the
>> contents of a REM statement or possibly even hidden machine language packed
>> into hidden program lines.
>>
>> -- John.
>>
>
> The 100 ROM definitely keeps the character values as their ASCII binaries
> when you save with ,A.
>
> I tried it with:
> 10 PRINT "▒█▒█▒"
> SAVE "TEST",A
>
> and TEST.DO had exactly the text above.
>
>
Seems complicated.

Maybe the right thing to do is just have VirtualT create a temporary
instance of the Model 100 (or whatever machine is being emulated) to do the
work. Then it could produce the same ASCII output as SAVE"FOO",A.

Without actually having to reproduce the detokenizer logic for each laptop.

I doubt it would even be slow in VT.

-- John

Re: [M100] Building VirtualT

[Tom Wilson]

On Wed, Mar 25, 2020 at 1:09 AM John R. Hogerhuis  wrote:

>
>
> On Wed, Mar 25, 2020 at 1:05 AM Tom Wilson  wrote:
>
>> Yeah, I experienced the same thing. At the very least, the de-tokenizer
>> needs to scan for quotes and set an "inQuote" flag when it hits a quote and
>> export those as their ASCII value, not their token code. However, it would
>> be really nice if we could get some sort of hex tokens, such as \xFF, so
>> the files would be 8-bit safe and we could construct BASIC programs on the
>> PC without having to hack in extended ASCII codes after the fact.
>>
>>>
>>>
> It might be useful, but you wouldn't be able to load such a program back
> into a Model T, at least without a well though out escape/quoting mechanism.
>

Yeah, this would be entirely for exchanging data between VirtualT and a PC
based editor.

I keep thinking of how the Commodore community did it...a long time ago,
the magazine writers standardized a set of {token codes} for all the key
combos that printed graphic symbols. So when we saw a listing with
something like {Shift P}, we would hold shift and press P.
I was actually thinking of writing a program to tokenize and de-tokenize
stuff using the Graph, Code, and Graph/Code+Shift codes... but I want to
get my Star Trek port done first. =)

Re: [M100] Building VirtualT

[Tom Wilson]

>
>
> I guess the question becomes, what do you want it to do?
>
> What does the Model 100 ROM do when you save that program as ASCII?
>
> If it keeps those bytes as binary for VT to do the same behavior it would
> have to understand whether it's detokenizing a token, a string, the
> contents of a REM statement or possibly even hidden machine language packed
> into hidden program lines.
>
> -- John.
>

The 100 ROM definitely keeps the character values as their ASCII binaries
when you save with ,A.

I tried it with:
10 PRINT "▒█▒█▒"
SAVE "TEST",A

and TEST.DO had exactly the text above.

Re: [M100] Building VirtualT

[John R. Hogerhuis]

On Wed, Mar 25, 2020 at 1:05 AM Tom Wilson  wrote:

> Yeah, I experienced the same thing. At the very least, the de-tokenizer
> needs to scan for quotes and set an "inQuote" flag when it hits a quote and
> export those as their ASCII value, not their token code. However, it would
> be really nice if we could get some sort of hex tokens, such as \xFF, so
> the files would be 8-bit safe and we could construct BASIC programs on the
> PC without having to hack in extended ASCII codes after the fact.
>
>>
>>
It might be useful, but you wouldn't be able to load such a program back
into a Model T, at least without a well though out escape/quoting mechanism.

-- John.

Re: [M100] Building VirtualT

[John R. Hogerhuis]

On Wed, Mar 25, 2020 at 12:24 AM Peter Noeth  wrote:

> Does that include bug fixes from v1.7?
>
> I sent Ken a PM back a while ago describing a bug I found, but got no
> response.
>
> The problem occurs when transferring a BASIC program from VirtualT to the
> PC in ASCII format. The bug concerns any BASIC program that uses embedded
> ASCII characters with the value greater than 127d directly in PRINT
> statements. When these characters are used (for example, the downward
> pointing triangle, 167d A7h), the ASCII character value is not preserved in
> the saved output file, but instead a BASIC keyword is substituted.
>
> For example (+ character is really 167d, input with the keyboard sequence
> [CODE]_ ):
> A program containing the line:
> 11510 PRINT@280,"++";
>
>  is saved in the ASCII format output file as:
> 11510 PRINT@280,"GOTOGOTO";
>
> I am not sure if the keyword GOTO is the actual substitution, as I am away
> from my "development" computer and can verify, but it illustrates the basic
> problem. Likely, as BASIC keywords are probably represented as values
> higher than 127d, and the routine in VirtualT to save a file on the PC in
> ASCII format is not setting a flag to track the occurrences of the "
> character pairs and interpret any characters within as ASCII characters and
> not BASIC keywords.
>
>
I guess the question becomes, what do you want it to do?

What does the Model 100 ROM do when you save that program as ASCII?

If it keeps those bytes as binary for VT to do the same behavior it would
have to understand whether it's detokenizing a token, a string, the
contents of a REM statement or possibly even hidden machine language packed
into hidden program lines.

-- John.

Re: [M100] Building VirtualT

[Tom Wilson]

Yeah, I experienced the same thing. At the very least, the de-tokenizer
needs to scan for quotes and set an "inQuote" flag when it hits a quote and
export those as their ASCII value, not their token code. However, it would
be really nice if we could get some sort of hex tokens, such as \xFF, so
the files would be 8-bit safe and we could construct BASIC programs on the
PC without having to hack in extended ASCII codes after the fact.





Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ


On Wed, Mar 25, 2020 at 12:23 AM Peter Noeth  wrote:

> Does that include bug fixes from v1.7?
>
> I sent Ken a PM back a while ago describing a bug I found, but got no
> response.
>
> The problem occurs when transferring a BASIC program from VirtualT to the
> PC in ASCII format. The bug concerns any BASIC program that uses embedded
> ASCII characters with the value greater than 127d directly in PRINT
> statements. When these characters are used (for example, the downward
> pointing triangle, 167d A7h), the ASCII character value is not preserved in
> the saved output file, but instead a BASIC keyword is substituted.
>
> For example (+ character is really 167d, input with the keyboard sequence
> [CODE]_ ):
> A program containing the line:
> 11510 PRINT@280,"++";
>
>  is saved in the ASCII format output file as:
> 11510 PRINT@280,"GOTOGOTO";
>
> I am not sure if the keyword GOTO is the actual substitution, as I am away
> from my "development" computer and can verify, but it illustrates the basic
> problem. Likely, as BASIC keywords are probably represented as values
> higher than 127d, and the routine in VirtualT to save a file on the PC in
> ASCII format is not setting a flag to track the occurrences of the "
> character pairs and interpret any characters within as ASCII characters and
> not BASIC keywords.
>
> Regards,
>
> Peter
>
> 
>Message: 10
>Date: Tue, 24 Mar 2020 13:27:39 -0700
>From: Ken Pettit 
>To: m100@lists.bitchin100.com
>Subject: Re: [M100] Building VirtualT
>Message-ID: <5e7a6d3b.4020...@gmail.com>
>Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
>Hey Guys,
>
>Steven Hurd also converted the SourceForge.net cvs repo to a git repo.
>Both he and I have been making updates to that repo.  I am working
>toward a VT 1.8 release.
>
>Ken
> 
>

Re: [M100] Building VirtualT

[Peter Noeth]

Does that include bug fixes from v1.7?

I sent Ken a PM back a while ago describing a bug I found, but got no
response.

The problem occurs when transferring a BASIC program from VirtualT to the
PC in ASCII format. The bug concerns any BASIC program that uses embedded
ASCII characters with the value greater than 127d directly in PRINT
statements. When these characters are used (for example, the downward
pointing triangle, 167d A7h), the ASCII character value is not preserved in
the saved output file, but instead a BASIC keyword is substituted.

For example (+ character is really 167d, input with the keyboard sequence
[CODE]_ ):
A program containing the line:
11510 PRINT@280,"++";

 is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";

I am not sure if the keyword GOTO is the actual substitution, as I am away
from my "development" computer and can verify, but it illustrates the basic
problem. Likely, as BASIC keywords are probably represented as values
higher than 127d, and the routine in VirtualT to save a file on the PC in
ASCII format is not setting a flag to track the occurrences of the "
character pairs and interpret any characters within as ASCII characters and
not BASIC keywords.

Regards,

Peter


   Message: 10
   Date: Tue, 24 Mar 2020 13:27:39 -0700
   From: Ken Pettit 
   To: m100@lists.bitchin100.com
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com>
   Content-Type: text/plain; charset="windows-1252"; Format="flowed"

   Hey Guys,

   Steven Hurd also converted the SourceForge.net cvs repo to a git repo.
   Both he and I have been making updates to that repo.  I am working
   toward a VT 1.8 release.

   Ken