Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Access Violation in MaskUtils.FormatMaskText
« Last post by dmitryb on Today at 05:20:07 am »
Hello

Lazarus 2.2.2 (rev lazarus_2_2_2-0-g537f43754c) FPC 3.2.2 x86_64-win64-win32/win64

When I call the next code

Code: Pascal  [Select][+][-]
  1. procedure TForm1.Button2Click(Sender: TObject);
  2. var
  3.   EditMask: String;
  4.   Result: String;
  5. begin
  6.   EditMask := '#-###-###-##-##;0;_';
  7.   Result := MaskUtils.FormatMaskText(EditMask, '');
  8. end;

I got an Access Violation in
function TMaskUtils.ApplyMaskToText(AValue: String): String;

I can't figure out if this is a feature or a bug.
2
General / Re: Absolute file path in {$include %file%}
« Last post by GetMem on Today at 04:28:21 am »

You could do something like
Code: Pascal  [Select][+][-]
  1.  
  2. program project1;
  3.  
  4. {$macro ON}
  5. {$define mypath:= extractfilepath(paramstr(0))+{$include %file%}}
  6. uses
  7. sysutils;
  8.  
  9. begin
  10.   writeln(mypath);
  11.   readln;
  12. end.
maybe.

Let's say your project is located in c:\MyProjects\Project1\. Build the application,  copy the executable to d:\test\, the run it. ExtractFilePath(Paramstr(0)) will point to d:\test\, OP needs c:\MyProjects\Project1\.
3
Hello,
I don't know about macOS, but at Linux there is no much sense to place lock file in directory where system doesn't look for lock files, except if only your program accesses this port. It is simpler to set TBlockSerial.LinuxLock property to false, though at Linux usually there is no problem with /var/lock.
in the constructor of TLazserial the LinuxLock property is set to false :
Code: Pascal  [Select][+][-]
  1. constructor TLazSerial.Create(AOwner: TComponent);
  2. begin
  3.   inherited;
  4.   //FHandle:=-1;
  5.   ReadThread:=nil;
  6.   FSynSer:=TBlockSerial.Create;
  7.   FSynSer.LinuxLock:=false;
  8.   FHardflow:=false;
  9.   FSoftflow:=false;
  10.   FFlowControl:=fcNone;
  11.   {$IFDEF LINUX}
  12.   FDevice:='/dev/ttyS0';
  13.   {$ELSE}
  14.   FDevice:='COM1';
  15.   {$ENDIF}
  16.   FRcvLineCRLF := False;;
  17. //  FBaudRate:=br115200;
  18. end;  
     

Friendly, J.P             
4
Other / tiobe index
« Last post by Weiss on Today at 02:34:35 am »
while looking up some other language (Wolfram it was) I couldn't help but noticed Delphi/Pascal is on 13th place. Moved up 7 places from its 20th place.

Isn't it a big jump? What happened?

5
Spanish / Re: Enviar, recibir datos de un servidor
« Last post by mav on Today at 02:12:45 am »
...jwaws2tcpip o jwaWinSock2 es Api de Windows, que uso porque en winsock no hay convertidas algunas estructuras y declaraciones del api
que si están en el jwa..El problema es, después de que al buffer (recvbuf: array[0..DEFAULT_BUFLEN] of byte;) le han llegado del servidor los 4 bytes.
¿Como los leo y posteriormente selecciono de dos en dos para operar con ellos :
Code: Pascal  [Select][+][-]
  1.                i: char?, string?,
  2.  
  3.                i:= Copy(recvbuf, 1,4);  //Evidentemente esto no se puede hacer pero sería lo que quiero
  4.                WriteLn(i);            
  5.  
         
 
6
General / Re: Immutable data types
« Last post by Warfley on Today at 01:47:58 am »
I don't see how it is the same point. You just made an incapsulated object(record) with an exlicit mutating method.
Basically, you reiterated that FPC/Delphi does not have "immutable objects" and calling any method might change the internal state.

But we all know it and we do not expect it otherwise. You called a method - you are on its mercy now.
Here is no broken expectations, at least no more than usual.
Yes it broke the expectation, the parameter is declared as const, therefore the expectation is that it is immutable. But the fact that by calling a method it can be mutated is breaking this expectation. And this should not be possible. In fact, with non method functions this is actually the case:
Code: Pascal  [Select][+][-]
  1. type
  2.   TTest = record
  3.     i: Integer;
  4.     procedure Inc;
  5.   end;
  6.  
  7. procedure TTest.Inc;
  8. begin
  9.   Self.i += 1;
  10. end;
  11.  
  12. procedure IncTest(var Self: TTest);
  13. begin
  14.   Self.i += 1;
  15. end;
  16.  
  17. procedure Foo(const t: TTest);
  18. begin
  19.   t.Inc; // Works
  20.   IncTest(t); // Error: Can't assign values to const variables
  21. end;
