Re: [M100] Building VirtualT

[Tom Dison]

Love it!

On Tue, Mar 31, 2020 at 07:29 Ken Pettit  wrote:

>
> On 3/26/20 7:00 PM, John R. Hogerhuis wrote:
> >
> >
> >
> > Don't ask, don't tell :-)
> >
> > sprintf at least is inherently dangerous and should never be used.
> > Should always use snprintf so you're committing to a certain buffer size.
>
> Yep.  But then again, almost all of this code was written over 10 year
> ago.  Did they even have snprintf then! ;)
>
> Heck, programmer's have it easy these days ... they get 1's *and* 0's.
> When I was a kid, we only had 0's!
>
> Ken
>
> --
Faith without Works is Dead...

Re: [M100] Building VirtualT

[Tom Wilson]

On Fri, Mar 27, 2020 at 6:18 PM Brian K. White  wrote:

> On 3/27/20 9:14 PM, Kevin Becker wrote:
> > The official sourceforge version builds on Fedora 31 with the distro
> > FLTK cleanly for me now. Thanks!
> >
> > As a side note, I'm leery of sourceforge too, but it has changed
> > ownership again since the days when they were injecting adware and such
> > into installers.
>
> ...and in the meantime of course, github has lost a bit of it's shine.
>
>
Yeah, I get that some people don't like MS, but so far, GitHub itself has
become more useful to me, with the addition of free, private repositories.

Re: [M100] Building VirtualT

[Tom Wilson]

On Fri, Mar 27, 2020 at 6:14 PM Kevin Becker  wrote:

> The official sourceforge version builds on Fedora 31 with the distro FLTK
> cleanly for me now. Thanks!
>
> As a side note, I'm leery of sourceforge too, but it has changed ownership
> again since the days when they were injecting adware and such into
> installers
>

Yes, the current owners are dedicated to keeping Sourceforge free and are
not doing the ad-supported build system. My only problem with SF today is
just how ugly and hard it is to navigate. GitHub has a much cleaner
interface. But I'm certainly not going to get into a platform war.

Speaking of warning removal... has anyone tried compiling on Windows since
making all those changes? I will try to run a build tonight, if I can, but
I want to make sure the build is still compatible with Visual Studio 19, so
us Windows folks can still build it (and VS19 is the only current community
build that people can get without paying for MSDN.)

Re: [M100] Building VirtualT

[Brian K. White]

On 3/27/20 9:14 PM, Kevin Becker wrote:
The official sourceforge version builds on Fedora 31 with the distro 
FLTK cleanly for me now. Thanks!


As a side note, I'm leery of sourceforge too, but it has changed 
ownership again since the days when they were injecting adware and such 
into installers.


...and in the meantime of course, github has lost a bit of it's shine.


--
bkw

Re: [M100] Building VirtualT

[Kevin Becker]

The official sourceforge version builds on Fedora 31 with the distro
FLTK cleanly for me now.  Thanks!
As a side note, I'm leery of sourceforge too, but it has changed
ownership again since the days when they were injecting adware and such
into installers.


On Fri, 2020-03-27 at 20:01 -0400, Brian K. White wrote:
> I've deleted github.com/bkw777/VirtualT because the upstream original
> builds cleanly now, and although I don't love sourceforge, it does
> turn out to offer basic collaboration like github/gitlab, where
> anyone can make an account, fork, modify, and submit back to the
> original, all browseable in a web ui to view patches etc. So it's
> good enough there is not enough reason to maintain a fork off on a
> different service.
> https://sourceforge.net/p/virtualt/
> 
> Thank you Steven Hurd

Re: [M100] Building VirtualT

[Brian K. White]

I've deleted github.com/bkw777/VirtualT because the upstream original 
builds cleanly now, and although I don't love sourceforge, it does turn 
out to offer basic collaboration like github/gitlab, where anyone can 
make an account, fork, modify, and submit back to the original, all 
browseable in a web ui to view patches etc. So it's good enough there is 
not enough reason to maintain a fork off on a different service.


https://sourceforge.net/p/virtualt/

Thank you Steven Hurd

--
bkw

Re: [M100] Building VirtualT

[Brian K. White]

On 3/26/20 9:44 PM, Ken Pettit wrote:

Hey Brian,

No, I didn't get any of these warnings, but then I didn't have the -Wall 
flag set.  When I set that ... oh my!  I will have to go through and do 
some cleanup ... I don't like warnings!


I'm pulling down my github copy because now the sourceforge copy is more 
up to date.


I've cleared all compiler warnings again, starting from your latest on 
sourceforge, and submitted a merge request.


https://sourceforge.net/u/bkw777/virtualt/

https://sourceforge.net/p/virtualt/code/merge-requests/1/

Next up "make install", .desktop launcher, and .deb package.

--
bkw

Re: [M100] Building VirtualT

[John R. Hogerhuis]

On Thu, Mar 26, 2020 at 7:10 PM Ken Pettit  wrote:

>
> Heck, programmer's have it easy these days ... they get 1's *and* 0's.
> When I was a kid, we only had 0's!
>
> Ken
>
>
Not judging your code or your advanced age ;-)

-- John.

Re: [M100] Building VirtualT

[Kevin Becker]

