Welcome, Guest. Please login or register.

Author Topic: Layers.library V45 on the aminet  (Read 64648 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline olsen

Re: Layers.library V45 on the aminet
« Reply #344 from previous page: September 21, 2014, 09:13:58 AM »
Quote from: kamelito;773249
@Olsen @Thor,

Since it's too late to go back to school, could you please give a list of good books to go from a "coder" to a "software engineer". Being about C, C++, Algorithms, Design patterns whatever else suit you.

Thanks
Kamelito
I missed one book which might be helpful, and which is also very readable: "The practice of programming", by Brian Kernighan and Robert Pike. It covers some of the same ground as the "Programming pearls" collection, but complements it well with material absent from it, such as testing and debugging. I'd say that had this book been available to me some 25 years ago, it would have opened doors which at the time I did not even know to exist.
« Last Edit: September 21, 2014, 09:16:51 AM by olsen »
 

Offline kolla

Re: Layers.library V45 on the aminet
« Reply #345 on: September 21, 2014, 02:33:59 PM »
Quote from: olsen;773379

This sounds pretty abstract, so I'd like to give an example of such a tool that might show up one day and prove its value lateron: software configuration management (SCM), using tools such as SCCS, RCS, CVS, SVN, git, you name it.


Hm, my mind boggles - in my book, SCM is a tad more than just a revision system, Software Configuration Management is more a tool for system administration, rather than software development. SCM also include automated building and testing of software (hudson, jenkins, codeship, cruisecontrol...), change control with peer reviewing before deployment (puppet, chef, cfengine ...) Of course, using such tools can also be usefull for developers too, and these days I dont know any coders who don't at least use a revision control system.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline olsen

Re: Layers.library V45 on the aminet
« Reply #346 on: September 21, 2014, 03:36:58 PM »
Quote from: kolla;773583
Hm, my mind boggles - in my book, SCM is a tad more than just a revision system, Software Configuration Management is more a tool for system administration, rather than software development. SCM also include automated building and testing of software (hudson, jenkins, codeship, cruisecontrol...), change control with peer reviewing before deployment (puppet, chef, cfengine ...) Of course, using such tools can also be usefull for developers too, and these days I dont know any coders who don't at least use a revision control system.

Modern times indeed. You'd be surprised how many people don't even know or care about SCM, even in its most simplistic form. Even talking them about it you're met with the kind of gaze I supposed is reserved for looking at cranky children, axe murderers and the remains of a dead rat which turned out to be hidden in a piece of sponge cake.

You are correct that the purpose of SCM goes beyond the simple stuff, yet it's the simple stuff which is underestimated, and the more complex stuff is ignored because you can do even the simple stuff manually, so why care?

Part of the job of developing software, performing system administration, etc. is not to become complacent and at least have an eye on where the field is moving. You can adopt what you find useful, after you have evaluated it. But in some cases that bit never happens, because things work well as they do. Until they don't, and when they suddenly don't work any more, you're in bound to be in a profoundly unhappy place :(
 

Offline kamelito

Re: Layers.library V45 on the aminet
« Reply #347 on: September 21, 2014, 07:46:28 PM »
Quote from: olsen;773565
I missed one book which might be helpful, and which is also very readable: "The practice of programming", by Brian Kernighan and Robert Pike. It covers some of the same ground as the "Programming pearls" collection, but complements it well with material absent from it, such as testing and debugging. I'd say that had this book been available to me some 25 years ago, it would have opened doors which at the time I did not even know to exist.


Thanks
Kamelito
 

Offline Minuous

Re: Layers.library V45 on the aminet
« Reply #348 on: September 22, 2014, 07:04:12 AM »
Quote from: kolla;773583
I dont know any coders who don't at least use a revision control system.


I don't use one, it doesn't make much sense for solo projects...
 

Offline biggun

  • Sr. Member
  • ****
  • Join Date: Apr 2006
  • Posts: 397
    • Show only replies by biggun
    • http://www.greyhound-data.com/gunnar/
Re: Layers.library V45 on the aminet
« Reply #349 on: September 22, 2014, 07:26:52 AM »
Quote from: Minuous;773639
I don't use one, it doesn't make much sense for solo projects...


Its crucial for team projects
and it can be very helpful also for solo projects.

Imagine a big project with many files on which you work for several years.
Every code change you did is with a revision system "marked" with a comment explaining its intention.
E.g.
"chip-bus rewrite to lower latency"
"decoder PC-calc change to improve clockrate"
"Ea rewrite to reduce LE count"
...
With a revisioning system you could "rollback" certain code changes even much later - if you expect them to cause problems.

You can also flag certain know good/stable version easily.
And you can easily mark releases.

If you give our releases to customer you can later apply importatn fixes to these releases as updates - without adding new features whih the main developmen stream might have,

For a sensible software development with release which get supported etc - something like a revision system is required to be able to do this.

Offline psxphill

Re: Layers.library V45 on the aminet
« Reply #350 on: September 22, 2014, 08:17:39 AM »
Quote from: biggun;773643
and it can be very helpful also for solo projects.

Imagine a big project with many files on which you work for several years.

Yeah, I rarely bother for solo projects that I am not going to share. But these usually turn out to be one off throw away programs anyway. While it makes some sense to source control those too, it is one of those jobs you put off. Like deleting old emails you no longer need.
 
 The biggest problem is when you write crappy programs that have hard coded paths etc, then these show up as changes in source control. You should split those out into configuration, but when it takes 30 seconds to write the code in the first place then making it tidy and putting it into source control is hardly worth it.
 
 You also have to maintain a server yourself, but if you're part of a team then you can offload that to someone else.
« Last Edit: September 22, 2014, 09:16:34 AM by psxphill »
 

Offline olsen

Re: Layers.library V45 on the aminet
« Reply #351 on: September 22, 2014, 08:48:26 AM »
Quote from: Minuous;773639
I don't use one, it doesn't make much sense for solo projects...

It can make good sense for solo projects, though modern SCMs make it look as if the technology is primarily enabling collaboration.

I started using RCS some twenty years ago in my small projects for two reasons.

The first reason is that the more you change your code, the harder it becomes to keep track of the changes. Instead of a single .bak file for each file you edited, or a collection of backup files which are tagged with a date in their names, you can keep all the changes in a single SCM file. There's also one common interface for storing the changes and retrieving them. Compare making individual backup files with just committing a change with a comment, and then later using the diff command integrated into your SCM tool to look at them, to comparing individual backup files manually.

The second reason is that a project can change scale and scope, and you may not notice how the daily changes gradually push it into a direction which make it harder to manage. The SCM acts as a safety-net, so that if your project crosses a certainly complexity threshold, you can still roll back changes, or review older revisions. Using the SCM regularly isn't that much of an effort. Getting back at the change history you cannot easily recover (because you don't have one, or because it only goes back 1-2 edits) puts a bigger burden on your work.

