What to do about a lack of developers for the compiler?

[VANYA]

Guys, you're asking the wrong questions. The main questions: who is so competent to make changes to the source code of the compiler? There are people who know three languages ​​at once: assembler, C and of course freebasic, as well as well aware of the architecture of windows and Linux? Are there people who understand the principles of building compilers? I know at least a couple of people on the this forum, but these people are very impulsive (like to jump from language to language, from project to project) and are not able to give themselves away completely, as dkl did. And if we can not answer these questions, then the questions connected with the development and ideology of the language do not make sense!

[fxm]

... I would suggest to select at least one new moderator/administrator to fill in for dkl and other past admins who left to reach a state in that admins are a bit less unresponsive and actively take part in discussions on the forums. My vote would e.g. go to fxm (provided that he wanted to do that). Maybe we could do a poll? But of course an existing admin is required first to decide and improve the current situation.

But, as already stated (viewtopic.php?f=17&t=25829#p234630), I am not a candidate for this type of formal responsibility.

[dodicat]

Why can't we just wrap up version 1.05.0 to 1.06.0 (official build) for the moment.
I believe a few bugs have been fixed.
At least we will have the latest build available for general download.

Counting_pine holds the fort meanwhile.

[counting_pine]

I think one way of keeping the project going would be to open up development more.

If there are people who want to make additions/changes to the compiler or runtime library, then probably the best thing they can do is start a thread, documenting their research, and asking questions about how to make changes or where to look for things in the source. Other community members can help out with investigation, and existing developers may be happy to drop in and offer suggestions and answer questions where they are able.

Changes can be made in forks of the code, e.g. on Github, and may even be eligible for including in the main source.

The more discussions that happen, the more interest can be stirred in further development.

To touch on the issue of making a release - currently, my only working build environment is in Linux. (Which is dead easy for many common distros.)
I think the wiki instructions for other environments potentially need to be followed, troubleshooted, and reworked, and don't feel I'm currently in a position to do that, but I can try and help out if other people want to.

I think a big part of keeping things like this going is knowing that other people are interested and prepared to spend time investigating/working on it and talking about it. So I would encourage interested people to start discussions, let's see if some of them can lead somewhere.

[MrSwiss]

I think one way of keeping the project going would be to open up development more.

I couldn't agree more, however, how is that *open up*, to be interpreted, exactly?

(Example of restricting factors, below)
Re-reading *hacking on FB*, one of the mentioned requirements for a release states:
"all the packages, should have the same Date" (or similar). This type of restriction, is
probably a *killer* to everybody, who isn't willing/able to *do it all* (as dkl did).
E.g. a person interested to the *Windows* side of things only ... (without having to
care about, other OS's ... ), another e.g. running Linux, caring about those builds ...

Cutting down (drastically) on build environments, testing, etc. (for each party).

From St_W's posts, about the Jenkins Build Server (he's running):
VM's induced problems, could possibly also be solved *out of the process* ?!? By doing
the builds on real OS, instead of having to use VM's.

[TeeEmCee]

As I've mentioned before, I plan to become a bit more involved in FB development, because I'm invested in FB and expect to be using FB for another decade... Hopefully I should have more free time later this year. There are a few features I'd like to implement.

I just pulled every fork of fbc I could find on github. There's a number of branches that haven't been merged back in; there are no pull requests for them. (OK, I'm the chief offender here, but I'll be finishing my branches when I have time). For example, this fix for bug 858. Of course only a few of the branches are actually suitable for merging.

Regarding 64 bit types, I simply did "#define integer long" to ensure that things are mostly the same in 32 bit and 64bit builds.

Regarding doing releases, dkl has a "crossbuild" branch for compiling a GNU crosscompiling toolchain and then crosscompiling fbc and its libraries to all supported platforms. I don't know if it's finished (he was working on it as recently as March), but it appears to automate most of the process.
Of course, if he has it automated and knows how to run this thing, it would be simplest to just ask him to do releases. He never said he was going to stop his involvement completely.

Keeping compatibility with existing code also prevents fixing some design errors (for example the inconsistent naming of the basic data types, which cannot be changed without breaking nearly all existing code).

Back in the ~0.16 days, basically every version was compatibility breaking. But many bugfixes are minor compatibility breaks. What's the policy for changes?

[St_W]

I just pulled every fork of fbc I could find on github. There's a number of branches that haven't been merged back in; there are no pull requests for them. (OK, I'm the chief offender here, but I'll be finishing my branches when I have time). For example, this fix for bug 858.

I wanted to write some unit tests for the issue before submitting a pull request, but didn't find free time to do so yet. btw it's interesting to see that the commit already spread to another fork :-)

