https://github.com/magiblot/tvision

Someone enterprising could make a TurboPascal clone out of FPC. :-)

Liam Proven wrote

https://github.com/magiblot/tvision Someone enterprising could make a TurboPascal clone out of FPC. :-)

Meh. FPC has had a Turbo Pascal-like console IDE for many years. It uses Free Vision, which is a pascal port of the C++ version of Turbo Vision (because Borland didn't release their Pascal version under a free/open source license).

https://wiki.freepascal.org/Free_Vision#Turbo_Vision

Nikolay

....FPC has had a Turbo Pascal-like console IDE for many years...

"has had" ?

AKAIK "has"

I still used it yesterday.

Grüße

Markus

English is not my native language, but I think "has had" means it still has it. If I had said "had" instead of "has had", it would mean it had it in the past, but no longer has it. Please correct me if I'm wrong.

Nikolay

Hello Nikolay,

I am a German - so may be we are both "lost in translation"

Kind Regards

Markus

Nikolay Nikolov via fpc-pascal schrieb am
Mo., 21. Dez. 2020, 11:36:

That's how I was taught it as well (with English not being my first language): "has had" means that the "having" started in the past and holds till now. "had had" would mean that it started in the past and ended somewhere less in the past and "had" alone is a specific point in the past.

Regards,
Sven

Sorry about this. I did not get this email, only the replies to it.

I was unaware of that!

Is this conversion of TurboVision FOSS, then?

Sven Barth via fpc-pascal wrote the following on 21/12/2020, 13:13:08:

"has had" is correct and good English.
Bob Martin in England

I don't know what non native english speakers are taught, nor can I address the folks across the pond, but here in the Us at least, has denotes currently exists, while had indicates past tense, I.E. no longer exists.  Combining the two is where it gets dicy, and is generally avoided for syntactical reasons.

Liam Proven wrote

Is this conversion of TurboVision FOSS, then?

Yes, it definitely is, otherwise it wouldn't be part of FPC. If you have FPC install, you should be able to simply type 'fp' from the command prompt and it should fire up the FreeVision Text IDE.

Here is a screenshot of the Text IDE from back in 2008, but it has been around a LOT longer than that. :-)

https://en.wikipedia.org/wiki/Free_Pascal#Integrated_development_environments

Regards,
Graeme

Liam Proven via fpc-pascal schrieb am
Mo., 21. Dez. 2020, 18:11:

It's license *might* not count as FOSS, but it's distributed as part of FPC (see $fpcdir/packages/fv).

The main restriction is that it only supports ShortString and thus has no Unicode support.

Regards,
Sven

Travis Siegel via fpc-pascal schrieb am
Mo., 21. Dez. 2020, 17:41:

There is nothing dicy about combining them as "have" is just a normal verb like anything else and thus can be used together with the "have/has/had" temporal particle without any problems.
As long as one knows why a certain temporal construct is used there is no problem and at least in Germany (or more specifically Bavaria) we were taught that in masses.

Regards,
Sven

W dniu 2020-12-21 o 23:41, Sven Barth via fpc-pascal pisze:

The main restriction is that it only supports ShortString and thus has no Unicode support.

I wonder which type would be best suited to store a unicode character (code point) for the screen buffer?

type
   TScreenBuffer = array of record
     Character: TypeForUnicodeCodepoint;
     AttributeAndColor: TAttributeAndColor;
   end;

Michał

Hi,

Sven Barth wrote

As long as one knows why a certain temporal construct is used there is no problem and at least in Germany (or more specifically Bavaria) we were taught that in masses. 

As a native speaker of a language which only has three tenses and no grammatical gender, it's difficult to decide if the twelve tenses of English, or the three genders of German are the more confusing. :P (Probably still the latter, tho'... ;) )

Anyway, any interest to develop Free Vision further is very welcome one, so we can move it from past tense to a future one. I still think text mode UI for console and terminals still has a place, but sadly the current FV implementation doesn't necessarily plays well on some Un*x terminals (it's highly dependent on the font, and many other factors), also a mono mode is sorely missing, which is a problem for both some modern and retro use cases. And yeah, on the high-end, Unicode would be needed.

Charlie

Speaking of Unicode, I have started working on adding Unicode support to the keyboard, video and mouse units (which are used internally by FV) in the unicodekvm branch. So, if anyone is interested in adding Unicode support to FV, take a look at this branch.