You don't have much to lose if you use an SCM in solo projects :)
 

Offline Minuous

Re: Layers.library V45 on the aminet
« Reply #352 on: September 22, 2014, 11:28:46 AM »
I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #353 on: September 22, 2014, 12:28:59 PM »
Quote from: Minuous;773653
I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.

Look, I worked the same way like 20 years ago when all at a sudden I was forced to use a revision control system (not even a full-fledged SCM) when I started in industry. At first, it sounded like an unnecessary overhead and a needless burden, but it was not. The learning curve for a simple tool like CVS or SVN is not very heavy. It really proved to be a very useful tool, even more so as you could go back any time you wanted, you could run a "bisection" to see in which release you introduced a bug, and you could follow the revisions and history easily.  

What you want to have in professional development is some kind of "development release" where you test your ideas, and a "stable" release you ship to your customers. If you make fixes in one release, you want to merge them to the other, but new ideas stay "local" until they have been tested, and have been exposed to the customer. Typically, "your customer" also has "customers", and thus, you would need to keep several revisions around in case your customer comes back to you with problems their customer had.

I was then rather shocked to find  when our company took over another company on the "professionalism" of our ex-competitors for using "manual revision control", i.e. manually copying source files around. This is very error prone, and you often forget to merge something, or check for conflicts. As soon as your project grows larger and becomes complex or you get new team members, you're lost. Instead of depending on an in-house protocol, rather depend on a protocol every professional engineer should know.  

Nowadays, I really regret that I did *not* use a simple revision control system (even RCS or CVS would have worked) for many of my Amiga sources. Lots of old code is lost in limbo, or somewhere in some strange places (manual backups) without enough information how the pieces fit together. It really pays off, and I would strongly suggest to try before banning a simple tool. Note well, I'm not talking about a full-fledged SCM like perforce (I kinna hate tools that "get in your way", and p4 is a prime candidate for it because you cannot use it without a longer lecture on its principles - but if you're working in a larger group, it's arguably unavoidable.) but really about simple minded elementary tools that can save your day.