Conceptually the method and the function should be the same, and infact they are, a method simply is a function with a hidden self var parameter as first parameter. But they work differently. The reason is that the const system works ok-ish for regular functions but does not extend to methods.

If I say that something is immutable with the const keyword, I would expect that I am not able to mutate it. The fact that I can do this, no matter if it's through a method, a function, an operator or by doing a performative dance in front of my pc, breaks this expectation. It's called "const" not "ConstUnlessYouCallAMethodOnIt", so I expect it to be constant

...and what does string.GetCar even mean now?
This is the classical diamond problem from multi inheritance. And the solution is extremely simple, throw an ambiguity error and let the user resolve it manually:
Code: Pascal  [Select][+][-]
  1. TMyHelper1(instance).Method; // Call Method from Helper1
  2. TMyHelper2(instance).Method; // Call Method from Helper2
This works for Multiinheritance in languages like C++. For type helpers specifically, these are a staple of the swift programming language, where this is also resolved similarly. This "problem" was solved decades ago.

Quote
Oooops, suddenly my old polished ocde i did not touch for 5 years changed the meaning and (hopefully) compiles no more. But if both heplers were returning IUnknown and being fancy trendy libraries provided OLEAuto runtime-binding interface... Ooooops - it only gives "catastrophic call failure" later in the runtime.
If the library you are using changes it's interface of course it effects your code. But this is not a property of type helpers, but of any function. Just imagine like:
Code: Pascal  [Select][+][-]
  1. CarModel := GetCar('Volvo X5 Black');
You have exactly the same problem. Typehelpers are just syntactic sugar, which converts functions of the form "Verb(subject, objects)" into the method form of "subject.verb(objects)". Semantically it is identical and therefore, as this is a completely non issue in the former case, it also is in the latter.

I mean yes this is actually sometimes a kindof problem when considering overloaded functions. This is exactly why C does not allow overloaded functions, but C++ does, because while the C developers see the "risk" of allowing this ambiguity to be to high, C++ doesn't. Pascal allows for overloaded functions, and this won't change probalby, so there is no reason to not allow multiple type helpers, because it's the exact same situation just with a different syntax.
7
General / Re: Immutable data types
« Last post by Arioch on Today at 01:09:39 am »
In FreePascal type helpers (something that does not even exist in Delphi) are alive and well.

But you can also change this to advanced records to make the same point.

I don't see how it is the same point. You just made an incapsulated object(record) with an exlicit mutating method.
Basically, you reiterated that FPC/Delphi does not have "immutable objects" and calling any method might change the internal state.

But we all know it and we do not expect it otherwise. You called a method - you are on its mercy now.
Here is no broken expectations, at least no more than usual.

Quote
from your point of view as a user you can assume it to be a black box.

This!

=====================

On helpers I'll have to see. My current understanding (shallow glance) is that FPC type helpers is the same as Delphi record helpers just renamed. Plus, FPC does not prohibit several different helpers be active at once. And so, i did not look any deeper.

Would those be compiler intrinsics, so that no one but compiler makers could create those helpers - it would've been okay. One compiler magic more, one less, no big deal. But they are not.

With people encouraged to make their own helpers - they have either go into self-censorship, identifying this feature as dangerous, or end up having different helpers in different libraries for the same type.

So they get the unpredictability of big (actually - unit-big) WITH clause. Some place up there  far away, visibly unrelated, included some unit - and suddenly he identifiers you use in your code changed meaning. Hopefully thy would stop compiling, worse if they would compile yet change meaning.

Delphi's restriction "only one helper" pessimizes creating your own helpers for types RTL already mase helpers for. But not prohibit it.
Multiple helpers mode of FPC does not even have it.

Imagine i have two libraries, both interface database of cars, but differnent datasets: one has information for different plate numbers (as road police gathers, "instances" of cars), and other - for different models (as shops/commercials do, "classes" of cars),

While i only had one library, it was cool, fancy and fashionably pythonish.

Code: Pascal  [Select][+][-]
  1.   UsedCar := 'VX-10574-RU'.GetCar;
  2.  

Code: Pascal  [Select][+][-]
  1.   CarModel := 'Volvo X5 Black'.GetCar;
  2.  

