Welcome, Guest. Please login or register.

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

Description:

0 Members and 2 Guests are viewing this topic.

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« on: July 13, 2014, 12:23:10 AM »
Quote from: itix;768786
MUI is de facto standard.
As far as I remember, MUI does not support the 68000. I do not consider it as a standard.
AmigaOS has flaws but each correction affects third-party softwares. It is a pleasure to note that it is updated. Thanks.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #1 on: September 14, 2014, 07:16:56 PM »
I have a dream. I'd like to see ThoR and Cosmos working intelligently together without killing each other, each in his field of expertise.
 
But unfortunately, since I saw the little mouse to be eaten by the cat, I do not believe in Christmas.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #2 on: September 15, 2014, 10:45:04 AM »
Quote from: Cosmos;773018
I only wanna explain that the quality of the code is very important.:)

And the problem is that each of you is right.
One said where to go while the other say how to go.
Then, each of you take one end of the same rope and pull very exactly in the opposite direction of the other. So, inevitably, nothing is moving forward.

Remenber, your discussion is about a 7 MHz clocked hardware.
Synergy will always be more profitable than a true false antagonism.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #3 on: September 15, 2014, 07:18:03 PM »
Quote from: Thomas Richter;773046
Well, look, first of all, I don't think we're "pulling in opposide directions", or that we aren't moving. This thread is about a move, after all, and I hope it's a move in the right direction.

Second, whether a processor is 7Mhz or not does not matter: If a given function (say AndRectRegion()) takes 1% of overall calling time to move a window, it does not matter whether you speed this up by a factor of two (realistic, if AllocMem is bypassed) or a factor of 1000 (unrealistic, unless you replace it by a NOP), the net effect will be NIL. It's really a very elementary truth that is independent of the processor speed. To get a speedup of two, *every single* function in the call path would have to be speed up by the very same factor, and that's not going to happen.

The problem really is that Cosmos has apparently never worked in a larger software project with exploding complexity, and thus has no feeling in what type of modifications one would want to make, and in which step of the project. Yes, of course it makes sense to optimize a bottleneck of a program, and there to use processor-specific code. But it does not make sense if you have additional constraints that are harder to characterize, such as maintainability, or portability. If the code can work on an old machine, and the speed impact by not using the latest processor instructions is below measurable, it makes no sense to use such optimizations. Basically you compromize compatibility and get nothing in return. In the same way, it does not make sense to replace an AllocMem() by a copy on the stack (all provided this is valid) if you don't receive a measurable effect. Again, you would compromize maintainability (as in: There is a single constructor call for a certain object) and would not gain anything measurable in return.

As always, you have to find compromizes in development, especially when it comes to larger and complex problems, and "running time" is not the one and only goal. You not only want to deploy your software on a wide variety of hardware, you also want compatibility to existing software, and you also want to be able to read your code from ten years from now. You also want that customers can install and use the software easily, and are not confused by compatibility issues that version C of a library can only work with programs P and Q, but program R requires version B, and program S may work with C, but only if specific settings are made...

The overall problem cannot be reduced to a simple count of cycles.

Pedagogically, it would have been more elegant and efficient to directly explain why everything has its reason for being.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #4 on: September 16, 2014, 10:39:28 AM »
I think I'll restart to program in machine language on punched cards.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #5 on: September 16, 2014, 02:22:42 PM »
Fortunately, the first C compiler was written in assembler.
(with that, it seems clear to me that I will not have new friends.)
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #6 on: September 16, 2014, 05:00:18 PM »
Quote from: Thomas Richter;773165
Where did you get that idea from? http://cm.bell-labs.com/who/dmr/chist.html
As far as I can remember, probably during training in microelectronics in the 80s:
"in 1972 the first version of C is written in assembler by Brian W. Kernighan and Dennis M. Ritchie."
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #7 on: September 17, 2014, 10:04:11 AM »
Quote from: psxphill;773221
Never believe anything they teach you in school.

I agree, and that's one reason why I never learned C. Another is that it is always better to avoid the use of an interpreter.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #8 on: October 03, 2014, 09:53:10 PM »
I just basically try them inside UAE + OS 3.1 + Visualprefs. This seems OK.
Thanks for your work.

NB: No error during extraction.