Cutting down (drastically) on build environments, testing, etc. (for each party).
From St_W's posts, about the Jenkins Build Server (he's running):
VM's induced problems, could possibly also be solved *out of the process* ?!? By doing
the builds on real OS, instead of having to use VM's.

Reducing the effort to test multiple systems and configurations is one of the reasons for using a CI tool like Jenkins. It could be definitely configured in a way so that full FreeBasic packages can be built. However, currently it's configured for doing continuous tests and nightly builds in a lightweight manner skipping some steps that would be required for a full FreeBasic package. Whether the builds are done on a physical machine or a virtualized one shouldn't make any difference, though. Nowadays most applications in a server environment are virtualized (just to mention some buzzwords like Cloud or Docker/Containers).

[TeeEmCee]

I wanted to write some unit tests for the issue before submitting a pull request, but didn't find free time to do so yet. btw it's interesting to see that the commit already spread to another fork :-)

OK, cool.
Actually that commit doesn't exist in coderJeff's (jayrm) repo; I wrote the wrong link. But it turns out that because github does deduplication, you can create a sha1 link to a commit that only exists in someone else's fork!

[stephanbrunker]

I do programming as a hobby, and even that only a few times a year on a wide range of topics, so that I simply don't have the deep knowledge to contribute to the compiler. The other problem is that I had something to contribute in the past and I was simply ignored, so the contribution management is something what needs improvement first.

I use FB on the one side to do simple calculations like juggling data from CSV-Files and on the other side I did some Windows GUI programming and a datalogger on a Raspberry Pi. Even if most of that is more or less translated C++, i prefer FB simply because the code is easier to read and write.

What I wanted to contribute to the examples and includes was a fast and working, fully overloaded Bigint datatype, replacing the very shadowy one (/examples/math/big_int) from 2005 in the package. I wrote a tutorial how to start in Windows GUI programming, and I implemented the DragDrop Interface using the latest expansions in the compiler, so that its inherited from IUnknown and so on (replacing /examples/win32/COM/DropTarget). You can find all that on http://www.freebasic-portal.de . And if someone wants that, I have implemented some crypto, like the Salsa20 Stream Cipher, Blake and Keccak Hashfunctions and UMAC Mac. Oh, and for the RPi project I implemented semaphores and shared memory for IPC. I just dumped a translation of the Windows service example which I need for my actual project, too. But unfortunately, there was no response here in the forum to my offer.

The question is how much you want to include in the language from the start - if you look at PHP, there are functions for virtually everything. I don't know if that is neccesary to FB too. But it's easy to include some *.bi files, if they are also written in FB you can edit them - what you cannot do with compiled libraries.

My personal include file has functions like circle functions for degrees, pi as constant, EndianSwitch for 32/64 bit and Strings, zeropadding, StringXor, modular exponentiation, rounding, Hex for Strings and conversion from a Hex back to a string, a little bit print for arrays, String insertion, replace like the function in PHP, array juggling like delete index or range, windows to unix time and back, removing the last dot if you dont want decimals in format(), the PHP explode() and implode(), DirExists(), and randomnormal and randomlognormal number generation. Not everything I have written myself and its only a few lines each, but even for my small projects its very handy. So if someone actually wants that stuff, I really want to share (includes for inifiles and csv-files, base64 encoding and the htmlhelp.bi for windows are also available). Atm I write a windows service running a NamedPipe server to communicate with a system tray application on the on side and a COM interface on the other (thanks to SimpleVariant.bi). You can do a lot with FB ...

[coderJeff]

