QB64 Phoenix Edition 3.4.1 Released

[mnrvovrfc]

From the program shown here:

https://staging.qb64phoenix.com/showthre...32#pid2332

I changed stuff before the "SCREEN _NEWIMAGE()" statement, in this way:

Code: (Select All)

dim as long w, h, iii

print "Starting..."
for iii = 1 to 10
    w = _DesktopWidth: h = _DesktopHeight
    if w > 0 then exit for
    _delay 0.5
next
if not(w > 0) then print "Sorry it didn't work!" : end
hd2 = h / 2

The compiled program simply refuses to display anything but "freeglut" on the following terminal line and quits. Tried to print the value of "iii" first of all. However, hard-coding the desktop width and height worked.

If "_DESKTOPWIDTH" isn't ready then why doesn't it just return zero? Should I have tried it for the other function?

This should have been reported earlier, but it's irritating the user program doesn't display anything at all at the user's command. This must mean stuff belonging to the "freeglut" is included in initialization when a Linux executable is run.

[SMcNeill]

Try this:

Code: (Select All)

dim as long w, h, iii

print "Starting..."

DO:  LOOP UNTIL _SCREENEXISTS

for iii = 1 to 10
    w = _DesktopWidth: h = _DesktopHeight
    if w > 0 then exit for
    _delay 0.5
next
if not(w > 0) then print "Sorry it didn't work!" : end
hd2 = h / 2

[mnrvovrfc]

That certainly worked. Thank you.

[Fifi]

Congratulations, very good job. We are also looking forward to multilingual support. So far English and Spanish are supported, we will gladly accept Greek as well. Good luck in your work.

Hi gaslouk,

what about also supporting the french language with its 16 specific characters for France, Belgium, Canada, Luxembourg, Switzerland, French West Indies and North and West African countries?

Unfortunately, this BBS doesn't support these characters.

During the last Francophone Language Summit last week, it was counted over 380 millions french speaking people worldwide and an expectation of over 550 millions in 2050.

Cheers.
Fifi

[mnrvovrfc]

Unfortunately, this BBS doesn't support these characters.

It's not nice to brag about quantities like that to a person whose first (preferred) language is different from your own.

Which letters aren't supported? If it's only the accented vowels, it might be a problem with input method. If gaslouk was able to write something in Greek then it should be even easier doing it in French. Try being Hungarian and having to deal with ő, for example that sometimes has to be misinterpreted with macron or circumflex.

[SpriggsySpriggs]

I don't know if it is necessarily bragging to state facts like there being more French speaking people than Greek. It just makes for a good case of supporting a larger language first since there would potentially be a greater reach.

[bert22306]

I don't know if it is necessarily bragging to state facts like there being more French speaking people than Greek. It just makes for a good case of supporting a larger language first since there would potentially be a greater reach.

In fact, on this subject, it looks like IBM's original extended ASCII character set consists entirely of one-byte characters and is by default supported by MS QBasic/QuickBasic and QB64. It does a nice job supporting French, Spanish, Italian (Spanish and Italian are comparatively easy to please with accent requirements), but a poor job with German, Scandinavian, and all the rest who use the Roman alphabet. And the few Greek characters supported are just barely enough for math and physics (for example, where are lower case gamma and lambda?).

As far as I can tell, the UTF-8 standard begins with the IBM extended set, but it replaces characters 166 on up to 255 with "more useful" accented characters. To support both Roman and Greek characters well, it looks like it takes two-byte characters, to fit in many of the Greek characters. So that's a significant addition, two-bytes/character as opposed to just one. If QB64 can be made capable of that, my hat's off to you guys.

[doppler]

Back in the day.  When computer much less the personal type.  Things were always in English.  With the higher acceptance of PC's in work/home place.  UTF standardization came into use.  It was first for the scientific and academic communities.  That's why the first dozen or so new UTF character set's where funny symbols.

QB64 will eventually get around to other languages.  This is going to be very hard.  Since the Basic programing language is deep in English syntax.  Confusion would ensue if QB64 was quickly changed to multi-language.

Use in language example:
This point of single unified language use is very important.  Such as with aviation communications.  It has caused deaths for improper use.  Avianca plane  crashed on Long Island after a failed JFK landing in less than optimal weather.  They requested "Priority" to land and tower communicated back to turn and proceed back in the landing queue. (busy night)  "Priority" word is not in aviation syllabus, they should have declared a fuel "Emergency".  Just weeks later in some other airport.  A diverted flight missed a landing, with "Avianca" fresh in minds.  The tower requested a status of fuel on the missed approach aircraft.  The pilot responded "Were a little low."  The tower declared the emergency and landed them immediately. Later when questioned the pilot did not declare the emergency because "low" was cutting into the reserved fuel load.  They must have a reserve load to each 2 alternate airports.

[mnrvovrfc]

Somebody created a Pascal compiler where the keywords are Portuguese... but I didn't check into it. The original author of Turbo Pascal could have done it in his language to keep it to himself...

Otherwise if somebody wants a BASIC dialect with keywords other than English, he/she would have to take it upon himself/herself. Obtain the QB64 source code and see what could be done. It's going to be much more than search and replace.

Somebody asked on this forum if QB64 could be presented in a language other than English, which is "less popular" than French or Spanish. Sadly it is emphasized that if he/she really, really wants it, he/she would have to act on it and if he/she prefers to wait on things, it could take too long to bear. This is also expected from payware -- try to reach as many "customers" as possible that could know one language.

Changing the language of the menus and help files of the IDE, and the error messages that QB64 gives out is possible using the "gettext" system which might have to be added with Unicode support. It's going to be limited however by the "locales" used by the GNU Compiler Collection (gcc) of which "g++" is part of, and from which MinGW on Windows is a derrivative. In other words, if the user also wants to change out of English the C++ compiler and linker error messages, he/she would have to deal with that side of things.

"Syntax error on line xxx" or "Illegal function call" or "Array subscript out of bounds" or something like that could be changed from English easier than "In file xxx conversion from this pointer type isn't allowed here" or something else. Don't spend my time memorizing errors, warnings, hints etc. from "g++" or any other mysterious compiler like that.

LOL but how about changing C/C++ out of English keywords? "principal() { emitef("Hola mundo!\n); }" or something further could take much more to type, and with marks on letters and stuff like that.

EDIT: A further post in this topic might be a better solution.

[mnrvovrfc]

https://projectfluent.org/