QLirc 1.99.8

Anything QL Software or Programming Related.
User avatar
dilwyn
Mr QL
Posts: 1718
Joined: Wed Dec 01, 2010 10:39 pm
Location: Wales
Contact:

QLirc 1.99.8

Postby dilwyn » Wed Nov 11, 2020 5:14 pm

Very little progress made on QLirc last few weeks due to being so busy. Here's the package as it stands, while I continue to work on it.

Connects to QL Forum online chat and other IRC channels on QPC2, and recent versions of QemuLator and sQLux, thanks to the work of Daniele Terdina and Graeme Gregory.

Written in BASIC and uncompiled as yet - runs quite reliably on my QPC2 system at least. Does not work on an unregistered QemuLator, TCP/IP must be enabled.

Before use, make sure you read the document showing how to alter the configuration settings as need be in the variables near the start of the program.
QLirc1_99_8.jpg
Opening screen

QLirc1_99_8.zip
QLirc
(58.2 KiB) Downloaded 20 times


--
All things QL - http://www.dilwyn.me.uk
Derek_Stewart
Font of All Knowledge
Posts: 2066
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: QLirc 1.99.8

Postby Derek_Stewart » Wed Nov 11, 2020 9:44 pm

Hi Dilwyn,

Could QLirc be adapted to be a web browser?


Regards,

Derek
User avatar
dilwyn
Mr QL
Posts: 1718
Joined: Wed Dec 01, 2010 10:39 pm
Location: Wales
Contact:

Re: QLirc 1.99.8

Postby dilwyn » Wed Nov 11, 2020 9:59 pm

Derek_Stewart wrote:Hi Dilwyn,

Could QLirc be adapted to be a web browser?

Not directly, no. But I do have longer term plans in that direction!


--
All things QL - http://www.dilwyn.me.uk
User avatar
ppe
Bent Pin Expansion Port
Posts: 92
Joined: Tue Dec 14, 2010 10:48 am
Location: Espoo, Finland

Re: QLirc 1.99.8

Postby ppe » Thu Nov 12, 2020 2:02 pm

Thank you for sharing, Dillwyn! This is a really nice implementation! The code is very readable and nicely structured. Will it go through Turbo nicely?

I must say that the problem of simultaneously reading keyboard and handling bidirectional network communications at the same time is a pretty tough one to pull off in SuperBasic so you and Tim have done a great job!

I did a bit of prototyping with a minimalistic C-based IRC client compiled with C68. Unfortunately, it uses the CURSES library whose implementation on the QL side seems to be lacking a couple of features. So I have not managed to mangle the implementation into a decent adaptation. Also, albeit based purely on feeling not actual benchmarking, the CURSES library implementation on the QL seems quite slow. But it does make the job of porting sw easier.


User avatar
dilwyn
Mr QL
Posts: 1718
Joined: Wed Dec 01, 2010 10:39 pm
Location: Wales
Contact:

Re: QLirc 1.99.8

Postby dilwyn » Thu Nov 12, 2020 3:14 pm

ppe wrote:Thank you for sharing, Dillwyn! This is a really nice implementation! The code is very readable and nicely structured. Will it go through Turbo nicely?

I must say that the problem of simultaneously reading keyboard and handling bidirectional network communications at the same time is a pretty tough one to pull off in SuperBasic so you and Tim have done a great job!

I did a bit of prototyping with a minimalistic C-based IRC client compiled with C68. Unfortunately, it uses the CURSES library whose implementation on the QL side seems to be lacking a couple of features. So I have not managed to mangle the implementation into a decent adaptation. Also, albeit based purely on feeling not actual benchmarking, the CURSES library implementation on the QL seems quite slow. But it does make the job of porting sw easier.

Thanks Petri. ATM it won't compile with Turbo - not tried current QLirc, can't remember why earlier ones wouldn't compile. A previous version was successfully compiled with QLiberator 3.36

The keyboard and bidirectional network communications was Tim Swenson's idea, I simply built on that. No library as such was used, merely uses the bog-standard TCP/IP handling in some emulators. There is a bit of an issue with some emulators concerning timeout on fetching individual characters from the TCP channel - I think Daniele changed something to help in the most recent QemuLator. In order to get the bidirectional working, you had to quickly alternate between reading and writing bytes from/to the TCP channel, and INKEY$(#channel) is the only practical way to do it in BASIC at least. I seem to remember Tim had some issues trying to get it to work on SMSQmulator (can't remember the reason - I don't have SMSQmulator on my computer). And XorA on here did some changes to sQLux (the uQLx derivative) to help deal with the same issue with TCP.

As ever with these things, time is the problem for me, as QL software projects tend to get larger and more complex. I've loads of ideas and part-written projects, but no time! I'd hoped our lockdown period in Wales would have allowed me a bit more time to work on QL software, but if anything the reverse happened :roll:


--
All things QL - http://www.dilwyn.me.uk
User avatar
ppe
Bent Pin Expansion Port
Posts: 92
Joined: Tue Dec 14, 2010 10:48 am
Location: Espoo, Finland

Re: QLirc 1.99.8

Postby ppe » Thu Nov 12, 2020 3:44 pm

dilwyn wrote:INKEY$(#channel) is the only practical way to do it in BASIC at least.

From perfomance perspective it would be really nice to have an

Code: Select all

INPUT #chan,var$,timeout
with the timeout parameter it would be possible to attempt to read a line but if nothing is available then continue.

dilwyn wrote:As ever with these things, time is the problem for me, as QL software projects tend to get larger and more complex. I've loads of ideas and part-written projects, but no time! I'd hoped our lockdown period in Wales would have allowed me a bit more time to work on QL software, but if anything the reverse happened :roll:


I think you are getting an amazing amount of things done :)


swensont
Forum Moderator
Posts: 190
Joined: Tue Dec 06, 2011 3:30 am
Location: SF Bay Area
Contact:

Re: QLirc 1.99.8

Postby swensont » Fri Nov 13, 2020 2:21 am

Petri,

> From perfomance perspective it would be really nice to have an
> INPUT #chan,var$,timeout

I was thinking of that, but the problem is that as the user is typing a new message, the program would not be getting any incoming messages.
By quickly getting input from either network or user, there is no lag on either side.

Tim



Who is online

Users browsing this forum: NormanDunbar and 5 guests