Hence, yes I regred that I do not have a formal education in such tools, and I had to learn the hard way that they are very necessary. Don't be the same fool I was years ago. I simply didn't know better... but at least you should now know better when people that did get a formal education (unlike me) tell you.
 

Offline olsen

Re: Layers.library V45 on the aminet
« Reply #354 on: September 22, 2014, 01:05:57 PM »
Quote from: Minuous;773653
I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.
That certainly can work, but it may not always work. Some 25 years go I could literally remember everything that went on in a program, its configuration files, it data files, what all the constants meant and how they were used.

Nowadays there's not so much of the old zing around (maybe the programs became bigger, maybe the tools got better), and I have become too lazy to do manually what a script, a program, a tool could do automatically for me.

Maintaining a change log is necessary, and it is very convenient to maintain it through subversion (SVN) commit messages, which lateron get folded into a release log file. The subversion repository keeps track of my file changes, the change log data that describes the changes, and it contains the release log file, too.

If need be, I can use the subversion repository to roll back changes I made (undo), and I can go back to old releases for review. All of that can be done by reviewing archived changes, stored in individual files (which clutter up the directory), but with a revision control system you just tell it to retrieve the file change history and you're able to review each small change you made and committed.

If you change one character in a file you can commit the change and it won't eat up a lot of disk space (revision control systems store differences between subsequent revisions), but you probably wouldn't store a full backup copy of that file for later reference.

The subversion command does work which I need to do anyway, and it allows me to spend far less time on it than doing it manually would. There are positive side-effects as well.

Revision control systems such as the old RCS, CVS and SVN do not need a makefile. It's possible that the makefile contains rules for invoking these programs, but these are just icing on the cake. You could invoke these commands manually and it would not change a thing.

What is needed is a place to store the revision information, etc. Both the old RCS, CVS and even subversion allow you to keep the data in a local directory on your computer. Storing that data on a separate system, where it can be safe from data corruption or loss may be a more appropriate solution though.

Once you commit to using a revision control system and clear the first hurdle in setting up a repository, it can become second nature to use it for every project you work on, no matter how small. If you consider each small project in isolation, then setting up the repository may look like unnecessary, unwarranted effort. But if you do start using it, then every project, no matter how small, can benefit from having it around.
« Last Edit: September 22, 2014, 03:12:51 PM by olsen »
 

Offline kolla

Re: Layers.library V45 on the aminet
« Reply #355 on: September 22, 2014, 01:39:35 PM »
No revision system ever had anything to do with Makefiles, what an obscure idea.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #356 on: September 22, 2014, 03:47:48 PM »
Quote from: kolla;773660
No revision system ever had anything to do with Makefiles, what an obscure idea.

No, makefiles and revision control are indeed independent, though both are a good idea. Make is just another one of the tools you want to know how to use, plus autoconf if you're working in a POSIX environment.

Anyhow, one thing a revision control system can do for you is to dump the version number upon check-in, in the makefile if you like.
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #357 on: October 02, 2014, 12:45:26 PM »
To facilitate further testing,  I prepared a new version with cliprect pooling partially disabled. It does not seem to make any difference here, though it might be *slightly* slower (due to the lack of the pools), though this is probably unnoticable.

Anyhow, I would be interested how this performs and whether it avoids the known problems of the previous release.

up.z01.zip
up.zip

Note that this is a beta release, i.e. your milage may vary. This is a multi-part zip archive, you first have to rename the first back to up.z01 or merge the files in the order up.z01.zip and up.zip to get one single archive which can then be extracted.
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #358 on: October 03, 2014, 11:47:17 AM »
Nobody interested in looking at this? Sorry, but I don't think I want to upload anything to Aminet before at least a couple of people had looked at a revised edition.  This version should likely fix the issue with Birdie (at least it seems to work fine here), and those of you who reported a problem with P96 should be ready for a small surprise.  Thanks, Thomsa
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #359 on: October 03, 2014, 11:59:06 AM »
i cant test as i dont know the issue, have never used birdie and above all have only a touch device with me that doesnt cope well with winuae. sorry.