BASIC Studio for Linux (Cancelled)

User contributed sources that have become inactive, deprecated, or generally unusable. But ... we don't really want to throw them away either.
Post Reply
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

Some libraries developed for the project can be downloaded from the website: http://www.basicstudio.org

The website is still very basic :-) as it was created three days ago.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by marcov »

lizard wrote:
All i want to know is if you think the optimization of routines for speed goes on forever or suddenly stops, maybe because single people
die.
No, but I think the interest field that they are working to optimize (optimizing dos fullscreen gaming using old dos techniques) gets nearly no new blood. The whole field, its optimization inclusive will die out. And not necessarily as crude as die, but people will move on or get less active in time.
And why such a group can't contribute to this project.
They seem not to have learned anything new in the last 20 years. Why start now?
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

marcov wrote:They seem not to have learned anything new in the last 20 years. Why start now?
What should they learn? Every good programmer will try to speed up his code, no matter what it is.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by marcov »

lizard wrote:
marcov wrote:They seem not to have learned anything new in the last 20 years. Why start now?
What should they learn? Every good programmer will try to speed up his code, no matter what it is.
No. A good programmer will find the biggest bottleneck and tackles that first. He doesn't go around to look for code to optimize.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

marcov wrote: No. A good programmer will find the biggest bottleneck and tackles that first. He doesn't go around to look for code to optimize.
That would be the job of the administrator to tackle bottle necks. The programmer has to care for his own code primarily.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: RAD for Linux (in development)

Post by caseih »

lizard wrote:
marcov wrote: No. A good programmer will find the biggest bottleneck and tackles that first. He doesn't go around to look for code to optimize.
That would be the job of the administrator to tackle bottle necks. The programmer has to care for his own code primarily.
I'm going to give you the benefit of the doubt here, and assume that you simply misunderstand what Marcov is saying. Because he's exactly right. You can have very slow code that, even when optimized, makes no difference whatsoever to the program's performance. In nearly all programs, 90% of the execution time is spent in less than 10% of the code. Until you've profiled your code and determined where the bottlenecks are, optimization is a waste of your time, and your employer's time (if you were an employee programmer). That's what Marcov is saying. Remember, premature optimization is the root of much programming evil. In fact in some case you might be introducing huge security holes.

I'm not saying you shouldn't choose good algorithms. Definitely you should be aware of appropriate algorithms and data structures as you code, and be aware of the memory use characteristics. It's a fine line, granted!
Last edited by caseih on Dec 21, 2017 23:42, edited 2 times in total.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

Progress is being made, but not with the editor or RAD interface directly. Instead, I am working on implementing full Unicode support, including the possibility to convert back and forth between the three formats UTF-8, UTF-16 and UTF-32. In order to provide some cohesion, the datatype UString is introduced, not as type string -- as was the case with the initial utf8 library -- but as an object, which makes it easy to access and change format specifics and also to convert to other formats. Granted, this is not traditional string handling, but we have to accept the fact that Unicode isn't about simple strings anymore. ;-) For example:

Code: Select all

#include once "system.bi"
#include once "utfx.bi"

dim Buffer as string
dim s as UString

' UTF-32 text file
open "textfile.txt" for input as #1
  line input #1, Buffer
close #1

' load UTF-32
s.Text = Buffer
' convert to UTF-8 (Linux default)
s.TextForm = TextForms.UTF8
print s.TextForm
print s.Endian   ' none
print s.Text
print
' convert to utf-16 LE (Windows default)
s.TextForm = TextForms.UTF16
s.Endian = Endians.LE
s.BOM = true   ' will save BOM upon storage
end

#include once "utfx.bas"
When TextForm is set, the string will change format immediately. The beauty is that internally a simple variable length string is used for storage, and iterated per 1, 2, 3 or 4 bytes depending on the format. This allows for maximum flexibility and easy conversion. The following example assigns a string, which is UTF-8 by default:

Code: Select all

dim s as UString = "Hello world!"
print s.Text
Additionally, codepages like old ASCII 437, 850 etc and ISO-8859-x can be imported. It's a lot of work, but also fun to do. ;-)
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

I really appreciate an IDE that is fully encoding-aware. Geany seems to handle this perfectly. It always shows encoding of the actual file in statusline. even if utf-8 with or without BOM. All this can be quite confusing and causes a lot of troubles in programming.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

