My attempt to use FAT
My attempt to use FAT
Since the standard FAT libraries are acting strangely, I thought I'd try Dany's Fat32 lib. I got this far:
Did I do anything wrong, or is this not quite ready?
Did I do anything wrong, or is this not quite ready?
If you know what you're doing, you're not learning anything.
Re: My attempt to use FAT
Hi, I see that the first error is
Can it be the case that in your project the mmc_Fat16 lib is still included (or some parts of it)?Identifier "Part" has been already declared in "__Lib_mmc_Fat16_Defs.mpas"
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Re: My attempt to use FAT
Yes. It isn't obvious that I have to scrub all the standard MMC_FAT libraries out.
I think I'll start a clean project with this, and see what happens.
I think I'll start a clean project with this, and see what happens.
If you know what you're doing, you're not learning anything.
Re: My attempt to use FAT
I created a new project, and got the same thing. What appears to be happening is that variables in this library conflict with variables in other libraries. When you turn all libraries off except the ones you need, the problem goes away. I can see that this is going to be a problem as Libstock proliferates. It's going to mean that certain libraries will be incompatible with others, and you won't be able to use both in a program.
If you know what you're doing, you're not learning anything.
Re: My attempt to use FAT
It's time for mikroElektronika to allow two routines with the same name, from different libraries to be compiled in the same project. This would solve many problems. However, this would make the compiler more Delphi like.LGR wrote:When you turn all libraries off except the ones you need, the problem goes away. I can see that this is going to be a problem as Libstock proliferates. It's going to mean that certain libraries will be incompatible with others, and you won't be able to use both in a program.
Re: My attempt to use FAT
Well, mutually exclusive libs may in principle have same variable/procedure/function names. One hardly expects them both included in one project.LGR wrote:What appears to be happening is that variables in this library conflict with variables in other libraries. When you turn all libraries off except the ones you need, the problem goes away. I can see that this is going to be a problem as Libstock proliferates. It's going to mean that certain libraries will be incompatible with others, and you won't be able to use both in a program.
On the other hand, it's certainly good practice to use unique names in libraries and Libstock may need a page dedicated to some instructions for library developers.
Maybe I'm wrong, but, excluding overloading, something like that may be possible only in object oriented language. (Not that I would mind procedure/function overloading in mP .)VCC wrote:It's time for mikroElektronika to allow two routines with the same name, from different libraries to be compiled in the same project.
Re: My attempt to use FAT
The problem is, they weren't necessarily mutually exclusive libraries, and the conflicts weren't all over procedures. One of the conflicts was over a variable named "Max", and it wasn't in the FAT package, it was in the dependent package "StrngUtils". When we start building libraries upon dependent libraries, the possibility for conflicts goes up dramatically, because you're forced to use several libraries.
This is a really stupid question, but wasn't the Package Manager supposed to handle compiled modules without source code, so these kinds of conflicts won't matter?
This is a really stupid question, but wasn't the Package Manager supposed to handle compiled modules without source code, so these kinds of conflicts won't matter?
If you know what you're doing, you're not learning anything.
Re: My attempt to use FAT
Whether source code is available or not, rules are the same - compiler has no way to choose between identically named variables or routines, so it has to indicate conflict.
Re: My attempt to use FAT
If it's a compiled object file, the internal variable and procedure names don't need to exist anymore. The only things that need to remain are the names of the library procedures.
Let me put it another way - if the linker is using procedure names, and more than one procedure of that name is available, they probably need to generate a meta-identifier with the library name in it to distinguish between the two. You'll end up with something like directory names.
How do open-source developers of large projects handle this issue? Without pre-coordination, this problem is bound to surface.
Let me put it another way - if the linker is using procedure names, and more than one procedure of that name is available, they probably need to generate a meta-identifier with the library name in it to distinguish between the two. You'll end up with something like directory names.
How do open-source developers of large projects handle this issue? Without pre-coordination, this problem is bound to surface.
If you know what you're doing, you're not learning anything.
Re: My attempt to use FAT
There is a way. If you have somewhere in a unit (e.g. MyUnit) something like:janni wrote:compiler has no way to choose between identically named variables or routines, so it has to indicate conflict.
Code: Select all
Uses Unit1, Unit2;
Code: Select all
Unit2.MyProc;
Code: Select all
Unit1.MyProc;
Re: My attempt to use FAT
It's not internal naming that's a problem here - without additional rules compiler simply has no way to guess programmers intentions.LGR wrote:Let me put it another way - if the linker is using procedure names, and more than one procedure of that name is available, they probably need to generate a meta-identifier with the library name in it to distinguish between the two. You'll end up with something like directory names.
Mostly using unique names . Common rule is to use library name (unit name, or any other name reflecting the task performed) as a prefix or part of name. Naturally only public (global) types/routines/variables/objects need unique names.How do open-source developers of large projects handle this issue?
Yes, indeed, I've forgotten about similar solution in Delphi. Still, this may be a solution for compiler developers, but I'm not sure it's good for programmers. Just too easy to make mistakes.VCC wrote:There is a way. If you have somewhere in a unit (e.g. MyUnit) something like:and both Unit1 and Unit2 export a routine, let's say, MyProc. If you call MyProc within MyUnit, the compiler should consider the first one, that is the MyProc from Unit1 because it is written first in the uses clause. To call the MyProc from Unit2, the user should call itCode: Select all
Uses Unit1, Unit2;
Code: Select all
Unit2.MyProc;
It must have always seemed a bad programming practice to me as I do not recall ever (conciously ) using such possibility with Delphi (after all it's not so hard to use unique names). To make things more ambiguous, while in Delphi the last unit from the list is regarded default, routines from initialisation sections are executed in order of units' appearance in the uses clause .
Re: My attempt to use FAT
Few late thoughts .
If there'll be enough requests from users, mE developers may introduce a mechanism that will discern between identically named variables/routines/types from different units and let compiler choose automatically one over the others. But what then?
Lets imagine two not-so-well-documented (a norm, I'm afraid) libraries used together. How will the user of these know that there was a conflict and which routine is actually executed, or which global variable used? Probably only while painstakingly debugging wrongly behaving code .
I do not think that the problem highlighted by LGR may be solved in any other way than by educating those from us that write libraries. I'm certain that most of those will gladly correct their libs when asked to, but it would be easier to give them some guidelines and what better place for these as Libstock?
If there'll be enough requests from users, mE developers may introduce a mechanism that will discern between identically named variables/routines/types from different units and let compiler choose automatically one over the others. But what then?
Lets imagine two not-so-well-documented (a norm, I'm afraid) libraries used together. How will the user of these know that there was a conflict and which routine is actually executed, or which global variable used? Probably only while painstakingly debugging wrongly behaving code .
I do not think that the problem highlighted by LGR may be solved in any other way than by educating those from us that write libraries. I'm certain that most of those will gladly correct their libs when asked to, but it would be easier to give them some guidelines and what better place for these as Libstock?
Re: My attempt to use FAT
It might be possible for the compiler to search all libraries and point out multiple instances, which is better than what happens now. But then the user is still at a loss for what to do, especially when the conflict is between dependent libraries, and the user isn't even aware of the dependencies.If there'll be enough requests from users, mE developers may introduce a mechanism that will discern between identically named variables/routines/types from different units and let compiler choose automatically one over the others. But what then?
Maybe a better idea would be for Package Manager to be in contact over the internet with an mE global identifier database, and won't let the developer create a package if some other registered package has already claimed it. Identifiers would be allowed on a "first come, first serve" basis.
If you know what you're doing, you're not learning anything.
Re: My attempt to use FAT
janni wrote:Lets imagine two not-so-well-documented (a norm, I'm afraid) libraries used together. How will the user of these know that there was a conflict and which routine is actually executed, or which global variable used?
Yes, the compiler should point out that there are conflicts, but should not treat them as such. It should only constrain the user to choose a particular routine like Unit1.MyProc or Unit2.MyProc and not simply MyProc as I said in my previous post.LGR wrote:It might be possible for the compiler to search all libraries and point out multiple instances, which is better than what happens now.
Re: My attempt to use FAT
This would cover only a part of the problem . Identical identifiers conflict, like in the case spotted by LGR, may concern dissimilar objects - moreover, these identifiers may be inaccessible from outside of a library. I'm afraid that care in choosing unique names cannot be replaced by a set of smart rules for compiler.