I know I haven't been active on forums in long time. But I have never really gone away from FreeBASIC ... always lurking in the shadows. So I will be bold here and offer some thoughts.

When I first got involved with the project, I was excited. I wanted FreeBASIC project to succeed. And the community surrounding the project was attractive. Here is my first post to the forum: viewtopic.php?f=7&t=1807

It was those few words of encouragement from v1ctor that helped me to get started. Documentation was a great place to start. Use FreeBASIC and help with the information about how to use. Over time, and after learning more things, I was able to contribute in more ways.

About the design philosophy...we have a design philosophy?!?

Generally, and respectfully, (and yes, so many other contributors not mentioned):
v1ctor: all about the speed
counting_pine: all about the consistency and correctness
dkl: all about the stability and useability
me: just make it work by any means necessary

I think those attitudes have complimented each other over the project life time. But to say there has been a design philosphy or that it has changed is a stretch of imagination. Mostly, it has been a handful of dedicated people banging away at the keyboard for hours/days/months at a time. Ultimately, it's the people doing the work that shape the FreeBASIC's future. No disrepect to the community, but bottom line, there has always been one guy that is willing to take all the blame and none of the credit that gets FreeBASIC delivered.

There was a time when I was the guy willing to take all the responsibility (blame). Making the packages for distribution. Even when there was only one package each for dos/win/linux it was a lot of work. I had multiple computers running different operating systems so that I could test each package on the actual target system. It was a personal goal. Something I wanted to do. With all the targets available now in 2017, it would be a very daunting task for one individual.

I think FreeBASIC has always been open. To make it more open, yes, I agree with counting_pine; have a discussion about building, packaging, bug, or feature, in the open, and ask for help. Just understand the difference between asking for help, and asking someone to do it for you.

I don't think gcc C backend emitter is a bad thing. It solves a specific problem. It allows fbc to compile programs to targets that nobody has time to support directly.

I have only ever used 32-bit gas assembler versions of fbc. Only over the past weeks have I explored the 64-bit builds and gcc. The wiki instructions on DevBuild are good and MinGW-w64 is giving good results. msys2 and win-builds seem like they should work, but there are building problems I haven't figured. For at least 2 years I have been poking away on a 64-bit -gen gas emitter but have not made much progress because 1) I need to learn many more things, and 2) my free time to pursue is limited.

Moving forward, I think project still needs a lead. Someone to look after the project as a whole, and verify others work. As for everyone that wants to help, just go for it. Even if you fail, you will still likely learn something.

[BasicCoder2]

.

[St_W]

The other problem is that I had something to contribute in the past and I was simply ignored, so the contribution management is something what needs improvement first.

One thing that has always worked for me has been submitting a pull request on GitHub. However, that requires that you are quite sure about the change and have already implemented it. If one has only a idea and wants further ideas from the community there are often no answers from the compiler developers on the forums. And unfortunately nobody is available on IRC either - e.g. one could talk to dkl regularly on #fb-portal or #freebasic.

I wrote a tutorial how to start in Windows GUI programming, and I implemented the DragDrop Interface using the latest expansions in the compiler, so that its inherited from IUnknown and so on (replacing /examples/win32/COM/DropTarget).

OT @stephanbrunker: there still seem to be errors in the code that cause it to crash, see: https://forum.qbasic.at/viewtopic.php?t=8535

So if someone actually wants that stuff, I really want to share

If you want to, you can just do it. e.g. on freebasic-portal.de or on GitHub and then create a thread here on the forums. However, don't expect too much response. Sometimes really good work doesn't get the attention that it would have deserved. Often the code is just used without any comments until some problem occurs.

I know I haven't been active on forums in long time. But I have never really gone away from FreeBASIC ... always lurking in the shadows. So I will be bold here and offer some thoughts. When I first got involved with the project, I was excited. I wanted FreeBASIC project to succeed. And the community surrounding the project was attractive.
It was those few words of encouragement from v1ctor that helped me to get started.

And that encouragement especially of the compiler developers / administrators is missing or only available on a much lower level today. There's a much lower responsiveness on the forums or on IRC.

