Re: [fpc-devel] Sets > 256
2015-10-15 16:14 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > > On Thu, 15 Oct 2015, Frederic Da Vitoria wrote: > > 2015-10-15 14:58 GMT+02:00 DaWorm <daw...@gmail.com>: >> >> On Wed, Oct 14, 2015 at 5:36 AM, Michael Schnell <mschn...@lumino.de> >>> wrote: >>> >>> (Not hitchhiking the other thread...) >>>> >>>> On 13/10/15 19:59, Mohsen wrote: >>>> >>>> >>>>> Pascal sets can only contain values/enumerations whose ordinal value is >>>>> <= 255. >>>>> >>>>> As currently new language features are discussed I would vote to drop >>>> (or >>>> relax to some K ) this limitation. This would not break any existing >>>> code. >>>> >>>> >>>> What if someone is storing a set in a file, or a stream? Old version >>> saves it, new version reads it, and all of the sudden the data isn't in >>> the >>> same format. >>> >>> >> Yes, this would be a problem. But wouldn't this be an acceptable price for >> the improvement? >> > > No, it is not that simple. Lazarus would stop working completely. > Would you care to explain? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sets > 256
2015-10-15 14:58 GMT+02:00 DaWorm <daw...@gmail.com>: > On Wed, Oct 14, 2015 at 5:36 AM, Michael Schnell <mschn...@lumino.de> > wrote: > >> (Not hitchhiking the other thread...) >> >> On 13/10/15 19:59, Mohsen wrote: >> >>> >>> Pascal sets can only contain values/enumerations whose ordinal value is >>> <= 255. >>> >> As currently new language features are discussed I would vote to drop (or >> relax to some K ) this limitation. This would not break any existing code. >> >> > What if someone is storing a set in a file, or a stream? Old version > saves it, new version reads it, and all of the sudden the data isn't in the > same format. > Yes, this would be a problem. But wouldn't this be an acceptable price for the improvement? After all, similar things happen with integers, which don't always mean the same thing, reals which changed format at least once in TP/Delphi's history, strings... Sure, we could stick with 256 elements sets, 16 bits integers, 255 characters strings, but we'd lose a lot of possibilities, wouldn't we? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-23 11:45 GMT+02:00 Michael Schnell mschn...@lumino.de: On 07/22/2015 11:21 PM, Frederic Da Vitoria wrote: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. ??? ANSI C is a Declare before use language, too. Ah yes, I was referring to old C syntax. I so much hated it that I never looked back into it since. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
2015-07-22 20:20 GMT+02:00 Paul van Helden p...@planetgis.co.za: I have never managed to understand why declare before use is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something Pascal, I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first. Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. But declare before use is also part of the Pascal philosophy. Pascal tries to prevent you from programming by just throwing in some straws, some nails and a bit of wire when needed. Pascal was designed so that you have to plan first and code only when your plans are ready. If you want to do quick and dirty programming (I agree doing complete plans before would sometimes be overkill), then use a scripting language. Of course, other 3rd gen languages also allow you to do completely structured programming, but Pascal was created to push users to do it. There is a joke about Pascal that Pascal is so coercive about good programming that you could program in Pascal for years and still not learn how to program correctly. Hmm, maybe this is not entirely a joke :-) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] French Translation
2015-04-13 19:04 GMT+02:00 Stéphane Aulery saul...@free.fr: Hello, Le lundi 13 avril 2015 à 09:37:09, Tomas Hajny a écrit : On Sun, April 12, 2015 20:43, Stéphane Aulery wrote: Je souhaiterais faire des mises à jour de la traduction française des message du compilateur FreePascal et Michael Van Canneyt m'a dirigé vers vous. Est-ce possible ? Quel est sont état ? L'encodage du fichier compiler/msg/errorf.msg est-il bien cp850 (ou Windows-1252 peut-être) ? J'ai trouvé cette page pour m'aidé: http://wiki.freepascal.org/Localization Please note that English shall be used when sending messages to the mailing list fpc-devel. Ok. Rough and brief translation for those not understanding French - Mr. Aulery is interested in updating the French message file and asks about the current state. There are two files for French right now - one in codepage 850 (errorf.msg), the other in ISO 8859-1 (errorfi.msg). Judging from their size (and also the note about the corresponding SVN revision of the errore.msg source appearing only in one of them), the one in CP 850 is even more outdated than the one in ISO 8859-1. Obviously, it should be no problem to convert the content from one encoding to the other and back. As you might see in the comments at the top of errorfi.msg, the revision mentioned there as source of this translation is a very old one. Looking at SVN history of that file, some minor updates have been performed in it since then, but these were somewhat random. You should review and update also the already translated messages, because some of the English messages have changed since that old revision. You may use a diff tool to compare differences between the current trunk version of errore.msg and revision 4165 mentioned in the comments to find out which messages have been modified. Regarding the process - once you move forward and have some update ready, you can create a bug report and attach either a diff file or the newly updated version so that it does not get lost and may be reviewed by Pierre or someone else. If you need Thank you, you gave me all the necessary information. It only remains to translate. Regards Hello If Stéphane is feeling lonely, I can lend a hand :-) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
2014-11-26 16:54 GMT+01:00 Hans-Peter Diettrich drdiettri...@aol.com: 2) Formatted numbers, as enterd by the user (maybe by copypaste from other applications), can have various encodings. Before a conversion into binary values I'd remove all unexpected characters, except for the last (rightmost) '.' or ',', which then becomes the decimal separator as expected by the decoding function (RTL provided). You mean that the first string to be converted to binary would automatically set the decimal separator? That would seem dangerous to me. What if the first string to be converted contained something like 11,000, does this mean 11000 with thousand separator = comma (which would be true in at least USA), or 11 with decimal separator = comma (which would be true at least in France)? I can't think of any way to choose automatically. AFAICS, the code needs either to use the system settings or to be told explicitly by the developer. Even relying on the system settings may not be enough, because one may need to import data formatted with different national settings from the system's settings. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
2014-11-26 1:54 GMT+01:00 Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk: Marco van de Voort wrote: In our previous episode, Pierre Free Pascal said: I am surprised, for me, as French, I always believed that the French thousand separator is simply a space, what else should it be? A shift space. In utf8 that takes two bytes. How does that look when hand-written on a cheque? :-) Not much more different than an em dash from an en dash or a baseline dot from a raised dot. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
2014-11-26 9:47 GMT+01:00 Michael Schnell mschn...@lumino.de: On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote: How does that look when hand-written on a cheque? Supposedly this is a non-breaking space, that does not allow to be replaced by a line-break (nbsp; in HTML) Precisely. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
2014-11-25 17:21 GMT+01:00 Pierre Free Pascal pie...@freepascal.org: I am surprised, for me, as French, I always believed that the French thousand separator is simply a space, what else should it be? Not quite. It looks like a space, but: - you wouldn't like to see 2 000 € printed as: 2 000 € would you? - exact typography rules state that the exact space should be actually be a little thinner than a usual space. But I guess if it is as large, few people will complain. Search expace insécable on wikipedia.fr for more explanations. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multithreading under DOS (was: [Lazarus] Why development remains constant for msdos?)
2013/9/25 Tomas Hajny xhaj...@hajny.biz If the goal is writing multi-threaded applications for existing pure DOS machines, then using features of a special DR-DOS version may not be relevant at all, because it imposes a considerable additional restriction (it is not like that potential applications developed this way may be simply run under the existing installations, but users would need to install this particular version first). If the goal is running light-weight multi-threaded FPC-compiled applications on old/weak hardware using free operating systems (which may need to be installed to support this application - as it would be the case with DR-DOS too), then there are probably better options (e.g. some fine-tuned Linux distribution). If the goal is converting previously existing TP/BP applications written for DOS to become multi-threaded, porting to a different target is probably still easier, because the multi-threaded design will require changes to the application anyway. If the fpc application is completely alone, you are probably right (although you should also take into account learning linux, which may not be easy for everybody). But the fpc application could be part of an existing set of applications, in which case changing the OS could be impossible. This is a purely theoretical observation, I haven't developed for PC/MS-DOS or been using it for years. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel