My attempt to use FAT

[Malcolm_M]

As janni wrote

I'm afraid that care in choosing unique names cannot be replaced by a set of smart rules for the compiler

How about the first three letters of your forum user name followed by underscore - LGR & VCC are already sorted This would be more easily recognisable than random letters.

As LGR wrote "there will need to be an mE global identifier database....." to cater for user names where the first 3 letters of the user name are the same.

Also, what happens with libraries which are specific to processors from the same manufacturer PIC18, 24 or 32 and also processors from different manufacturers.

All names Could start with:

Code: Select all

jan_P18_str , jan_P24_str, jan_ARM_str, dan_P18_F32 , dan_P24_F32, dan_ARM_F32

The second 3 digit group, has the processor manufacturer/ type as the first digit: A = ARM, P= PIC etc and digits 2 & 3 are the family 18, 24 etc. ?

The third group could be the library name and is up to the author to choose a name: so the variable 'max' could be 'jan_P18_str_max', 'jan_P18_string_utils_max', 'Dan_P18_F32_max' , 'Dan_P18_FAT32_max'

It could be that a different order is better: 'FAT32_P18_Dan_max' ?

No comment from mE so far, we know that the problem can only multiply unless some simple guidlines / rules are implemented.

Possibly the forum users can propose a solution and then mE can accept, modify or suggest changes ?

P.S. I am not suggesting/ requesting janni and Dany should convert their libraries for ARM - used just for explaining my ideas

[LGR]

Malcolm, I think you're on the right track. Not necessarily a user code, but a three letter unique code (26^3 = 17,576 combinations, 46,656 if you allow digits) generated by a hash function from the project name, and maybe the creation date in addition just to insure uniqueness. Hash functions are pretty straightforward.

Whether the three-letter code should be visible or not is another question entirely. I tend to think that it should be something that can be turned on and off, but I recently wasted a lot of time because I didn't realize that known extensions were turned off in my Windows.

[janni]

All names Could start with:

Code: Select all

jan_P18_str , jan_P24_str, jan_ARM_str, dan_P18_F32 , dan_P24_F32, dan_ARM_F32

There's really no need for strongly formalized naming . Libs' names should simply reflect their purpose.

Differentiation of libs by author would be plausible only when more than one author writes libs on the same subject - but then one usually uses only one such lib at a time. And then, one author may write more than one lib on the same subject. If the libs differ significantly, it may be worthwile to distinguish them - it should be enough to add a single letter/digit (that's what I did lately after significant changes to my xGLCD lib - it's now called uGLCD - the 'u' stands for 'micro', not 'universal' or 'unique' ).

As for processor families, their names should find place in package names rather than in libraries. This way one does not need to change code when moving to another family.

"mE global identifier database....." - wouldn't it be a nightmare for those that write libs for their own use only?

P.S. I am not suggesting/ requesting janni and Dany should convert their libraries for ARM - used just for explaining my ideas

Looks like Dany already extends his libs for all PIC families - ARMs are just a step away .

[LGR]

Janni,

Differentiation of libs by author would be plausible only when more than one author writes libs on the same subject - but then one usually uses only one such lib at a time.

I don't think that's safe to assume that different authors won't write for the same device. Look at the proliferation of LCD/GLCD/TFT libraries and drivers. And the thing that started this thread - the conflict between the mE FAT16 libraries and Dany's FAT32 (named simply "FAT") project.

The only way to avoid conflicts the way you envision is to enforce a stronger framework for naming libraries for these common and yet diverse libraries, and trying to coordinate ahead of time.

This is also likely to be a problem with less common hardware as well. Imagine that an author writes an GPRS library, using some internal TCP/IP code as dependents. We're going to have the same problem all over again when somebody uses this and the ethernet library.

There's an old saying: if architects built buildings the way programmers build programs, the first woodpecker to come along would destroy all civilization".

[Dany]

I did run into a similar kind of problem, see http://www.mikroe.com/forum/viewtopic.p ... 90&start=6.

The IDE (library mgr) works with .mpas/.mcl files (the actual library files) and searchpaths. If an .mpas/.mcl file is in more than one search path then the library manager can not distinguish between the two.

Something similar about local procedures in a library (which can of course have the same name): the compiler behaves well, but the statistics "functions tree" gives some wrong info, and also the listfile shows ambiguous info: http://www.mikroe.com/forum/viewtopic.php?f=86&t=27303 and http://www.mikroe.com/forum/viewtopic.php?f=86&t=27304

[LGR]

Dany, I've also noticed a bug in Pascal32 that causes the compile to bomb if you construct a project with all libraries defaulted to "on". I remember the SED13700 library and one other being the problems. So this can be a problem even without user projects.

The real root cause of the trouble, IMO, is that there are so many libraries and sublibraries and dependent libraries, that it's becoming extremely difficult for even mE to manage it all. This is only going to get worse without some sort of automatic system in place to prevent these conflicts from occurring.

[janni]

I don't think that's safe to assume that different authors won't write for the same device.

I did not assume that. I've even written that the same author may write more than one lib dedicated to the same subject - meaning simply that author's name or it's abbreviation is not enough to discriminate between libs.

Look at the proliferation of LCD/GLCD/TFT libraries and drivers. And the thing that started this thread - the conflict between the mE FAT16 libraries and Dany's FAT32 (named simply "FAT") project.

The conflict was caused by declaring a record type named 'Part' in definition file of the official lib. That's really bad programming practice to use such simple names for types - probably a mistake, judging by other identifiers in this library, and probably never used in the library itself. It only shows that guys at mE are human .

The only way to avoid conflicts the way you envision is to enforce a stronger framework for naming libraries for these common and yet diverse libraries, and trying to coordinate ahead of time.

I'd use the word 'encourage' rather than 'enforce' , at least in regard to users (mE developers have it probably enforced by managers and those have it enforced by us, users ). Otherwise you may soon find no available user libraries .

Obviously, I have nothing against using good programming practices (also in naming of identifiers in libraries ) and I'd like to see them popularised on Libstock or anywhere possible. Let us just preserve some common sense and do not try to enforce something that's not possible to enforce. This isn't a new problem and good solutions were worked-out decades ago. There are much bigger communities of programmers that somehow manage to distribute libraries without any 'normalising bodies'.

Seriously, the most important thing is a feedback between library author and it's users. As long as there's such a feedback, all problems may be solved. If there's no feedback, even best library will not survive passing of time. Same is true for our contact with mE - as long there's a strong feedback, compilers (and sometimes even official libs ) improve fast. (Unfortunately, there are signs of a worrying change in policy. Judging by latest anouncements, mE intends to separate beta testing process from general public . That didn't work well previously.)

There's an old saying: if architects built buildings the way programmers build programs, the first woodpecker to come along would destroy all civilization".

This saying is about professional programers , not hobbyists .