About the design philosophy ...we have a design philosophy?!? [...]
I think those attitudes have complimented each other over the project life time. But to say there has been a design philosphy or that it has changed is a stretch of imagination. Mostly, it has been a handful of dedicated people banging away at the keyboard for hours/days/months at a time. Ultimately, it's the people doing the work that shape the FreeBASIC's future. No disrepect to the community, but bottom line, there has always been one guy that is willing to take all the blame and none of the credit that gets FreeBASIC delivered.

It is fully understandable that the people who do the work ultimately decide on the implementation, but it wouldn't hurt if changes could be discussed with the community or at least among the developers. Of course, this doesn't make sense if there's only a single active developer, which also brings me back to my point above about the lack of responsiveness.

Making the packages for distribution. Even when there was only one package each for dos/win/linux it was a lot of work. I had multiple computers running different operating systems so that I could test each package on the actual target system. It was a personal goal. Something I wanted to do. With all the targets available now in 2017, it would be a very daunting task for one individual.

I don't think so. At a time of fully automized build pipelines and testing it's just a matter of creating a tag, let the CI system do its work and take the packages that it emits as artifacts to upload them on sourceforge. Of course there are additional task like writing release notes, updating website/forum, etc. but I think in total the release process got easier than it has been in previous times.

Moving forward, I think project still needs a lead. Someone to look after the project as a whole, and verify others work. As for everyone that wants to help, just go for it. Even if you fail, you will still likely learn something.

Having a lead would definitely be beneficial for the project. However, I don't think that this needs to a a single person. If there's a team of a few maintainers that would be fine too, given that they are active, able/willing to discuss and settle on a joint solution, have the needed knowledge to contribute and are open to learn new things.
That is why I suggested to allow new people to contribute and take the place of long-inactive former maintainers or developers. As we have seen in this thread many users would like to contribute, but just haven't been given the chance to do so. A new contributor might become a project lead after some time (and dkl is a great example that this can work).

[coderJeff]

St_W, thank-you for the feedback. Sincerely, all very insightful responses.

One of the points was to be more open, more responsive. Let's consider this topic thread as a discussion, in the open between developers] (active or not), potential developers, and the community, and see where it takes us.

So, here goes...

I love working on FreeBASIC. I think I have ability to help in some way, just not the capability. I find myself with some free time right now because I am on holiday. I probably have enough time to try building a package. I can't make any promises on when just now. The documentation packages seemed to build OK.

I feel awful, because regardless of effort, all I have to offer right now is talking about it. Then, with my schedule, I know it will be some time (weeks? months?) before I can return to it.

I don't think so. At a time of fully automized build pipelines and testing it's just a matter of creating a tag, let the CI system do its work and take the packages that it emits as artifacts to upload them on sourceforge. Of course there are additional task like writing release notes, updating website/forum, etc. but I think in total the release process got easier than it has been in previous times.

St_W, Can you do this?

I think building the 1.06.0 is a reasonable team goal. Even if it doesn't turn out perfect, I think anyone that has the time to participate can learn. Who will participate?

[St_W]

I feel awful, because regardless of effort, all I have to offer right now is talking about it. Then, with my schedule, I know it will be some time (weeks? months?) before I can return to it.

Discussion is a very good start and IMHO the basis for accomplishing bigger things.

regarding a CI system: Yes, I can :-) There's a system for creating nightly builds, which is now running since more than 3 years already. However, it will probably require quite some modifications to be used for creating release packages, which need to be discussed (for example which Linux version/distribution to use for the builds). And unfortunately my hardware resources are rather limited as the hardware is also used for other (non FreeBasic related) tasks. So in case somebody else wants to setup such a system and has more hardware resources available I'd also be happy to help.

I think building the 1.06.0 is a reasonable team goal. Even if it doesn't turn out perfect, I think anyone that has the time to participate can learn. Who will participate?

I'm definitely willing to help and hope that I'm also able to do so :-). This month I can't spend a lot of time, but starting with mid of next month I can spend more time on FB.

[TeeEmCee]

The main thing I and other contributors need is someone to review my changes. dkl has rewritten a couple of my previous ones, for reasons that seemed mysterious to me at the time. You need a good holistic understanding of the code base to know what the correct or best to implement something is.