PureBasic Forum

Has anyone successfully got the IDE to build yet?

I've been spoiled by PureBasic so dealing with all these Microsoft framework configs is a pain

Should we create a big thread for compilation help? I have already solved 3-4 of my errors but still can't finish make.

Hi Kenmo Your not the only one my old . And to #Null Yes Im on Windows 10 2004( yes seems pretty stable over past week or so case anyone`s interested) It`s networksupport.obj thats got me at every different attempt. I`ve even dragged all vs2013 include`s
into purebasic\libraries\debugger grep`ed <blabla.h> to "blabla.h" on all header files.

Probably barking up thhe wrong tree but haho thats how we learn. "What I`m Not sure!" More tomorrow.

@Kenmo yes I think a compilation help thread is needed, cause for me this and ue4 is what keeps me sane from the mad world out there or is it keeps me mad from the sane world out there! any ways its one of them

Zebuddi.

Amazing Fred thank you!

Thank you Fred.
I hope it will help to find the reason(s) for random crashes (memory capacity overflow/stack overwriting etc.).

@Fred
My suggestion: Can you create a branch "development"? Then you can only merge the changes in "master" that should be included in the PB version. It's just an idea.

Yes.
https://www.purebasic.fr/english/viewtopic.php?f=5&t=74155

Hello Fred and PB Dev Team,

I think this is a great decision!
Even if I wouldn't be interested in the source codes at all, I would at least benefit from the expected faster bugfixing and/or feature enhancements.

From my point of view the chances outweigh the risks by far.

Of course it would be nice if a certain set of rules would develop, so that all operating system variants would profit from it.

I could also imagine that in the future there would be different solutions for one and the same task.
Then of course it would be great if you could make the decision for Tool1 or Tool2 only by configuration and without compilation.

... these are just a few first thoughts of a hobby programmer ....
Let's start with what's there and look forward to the possibilities.

Happy Coding!
Andreas

I just pushed a new version with the OSX-x64.bash file which is needed to build the IDE on OSX. For linux it should be the same, instead of PB_COCOA=1, you should put PB_GTK=2 IIRC.

To use the OSX-x64.bash file:

1) edit it, and replace the PUREBASIC_HOME with a valid purebasic dir
2) in bash, type:
. ./OSX-x64.bash

It should setup all the needed things to compile the IDE.

Thanks Fred! Now I could make the IDE, open the IDE Project and compile/run it.

Hi to all Cracked it! and Dohhhhh ---- Make sure you get the correct path to VS includes. But it was start of a nice little learning curve. Now to look over Fred & Teams code to see how things are really done.

Zebuddi.

Questions for Fred :

1. Any reason why the IDE still use GTK2 instead of GTK3 ?
2. Are you willing the answer questions we might have about certain parts of the source code ?

Thanks.
StarBootics

The Road to Collaborative Editing

The announcement that the PureBasic IDE has become available under open source via GitHub is indeed great news for everyone in the PB community, and especially so for those wishing to contribute to its growth.

I can understand the overwhelming joy to this announcement, and that many developers here are eager to starting tweaking the IDE sources and implement their long-desired features.

But, if I may, I’d like to drop a couple of words of warning regarding this, for I hope that Fred’s initiative to open source parts of PureBasic source code is going to alleviate some maintenance burden from his shoulders and allow the community to improve the IDE and add new features to it.

In order for this to happen, collaborative editing needs to be organized in a well structured manner. Version control in general, and Git and GitHub (in this specific case) were designed with this specific goal in mind, i.e. simplifying collaborative editing of the same code base without introducing complications due to different contributors working on the same files across different OSs, editors and IDEs.

GitHub offers a rich plethora of tools to make this happen in a smooth way, and there are many standards and workflows out in the wild to aid collaborative efforts in a well structured and constructive way.

A point I’d like to stress (having cloned and studied the new purebasic repository) is that the project, as it currently stands, was clearly not designed with massive collaboration in mind. In other words, the shift from PB IDE development from a small group of coders to the open source realm might require some adjustments to prevent chaos creeping into the project.

As an example, those of you who looked closely at the PB sources on GitHub will have noticed that they don’t have a BOM. If you open those files and save them in UTF-8, the IDE will automatically add a BOM to the file, and Git will see the file as changed and expect you to commit them (even though no real contents were changed). On the other hand, if you handle the file in PB IDE as Ascii, you might corrupt some UTF-8 encoded strings without realizing it. This is just an example of how different people working on the same code with different editors or IDE settings could end up disrupting the source files in many subtle ways, often without realizing it (until it’s too late).

Surely, there’s nothing new under the sun, and similar situations are rather common in open source development, and there are various solutions to handle them and prevent code disruption — in this case, enforcing code styles via EditorConfig is currently a good way to preserve integrity of the project and allow contributors to work on the code using different editors and IDEs.

But there are many other problems and pitfalls that affect working with Git on PureBasic projects, ranging from choosing the right PB IDE settings (to prevent IDE settings from being stored into the source files) to ensure correct EOL normalization at check-in (without those settings, a Windows user could make the code unusable to Linux and macOS users by introducing CRLF EOLs in the repository Index).

My appeal to the PB community is to take this great opportunity that Fred donated to us as a chance to create a true collaborative effort on GitHub. I’m aware that not every user on the forum is favourable to using Git, but if we truly want to be able to joint-collaborate on the PB IDE growth we need to use version control, and to do so in a well regulated manner by setting forth some coding and contributing conventions, enforcing them via continuous integration services, and then stick to them.

