Hello,
Since FET is open source, I'd like to suggest using some kind of version control (maybe GIT?) and Trac. I think it would encourage users who know C++ and Qt to send patches and will simplify development for Liviu Lalescu.
Thank you for suggestion, but:
There are many reasons why I would like not to do that:
Firstly, I have never used such systems and they might prove disastrous for a beginner like me.
Then, I don't know how these systems work. I don't want to give rights to unknown persons, because they might make mistakes. The sources of FET are so fragile, because only one digit change in the generation algorithm might be fatal, but remain unnoticed for a very long time (forever?).
Also, I don't have time to learn these tools, I prefer to keep learning algorithms and new programming techniques.
Also, for the near future, I don't see very important changes to FET.
I just hope a good team will start a timetabling software based on FET and I will provide the allocation algorithm and help to integrate it. I just want to be a programmer on my part (algorithm of generation), not the leader of a complex program. I don't have organizational skills.
Thanks for the answer.
I understand your point. However, I think it would help FET to become more user-friendly (yes, I think it's the biggest problem with FET). Some time ago I thought about creating the timetabling software but it's a lot of work and I don't really have much time for it.
BTW, have you seen this: http://gstpl.wikispaces.com/Timetabling+Software+Survey ?
And many thanks for hard work on FET.
Yes, I have seen that link, in fact I gave to the author the facts about FET.
My hope is that a good team will begin to develop an interface for the FET engine. I am willing to help to integrate the engine. But I cannot work on the interface or learn version control or to make FET friendlier. I have no time, experience or pleasure to work in this field. I want to learn new algorithms - in fact I am now reading an algorithms book. The algorithm is a very important part of FET and needs much work. Also, I need to take care of particular requests on FET.
Hello,
it's 8 years later now. Have you reconsidered your decision not using any version control (and a public platform about that)? It may give your software new pace as it makes it easier for every interested developer to fork it, work on it and contribute the changes back to you.
It's not about giving up control or give someone else the right to make changes without your knowledge. In fact it makes it more transparent for you and everyone else to see what exactly has changed (and why). There is also a lot of easy to understand documentation and tutorials around describing the different VC systems. Also the various platforms make collaboration a lot easier.
With github for example you have a fork and pull-request system, where people can fork your code with one click, make changes in their own repository and contribute it back via a pull-request. This gives you an entry in the bug tracker where you can easily review all the changes and discuss it with the contributor. When you think, the change is ready to be merged into your official codebase, you can do this either locally via git with one click within the web frontend of github.
Another benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.
Thanks, Jan
Quote from: JanLo on September 01, 2016, 07:58:27 PMAnother benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.
even my pupils are clever enough to download and extract a file. but no one of my pupils is clever enough to use a version control system. so this is in fact a point against version control.
hmm... i fear you see "help developing" much too optimistic.
we even got request from guys that work at universities that teach only computer science and coding.
even a few of that guys ask us to compile the source since they don't understand how to compile.
if we now also force to learn a version control system, then we will even lose some developers. (in worst case even me, since i am also not good in that.)
seeing changes is very easy even without a version control system. you only need to use a comparison tool like kdiff, ...
very easy to use. very comfortable to see the changes.
Quote from: Volker Dirr on September 01, 2016, 08:22:27 PM
Quote from: JanLo on September 01, 2016, 07:58:27 PMAnother benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.
even my pupils are clever enough to download and extract a file. but no one of my pupils is clever enough to use a version control system. so this is in fact a point against version control.
My point here was, that you can search the code and point (link) to locations in it. I did not say, that a VCS should replace release tarballs. You can always have them, it's no problem with that. A VCS will just be a separate and more transparent way to distribute the code. You can even set release tags within the VCS to show the state that represents the code in a certain release. With this its easy to get a diff of the changes to spot regressions if one experienced one.
It would also not prevent someone to just download a tarball, make changes and send it (as a whole or as patch) back to upstream. In fact this is close to the way he linux kernel uses git as VCS: you send your commits to the VCS as set of patches to the subsystem maintainer who integrate them. You don't have to force anyone to use a VCS when you provide a public repository. You just give the opportunity to use it to people who are used to collaborate this way (software developers ;) ). I mean, you can try it. It will not change your software in any way - but I think it gives you the possibility for easier collaboration - at least with some people.
I would also think that your pupils will be clever enough to use a VCS if someone shows them the benefit. And if the work on the software should give them an insight in today's software development techniques it would be a huge benefit to show them how collaboration in this field works today ;).
my pupils are not coders :-)
that are "normal" pupils. on a "middle" school. Max age is around 16 years. They don't learn coding at my school. "Just" Mathe, German, English, History, Sport, ... but not coding.
Even they never code, that guys are clever enough to download and extract.
So you see my point?!
I understand the advantages you tell me, but you forgot the disadvantages. You can do all that stuff only if ...:
- ... you know how to do it
- ... you do it (i saw several projects on github that didn't add extra information. so in fact some of your advantages are only true if you add that information. that mean more work.)
By the way:
You can see also some disadvantages on Github.
Just check the FET source on github. You can already find it there.
You can already see the disadvantages there:
a) it doesn't pull new developers. the number of contributors stays at 1. (so the guy who uploaded it).
b) the addition information doesn't help. i can't see in single time where it is a "useful" information.
c) it looks like uploading is pretty much work, since they do it very rarly (i know myself that you need to press only a single button or write a single line. but as you can see: real life is different: there are no up to date uploads. looks like that is too much work.)
maybe you can upload there always and tag additional information? (since i don't have time to do that work)
Quote from: Volker Dirr on September 01, 2016, 08:50:08 PM
my pupils are not coders :-)
that are "normal" pupils. on a "middle" school. Max age is around 16 years. They don't learn coding at my school. "Just" Mathe, German, English, History, Sport, ... but not coding.
Even they never code, that guys are clever enough to download and extract.
So you see my point?!
I totally got it - and even if I think that they do not learn to code is a sad fact with the school system - it's not an issue for a VCS. They can easily continue to download, extract and do whatever they want with the tarballs. (But besides that I would also say, that C++ is not a good language to learn how to code in the first place ;) )
Quote from: Volker Dirr on September 01, 2016, 08:50:08 PM
I understand the advantages you tell me, but you forgot the disadvantages. You can do all that stuff only if ...:
- ... you know how to do it
- ... you do it (i saw several projects on github that didn't add extra information. so in fact some of your advantages are only true if you add that information. that mean more work.)
You just give the opportunity to people who are regular software developers to use it. You don't have to use it for your own at all. You can just stick with your release tarballs, commit the state of the release at one big commit and put it somewhere public. With that your release process will be extended by just one "git commit" and one "git push" - and if you wont remember the commands you could easily use a UI for git. Nothing changes except that you're offering another way to access the code :).
For me it would just be more convenient to have a official git source to clone from. If not I will just make a repository for my own purposes, import your latest release and maybe send patches of changes back. In fact the debian maintainers had already done this: https://anonscm.debian.org/cgit/collab-maint/fet.git (https://anonscm.debian.org/cgit/collab-maint/fet.git) :)
I have not looked at github at all because I looked at the official site for a source link. That's the problem with github repos that are created by people who miss official sources: they create them for their needs, get their work done and then orphan it. When you have a maintained "official" repo you can clone from it and everyone searching for it can easily see where it original came from. And as said, there are even a bunch of graphical interfaces for git if you cannot remember the commandline.
sorry, but i don't have time to upload and learn that. so what do you suggest who should do that work? will you always upload? i haven't got time to care about that.
Quote from: Volker Dirr on September 01, 2016, 09:30:55 PM
sorry, but i don't have time to upload and learn that. so what do you suggest who should do that work? will you always upload? i haven't got time to care about that.
It's no problem for me to do that but that will not solve the problem. My main point was, that you should refer to a official source on your website, because when I search on github, I get at least two repositories containing FET in some state in history. I'll never know whick is the right one. You could even refer to the debian VCS of FET. Just a source where people can easily base their work on and can be sure that this is the latest available version.
like i said: i haven't got time for that. i am around 10 years in this project now and in fact there wasn't more then around 10 lines of code contribution by other guys in all that years. So too much work to do that just for average 1 line of code per year.
but in fact Liviu is the guy in charge. He decides. I am not sure if he will do that work for such less benefit.
maybe it will be easier if you start sending patches. if we can see that there is someone coding good stuff, Liviu might rethink.
Thank you for your suggestion, Jan,
I am sorry, but I am still not prepared for this. You have good reasons, but I also have mine.
- I need to learn the system - there are possible critical mistakes;
- I prefer to keep the independence from other sites (I don't know if I can install GIT on my lalescu.ro);
- Sometimes I prefer to implement myself the suggestions, because other users are not that familiar with the FET code. If I have to take other programmers' code and analyze it, it may mean more work and very error prone.
- There are many possible improvements in the GUI part. Many users will come with suggestions and code. On one hand, I cannot implement all suggestions, on the other hand I need to check thoroughly the code, and this might take longer than actually me writing the code. So, best would be for some persons to start a new FET GUI and add the engine, and if this GUI proves good, to slowly make it an official alternative to the present GUI.
Also, please see KDiff3 - it can compare whole directories. It is really nice.
Hello,
you should definitely learn git one day. Its a distributed VCS - so you don't depend on some site. You just have multiple repositories with all holding the whole history and can synchronize changes between them in both ways. That's how the collaboration gets easier. Everyone can have its own repository, cloned from somewhere, work on it and ask you to sync the changes back if you want. Then you can totally transparent see all changes and decide which one you will take. Services like github just help to have on easy to access copy of the repository with some useful features around.
I, as an example, cloned the debian "upstream" branch from https://anonscm.debian.org/git/collab-maint/fet.git (https://anonscm.debian.org/git/collab-maint/fet.git), made some changes locally and pushed it to github to https://github.com/janLo/FET (https://github.com/janLo/FET). Now the code is on my laptop and on github and I do not depend on anything - and you can see the changes on github https://github.com/janLo/FET/commits/master (https://github.com/janLo/FET/commits/master), clone it grom there using "git clone https://github.com/janLo/FET" on your computer or compare all the changes at once online https://github.com/janLo/FET/compare/upstream...master (https://github.com/janLo/FET/compare/upstream...master). you can even click "clone" on the github page, get your own copy of the repository there and clone from that.
This also helps you not making terrible mistakes: If you want to try a new git-feature, you can easily clone (or even copy) the repo and try the changes there.
When it comes to the sensitivity of the code in case of errors, there is a lot of room for improvements. I started some cleanup yesterday and may continue on the next days. I think you could easily reduce the codebase by some refactoring and add more type safety alongside with that so that the compiler can find more mistakes.
last but not least: I really know kdiff3, kompare, melt and all this diff tools. I work in software development for a long time ;) . But having a compare tool does not replace a VCS. You could even use kdiff3 as dill- and mergetool for git if you like it: http://stackoverflow.com/questions/33308482/git-how-configure-kdiff3-as-merge-tool-and-diff-tool (http://stackoverflow.com/questions/33308482/git-how-configure-kdiff3-as-merge-tool-and-diff-tool) :)
At the end: I understand your concerns. I just waned to give you an overview of some of the benefits. If you won't use it: ok. I'll try to work with what I have from the debian project and hope you will take at least some of my changes back at some day. I'll send them to you as patchset on top of the latest release if you want (that's another benefit of git: you could easily rebase your changes on the latest upstream version when this moves forward).
Thanks, Jan
Thank you, I read some of your improvements and they are nice. I don't agree with some (0==expression, I prefer expression==0, teacherName(), I prefer getTeacherName() and setTeacherName()), there is a small mistake (the + case CONSTRAINT_TEACHER_NOT_AVAILABLE_TIMES: - you forgot to add TimeConstraintType:: before it).
The thing is that all such changes are critical and need a lot of time for checking. But I'll think about it.
Hello,
Quote from: Liviu Lalescu on September 02, 2016, 11:07:52 AM
Thank you, I read some of your improvements and they are nice. I don't agree with some (0==expression, I prefer expression==0, teacherName(), I prefer getTeacherName() and setTeacherName()), there is a small mistake (the + case CONSTRAINT_TEACHER_NOT_AVAILABLE_TIMES: - you forgot to add TimeConstraintType:: before it).
The thing is that all such changes are critical and need a lot of time for checking. But I'll think about it.
The links where only to show you how git can be used - I'm not finished with my refactoring but at 4am I stopped working on it to get some sleep ;) . The overloaded teacherName() is more common in the c++ world than getX() or setX(). But that's just personal preference. Both is better than having a public state without accessor functions ;) .
For the (0 == x) - I got used to this version because it prevents an accidental assignment when you typed only one equal sign because the compiler will complain about (0 = x) but not about (x = 0). But it's easy to change if you want, as its semantically the same ;) .
My goal is, to clean up the codebase a bit and separating the engine from the rest trough cleaner interfaces so that its easier to write a new UI or to use it as library in some other software. This should also open the possibility to write tests to prevent accidental changes in your algorithm.
Quote from: JanLo on September 02, 2016, 02:21:43 PM
The links where only to show you how git can be used - I'm not finished with my refactoring but at 4am I stopped working on it to get some sleep ;) . The overloaded teacherName() is more common in the c++ world than getX() or setX(). But that's just personal preference. Both is better than having a public state without accessor functions ;) .
I did not know this. It is maybe better as you say.
Quote
For the (0 == x) - I got used to this version because it prevents an accidental assignment when you typed only one equal sign because the compiler will complain about (0 = x) but not about (x = 0). But it's easy to change if you want, as its semantically the same ;) .
Yes, I know that, but also in the majority of the cases if(x=0) will trigger a compiler warning, and I prefer to have code readability.
Also, another thing, I prefer to use tabs, not spaces.
Please note that I did not promise to take your code :) . It is a lot to check and the changes are critical.
Edit: Another idea would be for you to use only the generate.h and generate.cpp and generate_pre.h and generate_pre.cpp, and derive your own additional code. The needed variables are in the beginning of the generate_pre.h. Because what you intend to change in the official code has that much to change that it might be better to start from scratch.
Well, I haven't see this before I start...
Here are my repositories:
https://bitbucket.org/rodolforg/fet
https://github.com/rodolforg/fet
I hope I can contribute to this project.
My goal is to provide unit tests to check the engine status and avoid break changes.
Thank you! But I am not experienced with this kind of collaboration. I hope I will learn something from your work.
For Brazilian Portuguese corrections, I think the best is for you to contact the Brazilian Portuguese translator.
Quote from: Liviu Lalescu on September 20, 2016, 10:38:56 AM
Thank you! But I am not experienced with this kind of collaboration. I hope I will learn something from your work.
I know this feeling...
If you want to learn git, I recommend this "e-book": https://git-scm.com/doc .
If you choose to not clone my repository (= have a local copy of my changes), I can provide you patch files of any commit (= set of changes I've done) you want.
This way you can merge with your own source code.
The patch file is easily created by git, as well it is to merge and check merge conflicts, though.
Quote from: Liviu Lalescu on September 20, 2016, 10:38:56 AM
For Brazilian Portuguese corrections, I think the best is for you to contact the Brazilian Portuguese translator.
Thank you. Done via forum.
Quote from: rodolforg on September 20, 2016, 01:17:08 PM
Thank you. Done via forum.
Thank you! I told khemis to look at that topic.