lizard wrote:I really appreciate an IDE that is fully encoding-aware. Geany seems to handle this perfectly. It always shows encoding of the actual file in statusline. even if utf-8 with or without BOM. All this can be quite confusing and causes a lot of troubles in programming.
Geany doesn't handle Unicode perfectly, but this is due to its use of Scintilla, which seems to handle characters of the BMP perfectly, but cannot move the cursor easily over characters that consist of multiple codepoints. But most web browsers seem to have the same problem, so that's not a shame. GtkSourceView/Textview seems to do a better job here. It looks like it is more aware of grapheme clusters.

Some may argue that the disadvantage of GtkSouceView is its lack of code folding support, but there are ways to build an interface such that code folding becomes essentially too much of an extra. I am specifically referring here to the REALbasic interface where programming was a bit different (easy to navigate) and code folding was never an issue. They effectively chose not to expose the programmer to large amounts of text. It would be a bit reminiscent to the QuickBASIC editor where one had to press F2 to navigate to other modules and procedures.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

the datatype UString is introduced, not as type string -- as was the case with the initial utf8 library -- but as an object
On second thought, using common string type will keep string handling simple and fast, but at the risk of utf8-string corruption (when erroneounsly using FB's built-in string procedures).

Code: Select all

#include once "encodings.bi"

dim as string buffer, s

' UTF-32 file
open "textfile.txt" for input as #1
  line input #1, buffer
close #1

' try to decode UTF-32
with Encodings
  s = .Decode(buffer)
  if .Invalid then
    print "Binary file."
    end
  end if
end with

' print UTF-8 text
print s
end

#include once "encodings.bas"
I believe FreePascal is suffering from the same "illness" coming from an age where Unicode wasn't as common as it is today.
Last edited by Munair on Dec 22, 2017 19:29, edited 2 times in total.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by marcov »

Munair wrote:
lizard wrote:I really appreciate an IDE that is fully encoding-aware. Geany seems to handle this perfectly. It always shows encoding of the actual file in statusline. even if utf-8 with or without BOM. All this can be quite confusing and causes a lot of troubles in programming.
Geany doesn't handle Unicode perfectly, but this is due to its use of Scintilla, which seems to handle characters of the BMP perfectly, but cannot move the cursor easily over characters that consist of multiple codepoints. But most web browsers seem to have the same problem, so that's not a shame.
Did you try the Lazarus editor? I can vaguely remember the editor guy, Martin, spending a lot of time on this, also RTL (right to left) sequence of characters in otherwise LTR sentences and graphemes that are n+ 1/2 wide.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

marcov wrote:graphemes that are n+ 1/2 wide.
Yes, those are the ones often causing problems. No, I haven't tried the Lazarus editor yet.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by marcov »

Munair wrote: I believe FreePascal is suffering from the same "illness" coming from an age where Unicode wasn't as common as it is today.
Free Pascal 3+ has a 1-byte string type that is tagged with encoding, allowing RTL routines to work fine. More importantly, the standard encoding can be detected and set up at application startup, iow runtime not just compile.

This allows to serve both progressive and very conservative (compatible) scenarios on an per application basis with the same compiled RTL. Static classes and helper types can be used to add routines (so the user can define pseudo-methods to call on native string types that change behaviour depending on encoding!)

At lot has changed in this in higher Delphi versions, and FPC3 implements a fair chunck of it(and another 10% more in trunk). Not all is done (not all textual save routines can be tagged with the encoding to write etc), but it is far, very far and still improving.

Keep in mind that majority target Windows still does not have utf8 as 1-byte stringtypes default. We wanted to avoid the Java trap where a basically inflexible language runtime is kept running using glue layers. Which is very portable, but you are far removed from the system.
Last edited by marcov on Dec 23, 2017 7:08, edited 2 times in total.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

Yes, FreePascal is making more progress in this respect.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

Another thing you can see at FreeQ and its designer: It looks somehow outdated. But what ist outdated there? RapidQ itself can't be outdated. It uses the same principles of oop like other systems.

The icons are looking strange, to small (24x24) and a bit oldfashioned. Some People may think graphics are completely unimportant, but this is definitely not true. The subconscious decides if a program looks good, so in a modern environment the icons are more important than many are thinking.
Post Reply