The challenge at hand is being able to fork the original (upstream) code base, implement our own changes and then be able to integrate them back to the upstream source, and to do so in an orderly manner. Git and GitHub are tools that can greatly simplify large-groups collaboration on the same codebase, but if used wildly they might end up complicating life instead of simplifying it.

By donating to us access to the PB IDE sources Fred has done us a great favour, but we have to realize that the raw project was intended for a small group of people who had an agreement on how to edit the code, and that we need to enforce some standards that can make the repository more oriented toward the GitHub way of forking and editing — and that we shouldn’t expect this burden to weigh on Fred’s shoulder.

Unless we do that, we’ll end up creating new IDE features which might prove hard to integrate back into original codebase, adding more burden on Fred’s shoulders instead of relieving him from it. Rushing each one in his/her own direction, without commonly agreed development patterns, has proven to be counter productive in the open source world — which is why standards, workflows and tools were introduced.

So, while I understand the enthusiasm to rush and start editing the IDE sources, I hope that developers in this community will also consider helping the new born repository to acquire solid collaborative foundations, by contributing settings to enable standards for code styles, continuous integration and deployment, version control schemes, an efficient features tracking system, and other tools that will prevent the project from blowing up in our faces if and when contributions start to be really big.

This is the first truly great GitHub challenge for the PureBasic community, and if we take it on the right way it could be the beginning of a new era of users contributions to PureBasic, which could ultimately lead to a richer PB echo system and a growth in the language popularity attracting more users.

And I’m sure that if we manage to prove to Fred that donating to the open source parts of the PureBasic code is going to relieve him from maintenance burden, and allow the community to contribute back great features in a seamless way, there’ll be more PureBasic open sourcing to come in the future.

@Tristano Excellent. This is the problem ahead of us, for myself I know very little about collaborative editing and no practical experience. I would`nt know where to start But I`m in and willing to get my hands dirty and learn So count me as Laboureur #1 No offence Fred

Zebuddi.

Hi @Zebuddi,



Glad to read this. We are a community and we can count on each other's help for this. I say, just join the project on GitHub and start by forking the repository (creating a free GitHub account gives you access to all the tools you need, so you won't need to purchase a Pro account for open source projects).

I've already started to create some Pull Requests (code changes proposal) for implementing safe guards to protect the code from disruption due to editor or OS differences, part of the changes have already been integrated into the codebase by Fred, others are pending review and approval:

https://github.com/fantaisie-software/purebasic/pull/4

GitHub repositories offer Issues, which are topic-based discussion threads where anyone with a GitHub account can ask questions, propose changes and submit comments; but unlike forums Issues offer powerful features that connect every discussion to the actual code being discussed, which makes it very easy for developers to follow topics development via tags and auto-generated references. Submitting requests, proposals, bugs, etc., on the repository Issues already alleviates its maintainers from the burden of having to cross reference external sites (like this forum) and allows them to track the project status from a single web interface.

https://github.com/fantaisie-software/purebasic/issues

I'll be happy to share whatever knowledge I've acquired on Git and GitHub with other PB users, as it is common practice in the open source world to support each other with advises and learning. After all, programming is huge field, there's always something new to learn and there are no exceptions to this rule. Even expert programmers find themselves in need of help when they embrace new tools, languages and standards. Life is too short to rely only on official documentations, and sometimes we only need a little help to start using new tools. As we say in Italy, "no one is born learned."

I've tackled many times with the various problems encountered in working with PB projects inside Git repositories, and I've written some articles here and there, which might be a useful starting point:

• Git Resources for PureBASIC (assets files hosted at: https://github.com/tajmone/pb-archives- ... opment/git)
• Source Settings Save Options (short article on recommended PB IDE settings)
• PB Project and Source Files

I've also created a PureBasic Repository Template for GitHub, which provides ready-to-use presets for working on PB projects:

• https://github.com/tajmone/purebasic-repository-template

I'm planning to use the associated Wiki to host in a centralized manner a series of articles and tutorials dealing with PB projects, code style settings and other Git related issues:

• https://github.com/tajmone/purebasic-repository-template/wiki

The Wiki is open to public editing and anyone is free to add new contents.

I'm sure that by uniting our own expertise and joining efforts on GitHub we'll manage to work as a strong community. When people start working together on a same project, teams are naturally formed, and everyone learns from each other, so eventually projects find their momentum and things start to happen fast — but, most important, people learn to work together, which is a skill in its own right.

When I first joined GitHub I had no clue how to use Git and, quite frankly, had a very vague idea of what the tool did, all I knew was that you need to know how to use Git in order to jump on the "open source community train", so to speak. It was thanks to the patience and support of various projects maintainers that I managed to eventually break through the impasse of not being able to do anything without destroying the repository every time, to eventually start to "walk on my own legs". Those who helped me were total strangers, but they realized that I wished to contribute to their projects and that simply I didn't know how to use Git, so they offered me free advise. At the end of the day, we all stand on the shoulders of those who came before us; we learn and improve, but no one reinvents the wheel ever.

I hope to see you on GitHub then!

You posts are very well done Tristano, thanks for it. You are indeed right when you said it was done only for a small group of dev (actually only 2: Fr34k and me) and we indeed agreed on coding style and such. Feel free to continue your pull requests to make it better for everyone contributing, like puting a BOM for everyone, and using a .cfg instead of storing config at the end of file etc.

TBH, I'm not that worried about future, it will take some iteration to get something usable for everyone but we will get there !

Happy hacking, glad to see than some of you successfully compiled the IDE