I can see that I’m not getting through to anybody here. One last try.
This community, after more than a decade, is stuck in a mindset that every user is also a developer. Which is why it looks set to repeat every one of Linux’s mistakes.
There are people out there called regular users. Remember them, the people all this is supposed to be about?. Regular users don’t need the yab BuildFactory, the example code, the manuals. All they need is a single yab executable in the PATH, preferably delivered on OS installation. Then, when they download their little text editor, or database, or utility, it simply works. Regular users should not need to know or care what language their apps were written in. They should not have to download a development environment just to run a 50-line script that renames MP3s.
Easy solution: the package can be split in two parts, probably called yab, and yab_devel. The first one will have the interpreter and whatever runtime is needed, and the second will have the IDE, BuildFactory, and anything development related.
We don’t forget about the users, but making life easier for developers is also a good thing: it makes the devs more productive, and only then they can start worrying about the users. That’s also why we’re still in alpha stage with Haiku. When we feel it’s good enough to let users take over it, we’ll do a stable release. The progress may seem slow, but it’s happening.
All yab needs is the yab binary to be placed in the search path so that !#yab finds it. Yab has no dependancies if compiled properly, not even libncurses.so.
So yes, a yab package and a yab_devel package are appropriate.
Hi,
i dont prefer yab_devel, this sounds like a yab development version!
better is:
1.) yab-interpreter -> this is ONLY the YAB Interpreter, no IDE and Docu, Examples.
1.1) yab-IDE -> this is ONLY the IDE with Docu and Examples
1.2) yab-bf -> is ONLY the BuildFactory
Note: 1.1 need 1 and 1.2 need 1 and 1.1
That’s possible as well. “_devel” is our convention for developer packages. For C++ libs this has the include files, development static libraries, and any tool that may be provided with the lib.
But the package manager doesn’t enforce that, so providing more packages is fine. This is some easy tweaking to the recipe, once it is working.
I don’t think you need yab_sdk, as the IDE and Build Factory will depend on the main yab package anyway. Let’s try to keep our package list clean and not overdo the package splitting.
The beauty of BeOS/Haiku was the simple elegance of everything from the GUI to the file system layout, which they messed up a little because of the package managemnt they’re developing. yab, and yab_devel is in keeping with the KISS (keep it simple stupid) principle.
KISS is an (American) English acronym for “Keep it simple and straightforward” - since most systems work best if they are kept simple rather than made complex. I sometimes forget that English is not the first language of most of the people involved with Haiku development. You didn’t think I was talking about rock & roll, did you?
Not every body will show to all his source code, because they are often much work and brainstorming behind it. Jan makes the source code not viewable at binding the source to yab.
You are right to say, put yab into the bin folder of Haiku (we ask many times, many years… nothing happens, since yab is out), so any open yab source are runable using the yab binary (if the source is made of base of the included yab version).
GitHub: Do that you like, but make it useable, every other way is stupid, because no one comes to try it out or begin development in yab, because the package are broken. Alternativly add a instruction to make the package workable. Give yab, a native development language for Haiku, a chance to alive.
And for the main question: Yes i have interest to take yab alive, so we make the unofficial version of yab. A result of testing and trying, because we are no C++ coders.
It will be fine to get some c++ coders to work on yab for the future releases. The main developers are not active, or we does not know that they are active.
http://www.besly.de: We have many tutorials for yab and much more. We starting a yab mailing list at freelists.org, for some years: http://www.freelists.org/list/yab-dev. We also starting up a IRC Channel on Freenode.org called #yab and #yab-dev, but we have not anough developers to make the channel full any time. If anyone have enough expierience in IRC, please make a bot for the channel
While we’re on the subject, exactly the same argument applies to Squirrel. In some ways that was even newbie-friendlier than yab and right now it’s even more broken.
We need this. We need yab, and Squirrel, and a Bethon installation that works out of the box. We need that Lua with API integration, and we need all of those integrated deeply into the OS, not something to be downloaded from a third-party site. Whether your programming background is in BASIC, Logo, Pascal, Python, Lua, Java or C, you should be able to sit down at a Haiku box and produce something straight away.
Look at what few new submissions there have been on Haikuware lately. Small yab utilities, QT ports in various stages of functionality and polish (please, porters, at least stick an icon on the thing) CLI ports, practically NO native Haiku GUI software written in C++. Am I the only one who thinks this is a crisis? If Haiku is not made attractive to developers at ALL skill levels to work with, then it will go nowhere.
please use the latest Package from bbjimmy and don’t change anything on it. We are happy that yab is working, because there is no action by jan64 for fixing bug.
It’s not a crime, when we have the same files also in the src directory of yab. I can understand that make no sence for c and c++ programmer, but yab is in this version good and working.
A conformity package can be build later by jan64 or stargater, when the make a new release in 10 Years ;-). Sorry, a little joke.
[quote=stargater]
Some people thinking, yab can not OO Programming, this is half true, in yab self you can make opbject as function and add it to a new function.[/quote]
[quote=Michel]
Look at what few new submissions there have been on Haikuware lately. Small yab utilities, QT ports in various stages of functionality and polish (please, porters, at least stick an icon on the thing) CLI ports, practically NO native Haiku GUI software written in C++. Am I the only one who thinks this is a crisis? If Haiku is not made attractive to developers at ALL skill levels to work with, then it will go nowhere.[/quote]
Does anyone know if the original Yabasic is still developed? The original developer had already abandoned the project a long time ago, but then there was another guy working on it. Version 3 was under way, he said… Some interesting features were going to be added, such as associative arrays and some (limited) OO features too. Unfortunately, there has been no recent news about it, and it’s release is long overdue. I am suspecting that the project might have been dropped altogether.
I was wondering, if a new Yabasic version were to come out, with those added features, would the development of our yab be influenced in turn? Of course, yab is an independent project now, but I think it would be nice to have those features. Would it be difficult to port them?
I think a little poll would not be out of place here, so I am making one.
POLL: what are the features that you would like to see added/changed in yab?
On my part:
associative arrays
some OO features/syntax (as an alternative, NOT as a replacement!)
In the WIP we have nice Lokalisation Funktions and a yab app, but nice Haiku broke sometime the API, so we waiting for r1. Since you can used the latest version 1.7 (see the link).
Thanks and Happy coding, let us see what can you do with haiku. Personalty i like and love yab fullscreen demos.
