Re: [fpc-pascal] dot within unit file name
Op Fri, 18 Jan 2008, schreef Bee: Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) I don't like that kind of attitude either. .Net is not crap as a whole, it does have some good features and ability. If some of them are really good, then why not implement some of them in FPC too? Agreed, but, many things in .NET interfere with how things work in Pascal. The .NET way of modular programming is totally different compared with the Pascal unit system, therefore it would function as an alien. What should be done is, that if the .NET namespace stuff provides advantages, the Pascal unit system should be logically extended to provide such functionality, rather than duplicate the .NET way of modular programming. Like FPC supports the ugly '+=' C syntax. :-P Maybe it's a good feature for some 'lazy' programmers, but I personally don't like it. However, I'm not against it, because FPC doesn't force me to use that syntax. It's just a 'nice' feature to please some people. ;) I think this feature is mainly there for historical reasons. Long ago someone wanted the feature and did provide a patch. It was made disabled by default because of uglyness. This is how things work in open source, if you write code, a lot is possible. But, I never encounter code that uses this feature; it is the perfect example of how adding syntactic sugar can help the needs of just one man. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:35, Bee wrote: Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) I don't like that kind of attitude either. .Net is not crap as a whole, it does have some good features and ability. Yeah, right. Nothing of that is new. It just wasn't hyped and backed by a big $ company before. If some of them are really good, then why not implement some of them in FPC too? *If*, yes. Don't get me wrong, I am not against this syntax (on the contrary, I'm even a strong supporter for easily extensible units), but I am against the (so far) suggested semantics. Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:16, Michael Fuchs wrote: Vinzent Hoefler schrieb: I think more interesting are dots in unit name for making better namespaces. Actually, I'm thinking child units. You mean like in Ada? Yes, this would be great. Are there any plans to implement this in future versions? Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:17, Matt Emson wrote: Vinzent Hoefler wrote: But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered. No problem, I just didn't get that from the glib you should learn how to program reply. That's not what I said. If at all I said you should learn how to engineer software. That's quite a difference. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Fri, 18 Jan 2008, Bee wrote: For clarity: I am not against this dot by itself. I can only assure you, if implemented, that it will not end up in 2.2.2. As for implementing this feature: this is not so trivial as one might think. 1. The parser needs changing. That's probably the easy part. 2. Symbol lookups need changing. This is the hard part, because you must be able to handle correctly unitname.identifier.identifier2.identifier3 It doesn't take a lot of intelligence to see that if unitname can containe one (or more) dots, this mechanism becomes suddenly a lot harder because your unitname may, by accident, match unitname.identifier1 of a symbol in another unit. And doing all this in a way that doesn't change current behaviour... Not something you can do in a day, if you ask me. Maybe it is a good time for me to learn fpc compiler codes now. I never look inside them before, just the RTL and FCL. :-D Can you show me which files I need to look and learn in order to have this feature? TIA. I'm not an expert, the compiler is not my domain, but: parser is in parser.pas sym*.pas files contain the symbol handling. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Agreed, but, many things in .NET interfere with how things work in Pascal. The .NET way of modular programming is totally different compared with the Pascal unit system, therefore it would function as an alien. I came from Delphi (my last Delphi is the Turbo Delphi) before I switch totally to FPC/Laz and Ubuntu. I must admit that Delphi way of thinking still affects me. I even still use it since FPC has very well compatibility with Delphi in Delphi mode. Though I don't intend to use dot as namespace, but I disagree if it is totally an alien to pascal. Delphi does it very well on this. This fact alone is enough to show that pascal is quiet friendly to dot namespace. So, why FPC can't? At least by supporting it in Delphi mode. What should be done is, that if the .NET namespace stuff provides advantages, the Pascal unit system should be logically extended to provide such functionality, rather than duplicate the .NET way of modular programming. I don't use .Net, but supporting Delphi dot namespace doesn't need to stop providing other functionality. Ideally, we should able to provide them both, the Delphi way and the FPC way. Both are the most used pascal compiler nowadays. ;) But, I never encounter code that uses this feature; it is the perfect example of how adding syntactic sugar can help the needs of just one man. You never encounter it doesn't mean it never been used or it's only used by one man. ;) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Jan 18, 2008, at 12:16 PM, Bee wrote: And yes, I'd like to have implemented that (child units) in FPC. What is child unit? http://www.adaic.com/docs/95style/html/sec_4/4-1-1.html -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
And yes, I'd like to have implemented that (child units) in FPC. What is child unit? But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered. It's alright. I can learn a new habit to use underscore instead of dot since today. Yes, bad habits die hard! :-D It just looks cool to see my unit like this: bee.buttons.myfancybutton; :-D -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Vinzent Hoefler schrieb: I think more interesting are dots in unit name for making better namespaces. Actually, I'm thinking child units. You mean like in Ada? Yes, this would be great. Are there any plans to implement this in future versions? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 11:44, ik wrote: Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language... Think records. If you can have unit.identifier.record_field ad infinitum (any record may contain another record), it's not too far fetched to extend that concept to unit.sub_unit. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ncurses extra package
On Fri, 18 Jan 2008, Guillermo Martínez Jiménez wrote: Hello everybody. Recently I asked myself if Free Pascal has support for ncurses and I've found it as an extra package. I've take a peek at the ncurses.pp file and I've found it uses a lot of external functions. That means this package will not compile on platforms that haven't a previous ncurses implementation (NDS, GP32/2X, etc.). I think if the ncurses package uses the RTL (Crt, keyboard, gpm, etc.) it would be more portable, if the platform can't support Crt, keyboard, mouse, etc. they can be emulated. Then I decided to write my own ncurses.pp alternative using only the RTL. I will not claim official declaration or support, and may be it will not be so complete and successful as Michael Van Canneyt's implementation, but any comment or advice will be welcome. To be clear: The point of the ncurses package in FPC is to allow you to use the official ncurses library. It does not implement any functionality by itself, it is just a translation of the C header files to pascal. Writing your own pascal-only ncurses is of course something that can be done, but this is a different goal... Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 11:48, Michael Fuchs wrote: Bee schrieb: Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? I think more interesting are dots in unit name for making better namespaces. Actually, I'm thinking child units. Namespaces don't even have the appropriate scoping rules. The Java language's package is a perfect example for that: No matter where you put the class, it only sees it's own package. There they missed a perfect opportunity to enforce scoping rules with the compiler instead of letting the programmer decide it all over again just like they did back in the 70s, where all programs were written in FORTRAN and never crossed the 1023 lines of code boundary. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Jan 18, 2008, at 11:16 AM, Bee wrote: Hi all, Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? I think the dot is used in the grammar. for example : unit foo; interface procedure Print; implementation [...] end. You want to be able to call foo.Print; and you can not make the difference between a dot for the filename and a dot as a separator. Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them both. TIA. -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Fri, 18 Jan 2008, Bee wrote: Use an underscore. Ok, I need to learn a new habit then. I can live with that. Thanks, Michael. :) For clarity: I am not against this dot by itself. I can only assure you, if implemented, that it will not end up in 2.2.2. As for implementing this feature: this is not so trivial as one might think. 1. The parser needs changing. That's probably the easy part. 2. Symbol lookups need changing. This is the hard part, because you must be able to handle correctly unitname.identifier.identifier2.identifier3 It doesn't take a lot of intelligence to see that if unitname can containe one (or more) dots, this mechanism becomes suddenly a lot harder because your unitname may, by accident, match unitname.identifier1 of a symbol in another unit. And doing all this in a way that doesn't change current behaviour... Not something you can do in a day, if you ask me. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language... Feature is feature, you may use it, if you like, you may not, if you don't. Doesn't need to make yourself got complicated. ;) It's like the '='. It does not always mean 'equal' as you have to use it on type declaration *and* comparison. It's like the 'end'. It does not always need to have 'begin' since 'case' and 'try' can also have an 'end'. Etc. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:01, Matt Emson wrote: Vinzent Hoefler wrote: On Friday 18 January 2008 11:39, Bee wrote: I used to use this feature on Turbo Delphi Explorer. But since I totally switch to FPC/Laz and Ubuntu, I really missed this feature on FPC. :( No offense, but maybe this is a good time to start becoming a serious developer now? I think you are missing the point. No, I don't. Bee may indeed be misguided, but the feature is in Delphi[.Net] in general. Screw Delphi. That feature was in ISO-standardized Ada back in 1995 already. And there it's called child units. Name spaces have too flat scoping rules to be really useful. And yes, I'd like to have implemented that (child units) in FPC. But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Bee schrieb: Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? I think more interesting are dots in unit name for making better namespaces. If I have a class called TSpecialButton, I want a unit name like Michael.GUI.Buttons.TSpecialButton. Or is there an other way to make namespaces like this? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Jan 18, 2008 12:34 PM, Bee [EMAIL PROTECTED] wrote: Probably not. And if at all, it wouldn't accomplish what you want to do. If someone would provide a patch for this, is it gonna be accepted? If not, may I know what the reason(s)? ;) unit_name.function () ... ... How would you coap with this situation if you'll have . inside ? You can translate it into _, yes, or you can just use underscore at the file name at the first place... Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language... Then use the branch/switch feature of your favourite version control system. That's one thing it was designed for. For some reasons, sometimes version control is too bloated, especially when the project is not too big. Nevertheless, it's the easiest way to have manual version control. :D -Bee- has Bee.ography at: http://beeography.wordpress.com Ido -- http://ik.homelinux.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] ncurses extra package
Hello everybody. Recently I asked myself if Free Pascal has support for ncurses and I've found it as an extra package. I've take a peek at the ncurses.pp file and I've found it uses a lot of external functions. That means this package will not compile on platforms that haven't a previous ncurses implementation (NDS, GP32/2X, etc.). I think if the ncurses package uses the RTL (Crt, keyboard, gpm, etc.) it would be more portable, if the platform can't support Crt, keyboard, mouse, etc. they can be emulated. Then I decided to write my own ncurses.pp alternative using only the RTL. I will not claim official declaration or support, and may be it will not be so complete and successful as Michael Van Canneyt's implementation, but any comment or advice will be welcome. See you, Guillermo Ñuño Martínez ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Use an underscore. Ok, I need to learn a new habit then. I can live with that. Thanks, Michael. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Vinzent Hoefler wrote: On Friday 18 January 2008 11:39, Bee wrote: I used to use this feature on Turbo Delphi Explorer. But since I totally switch to FPC/Laz and Ubuntu, I really missed this feature on FPC. :( No offense, but maybe this is a good time to start becoming a serious developer now? I think you are missing the point. Bee may indeed be misguided, but the feature is in Delphi[.Net] in general. It is used to implement Namespaces - something sadly lacking in the FPC dialect of Pascal. Maybe it is time *you* embraced modern programming techniques? I, for one, would rate Namespaces over templates and generics. I use them daily. Give me partial classes too (i.e. OO modular design.) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Probably not. And if at all, it wouldn't accomplish what you want to do. If someone would provide a patch for this, is it gonna be accepted? If not, may I know what the reason(s)? ;) Then use the branch/switch feature of your favourite version control system. That's one thing it was designed for. For some reasons, sometimes version control is too bloated, especially when the project is not too big. Nevertheless, it's the easiest way to have manual version control. :D -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Fri, 18 Jan 2008, Bee wrote: Hi all, Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? No. Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them Use an underscore. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 11:16, Bee wrote: Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? Probably not. And if at all, it wouldn't accomplish what you want to do. Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them both. Then use the branch/switch feature of your favourite version control system. That's one thing it was designed for. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] dot within unit file name
Hi all, Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them both. TIA. -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
The more important: What would the user gain from it? I could gain my old bad habit again. LOL :-D So, as far as I am concerned, putting effort into the development of such flat namespaces - which, while enforced by the developer only, are already there, but using underscores instead of dots - gain zero points, so I would be against it. FPC core developers don't need to do this by themselves. Perhaps I'll do it to learn and understand fpc compiler codes, in my spare times of course. Just for learning, nothing serious. ;) I hope FPC will accept a patch for this feature if it is done. This is just too much effort for pure syntactic sugar. Sugar is sweet. Lots of people like sweet things. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) I don't like that kind of attitude either. .Net is not crap as a whole, it does have some good features and ability. If some of them are really good, then why not implement some of them in FPC too? Like FPC supports the ugly '+=' C syntax. :-P Maybe it's a good feature for some 'lazy' programmers, but I personally don't like it. However, I'm not against it, because FPC doesn't force me to use that syntax. It's just a 'nice' feature to please some people. ;) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: ncurses extra package
On Fri, 18 Jan 2008, Michael Van Canneyt wrote: CgpPbiBGcmksIDE4IEphbiAyMDA4LCBHdWlsbGVybW8gTWFydMOtbmV6IEppbcOpbmV6IHdyb3Rl OgoKPiBIZWxsbyBldmVyeWJvZHkuCj4gCj4gUmVjZW50bHkgSSBhc2tlZCBteXNlbGYgaWYgRnJl ... Er... Pardon? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Bee: Both compilers [CAN] use the UCSD Pascal unit system, I have added a missing word from that statement I think. which, as of today is still one of the best modular programming systems. That is the base to start from. No, no it is not one of the best modular programming systems. Not for OO related code. Love them or hate them, namespaces and partial classes are extremely useful.. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Op Fri, 18 Jan 2008, schreef Bee: I don't use .Net, but supporting Delphi dot namespace doesn't need to stop providing other functionality. Ideally, we should able to provide them both, the Delphi way and the FPC way. Both are the most used pascal compiler nowadays. ;) As far as I am concerned, there will be no two ways of doing things. It will only be confusing and makes the language needlessly baroque. Both compilers use the UCSD Pascal unit system, which, as of today is still one of the best modular programming systems. That is the base to start from. But, I never encounter code that uses this feature; it is the perfect example of how adding syntactic sugar can help the needs of just one man. You never encounter it doesn't mean it never been used or it's only used by one man. ;) But it does show such features are irrelevant to the project. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Van Canneyt schrieb: unit Blah; Namespace MyAPI.Blah; And how will you know which namespace is in what unit (or file) ? You then need a second structure mapping namespaces on filenames, making it slower, bulkier and error prone. The cure is worse than the disease, IMHO. You are right. The better way is unit MyAPI.Blah;. The Namespace is the unit name. g Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Vinzent Hoefler wrote: On Friday 18 January 2008 12:35, Bee wrote: Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort. And units are better because...? I would take Namespaces over the crippled '80's unit notation any day. Units come from an age when filenames were limited to 8.3 format. Yes, we now have longer unit names, but Namespaces give context if nothing else. Scoping is what you make of it. Java has Packages, C++ has Namespaces, C# has DotNet style Namespaces (not entirely the same thing.) I'd far rather have: uses Windows.Win32.Standard, Windows.Win32.Messages; than uses Windows, Messages; File names should have nothing to do with Namespaces too. I'd also love: unit Blah; Namespace MyAPI.Blah; interface type TTest = partial class //non GUI code end; implementation end. and then be allowed unit Blah.GUI; Namespace MyAPI.Blah; interface type TTest = partial class public //GUI code end; implementation end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Matt Emson wrote: What is the difference ? The second one saves on typing, which is a plus in my book ? Right.. confusion over verbosity. Given two units called Constants.pas, which one is the correct unit? Given a unit called Utils.pas and one called ExtraDefs.pas, both of which contain different implementations of the type TSocket, which is the correct unit to use? File names should have nothing to do with Namespaces too. I'd also love: unit Blah; Namespace MyAPI.Blah; And how will you know which namespace is in what unit (or file) ? Turning it on its head - file names should have nothing to do with unit names. The unit lives in a namespace, The namespace directive gives the path to the unit. so it would be: unit Blah; namespace MyAPI and uses MyAPI.Blah; You then need a second structure mapping namespaces on filenames, making it slower, bulkier and error prone. The cure is worse than the disease, IMHO Nope.. see above. Do you have a problem with partial classes? Also called Categories in Objective C. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Marco van de Voort wrote: Michael Fuchs wrote: But how can fpc find the unit which contains this namespace? I think better is: Namespace = unit name = file name It is easier to allow a dot in the unit name than writing code, which search all units for the right naemspace. The filename would be MyAPI.Blah.pas as you indicate. And if I import blah what would be imported? As far as I can see this is no real advantage, except allowing dots in unitnames No, you would import MyAPI.Blah... I would say, remove unit replace with Namespace and all would be fine. Thinking about it, the Chrome dialect is a better model. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Marco van de Voort wrote: However again, as far as I understand partial classes (Class Helpers in Delphi.NET), for this you need a registration system again because you need to compile all units that might use class X so that they auto import all units with classhelpers for unit X. (or you have to scan all directories on each compiler start, and must make 100% sure that you don't use units that don't have these class helpers added. Not really. In practice, you can compile a partial class without all of its parts and use it just fine. In the real world, this is extremely useful in sharing an engine between GUI systems (or a web application and a Console application) without pulling in specifics for the role implemented (GUI kits etc). It allows for a modular design (extensions at compile time.) It allows the programmer to create a flatter less complex hierarchy - e.g MVC in a single class, but with clear separation of responsibility. In C#, Vs2005 always buts all of the GUI generation code in to a partial class called XXX.Designer.cs. This is an extreme improvement over the Pascal way. An extention to this would be partial units (just invented this) which would allow the removal of the include files that dog FPC's RTL and support libs. All specific files could be organised in such a way that the include path found only the correct unit parts. Yes, this is all a pipe dream, but dreaming is fun sometimes ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
I think if sb would waste time on it, and the patch is good quality it might be added. Not because it is a good feature (afaik it is not), but out of Delphi compat. Good or bad is relative. FPC is about development tool, each user has he's own good or bad way of programming. The more features it has, the better for the users. As I said, feature is feature, users may use it or not, it's absolutely up to him. So, it's all about Delphi compatibility. :) Because how do you determine the difference b.a.c.d (field d of class c in unit b.a) and b.a.c.d (field d of class c in class a in unit b) I know nothing about compiler. But in my simple way of thinking, the compiler should remember unit list. - If b.a.c is declared within the uses clause then threat each b.a.c as a unit. - If then in the unit body there is a b class/record that has an a property/subrecord that has a c record variable then compiler should raise an ambiguous identifier error. - If compiler finds b.a.d then it raises unknown identifier error since there's no b.a.d unit is declared within uses clause. - If there is no b.a.c in uses clause than threat b as an identifier. Of course, this logic is far too simplified. :-D What does Delphi/win32 really do with that? Does it more than simply ignoring parts of the name, and if so, what exactly? Could you make an overview of this feature? I don't know how Delphi handle this internally. AFAIK, Delphi threats b.a.c as a unit if it's declared in the uses clause. Actually it is like the usual way Delphi threat units, but allows dot in the unit's file name. You can't use a.c and hope it will refers to b. Use it all or use none. CMIIW. I didn't touch my Delphi in the last 6 months, I can be wrong or forget the detail of this feature. Somebody please confirm this. And what is the use in your view? I don't need (yet) namespace or whatever that is as in Delphi 2007, I just want to use dot in my unit's file name. Second, for Delphi compatibility. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Matt Emson wrote: What is the difference ? The second one saves on typing, which is a plus in my book ? Right.. confusion over verbosity. Given two units called Constants.pas, which one is the correct unit? Give two the same classes in the same namespace, which one is chosen? Given a unit called Utils.pas and one called ExtraDefs.pas, both of which contain different implementations of the type TSocket, which is the correct unit to use? Utils.TSocket or ExtraDefs.TSocket. unit Blah; Namespace MyAPI.Blah; And how will you know which namespace is in what unit (or file) ? Turning it on its head - file names should have nothing to do with unit names. That means either that you must scan all files in all dirs to build your state, or must register een unit (cq class) before using it, so that the compiler can limit the space. (this registration system can be a directory structure, but IMHO is replacing a fixed filename with a fixed dirname is no solution either) This is exactly what the unit system was designed to avoid, central registries of units/classes. Under Java/.NET you need this because the JIT must be able to find them runtime too. With normal compilation this is a burden. unit Blah; namespace MyAPI uses MyAPI.Blah; And all this to avoid double unit names. Which is way less of a problem, since you have multiple classes in an unit (namespace) as a feature. You then need a second structure mapping namespaces on filenames, making it slower, bulkier and error prone. The cure is worse than the disease, IMHO Nope.. see above. Do you have a problem with partial classes? Also called Categories in Objective C. I don't like the concept, but for some workarounds it can be of some use in quick 'n dirty hacks. All in the case where you don't want to change libs as a temporary workaround (e.g. if they have to be revalidated with other apps then too) However again, as far as I understand partial classes (Class Helpers in Delphi.NET), for this you need a registration system again because you need to compile all units that might use class X so that they auto import all units with classhelpers for unit X. (or you have to scan all directories on each compiler start, and must make 100% sure that you don't use units that don't have these class helpers added. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) I don't like that kind of attitude either. .Net is not crap as a whole, it does have some good features and ability. If some of them are really good, then why not implement some of them in FPC too? I think if sb would waste time on it, and the patch is good quality it might be added. Not because it is a good feature (afaik it is not), but out of Delphi compat. But, maybe you could enlighten me, what is exactly the needed functionality ? Because how do you determine the difference b.a.c.d (field d of class c in unit b.a) and b.a.c.d (field d of class c in class a in unit b) What does Delphi/win32 really do with that? Does it more than simply ignoring parts of the name, and if so, what exactly? Could you make an overview of this feature? And what is the use in your view? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 14:06, Bee wrote: The more features it has, the better for the users. No. It's more like: The nice thing about standards is that you have so many to choose from. -- Andrew S. Tanenbaum (And yes, that was meant ironically.) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Jonas wrote: The magic word would be scope here. It's the same as with using two different units including the same identifier twice. Yes and no, of course it will work, but might be counterintuitive. uses x, a.b.c; a.b.c.d. if x also contains an identifier a. error : a.b.c.d identifier not found. (but a.b.c.d exists). We already print fully qualified identifiers in some error messages in case confusion is possible (e.g. unit1.type1 expected, but got unit2.type1). True, but this is different. To know the cause you have to search further than the first hit, not just detect a mismatch. PS: could you configure your mail client so it inserts an attribution line at the top? (it's hard to follow who wrote what) Phew. elmrc is not my favorite, but I'll try to look into it tomorrow ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Op Fri, 18 Jan 2008, schreef Michael Van Canneyt: On Fri, 18 Jan 2008, Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Michael Van Canneyt: To the user, it may appear as a bunch of dots. To the compiler, it doesn't know how to map the a.b.c.d: Well, with normal Pascal rules, you cannot declare a variable with the same name as a unit you use, because a unit is also an identifier. Most logical would be to reject the declaration of variable A in this case due to a duplicate identifier. No, because the unit identifier is a.b.c, not a. It has to be, otherwise units windows.messages and windows.records would both have identifier windows, leading to an error. You are right. In other words, .NET namespaces cannot be unified with normal scoping rules, meaning you would need a new set of scoping rules and mark the old ones legacy. Not acceptable. I have made my conclusion: No .NET namespaces and no dots in names. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Vinzent Hoefler: On Friday 18 January 2008 16:04, Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Michael Van Canneyt: To the user, it may appear as a bunch of dots. To the compiler, it doesn't know how to map the a.b.c.d: Well, with normal Pascal rules, you cannot declare a variable with the same name as a unit you use, because a unit is also an identifier. Most logical would be to reject the declaration of variable A in this case due to a duplicate identifier. No, because the unit identifier is a.b.c, not a. It has to be, otherwise units windows.messages and windows.records would both have identifier windows, leading to an error. Why? It would be in the uses clause, not in the declaration part. So it's not declaring the same identifier twice. Search for unit identifier in TP/Delphi books. uses x declares x as unit identififier in the symtable of the current program/unit. So, it is declared twice (with reason). Well, but at that time there would be no confusion between a Windows.Messages and Windows.Constants. Both have to be units at that point. Maybe my view is skewed too much by the use of Ada where even a function declares a record identifier. In Ada it is even possible to do: --- procedure Test is X : Integer; procedure B is X : Integer; begin X := 1; Test.X := 2; -- references X of Test procedure end B; begin X := 3; end Test; --- Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
On 1/18/08, Vinzent Höfler [EMAIL PROTECTED] wrote: On the other hand: uses a; var a:byte; ... both unit a as variable a would go into the global symtable, which is the same lexical level, thus causing duplicate identifier conflicts. In Ada the fully qualified name of the variable would be A.A here. I certainly see the problems for the (Pascal) compiler write here, but from a user's point of view this identifier is in no way different than SysUtils.Sleep. Ada really does have an extremely well-defined and flexible package/module system with the ability to define child packages, which are conceptually identical to nestes packages/units. But there are actually two keywords to handle modules and namespaces in Ada: with and use. When you with a module, you make it's identifiers accessible to the current file, but only in a qualified manner: you have to use dot notation for everything. So if you: with Unit_1; you have to use: Unit_1.foo; to access foo from Unit_1. If you try to access foo without the qualifier, you get compile errors because foo is unkown, only Unit_1.foo is known. However, you can also do: with Unit_1; use Unit_1; This imports the namespace of Unit_1 into the current file so that now you *can* refernce foo without a qualifier. It's as if all the identifiers in Unit_1 were defined in the current file (and so yes, you can get conflicts). To accomplish the same type module system that Ada has would require at least another keyword (e.g. with) in addition to uses, and the grammar would have to allow defining nested/child units. But then Pascal would basically become Ada95. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
On Fri, 18 Jan 2008, Vinzent Hoefler wrote: On Friday 18 January 2008 15:19, Michael Van Canneyt wrote: I saw this week a CodeGear Guy in a cg ng talking about that. In Win32 its is Just dots in the name, nothing else. If he said that, he is totally braindead and doesn't have a clue about what he is talking. Well, the discussion and explanation that have been provided so far, back up that braindead guy's statement. Of course not: tell me, what does a.b.c.d mean if you have a record a with field b, and you have a uses a.b.c in your uses clause ? so unit a.b.c; interface Var D : Integer; implementation end. and then: unit test; interface uses a.b.c; Type T = record b : integer; end; Implementation var A : T; begin A.b.c.d:=3;// ??? end. To the user, it may appear as a bunch of dots. To the compiler, it doesn't know how to map the a.b.c.d: 1. Scoping rules dictate that the first match is the variable a. So, it finds a as a variable. 2. then it finds b in the fields of T. OK, it's on the right track! 3. But then it looks for C, but doesn't find it - error, what now ? nevertheless (a.b.c).d would be a correct reference to integer d in unit a.b.c (the brackets serve just to make a point, they are not real notation). So, what to do ? Throw an error, or set d in unit a.b.c. ? And what about searching for (a).b.c.d and (a.b).c.d ? What combinations of dots and brackets must be tried ? (namespaces could also be a and a.b) Maybe someone with delphi for .net available can run the above test ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 14:56, Matt Emson wrote: I would say, remove unit replace with Namespace and all would be fine. And the same as before, just with a different syntax. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Vinzent Höfler: Maybe my view is skewed too much by the use of Ada where even a function declares a record identifier. In Ada it is even possible to do: --- procedure Test is X : Integer; procedure B is X : Integer; begin X := 1; Test.X := 2; -- references X of Test procedure end B; begin X := 3; end Test; --- There is fundamental problem which such a construct even using normal Pascal scoping rules. The identifier test in this case, is in the symtable of procedure B, which is a deeper lexical level, thus can hide global identifiers. Yes. That's precisely why in Ada you have to write Test.X to go up that lexical level. The hiding happens here, too - but you have the possibility to explicitely override it. (Let's put aside the fact, that such constructs are usually bad coding style.) On the other hand: uses a; var a:byte; ... both unit a as variable a would go into the global symtable, which is the same lexical level, thus causing duplicate identifier conflicts. In Ada the fully qualified name of the variable would be A.A here. I certainly see the problems for the (Pascal) compiler write here, but from a user's point of view this identifier is in no way different than SysUtils.Sleep. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Michael Van Canneyt wrote: You are wrong. It does not compile, neither in delphi, nor in FPC. D is not found, because 'A' resolves to the local a, and then the search is stopped. Ok, I think I got it. It's probably the same reason why in --- procedure Foo (const A : My_Type); overload; procedure Foo (const B : Some_Type); overload; procedure Bar; var A : My_Type; B : Some_Type; begin Foo (A); // works Foo (B); // works end; procedure Foobar; // declare Another_Type locally procedure Foo (const C : Another_Type); begin ... end; var A : My_Type; C : Another_Type; begin Foo (C); // works Foo (A); // wrong type! end; --- the last call does not work (unless I write unitname.Foo (A) there). BTW, the same happens with overloaded methods in classes when I try to extend the class: The overloaded methods of the parent class are suddenly not available anymore once I declare another overloaded method. This actually happened to me when I tried to extend the XMLConfig class for Double types. Once I declared SetValue (Double) in the derived class, I would have needed typecasts to access SetValue (Integer) and SetValue (String) in virtually every call. The other solution would have been to redeclare the overloaded methods in the derived class, I guess. Well, writing about all that, I come to the conclusion that the Pascal scoping rules can really suck from time to time. ;) No plan to change that, though, I suppose? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 13:22, Matt Emson wrote: Vinzent Hoefler wrote: On Friday 18 January 2008 12:35, Bee wrote: Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort. And units are better because...? *Child* units are better, because they provide both _compiler checked_ namespaces and clearly defined visibility rules. Namespaces don't. Namespaces are ugly C++ hacks from the time where the only namespace lied in the hope that a 6 letter identifier (where the first 2 letters were the initials of the programmer, two digits the project number and with the remaining two significant characters freely available to the programmer with the first one required to be an underscore[1]) would still link with the third party library from the vendor without having duplicate symbols to resolve. Vinzent. [1] All this naming convention may sound like a joke. Actually, it isn't.[2] [2] It may be a bit exaggerated, though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ncurses extra package
On Fri, 2008-01-18 at 12:02 +0100, Guillermo Martínez Jiménez wrote: Hello everybody. Recently I asked myself if Free Pascal has support for ncurses and I've found it as an extra package. There is also an ncrt unit. If all your looking at is the ability to run the program on different terminals this might be the ticket. This unit implements all the crt functionality but uses ncurses as the back end. Anthony I've take a peek at the ncurses.pp file and I've found it uses a lot of external functions. That means this package will not compile on platforms that haven't a previous ncurses implementation (NDS, GP32/2X, etc.). I think if the ncurses package uses the RTL (Crt, keyboard, gpm, etc.) it would be more portable, if the platform can't support Crt, keyboard, mouse, etc. they can be emulated. Then I decided to write my own ncurses.pp alternative using only the RTL. I will not claim official declaration or support, and may be it will not be so complete and successful as Michael Van Canneyt's implementation, but any comment or advice will be welcome. See you, Guillermo Ñuño Martínez ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing ROM BIOS Font in Linux.
On Thu, 2008-01-17 at 11:47 +0100, Michael Van Canneyt wrote: On Thu, 17 Jan 2008, Vinzent Hoefler wrote: On Thursday 17 January 2008 01:27, [EMAIL PROTECTED] wrote: The question. Is this font accessible from linux; do I have to be root ? Yes. Yes. /dev/mem should be the raw memory device (where even the BIOS image can be read from), but this device which is only accessible to root. But you cannot use this font to write to the screen directly ? Actually, I read the font and drew to the screen. :) I first used this to make Banners in Text Mode out of the Letters themselves. (A was made out of A, B or B's etc...). At one time I almost completed a set of 256 color 2d graphics primitives in Pascal and assembler. I used the BIOS font in my OutTextXY procedure. I just remembered where I had some of the code this morning. http://home.comcast.net/~anthonyh63/mysoftware/vesa.zip These routines are not complete and are mostly useless today. (Real mode DOS.) The routines in question are in WRITETXT.SRC which was used as an include file rather then a unit. Include files were a habit I picked up from programming with Turbo 3.0 even though this work was done under Turbo 6. :) Upon rereading the source I had forgotten you also had to make a BIOS call to get the address though it returned an identical address for most BIOS's. (If memory serves). Thanks to everyone who answered. I'm checking the Linux newsgroups now to see if there is a way to hack a BIOS call under Linux but I don't have a lot of hope :) (rightfully so, people shouldn't make direct BIOS calls in an application now.) I'll probably end up linking a binary font into the program. Anthony. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Fuchs wrote: But how can fpc find the unit which contains this namespace? I think better is: Namespace = unit name = file name It is easier to allow a dot in the unit name than writing code, which search all units for the right naemspace. The filename would be MyAPI.Blah.pas as you indicate. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RES: [fpc-pascal] dot within unit file name
Op Fri, 18 Jan 2008, schreef Vinzent Höfler: Maybe my view is skewed too much by the use of Ada where even a function declares a record identifier. In Ada it is even possible to do: --- procedure Test is X : Integer; procedure B is X : Integer; begin X := 1; Test.X := 2; -- references X of Test procedure end B; begin X := 3; end Test; --- There is fundamental problem which such a construct even using normal Pascal scoping rules. The identifier test in this case, is in the symtable of procedure B, which is a deeper lexical level, thus can hide global identifiers. On the other hand: uses a; var a:byte; ... both unit a as variable a would go into the global symtable, which is the same lexical level, thus causing duplicate identifier conflicts. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ncurses extra package
Recently I asked myself if Free Pascal has support for ncurses and I've found it as an extra package. I've take a peek at the ncurses.pp file and I've found it uses a lot of external functions. That means this package will not compile on platforms that haven't a previous ncurses implementation (NDS, GP32/2X, etc.). I think if the ncurses package uses the RTL (Crt, keyboard, gpm, etc.) it would be more portable, if the platform can't support Crt, keyboard, mouse, etc. they can be emulated. Then I decided to write my own ncurses.pp alternative using only the RTL. I will not claim official declaration or support, and may be it will not be so complete and successful as Michael Van Canneyt's implementation, but any comment or advice will be welcome. Ncurses is mostly added from a so that we have at least something on Unix perspective. Not so much as crossplatform solution, since the concepts of NCurses are a bit Unix centric. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing ROM BIOS Font in Linux.
On Thu, 2008-01-17 at 15:32 +, Mark Morgan Lloyd wrote: Michael Van Canneyt wrote: The question. Is this font accessible from linux; do I have to be root ?How do I make the 16 bit segment/offset address into a 32 bit pointer to access these fonts ? This font is not accessible. Linux does not allow direct hardware access unless you write a device driver. What exactly are you trying to do- read the pixels that make up the BIOS fount so that you can plot them as blocks in a text- or graphics-mode session? Yes... I've done this in the past... (late 80's early 90's :) I'd have thought it would be better practice to store a fount file as constant data (possibly a resource) inside the program- there's plenty of fount editors etc. available from DOS days. Your completely right. I still think like a DOS programmer sometimes. (Keeping program code small..). I was actually thinking of using it as fall back font. (Font files missing). It was going to be graphics mode programming. I think if I follow through with this project then converting a Bit Font to an Array Constant is really the way to go. I really don't have to worry about the few Kilobytes it will add to the program file :). Anyone know any good GPL'd or Public Domain bit fonts ? Anthony ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
If you request for features please come up with something realistic and also provide good information how it then should work. E.g. provide grammar how the syntax and semantics work. And if it is for compatibility you should also be able to provide real pascal examples that show how ambigious constructs are handled by Delphi. So please answer first the question that Marco already wrote before continueing other discussions about this topic: Take as example the reference to a.b.c.d. - Can someone provide the grammar how an identifier looks like in Delphi? - How shall the compiler detect that a.b is an unit if a is also defined as a record that doesn't contain a field b? - How shall the compiler handle if a.b.c is an unit and a.b.c is class? So please come with a design instead of just asking give me this feature in one line. Because if the feature was really important and simple it was for sure already implemented. The left over features are therefor not in the category simple anymore. Also important is debatable because we've already lived without them for years. Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Fuchs wrote: But how can fpc find the unit which contains this namespace? I think better is: Namespace = unit name = file name It is easier to allow a dot in the unit name than writing code, which search all units for the right naemspace. The filename would be MyAPI.Blah.pas as you indicate. And if I import blah what would be imported? As far as I can see this is no real advantage, except allowing dots in unitnames. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] beginner in pascal for Mac
[EMAIL PROTECTED] wrote: Damien Gerard wrote: On Jan 15, 2008, at 11:54 AM, Ezequiel Tacsir wrote: I was used to wok with freepascal on windows. Now, I have switch to mac (10.5) and would like to know what are the things that I need to have it running. If anybody can send me a basic tutorial for installation, running and so on, I will be delighted. Using FPC on a mac is really easy if you are comfortable with Terminal and I use it every days. After that, I don't know, my Vim is for me really really more efficient that any text editor :) Installation is easy. You need to install the developer tools (Xcode, but the GCC linker is the important thing), but both the Xcode and FPC installers are Mac standard installers, no trouble. (Perhaps the best feature with the Mac is the excellent installation systems.) After installing Xcode, you can trash the entire Developer folder if you don't want the applications (freeing up most of the disk space). The important things are installed in /usr/local, which is only visible from the Terminal. If command-line work is all you want, the Terminal is what you want. Plus a text editor. Nobody (?) does text editing on the command line any more, but there are plenty of nice text editor to choose from. When fed up with command-line compilations, you can consider two IDE options: Xcode (with plug-ins) or Lightweight IDE. I wrote Lightweight IDE myself after giving up Xcode and found myself back at the command-line. /Ingemar ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
