Re: [fpc-other] [fpc-pascal] FPC Graphics options?
Am 2017-05-24 um 15:28 schrieb Karoly Balogh (Charlie/SGR): > Strings are a library feature, with syntax sugar on top of it. Nothing > stops you to implement Pascal-alike strings in C, minus the syntax sugar. > In fact I'm willing to bet, there are some libs out there already, ready > to be used. In fact, see what someone wrote about UTF-8 later in the > thread, pretty sure you can just pull in an UTF-8 string library in your > project and run with it... Then why hasn't it been added to the C language definition yet? At Turbo Pascal times I also added routines for variable length arrays but because of getmem etc. I lost range checking etc. It was an ugly hack (nevertheless the only way to handle such arrays at that time). Now with dynamic arrays I am so much happier. Why weren't such things added to C decades ago? Strange. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
Am 2017-05-24 um 15:44 schrieb Karoly Balogh (Charlie/SGR): > OK, this is also beautiful, thanks again. :) BSDs seem to have strlcpy() > tho', which works around both defects mentioned here, but that's non > standard obviously, because who needs standard functions which make sense. > :) Yes, and there is still a lot of very old C code used in programs and libraries that was written with strcpy and I doubt that someone will change all theses occurences at any time. Why should it be changed? It works! ;-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
Am 2017-05-24 um 14:02 schrieb wkitt...@windstream.net: > On 05/24/2017 12:54 AM, Ralf Quint wrote: >> Well, the problem is that you can't use those handy Pascal strings that >> much anymore these days. Ever since you need to use UTF8 to properly >> represent textual context, this all has become one hell of a mess, >> pretty leveling the playing field when it comes to handling such strings >> with (Free)Pascalor C... > > quite true, my friend... quite true :) I disagree! You still know the byte(!) length of UTF-8 strings and in many cases you don't need anything more. If I search for the existence of an ASCII character I can still iterate my string in a for loop: for i := low(MyString) to high(MyString) do begin case MyString[i] of '!' : do_something; 'a','A' : do_something_else; end; // of case end; Works perfectly on UTF-8 strings. And if it's coming to the number of glyphs in a string you will have a hard time anyway because of diacrytics etc. But I very seldom need the exact number of displayed glyphs. And for these cases there are powerfull functions available in Free Pascal to handle them. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
Am 2017-05-24 um 13:59 schrieb Graeme Geldenhuys:
> But in Object Pascal you have...
>
> begin
> ...
> if then
> begin
> ...
> if then
> begin
> ...
> Object Pascal blocks are longer to type - “begin” vs ”{” and “end” vs
”}”.
I don't know why this argument pops up over and over again.
To me it's just the opposite:
I can type "begin" and "end" much faster than the cryptic { and } (on my
german keyboard).
I use all 10 fingers for typing and each special character is an
interruption in my coding flow..
Also, as I already often said:
Program code is *written* only once but maybe *read* very often.
I prefer readable code even if it takes a millisecond longer to type
(which is not the case for me!)
> Also IF statements require the extra “then” keyword etc.
Same argumentation here.
I don't bother to type just another (ASCII) word.
Before I can think about a delay it is typed already...
> As for indentation. At least with real TAB character indentation, you
can configure the width of a TAB as a user configurable parameter
without affecting the source code. With space indentation you are stuck
with whatever the original author did.
That does not help me as I use an indentation scheme that not only relys
on TABs.
I always indent the begin (and end) of a block together with the block:
if true then
begin
DoSomething;
end;
This way the indentation always looks similar
independent from whether you have begin/end or not:
if true then
DoSomething;
Some people indent the code lines only:
if true then
begin
DoSomething;
end;
And some write the begin on the same line:
if true then begin
...
end;
You cannot solve all these cases just by TABs.
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
Am 2016-11-23 um 15:03 schrieb Graeme Geldenhuys: > If you want columns, then columns you shall have. ;-) > See attachment. I've also reduced the tabSize to 2, to make it more > representative of common Object Pascal coding style standards. Well, actually I would like to have the tabsize zero. I just want to align with tabs, not add space. These 2 things should not be combined. > The only thing I can see that is still different to your original code > [which ET can't do] is make your const/var column right aligned. Yes, although this would be no show stopper for me. > See attached screenshot. Again, I've enabled jEdit's setting to show > where I inserted TAB characters to make it easier to reproduce. Looks nearly as I would like it. If only I could specify a new block without adding a line without tabstops then I would be very interested in these elastic tabstops. Currently, whenever I change variable or parameter names I have to (re)align manually which would be automatic with ET. The other drawback of ET is, that all alignment is gone if you view the code in an editor that does not support ET. But if it would become more common, this issue may go away over time... ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
Am 2016-11-23 um 13:26 schrieb Graeme Geldenhuys: > On 2016-11-23 12:14, Jürgen Hestermann wrote: >> In your screenshot you use empty lines >> but no comment lines to separate the blocks. > It makes no difference... it has the same result. See attached > screenshot, where I added comments using a // prefix. > You seem to be missing how indentation or alignment is triggered with > ET. It only happens when a TAB (U+0009) character is found. Yes, I see now. It will only be a problem when 2 (different) blocks with elastic tabstops are directly following each other (without a line that has no tabstops as a separator). But this happens quite often in my code in function/procedure declarations as I align the parameters and directly after this the var declarations are aligned too (but not aligned to the parameter declaration): -- function MyProcedureThatDoesSomething(const Path, SourceItemName, TargetPath, TargetItemName : MyStringType; CopyProgressRoutine : CopyProgressRoutineTyp; const Flag: boolean; out ErrorCode : DWord; var ItemSkipped : boolean; const ExistingMode: OverwriteExistingModeTyp) : boolean; var Flags, VolumeS, VolumeT: DWord; S,T: MyStringType; FileEntryS, FileEntryT : BasicFileTyp; H : hwnd; -- In this case I would need to insert an empty (or comment line) between both blocks which I do not want in all cases. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
Am 2016-11-23 um 13:10 schrieb Graeme Geldenhuys: On 2016-11-22 18:29, Jürgen Hestermann wrote: I tried a new file in JEdit (I don't know what format this has then) but a line beginning with double backslash did not separate the blocks. Even worse, it was taken as the first column of the whole block. See attached. In your screenshot you use empty lines but no comment lines to separate the blocks. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
Am 2016-11-22 um 19:29 schrieb Jürgen Hestermann: > Am 2016-11-22 um 17:59 schrieb Graeme Geldenhuys: > > Inserting a blank line between the two blocks will treat themt > > differently with different indentation widths. > > Yes. But sometimes I do not want to be forced to > insert a blank line just to achieve this and > sometimes I even want to align what is separated > by a blank line. I am wondering how you can achieve this kind of code alignment - MyvariableA := 0; Myx := 1; MyProcedureCall(Param1,Param2,Param3); - by using elastic tabstops and without having an empty line between the 2nd and 3rd code line. Wouldn't the 3rd line always expand the first column of the block shifting the ':=' far to the right? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
Am 2016-11-22 um 17:59 schrieb Graeme Geldenhuys: > Inserting a blank line between the two blocks will treat themt > differently with different indentation widths. Yes. But sometimes I do not want to be forced to insert a blank line just to achieve this and sometimes I even want to align what is separated by a blank line. > If your file format supports comments, > inserting a comment line between the two blocks will > also work. I tried a new file in JEdit (I don't know what format this has then) but a line beginning with double backslash did not separate the blocks. Even worse, it was taken as the first column of the whole block. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
Am 2016-11-22 um 17:26 schrieb Graeme Geldenhuys: > On 2016-11-22 15:57, Jürgen Hestermann wrote: >> I just tried elastic tab stops with JEdit a bit but they are too restrictive for me: >> >> 1.) They do not allow me to start a new table without having an empty line between. >> The following indentation seems to be impossible with elastic tabstops (at least I did not found out how to do this): >> >> >> >> 11 22 33 >> 44 55 66 >> 77 88 99 > > I'm not sure I understand what exactly you are trying to accomplish. Do > you mean column data (think TAB delimiter data files like what Excel > exports)? See attached screenshot. Simply insert a TAB character between > every column of text. I just want it in the way I have shown in my email (via spaces). The first 3 lines and the last 3 lines should *not* share the same tab positions! Only each block of 3 lines should do so. In your screenshot "11 22 33" is aligned with 'ggg ' which I do not want. There should be 2 blocks each with their own columns. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Underscores in numerical literals - grouping
I just tried elastic tab stops with JEdit a bit but they are too restrictive for me: 1.) They do not allow me to start a new table without having an empty line between. The following indentation seems to be impossible with elastic tabstops (at least I did not found out how to do this): 11 22 33 44 55 66 77 88 99 There is no way to specify when a block starts and ends other than empty lines. Even worse, when having a block like above and I then start a new line which has nothing to do with the above block this whole new line is taken as the first column shifting everything above to the right (which is not what I intended). Elastic tabstops are way "too smart". They disturb more often than they help. 2.) When spaces are used instead of tabs (like in Lazarus IDE) then my file has the same look on all editors with monospaced fonts. When I would have used (elastic) tabstops then this would look totally confusing in these editors. 3.) Together with the issues above the advantages are too few to let me put any time into this (I already wasted too much time on testing and writing these emails ;-) ) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] *** GMX Spamverdacht *** Re: Documentation, syntax diagrams
Am 2014-01-12 00:40, schrieb Jonas Maebe:
>> You seem to imply that I am demanding something for myself.
>> But I only report these documentation problems for potential new users
>> because I think that Pascal should be used by more people
>> while you seem to not care about them.
> Claiming that Michael does not care about (new) people using Pascal is, given
his work on FPC and in particular the FPC documentation for the past 19 or so
years, nonsense.
> He clearly does not share your priorities or opinions in this case, but trying to convince him
(or anyone, for that matter) with arguments based on moral superiority (not speaking for yourself but
potential new users, caring while the other person "does not seem to care") or hyperbole
that degrades their over a decade old body of continued work ("If the diagrams stay like this
they are too confusing to be of any use") is unlikely to have any positive effects, no matter how
right you may feel that that you are or even be. To the contrary, in fact, since few people want to
encourage this kind of behaviour towards themselves by being receptive to the underlying arguments
when they are voiced in such a way.
If you are realy trying to tell me that these diagrams are okay
then I will stop reporting any issues about the documention now.
Thanks for making this clear to me.
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] 30 years of Turbo Pascal
Am 2013-11-20 15:33, schrieb Sven Barth: Turbo Pascal was released today on the 20th November 30 years ago. Is this correct for all datediff-functions? ;-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] What does Embarcadero spend there time on
Am 2013-03-08 16:17, schrieb Jonas Maebe: On 08 Mar 2013, at 16:14, Graeme Geldenhuys wrote: It's not karma, just some people that are outright idiots. That does it, you're back on moderation. Please grow up, finally. Well, I don't understand this reaction? It seem Jonas just wanted to provoke this kind of escalation. What was wrong with Graeme's mail? He simply posted a link. I don't get it. It seems some people/moderators feel like god and want to show this clearly. This all started with Jonas' totaly excaggarated mail. Now suddenly Graeme is the evil thow it should be Jonas. Strange list moderation ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] News on Delphi x64
DaWorm schrieb: The TP to Delphi change was one of the reasons I always use longint in Delphi now, and never, ever use integer. Yes, I also never use any generic types (like string or integer). It begs for trouble once you migrate such code to another platform. I always program with the limits of datatypes in mind (I think it's necessary to do so). If such limits change, my whole program may have a problem. So I never want data types changed in the background without me knowing. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] News on Delphi x64
Sven Barth schrieb: So Extended might not be even really needed cause Double is already enough for most important stuff. Definitely not! I once wrote a numeric simulator which did not converge with single type. Only extended lead to the correct results. The number of significant bits is quite important, because the convergence criterion has to be lower than the available significant bits and double only has about 16 while extended has 19-20. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