Just to be clear, Fedora's distro supplied version of FLTK is 1.3.5
which is the current stable release on fltk.org
On Thu, 2020-03-26 at 21:40 -0400, Brian K. White wrote:
> On 3/25/20 10:27 AM, 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
> 
> Don't you get a lot of these generated by your compiler?This is just
> a couple out of many from a fresh git pull.I didn't find these myself
> before, I just addressed each compiler warning until there weren't
> any more.I'll go through them again and see if sourceforge provides a
> way to submit patches back up like gitlab or github.
> src/m100emu.c: In function ‘check_installation’:src/m100emu.c:723:39:
> warning: ‘%s’ directive writing up to 255 bytes into a region of size
> 240 [-Wformat-overflow=]   723 |   sprintf(localpath, "No ROM file
> for %s", errors);   |   ^~  
> ~~In file included from /usr/include/stdio.h:867,
>  from src/m100emu.c:32:/usr/include/x86_64-linux-
> gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output
> between 17 and 272 bytes into a destination of size 25636 |  
> return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,   |
> ^~37 |  
> __bos (__s), __fmt, __va_arg_pack ());   |  
> ~
> 
> I also get this, which is probably from me using the latest fltk.But
> the changes I made for that apparently didn't break building with the
> older versions since Keven Becker said he just used the distro
> supplied package.
> Linking virtualt/usr/bin/ld: obj/remote.o: in function
> `key_delay()':remote.cpp:(.text+0x8f7): undefined reference to
> `fl_wait(double)'/usr/bin/ld: remote.cpp:(.text+0x927): undefined
> reference to `fl_wait(double)'/usr/bin/ld: obj/remote.o: in function
> `cmd_step(ServerSocket&, std::__cxx11::basic_string std::char_traits, std::allocator
> >&)':remote.cpp:(.text+0x3279): undefined reference to
> `fl_wait(double)'/usr/bin/ld: obj/remote.o: in function
> `cmd_step_over(ServerSocket&, std::__cxx11::basic_string std::char_traits, std::allocator
> >&)':remote.cpp:(.text+0x3577): undefined reference to
> `fl_wait(double)'/usr/bin/ld: remote.cpp:(.text+0x3639): undefined
> reference to `fl_wait(double)'/usr/bin/ld:
> obj/remote.o:remote.cpp:(.text+0xb066): more undefined references to
> `fl_wait(double)' followcollect2: error: ld returned 1 exit
> statusmake: *** [GNUmakefile:124: virtualt] Error 1
> 
> Assuming sourceforge provides a way to submit merge requests I'll do
> that shortly.
> 

Re: [M100] Building VirtualT

[Ken Pettit]

On 3/26/20 7:00 PM, John R. Hogerhuis wrote:




Don't ask, don't tell :-)

sprintf at least is inherently dangerous and should never be used. 
Should always use snprintf so you're committing to a certain buffer size.


Yep.  But then again, almost all of this code was written over 10 year 
ago.  Did they even have snprintf then! ;)


Heck, programmer's have it easy these days ... they get 1's *and* 0's.  
When I was a kid, we only had 0's!


Ken

Re: [M100] Building VirtualT

[Brian K. White]

On 3/26/20 9:44 PM, Ken Pettit wrote:

Hey Brian,

No, I didn't get any of these warnings, but then I didn't have the -Wall 
flag set.  When I set that ... oh my!  I will have to go through and do 
some cleanup ... I don't like warnings!


On the plus side, when I did this the first time it didn't take too long 
and none of them were great mysteries, just an obvious and mechanical 
adjustment in each case.


--
bkw

Re: [M100] Building VirtualT

[John R. Hogerhuis]

On Thu, Mar 26, 2020 at 6:44 PM Ken Pettit  wrote:

> Hey Brian,
>
> No, I didn't get any of these warnings, but then I didn't have the -Wall
> flag set.  When I set that ... oh my!  I will have to go through and do
> some cleanup ... I don't like warnings!
>
> Ken
>
>
Don't ask, don't tell :-)

sprintf at least is inherently dangerous and should never be used. Should
always use snprintf so you're committing to a certain buffer size.

-- John.

Re: [M100] Building VirtualT

[Ken Pettit]

Hey Brian,

No, I didn't get any of these warnings, but then I didn't have the -Wall 
flag set.  When I set that ... oh my!  I will have to go through and do 
some cleanup ... I don't like warnings!


Ken

On 3/26/20 6:40 PM, Brian K. White wrote:

On 3/25/20 10:27 AM, 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



Don't you get a lot of these generated by your compiler?
This is just a couple out of many from a fresh git pull.
I didn't find these myself before, I just addressed each compiler 
warning until there weren't any more.
I'll go through them again and see if sourceforge provides a way to 
submit patches back up like gitlab or github.


src/m100emu.c: In function ‘check_installation’:
src/m100emu.c:723:39: warning: ‘%s’ directive writing up to 255 bytes 
into a region of size 240 [-Wformat-overflow=]

  723 |   sprintf(localpath, "No ROM file for %s", errors);
  |   ^~   ~~
In file included from /usr/include/stdio.h:867,
 from src/m100emu.c:32:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: 
‘__builtin___sprintf_chk’ output between 17 and 272 bytes into a 
destination of size 256

   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  | ^~
   37 |   __bos (__s), __fmt, __va_arg_pack ());
  |   ~


I also get this, which is probably from me using the latest fltk.
But the changes I made for that apparently didn't break building with 
the older versions since Keven Becker said he just used the distro 
supplied package.


Linking virtualt
/usr/bin/ld: obj/remote.o: in function `key_delay()':
remote.cpp:(.text+0x8f7): undefined reference to `fl_wait(double)'
/usr/bin/ld: remote.cpp:(.text+0x927): undefined reference to 
`fl_wait(double)'
/usr/bin/ld: obj/remote.o: in function `cmd_step(ServerSocket&, 
std::__cxx11::basic_string, 
std::allocator >&)':

remote.cpp:(.text+0x3279): undefined reference to `fl_wait(double)'
/usr/bin/ld: obj/remote.o: in function `cmd_step_over(ServerSocket&, 
std::__cxx11::basic_string, 
std::allocator >&)':

remote.cpp:(.text+0x3577): undefined reference to `fl_wait(double)'
/usr/bin/ld: remote.cpp:(.text+0x3639): undefined reference to 
`fl_wait(double)'
/usr/bin/ld: obj/remote.o:remote.cpp:(.text+0xb066): more undefined 
references to `fl_wait(double)' follow

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


Assuming sourceforge provides a way to submit merge requests I'll do 
that shortly.

Re: [M100] Building VirtualT

[Brian K. White]

On 3/25/20 10:27 AM, 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



Don't you get a lot of these generated by your compiler?
This is just a couple out of many from a fresh git pull.
I didn't find these myself before, I just addressed each compiler 
warning until there weren't any more.
I'll go through them again and see if sourceforge provides a way to 
submit patches back up like gitlab or github.


src/m100emu.c: In function ‘check_installation’:
src/m100emu.c:723:39: warning: ‘%s’ directive writing up to 255 bytes 
into a region of size 240 [-Wformat-overflow=]

  723 |   sprintf(localpath, "No ROM file for %s", errors);
  |   ^~   ~~
In file included from /usr/include/stdio.h:867,
 from src/m100emu.c:32:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: 
‘__builtin___sprintf_chk’ output between 17 and 272 bytes into a 
destination of size 256

   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  | ^~
   37 |   __bos (__s), __fmt, __va_arg_pack ());
  |   ~


I also get this, which is probably from me using the latest fltk.
But the changes I made for that apparently didn't break building with 
the older versions since Keven Becker said he just used the distro 
supplied package.