Cuule, man, aintah?

But of course, i might want to integrate both datasets.
If my program user looks to buy a used car on esome -bay, then he would benefit from oth reading reviews of the car model, and reading "police story" about this specific instance, maybe it was into accidents.
So, i throw both units, accessing both datasets into my uses clause....

...and what does string.GetCar even mean now?

And here we go back to your earlier statement:

Quote
it is easy to see a situation where one person is writing a type (or typehelper) and changes the definition of one method to now alter one of the fields, while the usage, where it is assumed to be constant, is made by a different person

Type helpers promote sudden and global change of the working code, without actually the sources of that code being touched.

Imagine i was lucky to have a lucky sequency in my uses.

Code: Pascal  [Select][+][-]
  1. uses .... CarHistoryDB, CarMagazineReviews, ....
  2.  
  3. ....
  4.  
  5.   CarModel := 'Volvo X5 Black'.GetCar;
  6.  

Works like a charm.

Then the CarMagazineReviews library team decided they made bad name, ambiguos if not misleading. And they cheanged their helper to be publish GetReviews instead.

Oooops, suddenly my old polished ocde i did not touch for 5 years changed the meaning and (hopefully) compiles no more. But if both heplers were returning IUnknown and being fancy trendy libraries provided OLEAuto runtime-binding interface... Ooooops - it only gives "catastrophic call failure" later in the runtime.

And then there was another string helpers, that also published a function string.GetReviews - but those were reviews of parking lots for tourists.
Those calls suddenly got broken too!

 %)

Good luck with this mess...
8
I don't know about macOS, but at Linux there is no much sense to place lock file in directory where system doesn't look for lock files, except if only your program accesses this port. It is simpler to set TBlockSerial.LinuxLock property to false, though at Linux usually there is no problem with /var/lock.

By the way, there is ancient code in function TBlockSerial.cpomComportAccessible, which is still not corrected (from synaser.pas in the last trunk of Synapse):
Code: Pascal  [Select][+][-]
  1.   // Is port owned by orphan? Then it's time for error recovery.
  2.   //FPC forgot to add getsid.. :-(
  3.   {$IFNDEF FPC}
  4.   if {$IFNDEF POSIX}Libc.{$ENDIF}getsid(ReadLockfile) = -1 then
  5.   begin //  Lockfile was left from former desaster
  6.     DeleteFile(Filename); // error recovery
  7.     CreateLockfile(MyPid);
  8.     result := FileExists(Filename);
  9.     exit;
  10.   end;
  11.   {$ENDIF}
FPC has fpGetsid for many years...
9
Spanish / Re: Enviar, recibir datos de un servidor
« Last post by Edson on Today at 12:12:13 am »
Las preguntas son:
  1- ¿Como podria escribir (WriteLn) los dígitos enviados por el cliente, para comprobar que está bien? y
  2- La respuesta que tengo que enviar es :
     (Los dos primeros dígitos XOR hora actual) + (Los tercero y cuarto digito Xor minuto actual)
    ...esto último casi lo tengo ya experimentando con DecodeTime un poco.
    ¿Como separo los dátos de dos en dos, para operar con ellos?

1) No he usado jwaws2tcpip o jwaWinSock2 (¿Es Jedi?) pero se puede ver que lo que buscas debe estar en "recvbuf". Tal vez puedas encontrar algún ejemplo en la documentación o en páginas equivalentes. Si no encuentras en Lazarus, te puedes guiar de los ejemplos de Delphi.
2) Para separar una cadena, puedes usar la función copy() y tomar dos subcadenas de la cadena original. En tu caso las subcadenas serían '12' y '34'. Luego tienes que convertir esas cadenas a número si quieres aplicarles el XOR.
10
Hello,

an AppImage might be a solution?

I don't know if there is an easy tool to generate a Linux AppImage from Lazarus.

An AppImage should have all dipendences in the unique file.

Anyone has tried?

Best regards,

Stephanie

The quick, easy an safe way is to install Debian 10 Buster that uses libc.so.6 ver 2.28.
https://www.debian.org/releases/buster/debian-installer/

You may install the downloaded iso image with a server virtualization software like VMWare or VirtualBox or QEmu.

Then install on that virtual machine last fpc, last Lazarus and compile your last source (that you have developed on your main dev-machine an copy on a usb stick, loaded in the virtual machine).
An copy the compiled-result-binary and paste it in your release-package.

Your release will run on nearly all actual Linux distros.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018