Nikolay

English and German tenses are very much alike. Except for English having the progressive forms, which do not exist in German (...ing form)

past perfect (started before the past, and usually either continuing into the past or having an effect lasting into the past / used with some other event in the past)   // Plusquamperfekt
had had  (had + verb in past)    //  hatte gehabt

past
had  // hatte

perfect (started in the past, still going on or having an effect still lasting)

have had  //  habe gehabt
has had (3rd person)

present
have // habe

and for a bit of fun (future perfect / future 2) conjunctive/subjunctive mood
causative

I would have had had it done
Würde es getan lassen haben

And if I - in a none nonsensical form - have somebody else possess a hat for me (future 2 / conjunctive):
I would have had had the hat had.

Now please, nobody is going to not tell me they didn't have no fun at all with this.

Op 2020-12-22 om 00:42 schreef gabor via fpc-pascal:

The problem is that multiple unicode codepoints might translate to one character. But that character might have variable width (1, 1.5, 2).  And the rendering of codepoints to characters is output device (terminal, GUI canvas) dependent.

First and for all, I would keep the buffer private. This allows to keep the buffer in a format suitable to quickly convert to the output device, and access won't be simple array like anyway. This also abstracts final writing API and end device encoding.

Maybe have multiple arrays, one for one codepoint per character, and one larger ones for additional ones.

This way you can simply scan the larger array if there are additional ones, and if not, emit the primary one in a straightforward way.

Travis Siegel wrote

I don't know what non native english speakers are taught, nor can I address the folks across the pond, but here in the Us at least, has denotes currently exists, while had indicates past tense, I.E. no longer exists. Combining the two is where it gets dicy, and is generally avoided for syntactical reasons.

FWIW... I'm (among other things) a qualified teacher of English as a second language. "Has had" and "had had" are 100% genuine correct English tenses, called the present perfect and past perfect respectively.

Simple present: FPC _has_ a console-mode IDE -- now, it possesses one. Simple past: FPC _had_ a console-mode IDE -- it used to, but this state ended in the past; it no longer does.
Present perfect: FPC _has had_ a console-mode IDE -- it has one, and the time it started to have one is a significant time ago. Past perfect: FPC _had had_ a console-mode IDE -- it used to have one a long time ago, but it stopped having it a long time ago.

I will not itemise all the other alternatives. There is an informal competition as to how many tenses it is possible to create in English, and the record is some 120 different ones, and 144 if you include passive-voice constructions. There are about a dozen in common use.

FPC has had a console-mode IDE means that there is one now and that there has been one for a considerable time. I presume this is what Nikolay meant. I did not know and I apologize for my ignorance of this.

Wow..

I am impressed... I hope my PASCAL is better then my English (first foreign language: Latin (for 7 years), 2nd English (6 years), 3rd ancient Greek (3 years)...)

Programming languages I worked with in the last 40 years:

1. Basic first on a Tektronix 4050 and a TRS-80 about 1979
2. Fortran batch jobs on a CDC Cyber 205
3. PASCAL first on a DEC VAX 780 about 1986
4. PDC Prolog on MS-DOS
5. Assembler
6. C
8. Perl and others on Linux from 1998
9. Java
10. Python
11. PHP
12. SPIN
....
n. ERLANG <- most recently

aside FORTRAN I earned some money programming in all languages above..

Totally off topic, but it is Christmas time..

Kind Regards

Markus

W dniu 2020-12-22 o 11:13, Marco van de Voort via fpc-pascal pisze:

The problem is that multiple unicode codepoints might translate to one character. But that character might have variable width (1, 1.5, 2). And the rendering of codepoints to characters is output device (terminal, GUI canvas) dependent.

Sorry, I keep mistaking code point for character. I thought that the code point is a value in the range 0..10FFFF. I don't think I fully understand Unicode...

But an off-screen drawing buffer would also be useful. For example, FV uses such a buffer to draw views (TDrawBuffer = Array [0..MaxViewWidth - 1] Of Word).
Buffer declared as an array of records with character and color elements could be easily and quickly drawn in another buffer.

Michał.

That is definitely a shocking amount. O.o

FPC has had a console-mode IDE means that there is one now and that there has been one for a considerable time. I presume this is what Nikolay meant. I did not know and I apologize for my ignorance of this.

