Re: [fpc-pascal] USB Human Interface Devices
El 14/08/2019 a las 1:41, James Richters escribió: I wonder if HID devices will work at all on Windows the same as they do on Linux. I have not been able to get the HID part of the python code to work on windows yet either because the instructions given to install the packages needed Hello, HID devices works in the same way, you need a device driver for the hardware that exposes a HID interface and you can manage that HID interface using native hid.dll or use an abstraction layer like libusb-1.0. https://github.com/JoshyFun/VUSBRelayPascal My code to manage HID USB relays uses hid.dll (32 & 64 bits) or libusb-1.0 (32 bits only tested) on Windows, and libusb-1.0 or libusb-0.1 in Linux. Of course, functions on hid.dll and libusb are no the same, they work in different way, but the libusb-1.0 works the same way in both platforms. Implementation of hid.dll, libusb, etc, in my code only have relevant functions used in USB relays, so they can not used as a complete implementation. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] *** SPAM *** Re: USB Human Interface Devices
Le 14/08/2019 à 01:41, James Richters a écrit : Anyone have any thoughts on all this? I'm busy for now, but I'll have a look as soon as possible. Did you try to change your driver with Zadig (https://zadig.akeo.ie/) for your device 10CE:EB93 ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] PPCJVM Android JVM target speed of compiled classes measurement
Please, does somebod of us know, if it would be possible to create some scientific measurement of The speed of compiled classes which have been produced by PPCJCM Android JVM target mode? Or it is rather impossible to create valid test, since there are too many different devices? I would like to know, if The speed is much more slower than one Pascal source command for One Millisecond. Thank you very very much for yome information about it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Le 14/08/2019 à 23:18, Martin a écrit : inc(CALL_LVL [ LOCAL_CALL ],1) Yes, "inc" does not work for properties. But neither does +=. I agree and in the case of a property I think it would be cleaner to code an Inc method directly in the class, or eventually in a class helper, to write something like: CALL_LVL [ LOCAL_CALL ].Inc(1) In case of property, it's likely that you'll even be able to optimize the code, trimming some lines of the getter and the setter in you Inc method. This said, I like to use += when I code in C++ for Arduino I also think to the worse case, in Java, when you need to type something like a.SetX( a.GetX()+1) ... And to Python, where in the code of the methods I need to prefix all accesses to methods and attributes of the object with "self." I have some code self. self. self. everywhere ... Variant in Javascript: this. this. this. Variant in PHP: $this. $this. $this. Yes, I keep my FreePascal ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
On 14/08/2019 23:05, Bernd Oppolzer wrote: 4 characters in your case, but if you have for example: CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ; inc(CALL_LVL [ LOCAL_CALL ],1) "inc(,)" vs "+=" 6 vs 2 chars 4 more. Yes, "inc" does not work for properties. But neither does +=. and you write instead: CALL_LVL [ LOCAL_CALL ] += 1; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Am 14.08.2019 um 17:41 schrieb wkitt...@windstream.net: On 8/14/19 10:54 AM, Ryan Joseph wrote: Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a simple operation. All languages I use have adopted this syntax and for good reason. good reason?? because someone is too lazy to type 4 more characters? yes, i'm counting the readability spaces which could easily be left out... /me tightens belt on asbestos britches... 4 characters in your case, but if you have for example: CALL_LVL [ LOCAL_CALL ] := CALL_LVL [ LOCAL_CALL ] + 1 ; and you write instead: CALL_LVL [ LOCAL_CALL ] += 1; it's more than 4 chars, and it's easier, when it comes to changes, and and and ... This is only a simple example; consider arrays with more indexes and record components and pointer references ... BTW: the two statements are not equivalent, if the index expression contains for example a function call with side effects :-) PL/1 is another language which has been enhanced to support this notation some years ago. Kind regards Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
I agree, I hate the self. And this. I really don't even understand them... I'll keep Freepascal too, which I've been able to do more with than I ever imagined possible. James >I also think to the worse case, in Java, when you need to type something like >a.SetX( a.GetX()+1) ... >And to Python, where in the code of the methods I need to prefix all accesses >to methods and attributes of the object with "self." I have some code self. >self. self. everywhere ... >Variant in Javascript: this. this. this. >Variant in PHP: $this. $this. $this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
We're talking apples and oranges here.. sorry my mistake. I was referring to the defaults in the Text IDE, fp.cfg, not fpc.cfg.If you delete fp.cfg or run the Text IDE (fp.exe) from a directory you never ran it in before, it creates new fp.cfg, and fp.ini and the default for those new files it creates is to have nothing on except "Allow LABEL and GOTO" and "Allow inline". All other Syntax Switches are turned off including "C-like operators" by default when the text IDE creates a new fp.cfg and fp.ini from scratch. James >> No, the default is for ”C-Like operators” to be disabled in FPC. >No, Sven is right. >This is in the default fpc.cfg ># Allow goto, inline, C-operators, C-vars -Sgic >Of course if you delete that file, then all these are off. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Challenge accepted
Op 11-08-19 om 12:28 schreef Michael Van Canneyt: What additions are you talking about ? Can we incorporate it ? Improvements are always welcome. Maybe the ability to handle read- or write-only properties. And a flag to allow that properties which are not available in the JSON, are simply skipped. (Not by using the allow-errors flag) Note that the SQLDB rest bridge has dataset result streaming in various formats. It's somewhat similar to your goal, but is limited to datasets. Does remind me. It should also be able to stream datasets to something else. And offcourse to stream objects to a dataset. Another thing, can you help me setting up some kind of git-repository on the FPC-infrastructure? Or don't you have any plans in that direction? Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
On Wed, Aug 14, 2019 at 9:03 PM James Richters wrote: > No, the default is for ”C-Like operators” to be disabled in FPC. No, Sven is right. This is in the default fpc.cfg # Allow goto, inline, C-operators, C-vars -Sgic Of course if you delete that file, then all these are off. -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] where to find materials about MP3 file format
I have A very big and non easy dream. Making similar MP3 editor like MP3 direct cut for Windows is. But sure! I would like to develop it for Android. And I want to support keyboard letter commands such as inside MP3 directcut for Windows. Sure. I Am not so expert like MR Martin Pesh is. So I must go much more easier way. I want to only develop engine, which will play, stop, will support left and right arrow key as A key for making forward and backward. And especially, and this is The most important, I want to support Block operations to assign beginning of block and its end. And mainly, I want to use remove block command, which will hae immediate effect. So MP3 engine will skip previously non removed data. What do I need? Some technical manual about MP3 format. Sure. Even Android media player will allow Me to play, forward, backward, playand stop. But I must have deep knowledge about MP3 file format structure. So I will be able to remove block. MP3directcut do not remove data directly from existing MP3 file or from temporary copy of this file. It making software magic so software counter, which control The playback simply do not know about previously assigned MP3 part for removal. Removed data are physically stored after user use corresponding save function from menu. Before this, user can remove as much part as he or she wants. To prevent Android crash, I will avoid to use clipboard operations. Android is not Windows and too big data chunks may be cause some memory allocation issues. Who of us would have some tip how to find MP3 file format technical specifications? Pascal support binary file operations. So real data manipulations will begin after user press function save changes. Sure. As MP3 directcut, I will have to use The same approach. I must create copy of original file after user press save and after this copy will be created, I must manipulate with data. I think, that I will have to use array which will contain beginning and end of MP3 data for removal. It will not be easy work. But as I have written previously. I do not have ambitions to create real clone of MP3 direct cut for Android with all of its functions. I want only play, stop, forward, backward while play. MP3 directcut uses frames approach. So I will have to include slider which will allow users to specify number of MP3 frames while backward and forwarding. Existing MP3 editors for Android on Google Play are not comfortable for Me. It do not support keyboard shortcut and it is not possible to remove many parts of MP3 files. Only one selection inside one file. I hope, that PPCJVM compiler contain enoug of internal command to create this tool. Sure. I will use Android Media Player APIS, thanks to creator of Pandroid, I have functioning example how to call it even without crashes and memory allocation leaks. The most difficult part will be to correctly reproduce original MP3 file when saving data without removed MP3 blocks. Sure. Application must be usable also for sighted users so I will not only use keyboard show method without GUI. App will contain The series of Buttons. By The way. Do you know, that Pandroid bundle contain special unit, which will allow you to combine buttons with A nice .png pictures? And GUI look very nicely. You will be able to scroll among many many buttons without crashes. And you will not had to use object position values. But how to achieve The complex algorithm for recreating MP3 file. It will not be easy walk across The park. I will also have to use effective approach to prevent memory allocation problems. I hve analysed Github but there was no useful source codes. May be, that somebody of us would give Me some tips and tricks. I do not want to use Basic, since interpreter machine contain many many lines of Java source code. And I Am convinced, that when I compile app directly to .dex format by using PPCJVM Android JVM target, resulting code would interpret faster than one Millisecond for one command. But I do not know, how to measure so complex thinks. It would be interesting, if somebody, who have created PPCJVM would try to make some scientific measurement on some device. Or do you think, that it will be even much more slower than One Millisecond per one Pascal command? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
On 8/14/19 10:54 AM, Ryan Joseph wrote: Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a simple operation. All languages I use have adopted this syntax and for good reason. good reason?? because someone is too lazy to type 4 more characters? yes, i'm counting the readability spaces which could easily be left out... /me tightens belt on asbestos britches... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 11:41 AM, wkitt...@windstream.net wrote: > > good reason?? because someone is too lazy to type 4 more characters? yes, i'm > counting the readability spaces which could easily be left out... yes, that’s exactly why. Programers got sick of wasting time typing redundant characters so they attacked the problem at the root. It’s so intuitive that basically all languages have adopted the syntax. I’m not saying you should but it’s going to hurt Pascal if we ignore these kinds of trends. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Op 14-08-19 om 17:45 schreef Ryan Joseph: On Aug 14, 2019, at 11:41 AM, wkitt...@windstream.net wrote: good reason?? because someone is too lazy to type 4 more characters? yes, i'm counting the readability spaces which could easily be left out... yes, that’s exactly why. Programers got sick of wasting time typing redundant characters so they attacked the problem at the root. It’s so intuitive that basically all languages have adopted the syntax. I’m not saying you should but it’s going to hurt Pascal if we ignore these kinds of trends. Roflol... yeah... people do not use Pascal because they have to type: i := i + 1; Sure. Thanks for the laugh, though. But completely off-topic. I shouldn't have responded. Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 11:52 AM, Joost van der Sluis wrote: > > Roflol... yeah... people do not use Pascal because they have to type: > i := i + 1; > > Sure. I’m once again shocked that anyone would be against such syntaxes as += so maybe the compiler needs to put them behind a modeswitch. Given what Sven said I’m surprised they didn’t do this from the start. Even “out” is behind a mode switch after all. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
On Mittwoch, 14. August 2019 11:45:20 CEST Ryan Joseph wrote: > > On Aug 14, 2019, at 11:41 AM, wkitt...@windstream.net wrote: > > > > good reason?? because someone is too lazy to type 4 more characters? yes, > > i'm counting the readability spaces which could easily be left out... > yes, that’s exactly why. Programers got sick of wasting time typing > redundant characters so they attacked the problem at the root. I am so sick of typing all the characters... No, your eyes get sick if you have to read C code. If you had a real problem where there is no solution at the moment I could understand you. But there is no problem, and no one is preventing you from writing good and readable code. > It’s so > intuitive that basically all languages have adopted the syntax. That is not true. > I’m not > saying you should but it’s going to hurt Pascal if we ignore these kinds > of trends. Also not true. > > Regards, > Ryan Joseph > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann > wrote: > >> It’s so >> intuitive that basically all languages have adopted the syntax. > > That is not true All languages I use have them: Pascal, C, PHP, C#, Swift, Python, JavaScript. These are some of the most popular languages in the world right now. You’re fighting a losing battle sir. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
On Wed, 14 Aug 2019, Ryan Joseph wrote: On Aug 14, 2019, at 12:04 PM, Rainer Stratmann wrote: It’s so intuitive that basically all languages have adopted the syntax. That is not true All languages I use have them: Pascal, C, PHP, C#, Swift, Python, JavaScript. These are some of the most popular languages in the world right now. You’re fighting a losing battle sir. I don't see what the issue is ? You do have += and the like. They exist, since about as long as I can remember. You just cannot use it on properties. Properties have some other restrictions as well: * You also cannot Use Inc() on integer properties, * or use Include()/Exclude() on set properties. * You also cannot do SomeRecordProp.X:=Y; * or pass them to functions that require var arguments. And I'm probably forgetting some other limitations. The += is just another one in the list of limitations of properties. Basically any operation that requires an address is not allowed. That += is using an address is an implementation detail of the compiler. Same as Inc() or In/Exclude(). I don't know the exact reason for this limitation, but it's bound to be a good one, otherwise it would have been lifted a long time ago... And if someone doesn't like these limitations of properties, (s)he can use fields. No-one abolished those, after all. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 2:53 PM, James Richters > wrote: > > I have only used += once; I normally would not use I:=I+1; or I+=1; I > would use Inc(I); Here’s an example of why we like c-style operators, i.e. it reduces redundancy of the variable name. It’s no surprise that programmesr figured out "viewTransform := viewTransform *” could be compressed and still have the same meaning. viewTransform := TMat4.Identity; viewTransform *= TMat4.Translate(x, y, 1); viewTransform *= TMat4.Scale(scale, scale, 1); or viewTransform := TMat4.Identity; viewTransform := viewTransform * TMat4.Translate(x, y, 1); viewTransform := viewTransform * TMat4.Scale(scale, scale, 1); Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
>They already are, but not a modeswitch, but a directive: {$COperators On/Off}.
>Probably from a time before modeswitches were introduced.
>It's even per default off. The default fpc.cfg however enables them...
No, the default is for ”C-Like operators” to be disabled in FPC. I just
deleted fp.cfg and ran the text IDE and “Allow LABEL and GOTO” and “Allow
inline” are the only two compiler options that are on by default with FPC… note
this it not the Lazarus version of FPC, which has been modified, in fact the
Lazarus version does not even have the text IDE included with it. If anything
perhaps it is a bug of Lazarus to turn it on by default when FPC by itself has
it off by default.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
I find viewTransform := TMat4.Identity; viewTransform := viewTransform * TMat4.Translate(x, y, 1); viewTransform := viewTransform * TMat4.Scale(scale, scale, 1); much more readable. But I would just do: viewTransform := TMat4.Identity * TMat4.Translate(x, y, 1) * TMat4.Scale(scale, scale, 1); why bother storing the intermediate results at all? Putting the operator before the = makes you have to go back and look to see what the operator is, where having the code in Result := Term * Term; format is more readable because you read it left to right and the operators are in the correct order they are actually used. I admit I am probably biased by looking at code without += for 35 years, but I still find it more readable. I completely understand += -= *= and /= I just don't care for it from a readability point of view.. and figuring our what some code is doing 2 years from now is way more important than getting it to work right now... it's when you go back later you want it to be as readable as possible. I guess I just prefer Variable := Formula; syntax and the clarity of it. James -Original Message- From: fpc-pascal On Behalf Of Ryan Joseph Sent: Wednesday, August 14, 2019 2:58 PM To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] += property bug? > On Aug 14, 2019, at 2:53 PM, James Richters > wrote: > > I have only used += once; I normally would not use I:=I+1; or I+=1; I > would use Inc(I); Here’s an example of why we like c-style operators, i.e. it reduces redundancy of the variable name. It’s no surprise that programmesr figured out "viewTransform := viewTransform *” could be compressed and still have the same meaning. viewTransform := TMat4.Identity; viewTransform *= TMat4.Translate(x, y, 1); viewTransform *= TMat4.Scale(scale, scale, 1); or viewTransform := TMat4.Identity; viewTransform := viewTransform * TMat4.Translate(x, y, 1); viewTransform := viewTransform * TMat4.Scale(scale, scale, 1); Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 3:15 PM, James Richters > wrote: > > I find > viewTransform := TMat4.Identity; > viewTransform := viewTransform * TMat4.Translate(x, y, 1); > viewTransform := viewTransform * TMat4.Scale(scale, scale, 1); > > much more readable. then by having both we all win. I never said we shouldn’t both, I’m just reacting to the idea that FPC almost didn’t include them because they "aren’t desirable". > > But I would just do: > viewTransform := TMat4.Identity * TMat4.Translate(x, y, 1) * > TMat4.Scale(scale, scale, 1); > > why bother storing the intermediate results at all? Maybe that was a bad example but I still like to break up lines. For anyone that knows, does the compiler have any fancy optimizations to not store the intermediate results? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] *** SPAM *** Re: USB Human Interface Devices
> Did you try to change your driver with Zadig (https://zadig.akeo.ie/) for > your device 10CE:EB93 ? No, I didn't try that.. but I'm trying it now I downloaded Zadig, and used the pulldown and selected devices until I got the one with the USB ID I want. It filled in as follows: "USB Input Device" Driver: HidUSB (v10.0.17763.1) USB ID: 10CE EB93 WCID has a red X in it I am not sure what to do from here. It looks like it has a driver for HidUSB and maybe that's what I want because the project at https://github.com/prof7bit/HIDAPI.pas has the same functions as the ones I am looking to duplicate... but then I don't know, maybe I am mixing up terminology Anyway, before I go changing drivers.. is there some way to un-do this change? I don't see HidUSB in the list of drivers that Zadig can install, so if it turns out hat I really wanted HidUSB driver and I changed it to LibUsb then is there a way to put it back? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
>My code to manage HID USB relays uses hid.dll (32 & 64 bits) or >libusb-1.0 (32 bits only tested) on Windows, and libusb-1.0 or >libusb-0.1 in Linux. I'll have a look at your project.. maybe it will give me some clues. Can you tell me how to get hid.dll? I find it all very confusing, can I just download the dll somewhere or do I have to get this huge confusing package and built it myself? The sample code that is able to access my device with python on Linux uses hid.dll I would like to at least be able to try the hid.dll... if I can get hid.dll somewhere. >Of course, functions on hid.dll and libusb are no the same, they work in >different way, but the libusb-1.0 works the same way in both platforms. The hid.dll way seems to have the functions I am trying to duplicate. >Implementation of hid.dll, libusb, etc, in my code only have relevant >functions used in USB relays, so they can not used as a complete >implementation. Maybe it will at least be able to get me started with some basic access.. at this point I would be happy to make it just open and close the device without an error. >In the other hand, the hardware you are trying to manage is 10CE:EB93 ? Yes, I got a listing of all devices, then I plugged in the new one, and that is the ID that was not there before. >If the answer is yes, that device is *not* HID compatible so you can not use >hid.dll for native access, you must use WinUSB API set, or the >libusb-1.0 abstraction layer. I'm curious how you can tell that by looking at the number of it? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 13, 2019, at 11:09 AM, Sven Barth via fpc-pascal > wrote: > > In general the C operators are not desired. They where added way in the past > in a weak moment and I don't think they'd be added today if FPC wouldn't have > them already. > Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a simple operation. All languages I use have adopted this syntax and for good reason. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Michael Van Canneyt schrieb am Mi., 14. Aug. 2019, 18:24: > Basically any operation that requires an address is not allowed. > That += is using an address is an implementation detail of the compiler. > Same as Inc() or In/Exclude(). I don't know the exact reason for this > limitation, > but it's bound to be a good one, otherwise it would have been lifted a > long time > ago... > The restriction regarding taking an address was only started to be enforced in 2.4.0 (see https://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields) and further extended to records in 2.6.0 (see https://wiki.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties ). The idea is to have properties backed by a field and backed by methods behave identically. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 12:33 PM, Rainer Stratmann > wrote: > > Didn't you know that Ryan? Yes, of course, I use them all the time and it’s why I was defending them from their critics (which I still find hard to believe even exist). Anyways, they exist and can be disabled using the directive Sven mentioned. Everyone wins. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
I have only used += once; I normally would not use I:=I+1; or I+=1; I would
use Inc(I);
FPC does not compile I+=1; by default, you have to go into compiler options
and turn on C-Like operators.. I'm sure Lazarus turns this on by default, but
it's not the normal default for just FPC. I know it is not the default because
I just installed FPC and if would not compile the exactly 1 instance I used +=
until I went in and turn on C-Like operators.
As far as typing code goes, I find all the begin's and end's to take more
effort than anything else... but I can type a block of
Begin
End
Else
Begin
End;
Super fast now anyway... and I find that I defiantly PREFER to make the effort
because the code is much more readable than things like python that don't use
anything but indentation or C that uses the {} braces.. I find it so much
easier to follow after the fact having begin and end than trying to follow a
huge chain of braces which blend in way too easily with parenthesis (). Also
most coding has more to do with cutting and pasting than actually typing things
out anyway. Readability after the fact is simply WAY more important than how
many keyboard keys you need to hit to get the code on the screen.
James
-Original Message-
From: fpc-pascal On Behalf Of Rainer
Stratmann
Sent: Wednesday, August 14, 2019 12:33 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] += property bug?
On Mittwoch, 14. August 2019 18:24:40 CEST Michael Van Canneyt wrote:
> On Wed, 14 Aug 2019, Ryan Joseph wrote:
> >> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann wrote:
> >>> It’s so
> >>> intuitive that basically all languages have adopted the syntax.
> >>
> >> That is not true
> >
> > All languages I use have them: Pascal, C, PHP, C#, Swift, Python,
> > JavaScript. These are some of the most popular languages in the
> > world right now. You’re fighting a losing battle sir.
> I don't see what the issue is ?
>
> You do have += and the like. They exist, since about as long as I can
> remember.
Didn't you know that Ryan?
> You just cannot use it on properties.
>
> Properties have some other restrictions as well:
>
> * You also cannot Use Inc() on integer properties,
> * or use Include()/Exclude() on set properties.
> * You also cannot do SomeRecordProp.X:=Y;
> * or pass them to functions that require var arguments.
>
> And I'm probably forgetting some other limitations.
>
> The += is just another one in the list of limitations of properties.
>
> Basically any operation that requires an address is not allowed.
> That += is using an address is an implementation detail of the compiler.
> Same as Inc() or In/Exclude(). I don't know the exact reason for this
> limitation, but it's bound to be a good one, otherwise it would have
> been lifted a long time ago...
>
> And if someone doesn't like these limitations of properties, (s)he can
> use fields. No-one abolished those, after all.
>
> Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
> On Aug 14, 2019, at 12:24 PM, Michael Van Canneyt > wrote: > > I don't see what the issue is ? > > You do have += and the like. They exist, since about as long as I can > remember. I’m just responding to the fact Sven he regretted added them for some reason (and others now I’m learning). I just can’t understand that. As per the original message I seriously thought it was a bug but there are technical implications apparently. I was going to fix it but there’s no interest in doing that so I’m just going to work around it for now. No problem. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
On Mittwoch, 14. August 2019 18:24:40 CEST Michael Van Canneyt wrote: > On Wed, 14 Aug 2019, Ryan Joseph wrote: > >> On Aug 14, 2019, at 12:04 PM, Rainer Stratmann wrote: > >>> It’s so > >>> intuitive that basically all languages have adopted the syntax. > >> > >> That is not true > > > > All languages I use have them: Pascal, C, PHP, C#, Swift, Python, > > JavaScript. These are some of the most popular languages in the world > > right now. You’re fighting a losing battle sir. > I don't see what the issue is ? > > You do have += and the like. They exist, since about as long as I can > remember. Didn't you know that Ryan? > You just cannot use it on properties. > > Properties have some other restrictions as well: > > * You also cannot Use Inc() on integer properties, > * or use Include()/Exclude() on set properties. > * You also cannot do SomeRecordProp.X:=Y; > * or pass them to functions that require var arguments. > > And I'm probably forgetting some other limitations. > > The += is just another one in the list of limitations of properties. > > Basically any operation that requires an address is not allowed. > That += is using an address is an implementation detail of the compiler. > Same as Inc() or In/Exclude(). I don't know the exact reason for this > limitation, but it's bound to be a good one, otherwise it would have been > lifted a long time ago... > > And if someone doesn't like these limitations of properties, (s)he can use > fields. No-one abolished those, after all. > > Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