Linking virtualt
/usr/bin/ld: obj/remote.o: in function `key_delay()':
remote.cpp:(.text+0x8f7): undefined reference to `fl_wait(double)'
/usr/bin/ld: remote.cpp:(.text+0x927): undefined reference to 
`fl_wait(double)'
/usr/bin/ld: obj/remote.o: in function `cmd_step(ServerSocket&, 
std::__cxx11::basic_string, 
std::allocator >&)':

remote.cpp:(.text+0x3279): undefined reference to `fl_wait(double)'
/usr/bin/ld: obj/remote.o: in function `cmd_step_over(ServerSocket&, 
std::__cxx11::basic_string, 
std::allocator >&)':

remote.cpp:(.text+0x3577): undefined reference to `fl_wait(double)'
/usr/bin/ld: remote.cpp:(.text+0x3639): undefined reference to 
`fl_wait(double)'
/usr/bin/ld: obj/remote.o:remote.cpp:(.text+0xb066): more undefined 
references to `fl_wait(double)' follow

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


Assuming sourceforge provides a way to submit merge requests I'll do 
that shortly.



--
bkw

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 <mailto:m100@lists.bitchin100.com>
Subject: Re: [M100] Building VirtualT
Message-ID: <5e7b616f.6010...@gmail.com 
<mailto: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 bu

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
 

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 <mailto:m100@lists.bitchin100.com>
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
<mailto: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"
&

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 <mailto:m100@lists.bitchin100.com>
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
<mailto: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 <mailto:m100@lists.bitchin100.com>
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
<mailto: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 <mailto:wilso...@gmail.com>
(619)940-6311
K6ABZ


On Wed, Mar 25, 2020 at 12:23 AM Peter Noeth <mailto:petern0...@gmail.com>> 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 <mailto:m100@lists.bitchin100.com>
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com
<mailto: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 <mailto:m100@lists.bitchin100.com>
   Subject: Re: [M100] Building VirtualT
   Message-ID: <5e7a6d3b.4020...@gmail.com 
<mailto: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

Re: [M100] Building VirtualT

[Ken Pettit]

Yes,

It is on SourceForge here:

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

I will have MANY more changes to commit that are not in there yet.

Ken

On 3/24/20 7:20 PM, Brian K. White wrote:

Applied, thank you.
Tom's fix is in there now too.

This is still behind though. Whatever Ken and Steve have done recently 
is not here.


Ken is your git repo on github or gitlab or someplace else public like 
that?

Re: [M100] Building VirtualT

[Brian K. White]

Applied, thank you.
Tom's fix is in there now too.

This is still behind though. Whatever Ken and Steve have done recently 
is not here.


Ken is your git repo on github or gitlab or someplace else public like that?

--
bkw

On 3/24/20 7:04 PM, Joshua O'Keefe wrote:
Here's a diff for building your tree on modern OSX.  It's a pretty small 
diff -- just fixing Darwin.mk to use a modern arch (i386 and ppc aren't 
buildable any more), and fixing a pointer comparison to an int (which is 
an error on clang).  The resulting binary runs, although I don't know 
enough about virtualT to tell you how well.  Feel free to incorporate it 
if you like.




On Tue, Mar 24, 2020 at 3:28 PM Brian K. White > wrote:


This version has a handful of build fixes and array size fixes, but
does
not yet have the speed fix Tom Wilson posted.

Well, my best guess at the proper fixes. I made the compiler
warnings go
away, but I'm not 100% sure they are really the right way to fix
each item.

Some arrays looked like they were one byte too small so they couldn't
hold their terminating null. But maybe the arrays were the right size
and the variables that used them needed to be reduced by one instead.

Others were fuzzier like just needing more room for path strings,
but no
specific number, just, more, so I just picked a bigger value
arbitrarily.

This shows everything in one diff

https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d

Oh yeah I see some fltk fixes for newer versions too I forgot those.

Particularly I'm not sure if removing the Cancel button in display.cpp
was correct. It makes the too-many-params error go away, but I don't
know if that option was actually needed and so it needs some other fix
that lets you still have the button.

I think Ken said he addressed the speed problem in his repo by now. I
don't remember if he posted a github or other public link to his new
git
repo.

The diff for Tom's speed fix from my local copy is:
(not a real diff, I collapsed all the spaces for the email)

bkw@negre:~/src/VirtualT$ git diff HEAD^
diff --git a/src/io.c b/src/io.c
index 28bbdb4..ef4cf42 100644
--- a/src/io.c
+++ b/src/io.c
@@ -1262,14 +1262,15 @@ int inport(uchar port)
{
   if (fullspeed == 0)
    {
+  // Disabled per Tom Wilson mailto:wilso...@gmail.com>> post to m100 list
     /* Loop through all LCD driver modules */
-  for (c = 0; c < 10; c++)
-   {
-    /* Check if this driver is enabled */
-    if (lcdbits & (1 << c))
-     if (lcdTime[c]+.14 > hirestimer())
-      return (0x80);
-   }
+   //for (c = 0; c < 10; c++)
+   //{
+   // /* Check if this driver is enabled */
+   // if (lcdbits & (1 << c))
+   //  if (lcdTime[c]+.14 > hirestimer())
+   //   return (0x80);
+   //}
      return 64;
     }
    else


-- 
bkw



On 3/24/20 4:22 PM, Kevin Becker wrote:
 > For what it's worth, I just built VirtualT on Fedora 31 using
Brian's
 > github.  I didn't build fltk myself, I used the packaged versions.
 >
 > git clone https://github.com/bkw777/VirtualT.git
 > sudo dnf install fltk fltk-devel fltk-static fltk-fluid
 > libXinerama-devel libjpeg-devel
 > export FLTKDIR=/usr/lib64
 > make
 >
 > I haven't done any real testing but it launches and appears to work
 >
 > On Mon, Jan 6, 2020, at 10:17 PM, Brian K. White wrote:
 >> I was just now able to build the latest FLTK and VirtualT on
linux with
 >> the following changes from the v1.7 sourceforge version:
 >>
 >>

https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
 >>
 >> I don't know if every change is quite the most correct way to
resolve
 >> the compiler warnings or errors, and I don't know if one or two
changes
 >> don't also break compiling on Windows or Mac.
 >>
 >> But this commit link shows everything all together and it's not very
 >> much, and at least for me, it builds without even any compiler
warnings
 >> let alone errors, and the resulting binary runs.
 >>
 >> I started with a clean copy of the src zip file from
sourceforge, not a
 >> fork from one of the other copies of VirtualT already on github.
 >>
 >> For fltk I didn't I didn't have to change anything. I just
cloned the
 >> current fltk repo from github (from the fltk web site) and
followed the
 >> CMake directions for building on linux.
 >>
 >> --
 >> bkw
 >>
 >


-- 
bkw





--
bkw

Re: [M100] Building VirtualT

[Joshua O'Keefe]

Here's a diff for building your tree on modern OSX.  It's a pretty small
diff -- just fixing Darwin.mk to use a modern arch (i386 and ppc aren't
buildable any more), and fixing a pointer comparison to an int (which is an
error on clang).  The resulting binary runs, although I don't know enough
about virtualT to tell you how well.  Feel free to incorporate it if you
like.



On Tue, Mar 24, 2020 at 3:28 PM Brian K. White  wrote:

> This version has a handful of build fixes and array size fixes, but does
> not yet have the speed fix Tom Wilson posted.
>
> Well, my best guess at the proper fixes. I made the compiler warnings go
> away, but I'm not 100% sure they are really the right way to fix each item.
>
> Some arrays looked like they were one byte too small so they couldn't
> hold their terminating null. But maybe the arrays were the right size
> and the variables that used them needed to be reduced by one instead.
>
> Others were fuzzier like just needing more room for path strings, but no
> specific number, just, more, so I just picked a bigger value arbitrarily.
>
> This shows everything in one diff
>
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
>
> Oh yeah I see some fltk fixes for newer versions too I forgot those.
>
> Particularly I'm not sure if removing the Cancel button in display.cpp
> was correct. It makes the too-many-params error go away, but I don't
> know if that option was actually needed and so it needs some other fix
> that lets you still have the button.
>
> I think Ken said he addressed the speed problem in his repo by now. I
> don't remember if he posted a github or other public link to his new git
> repo.
>
> The diff for Tom's speed fix from my local copy is:
> (not a real diff, I collapsed all the spaces for the email)
>
> bkw@negre:~/src/VirtualT$ git diff HEAD^
> diff --git a/src/io.c b/src/io.c
> index 28bbdb4..ef4cf42 100644
> --- a/src/io.c
> +++ b/src/io.c
> @@ -1262,14 +1262,15 @@ int inport(uchar port)
> {
>   if (fullspeed == 0)
>{
> +  // Disabled per Tom Wilson  post to m100 list
> /* Loop through all LCD driver modules */
> -  for (c = 0; c < 10; c++)
> -   {
> -/* Check if this driver is enabled */
> -if (lcdbits & (1 << c))
> - if (lcdTime[c]+.14 > hirestimer())
> -  return (0x80);
> -   }
> +   //for (c = 0; c < 10; c++)
> +   //{
> +   // /* Check if this driver is enabled */
> +   // if (lcdbits & (1 << c))
> +   //  if (lcdTime[c]+.14 > hirestimer())
> +   //   return (0x80);
> +   //}
>  return 64;
> }
>else
>
>
> --
> bkw
>
>
> On 3/24/20 4:22 PM, Kevin Becker wrote:
> > For what it's worth, I just built VirtualT on Fedora 31 using Brian's
> > github.  I didn't build fltk myself, I used the packaged versions.
> >
> > git clone https://github.com/bkw777/VirtualT.git
> > sudo dnf install fltk fltk-devel fltk-static fltk-fluid
> > libXinerama-devel libjpeg-devel
> > export FLTKDIR=/usr/lib64
> > make
> >
> > I haven't done any real testing but it launches and appears to work
> >
> > On Mon, Jan 6, 2020, at 10:17 PM, Brian K. White wrote:
> >> I was just now able to build the latest FLTK and VirtualT on linux with
> >> the following changes from the v1.7 sourceforge version:
> >>
> >>
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
> >>
> >> I don't know if every change is quite the most correct way to resolve
> >> the compiler warnings or errors, and I don't know if one or two changes
> >> don't also break compiling on Windows or Mac.
> >>
> >> But this commit link shows everything all together and it's not very
> >> much, and at least for me, it builds without even any compiler warnings
> >> let alone errors, and the resulting binary runs.
> >>
> >> I started with a clean copy of the src zip file from sourceforge, not a
> >> fork from one of the other copies of VirtualT already on github.
> >>
> >> For fltk I didn't I didn't have to change anything. I just cloned the
> >> current fltk repo from github (from the fltk web site) and followed the
> >> CMake directions for building on linux.
> >>
> >> --
> >> bkw
> >>
> >
>
>
> --
> bkw
>


virtualt-darwin-fix.diff
Description: Binary data

Re: [M100] Building VirtualT

[Ken Pettit]

Hey Brian,

I think I found some of those array size fixes also, but not sure I 
found all the same one you did perhaps.  I will double-check your repo.


The extra warning parameter on the "Cancel button" in display.cpp was 
correct ... I also made that change.


Ken

On 3/24/20 3:28 PM, Brian K. White wrote:
This version has a handful of build fixes and array size fixes, but 
does not yet have the speed fix Tom Wilson posted.


Well, my best guess at the proper fixes. I made the compiler warnings 
go away, but I'm not 100% sure they are really the right way to fix 
each item.


Some arrays looked like they were one byte too small so they couldn't 
hold their terminating null. But maybe the arrays were the right size 
and the variables that used them needed to be reduced by one instead.


Others were fuzzier like just needing more room for path strings, but 
no specific number, just, more, so I just picked a bigger value 
arbitrarily.


This shows everything in one diff
https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d 



Oh yeah I see some fltk fixes for newer versions too I forgot those.

Particularly I'm not sure if removing the Cancel button in display.cpp 
was correct. It makes the too-many-params error go away, but I don't 
know if that option was actually needed and so it needs some other fix 
that lets you still have the button.


I think Ken said he addressed the speed problem in his repo by now. I 
don't remember if he posted a github or other public link to his new 
git repo.


The diff for Tom's speed fix from my local copy is:
(not a real diff, I collapsed all the spaces for the email)

bkw@negre:~/src/VirtualT$ git diff HEAD^
diff --git a/src/io.c b/src/io.c
index 28bbdb4..ef4cf42 100644
--- a/src/io.c
+++ b/src/io.c
@@ -1262,14 +1262,15 @@ int inport(uchar port)
{
 if (fullspeed == 0)
  {
+  // Disabled per Tom Wilson  post to m100 list
   /* Loop through all LCD driver modules */
-  for (c = 0; c < 10; c++)
-   {
-/* Check if this driver is enabled */
-if (lcdbits & (1 << c))
- if (lcdTime[c]+.14 > hirestimer())
-  return (0x80);
-   }
+   //for (c = 0; c < 10; c++)
+   //{
+   // /* Check if this driver is enabled */
+   // if (lcdbits & (1 << c))
+   //  if (lcdTime[c]+.14 > hirestimer())
+   //   return (0x80);
+   //}
return 64;
   }
  else

Re: [M100] Building VirtualT

[Tom Wilson]

Isn’t Ken just updating the SourceForge repo? There’s not a new build from
there, but I’ve seen checkin comments.

I have been able to get VirtualT to build on Windows with Visual Studio,
but I did have to locate the older version of FLTK. I may pull the latest
repo to update my working copy and integrate Ken’s latest changes.

I don’t know if there’s a way to do pull requests on SourceForge, like
there is on GitHub, but if there is, that’s where I’d start. Get your work
rolled back in to the main repo.

I’m planning on patching a bug in the serial port emulation; the program
locks up when you close it with the serial port emulation turned on, and it
doesn’t open the serial port when you select it from the peripheral menu.
The user has to restart the program. So that all needs some cleanup.

The internal Rex implementation is also out of date; the control-key
hotkeys don’t work, for example.

Specifically on paths: I think the Windows shell limit on path sizes is 260
characters, but if VirtualT is still using char* arrays for paths, that
should probably be refactored to use the STL string type.

Ken has been commenting here, so hopefully he’ll have some advice on how we
can submit patches for these things.

On Tue, Mar 24, 2020 at 3:28 PM Brian K. White  wrote:

> This version has a handful of build fixes and array size fixes, but does
> not yet have the speed fix Tom Wilson posted.
>
> Well, my best guess at the proper fixes. I made the compiler warnings go
> away, but I'm not 100% sure they are really the right way to fix each item.
>
> Some arrays looked like they were one byte too small so they couldn't
> hold their terminating null. But maybe the arrays were the right size
> and the variables that used them needed to be reduced by one instead.
>
> Others were fuzzier like just needing more room for path strings, but no
> specific number, just, more, so I just picked a bigger value arbitrarily.
>
> This shows everything in one diff
>
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
>
> Oh yeah I see some fltk fixes for newer versions too I forgot those.
>
> Particularly I'm not sure if removing the Cancel button in display.cpp
> was correct. It makes the too-many-params error go away, but I don't
> know if that option was actually needed and so it needs some other fix
> that lets you still have the button.
>
> I think Ken said he addressed the speed problem in his repo by now. I
> don't remember if he posted a github or other public link to his new git
> repo.
>
> The diff for Tom's speed fix from my local copy is:
> (not a real diff, I collapsed all the spaces for the email)
>
> bkw@negre:~/src/VirtualT$ git diff HEAD^
> diff --git a/src/io.c b/src/io.c
> index 28bbdb4..ef4cf42 100644
> --- a/src/io.c
> +++ b/src/io.c
> @@ -1262,14 +1262,15 @@ int inport(uchar port)
> {
>   if (fullspeed == 0)
>{
> +  // Disabled per Tom Wilson  post to m100 list
> /* Loop through all LCD driver modules */
> -  for (c = 0; c < 10; c++)
> -   {
> -/* Check if this driver is enabled */
> -if (lcdbits & (1 << c))
> - if (lcdTime[c]+.14 > hirestimer())
> -  return (0x80);
> -   }
> +   //for (c = 0; c < 10; c++)
> +   //{
> +   // /* Check if this driver is enabled */
> +   // if (lcdbits & (1 << c))
> +   //  if (lcdTime[c]+.14 > hirestimer())
> +   //   return (0x80);
> +   //}
>  return 64;
> }
>else
>
>
> --
> bkw
>
>
> On 3/24/20 4:22 PM, Kevin Becker wrote:
> > For what it's worth, I just built VirtualT on Fedora 31 using Brian's
> > github.  I didn't build fltk myself, I used the packaged versions.
> >
> > git clone https://github.com/bkw777/VirtualT.git
> > sudo dnf install fltk fltk-devel fltk-static fltk-fluid
> > libXinerama-devel libjpeg-devel
> > export FLTKDIR=/usr/lib64
> > make
> >
> > I haven't done any real testing but it launches and appears to work
> >
> > On Mon, Jan 6, 2020, at 10:17 PM, Brian K. White wrote:
> >> I was just now able to build the latest FLTK and VirtualT on linux with
> >> the following changes from the v1.7 sourceforge version:
> >>
> >>
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
> >>
> >> I don't know if every change is quite the most correct way to resolve
> >> the compiler warnings or errors, and I don't know if one or two changes
> >> don't also break compiling on Windows or Mac.
> >>
> >> But this commit link shows everything all together and it's not very
> >> much, and at least for me, it builds without even any compiler warnings
> >> let alone errors, and the resulting binary runs.
> >>
> >> I started with a clean copy of the src zip file from sourceforge, not a
> >> fork from one of the other copies of VirtualT already on github.
> >>
> >> For fltk I didn't I didn't have to change anything. I just cloned the
> >> current fltk repo from github (from the fltk web site) and followed the
> >> CMake directions for building on linux.
> >>
> >> --
> >> bkw
> 

Re: [M100] Building VirtualT

[Brian K. White]

This version has a handful of build fixes and array size fixes, but does 
not yet have the speed fix Tom Wilson posted.


Well, my best guess at the proper fixes. I made the compiler warnings go 
away, but I'm not 100% sure they are really the right way to fix each item.


Some arrays looked like they were one byte too small so they couldn't 
hold their terminating null. But maybe the arrays were the right size 
and the variables that used them needed to be reduced by one instead.


Others were fuzzier like just needing more room for path strings, but no 
specific number, just, more, so I just picked a bigger value arbitrarily.


This shows everything in one diff
https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d

Oh yeah I see some fltk fixes for newer versions too I forgot those.

Particularly I'm not sure if removing the Cancel button in display.cpp 
was correct. It makes the too-many-params error go away, but I don't 
know if that option was actually needed and so it needs some other fix 
that lets you still have the button.


I think Ken said he addressed the speed problem in his repo by now. I 
don't remember if he posted a github or other public link to his new git 
repo.


The diff for Tom's speed fix from my local copy is:
(not a real diff, I collapsed all the spaces for the email)

bkw@negre:~/src/VirtualT$ git diff HEAD^
diff --git a/src/io.c b/src/io.c
index 28bbdb4..ef4cf42 100644
--- a/src/io.c
+++ b/src/io.c
@@ -1262,14 +1262,15 @@ int inport(uchar port)
{
 if (fullspeed == 0)
  {
+  // Disabled per Tom Wilson  post to m100 list
   /* Loop through all LCD driver modules */
-  for (c = 0; c < 10; c++)
-   {
-/* Check if this driver is enabled */
-if (lcdbits & (1 << c))
- if (lcdTime[c]+.14 > hirestimer())
-  return (0x80);
-   }
+   //for (c = 0; c < 10; c++)
+   //{
+   // /* Check if this driver is enabled */
+   // if (lcdbits & (1 << c))
+   //  if (lcdTime[c]+.14 > hirestimer())
+   //   return (0x80);
+   //}
return 64;
   }
  else


--
bkw


On 3/24/20 4:22 PM, Kevin Becker wrote:
For what it's worth, I just built VirtualT on Fedora 31 using Brian's 
github.  I didn't build fltk myself, I used the packaged versions.


git clone https://github.com/bkw777/VirtualT.git
sudo dnf install fltk fltk-devel fltk-static fltk-fluid 
libXinerama-devel libjpeg-devel

export FLTKDIR=/usr/lib64
make

I haven't done any real testing but it launches and appears to work

On Mon, Jan 6, 2020, at 10:17 PM, Brian K. White wrote:

I was just now able to build the latest FLTK and VirtualT on linux with
the following changes from the v1.7 sourceforge version:

https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d

I don't know if every change is quite the most correct way to resolve
the compiler warnings or errors, and I don't know if one or two changes
don't also break compiling on Windows or Mac.

But this commit link shows everything all together and it's not very
much, and at least for me, it builds without even any compiler warnings
let alone errors, and the resulting binary runs.

I started with a clean copy of the src zip file from sourceforge, not a
fork from one of the other copies of VirtualT already on github.

For fltk I didn't I didn't have to change anything. I just cloned the
current fltk repo from github (from the fltk web site) and followed the
CMake directions for building on linux.

--
bkw






--
bkw

Re: [M100] Building VirtualT

[Ken Pettit]

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


On 3/24/20 1:22 PM, Kevin Becker wrote:
For what it's worth, I just built VirtualT on Fedora 31 using Brian's 
github.  I didn't build fltk myself, I used the packaged versions.


git clone https://github.com/bkw777/VirtualT.git
sudo dnf install fltk fltk-devel fltk-static fltk-fluid 
libXinerama-devel libjpeg-devel

export FLTKDIR=/usr/lib64
make

I haven't done any real testing but it launches and appears to work

On Mon, Jan 6, 2020, at 10:17 PM, Brian K. White wrote:

I was just now able to build the latest FLTK and VirtualT on linux with
the following changes from the v1.7 sourceforge version:

https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d

I don't know if every change is quite the most correct way to resolve
the compiler warnings or errors, and I don't know if one or two changes
don't also break compiling on Windows or Mac.

But this commit link shows everything all together and it's not very
much, and at least for me, it builds without even any compiler warnings
let alone errors, and the resulting binary runs.

I started with a clean copy of the src zip file from sourceforge, not a
fork from one of the other copies of VirtualT already on github.

For fltk I didn't I didn't have to change anything. I just cloned the
current fltk repo from github (from the fltk web site) and followed the
CMake directions for building on linux.

--
bkw

Re: [M100] Building VirtualT

[Kevin Becker]

For what it's worth, I just built VirtualT on Fedora 31 using Brian's github. I 
didn't build fltk myself, I used the packaged versions.

git clone https://github.com/bkw777/VirtualT.git
sudo dnf install fltk fltk-devel fltk-static fltk-fluid libXinerama-devel 
libjpeg-devel 
export FLTKDIR=/usr/lib64
make

I haven't done any real testing but it launches and appears to work

On Mon, Jan 6, 2020, at 10:17 PM, Brian K. White wrote:
> I was just now able to build the latest FLTK and VirtualT on linux with 
> the following changes from the v1.7 sourceforge version:
> 
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
> 
> I don't know if every change is quite the most correct way to resolve 
> the compiler warnings or errors, and I don't know if one or two changes 
> don't also break compiling on Windows or Mac.
> 
> But this commit link shows everything all together and it's not very 
> much, and at least for me, it builds without even any compiler warnings 
> let alone errors, and the resulting binary runs.
> 
> I started with a clean copy of the src zip file from sourceforge, not a 
> fork from one of the other copies of VirtualT already on github.
> 
> For fltk I didn't I didn't have to change anything. I just cloned the 
> current fltk repo from github (from the fltk web site) and followed the 
> CMake directions for building on linux.
> 
> -- 
> bkw
> 

Re: [M100] Building VirtualT

[Stephen Adolph]

How about Windows?
Anyone have a formula for what one needs to compile VT on Windows?
thanks.

Re: [M100] Building VirtualT

[Stephen Adolph]

sorry meant instructions on the Bitchin100 wiki.
http://bitchin100.com/wiki/index.php?title=Building_VirtualT_on_Linux

On Sat, Feb 1, 2020 at 9:42 AM Stephen Adolph  wrote:

> I was able to compile virtualT1.7, as it stands on Sourceforge, using the
> instructions at club100, on the following system
>
> Ubuntu 14.04 LTS
> FLTK 1.3.5 obtained from FLTK site
> GCC 4.8.4
>
> I got a few warnings but no errors.
> seems to work in linux.
>
> Why I am doing this:  extend VirtualT to support REXCPM.  I'll keep my
> updates separate until such time as there is a new release planned.
>
> cheers
> Steve
>
>
> On Sat, Feb 1, 2020 at 8:38 AM Stephen Adolph 
> wrote:
>
>> any reason why these might not work on Ubuntu 16.04 LTS?
>>
>> On Wed, Jan 8, 2020 at 12:12 AM Brian K. White 
>> wrote:
>>
>>> Ubuntu 19.10
>>>
>>> gcc 9.2.1
>>>
>>> fltk 1.4.0
>>>actually "git clone https://github.com/fltk/fltk.git;
>>>And the CMake directions in the middle of here:
>>>https://github.com/fltk/fltk/blob/master/README.CMake.txt
>>> "
>>>  mkdir build
>>>  cd build
>>>  cmake ..
>>>  make
>>>  sudo make install
>>> "
>>> I didn't supply any of those options shown in that doc, just the steps
>>> right here.
>>>
>>> You may need to install some things before the fltk build works, and I
>>> can't say what those might be, because it depends what you just randomly
>>> happen to have installed and what I happened to have already had
>>> installed. The main useful thing to know is just that I didn't touch the
>>> fltk source at all, and I didn't even give any of the configure or build
>>> commands any special commandline flags or set any special environment
>>> variables. It was literally just these bare commands above. It means
>>> that if fltk doesn't build for you, you *probably* only need to install
>>> something indicated by the error message. like "apt install libjpeg-dev"
>>> etc, or yum install ... for centos etc. No special tricks or anything.
>>>
>>> And the virtualt 1.7 source zip file from here:
>>> https://sourceforge.net/projects/virtualt/files/Source/v1.7/
>>>
>>> Except you would not get that zip unless you wanted to start from that
>>> same starting point and add your own changes manually. To get the
>>> changes already applied, you could just clone the repo:
>>>git clone g...@github.com:bkw777/VirtualT.git
>>>
>>> --
>>> bkw
>>>
>>>
>>> On 1/7/20 5:54 AM, r cs wrote:
>>> > What specific versions of Linux, gcc, and FLTK were used?  Any changes
>>> > to build FLTK?
>>> >
>>> > Thank you for sharing.
>>> >
>>> > Regards,
>>> > rcs
>>> >
>>> > On Mon, Jan 6, 2020 at 10:17 PM Brian K. White >> > > wrote:
>>> >
>>> > I was just now able to build the latest FLTK and VirtualT on linux
>>> with
>>> > the following changes from the v1.7 sourceforge version:
>>> >
>>> >
>>> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
>>> >
>>> > I don't know if every change is quite the most correct way to
>>> resolve
>>> > the compiler warnings or errors, and I don't know if one or two
>>> changes
>>> > don't also break compiling on Windows or Mac.
>>> >
>>> > But this commit link shows everything all together and it's not
>>> very
>>> > much, and at least for me, it builds without even any compiler
>>> warnings
>>> > let alone errors, and the resulting binary runs.
>>> >
>>> > I started with a clean copy of the src zip file from sourceforge,
>>> not a
>>> > fork from one of the other copies of VirtualT already on github.
>>> >
>>> > For fltk I didn't I didn't have to change anything. I just cloned
>>> the
>>> > current fltk repo from github (from the fltk web site) and
>>> followed the
>>> > CMake directions for building on linux.
>>> >
>>> > --
>>> > bkw
>>> >
>>> >
>>> >
>>> > --
>>> > /Níl aon tinteán mar do thinteán féin. /[Irish Gaelic]
>>> > (There is no fireside like your own fireside.)
>>> >
>>> >
>>>
>>>
>>> --
>>> bkw
>>>
>>

Re: [M100] Building VirtualT

[Stephen Adolph]

I was able to compile virtualT1.7, as it stands on Sourceforge, using the
instructions at club100, on the following system

Ubuntu 14.04 LTS
FLTK 1.3.5 obtained from FLTK site
GCC 4.8.4

I got a few warnings but no errors.
seems to work in linux.

Why I am doing this:  extend VirtualT to support REXCPM.  I'll keep my
updates separate until such time as there is a new release planned.

cheers
Steve


On Sat, Feb 1, 2020 at 8:38 AM Stephen Adolph  wrote:

> any reason why these might not work on Ubuntu 16.04 LTS?
>
> On Wed, Jan 8, 2020 at 12:12 AM Brian K. White 
> wrote:
>
>> Ubuntu 19.10
>>
>> gcc 9.2.1
>>
>> fltk 1.4.0
>>actually "git clone https://github.com/fltk/fltk.git;
>>And the CMake directions in the middle of here:
>>https://github.com/fltk/fltk/blob/master/README.CMake.txt
>> "
>>  mkdir build
>>  cd build
>>  cmake ..
>>  make
>>  sudo make install
>> "
>> I didn't supply any of those options shown in that doc, just the steps
>> right here.
>>
>> You may need to install some things before the fltk build works, and I
>> can't say what those might be, because it depends what you just randomly
>> happen to have installed and what I happened to have already had
>> installed. The main useful thing to know is just that I didn't touch the
>> fltk source at all, and I didn't even give any of the configure or build
>> commands any special commandline flags or set any special environment
>> variables. It was literally just these bare commands above. It means
>> that if fltk doesn't build for you, you *probably* only need to install
>> something indicated by the error message. like "apt install libjpeg-dev"
>> etc, or yum install ... for centos etc. No special tricks or anything.
>>
>> And the virtualt 1.7 source zip file from here:
>> https://sourceforge.net/projects/virtualt/files/Source/v1.7/
>>
>> Except you would not get that zip unless you wanted to start from that
>> same starting point and add your own changes manually. To get the
>> changes already applied, you could just clone the repo:
>>git clone g...@github.com:bkw777/VirtualT.git
>>
>> --
>> bkw
>>
>>
>> On 1/7/20 5:54 AM, r cs wrote:
>> > What specific versions of Linux, gcc, and FLTK were used?  Any changes
>> > to build FLTK?
>> >
>> > Thank you for sharing.
>> >
>> > Regards,
>> > rcs
>> >
>> > On Mon, Jan 6, 2020 at 10:17 PM Brian K. White > > > wrote:
>> >
>> > I was just now able to build the latest FLTK and VirtualT on linux
>> with
>> > the following changes from the v1.7 sourceforge version:
>> >
>> >
>> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
>> >
>> > I don't know if every change is quite the most correct way to
>> resolve
>> > the compiler warnings or errors, and I don't know if one or two
>> changes
>> > don't also break compiling on Windows or Mac.
>> >
>> > But this commit link shows everything all together and it's not very
>> > much, and at least for me, it builds without even any compiler
>> warnings
>> > let alone errors, and the resulting binary runs.
>> >
>> > I started with a clean copy of the src zip file from sourceforge,
>> not a
>> > fork from one of the other copies of VirtualT already on github.
>> >
>> > For fltk I didn't I didn't have to change anything. I just cloned
>> the
>> > current fltk repo from github (from the fltk web site) and followed
>> the
>> > CMake directions for building on linux.
>> >
>> > --
>> > bkw
>> >
>> >
>> >
>> > --
>> > /Níl aon tinteán mar do thinteán féin. /[Irish Gaelic]
>> > (There is no fireside like your own fireside.)
>> >
>> >
>>
>>
>> --
>> bkw
>>
>

Re: [M100] Building VirtualT

[Stephen Adolph]

any reason why these might not work on Ubuntu 16.04 LTS?

On Wed, Jan 8, 2020 at 12:12 AM Brian K. White  wrote:

> Ubuntu 19.10
>
> gcc 9.2.1
>
> fltk 1.4.0
>actually "git clone https://github.com/fltk/fltk.git;
>And the CMake directions in the middle of here:
>https://github.com/fltk/fltk/blob/master/README.CMake.txt
> "
>  mkdir build
>  cd build
>  cmake ..
>  make
>  sudo make install
> "
> I didn't supply any of those options shown in that doc, just the steps
> right here.
>
> You may need to install some things before the fltk build works, and I
> can't say what those might be, because it depends what you just randomly
> happen to have installed and what I happened to have already had
> installed. The main useful thing to know is just that I didn't touch the
> fltk source at all, and I didn't even give any of the configure or build
> commands any special commandline flags or set any special environment
> variables. It was literally just these bare commands above. It means
> that if fltk doesn't build for you, you *probably* only need to install
> something indicated by the error message. like "apt install libjpeg-dev"
> etc, or yum install ... for centos etc. No special tricks or anything.
>
> And the virtualt 1.7 source zip file from here:
> https://sourceforge.net/projects/virtualt/files/Source/v1.7/
>
> Except you would not get that zip unless you wanted to start from that
> same starting point and add your own changes manually. To get the
> changes already applied, you could just clone the repo:
>git clone g...@github.com:bkw777/VirtualT.git
>
> --
> bkw
>
>
> On 1/7/20 5:54 AM, r cs wrote:
> > What specific versions of Linux, gcc, and FLTK were used?  Any changes
> > to build FLTK?
> >
> > Thank you for sharing.
> >
> > Regards,
> > rcs
> >
> > On Mon, Jan 6, 2020 at 10:17 PM Brian K. White  > > wrote:
> >
> > I was just now able to build the latest FLTK and VirtualT on linux
> with
> > the following changes from the v1.7 sourceforge version:
> >
> >
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
> >
> > I don't know if every change is quite the most correct way to resolve
> > the compiler warnings or errors, and I don't know if one or two
> changes
> > don't also break compiling on Windows or Mac.
> >
> > But this commit link shows everything all together and it's not very
> > much, and at least for me, it builds without even any compiler
> warnings
> > let alone errors, and the resulting binary runs.
> >
> > I started with a clean copy of the src zip file from sourceforge,
> not a
> > fork from one of the other copies of VirtualT already on github.
> >
> > For fltk I didn't I didn't have to change anything. I just cloned the
> > current fltk repo from github (from the fltk web site) and followed
> the
> > CMake directions for building on linux.
> >
> > --
> > bkw
> >
> >
> >
> > --
> > /Níl aon tinteán mar do thinteán féin. /[Irish Gaelic]
> > (There is no fireside like your own fireside.)
> >
> >
>
>
> --
> bkw
>

Re: [M100] Building VirtualT

[Brian K. White]

Ubuntu 19.10

gcc 9.2.1

fltk 1.4.0
  actually "git clone https://github.com/fltk/fltk.git;
  And the CMake directions in the middle of here:
  https://github.com/fltk/fltk/blob/master/README.CMake.txt
"
mkdir build
cd build
cmake ..
make
sudo make install
"
I didn't supply any of those options shown in that doc, just the steps 
right here.


You may need to install some things before the fltk build works, and I 
can't say what those might be, because it depends what you just randomly 
happen to have installed and what I happened to have already had 
installed. The main useful thing to know is just that I didn't touch the 
fltk source at all, and I didn't even give any of the configure or build 
commands any special commandline flags or set any special environment 
variables. It was literally just these bare commands above. It means 
that if fltk doesn't build for you, you *probably* only need to install 
something indicated by the error message. like "apt install libjpeg-dev" 
etc, or yum install ... for centos etc. No special tricks or anything.


And the virtualt 1.7 source zip file from here:
https://sourceforge.net/projects/virtualt/files/Source/v1.7/

Except you would not get that zip unless you wanted to start from that 
same starting point and add your own changes manually. To get the 
changes already applied, you could just clone the repo:

  git clone g...@github.com:bkw777/VirtualT.git

--
bkw


On 1/7/20 5:54 AM, r cs wrote:
What specific versions of Linux, gcc, and FLTK were used?  Any changes 
to build FLTK?


Thank you for sharing.

Regards,
rcs

On Mon, Jan 6, 2020 at 10:17 PM Brian K. White > wrote:


I was just now able to build the latest FLTK and VirtualT on linux with
the following changes from the v1.7 sourceforge version:


https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d

I don't know if every change is quite the most correct way to resolve
the compiler warnings or errors, and I don't know if one or two changes
don't also break compiling on Windows or Mac.

But this commit link shows everything all together and it's not very
much, and at least for me, it builds without even any compiler warnings
let alone errors, and the resulting binary runs.

I started with a clean copy of the src zip file from sourceforge, not a
fork from one of the other copies of VirtualT already on github.

For fltk I didn't I didn't have to change anything. I just cloned the
current fltk repo from github (from the fltk web site) and followed the
CMake directions for building on linux.

-- 
bkw




--
/Níl aon tinteán mar do thinteán féin. /[Irish Gaelic]
(There is no fireside like your own fireside.)





--
bkw

Re: [M100] Building VirtualT

[r cs]

What specific versions of Linux, gcc, and FLTK were used?  Any changes to
build FLTK?

Thank you for sharing.

Regards,
rcs

On Mon, Jan 6, 2020 at 10:17 PM Brian K. White  wrote:

> I was just now able to build the latest FLTK and VirtualT on linux with
> the following changes from the v1.7 sourceforge version:
>
>
> https://github.com/bkw777/VirtualT/commit/fe6df94725a5fcf1989964b22cb79848dc778a6d
>
> I don't know if every change is quite the most correct way to resolve
> the compiler warnings or errors, and I don't know if one or two changes
> don't also break compiling on Windows or Mac.
>
> But this commit link shows everything all together and it's not very
> much, and at least for me, it builds without even any compiler warnings
> let alone errors, and the resulting binary runs.
>
> I started with a clean copy of the src zip file from sourceforge, not a
> fork from one of the other copies of VirtualT already on github.
>
> For fltk I didn't I didn't have to change anything. I just cloned the
> current fltk repo from github (from the fltk web site) and followed the
> CMake directions for building on linux.
>
> --
> bkw
>


-- 
*Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
(There is no fireside like your own fireside.)