Thank you for confirming that Nikolay (and I) had the right gist regarding the time. ;)

And no need to apologize. Most users will probably use FPC together with Lazarus and thus don't come into contact with the textmode IDE, but nervetheless it /is/ there and can be used, though as this thread showed it can (and probably should) be improve. :)

Regards,
Sven

gabor wrote

Sorry, I keep mistaking code point for character. I thought that the code point is a value in the range 0..10FFFF. I don't think I fully understand Unicode...

Here in an example:
https://en.wikipedia.org/wiki/Combining_character

Two or more code points combined can form a "single character" when rendered on screen or paper.

Sometimes you can replace those with a single "precomposed character" too. The Unicode standard includes many of them, but not all.

https://en.wikipedia.org/wiki/Precomposed_character

Hope that helps.

Regards,
Graeme

When you say spin, I'm assuming you're talking about the parallax propeller boards programming language.  The propeller 2 is coming out shortly (already out for early adopters), and I am anxiously awaiting the day I can get my hands on one.  I've built all kinds of projects with the propeller 1 board, the first of which was an FM radio.

But, to put this (somewhat) on topic, I've been wondering how complicated it would be to port FPC to the propeller 2 board, since they now have GCC ported, I would absolutely love to be able to program the propeller boards in pascal.  I do have a couple of their java stamps, those are interesting, and they do have a micro python that can be run on the propeller 2 boards, so adding pascal should be doable, I'm just not sure how much work it would take, but it would be nice to have another language to add to the mix.

Travis,

I was working with the Propeller1 for many years We realized a commercial project with it . See http://www.schleibinger.com/cmsimple/en/?Setting_and_Maturity:Ultrasonic_Setting_Measurement

It works very reliable.

In June, I have got my first Propeller2 board from Parallax. Really an impressive chip. Getting all relevant info and testing and evaluating all the different development platforms is still demanding. But situation is getting better each day.

Pascal on the Propeller itself would be possible. There are CPM2.2 emulator for the Propeller around, so TurboPascal 3.0 should work. But with all the CP/M and Z80 emulator overhead.

As you may know, Niklaus Wirth developed Oberon as a successor of Pascal. Its near identical to Pascal, just yet another name.

Its not only a compiler but also a development environment, including an editor and also an own OS and GUI ! He developed it with Gutknecht mainly at the Xerox PARC labs, long before Steve Jobs and Bill Gates made their own copies of the ALTO work-station.

The required resources are minimal. In 2013 Wirth developed an own RISC processor on a FPGA He published the Verilog and also the Oberon code, because Oberon is written in Oberon (!) The whole compiler, editor, OS, GUI, screen driver, mouse control, etc has less then 10.000 lines of Oberon code !!! That is near nothing,
See
http://people.inf.ethz.ch/wirth/
and
http://www.projectoberon.com/

I realized this project on a FPGA for myself as proof of concept. It worked finally, but handling the Xilinx development software was (and is still) a mess. Later I translated the according PC emulator of Peter de Wachter from C to FreePascal.

The RISC-5 ** architecture of Wirth is quite simple and I would see no real problem to adapt the Oberon system to the Propeller2.

The 3 main obstacles:

1. There is no divider in the COGs, but I guess its possible to use the CORDIC divider instead.

2. The RAM space of the Propeller2 is too small, OBERON requires 1 MByte of RAM mainly for the video buffer. The Propeller2 is supporting some RAM extension, so also this should work. As far as I can see know, this would be the only necessary hardware extension the the P2 evaluation board.

3. RISC-5 has a floating point adder, multiplier and divider. So any emulator required.

Porting the core compiler called OBERON-0 to the propeller would be the most complicated thing and OBERON-0 is using no floating point math.
All other things should be easier, I guess.
Finally we would get a 8 core OBERON computer....

Many Christmas dreams...

Regards
Markus

P.S. **) don't mix RISC-5 up with the now popular RISC-V architecture. Wirth is a genius, but has never a lucky hand for finding good and unique names for his projects. So from Algol to Pascal to Modula to Oberon to Oberon-2 to A2 to Project Oberon...

As you may know, Niklaus Wirth developed Oberon as a successor of Pascal. Its near identical to Pascal, just yet another name.

Indeed. There is a somewhat active mailing list over on: ETH Oberon and related systems

As I understand it, Wirth had some fairly radical ideas about upgrade Algol-60, but the Algol committee didn't like them and went with Adriaan van Wijngaarden's proposal instead, creating Algol-68, causing "shock, horror and dissent" and leading one computer scientist to read the huge report trying to find what "language was hidden inside of it".

It was more or less the end of Algol. Wirth released his proposal as Algol-W and later refined it into a new language, named after great French philosopher-mathematician Blaise Pascal.

Later came Modula, which is Pascal with modules, and then Modula-2. So in a way, Modula was Pascal 2 and Modula-2 is Pascal 3.

(Modula-3 was someone else, so outside the sequence.)

Acorn, the British company who invented the ARM chip, tried to develop a whole new OS for the new computer in Modula-2, but failed. Instead, a last-ditch skunkworks effort to modernise their 6502 machines' OS, MOS, resulted in Arthur, renamed RISC OS in version 2. It is still alive and maintained today and there is a FOSS fork of it which runs on the Raspberry Pi. This came up recently over on the FPC web fora.

After building the OS of his Lilith workstation in Modula-2, Wirth realised it was not ideal for OS development and built Oberon (the language) for his Ceres workstation workstation instead.

Oberon therefore could be seen as Pascal 4!

Its not only a compiler but also a development environment, including an editor and also an own OS and GUI !

Indeed. I've been trying to get people on the Oberon mailing list interested in the idea of a native port of Oberon for the Raspberry Pi. The language compiler can target ARM.

The slight snag is that the original Oberon OS only supports 1 CPU and has no threading. There are multiple successor languages to Oberon.

First, Wirth and collaborators did Oberon-2 -- so that, in a way, is Pascal 5. https://en.wikipedia.org/wiki/Oberon-2

Then another, Active Oberon (Pascal 6?) which also has its own OS called AOS, A2 and sometimes Bluebottle.
https://en.wikipedia.org/wiki/Active_Oberon
https://en.wikipedia.org/wiki/Bluebottle_OS

A derivative of Oberon 2, minus the OS, is sold as a Windows development environment called Component Pascal.
https://en.wikipedia.org/wiki/Component_Pascal

And finally, Wirth's latest iteration is Oberon-07, which is derived from the original Oberon, not from Oberon 2 or Active Oberon. So I suppose the version numbering finally converges and Oberon-07 is also Pascal 7.

A2/Bluebottle OS used to have a StrongARM version, so I think getting it running on modern ARM hardware would not be impossible, and might attract a much larger audience than the expensive FPGA boards that Project Oberon 2018 currently runs on:
http://www.projectoberon.net/ostation/OberonStationQR.pdf

I wrote about it here:
https://www.theregister.com/Print/2015/12/02/pi_versus_oberton/

He developed it with Gutknecht mainly at the Xerox PARC labs, long before Steve Jobs and Bill Gates made their own copies of the ALTO work-station.

Yup. Good summary/overview here:
http://ignorethecode.net/blog/2009/04/22/oberon/

P.S. **) don't mix RISC-5 up with the now popular RISC-V architecture. Wirth is a genius, but has never a lucky hand for finding good and unique names for his projects. So from Algol to Pascal to Modula to Oberon to Oberon-2 to A2 to Project Oberon...

Oberon now runs on RISC-V as well:
https://github.com/solbjorg/oberon-riscv

With GCC being available and there existing a port of binutils it would in principle be possible to implement a cross compiler of FPC. :)

Regards,
Sven

Amazing !

W dniu 2020-12-23 o 14:27, Graeme Geldenhuys via fpc-pascal pisze:

Thanks, that is very helpful. But if I understand correctly, each such combination of code points can be properly represented by one code point (NFC normalization).

Michał.

W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze:

Very interesting. But in a future version of the FV (or other TUI framework) apart from migrating from objects to classes, using component streaming, collections, etc... it would be good if the unit "drivers" were more abstract and not strictly dependent on Video, Mouse and Keyboard units. Then it will be possible to create a driver that, for example, renders the screen buffer in a win32-gdi window, or even in html5 canvas or LCL.

Michał

gabor wrote

W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze:

.
.

There's nothing preventing you to implement unit video in these environments, IMHO.

Tomas

W dniu 2020-12-26 o 16:34, Tomas Hajny via fpc-pascal pisze:

Of course, but then we need to finish what Charlie started - unicode. And think about possibility of including multiple drivers in single executable.

Michał.