Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Re: Parameter passing oddities
« Last post by Thaddy on Today at 12:11:18 pm »
That is what I wrote, but much more confusing.
Also this part is dubious:
Quote
So the compiler knows, aha! Variable "c" is open to be modified, also the compiler knows that "a" and "b" are read-only.
If you think that Add(c1, c1, c1) would all be treated as "a" than you are total wrong.
He is wrong, but you are too. It is what I wrote.
2
General / Re: Parameter passing oddities
« Last post by KodeZwerg on Today at 12:04:57 pm »
When I call your example as "add (C1,C2,C1)", then C1 will be changed. The compiler cannot detect that, it does not know that two parameters are at the same address.
It depend on what C1 you talking about, the first stay unchanged the second, where the programmer chooses to write to, will be written to.
Dont you understand stand we turn in circles?
3 arguments, 3 variables, but just one where your method writes to.
So if you call Add(c1, c1, c1) what in your world of logic should happen? Are you now saying that it would write 3 times to c1 or do you finally accept my first given answer that the developer is in charge about what variable will be used as output and only the last c1 (variable c internal) is the one where the writing happen?

Add(
constref a: Integer; // this will be passed by reference to maybe do compare address with "c" -> unchangable
const b: Integer; // this will be passed by value, no checks beside for value are possible -> unchangable
out c: Integer; // this is passed by reference and its the only variable where you can write to -> changable
);

So the compiler knows, aha! Variable "c" is open to be modified, also the compiler knows that "a" and "b" are read-only.
If you think that Add(c1, c1, c1) would all be treated as "a" than you are total wrong.

So what did I told.....
If on the other hand you as developer call such method in a (a, b, a) way, then its upon you to decide if its smart or not.
[/quote]
3
General / Lazarus features in a non-graphical environment
« Last post by jollytall on Today at 11:53:17 am »
I have a command line program running on a Linux server somewhere far in a datacenter. It uses Indy for networking. The program was running for a long time, but now I needed to make some cosmetic changes, but I could not compile the source, and later could not run the executable. Details are in a Networking thread: https://forum.lazarus.freepascal.org/index.php/topic,67027.0.html

Now I made some more checks and came across a number of problems:
- Paweld recommended to add Interfaces to the uses clause. After doing so, my program with Indy compiled but the executable got much-much larger (13.2MB instead of 3.5MB). I checked the Interfaces unit and it is related to gtk2 and forms, although as said above my program is a service running with no GUI, and even more not even accessing a terminal. So, I am totally confused why adding Interfaces was necessary to use Indy.
- Nonetheless, I can live with the extra large executable, but it did not run. The reason apparently is that the server is an older Linux than my Desktop, so the program does not have the right libraries. It is a bit bothering that FPC/Lazarus can cross-compile from Linux to e.g. Windows, but cannot cross-compile it to another Linux. Can there be an easy solution?

But then again, I can also live with this, if I compile the program on the server (sub-optimal solution, but anyway). However, I do not know how to do that. I have IndyLaz and other packages added as required packages in the Project Inspector of Lazarus. Although, I did compile other programs with FPC only, those were simpler ones. I do not know, how to do an FPC compilation, using these kind of Lazarus features. It is obvious that I cannot have Lazarus running, but then what sort-of makefile or config file is needed to compile Lazarus projects with FPC only.

Can you help in this last question, but would also be happy to get comments on the Interfaces question as well (the Linux version was detailed in the other thread, but any better idea is again welcome).
4
First, a big thank-you to all who helped!

Simply removing all 'prepare' calls from our source code seems to have fixed the problem (at a superficial level at least).

My priority has to be implementing the required changes to our code, rather than debugging the fpc library.
So I shall consider the case closed - it seems that the problem is known ( see comments in TCustomSQLQuery.BeforeRefreshOpenCursor ), and since this was known several versions ago I assume that fixing it was not trivial. I hope someone will tackle this in the near future!
5
Third party / Re: Ho Ho Ho IntraWeb in Lazarus!!!
« Last post by irawan on Today at 11:39:39 am »
any news on this special product?
6
Debugger / Re: FpDebug questions
« Last post by Martin_fr on Today at 11:25:02 am »
The line order in the asm, is due to what FPC said for each address which line it was.

If you step (or try to step in) this lines, then you will notice it goes back and forth too. => as each param gets prepared, and then put in place for the call. Or something like this, whatever criteria fpc used to attribute each asm statement to either line.



The handle for the file can be set (seeked) to the begin or end of the file.

E.g. if you want to "tail" that file, if it still gets written to.
7
General / Re: Parameter passing oddities
« Last post by Thaddy on Today at 11:23:20 am »
Basically that is legal, because c1 is passed in and subsequently passed out in a different guise.. At the point of the calculation the first C1 is treated as const, but the result calculation that is passed out changes C1 in a legal way, since it is a store outside of the procedure itself.
const is confusing, but not that confusing.
Which is less disturbing than this:
Code: Pascal  [Select][+][-]
  1. var
  2.   i:integer;
  3. begin
  4.   for i := 0 to 10 do
  5.   begin
  6.    writeln(i);
  7.    inc(pinteger(@i)^);
  8.   end;
  9. end.
Which should be illegal, but isn't...
They are related, though.
8
General / Re: splitting an image
« Last post by Dzandaa on Today at 11:15:40 am »
Hi,

You cant try this skeleton (using BGRABitmap)

B->
9
General / Re: how to tweek fpmake to compile RTL?
« Last post by marcov on Today at 10:35:11 am »
So to be clear: the rtl, toplevel and compiler makefiles use an older build system; makefiles generated from a template by FPCMAKE and fpmake

Before say 2015, nearly everything was like that.
10
General / Re: splitting an image
« Last post by TRon on Today at 10:34:19 am »
the image is loaded like this from a TImageList. It is depended on a color:
That answers at least one of my questions ....  :P

Ah well, let's see how far you are able to get with the following (you would have to adjust to meet your specific requirements).

Code: Pascal  [Select][+][-]
  1. procedure TForm1.Button1Click(Sender: TObject);
  2. var
  3.   sameArea: TRect;
  4.   srcRect: TRect;
  5.   dstRect: TRect;
  6. begin
  7.   // split original image into two separated ones
  8.  
  9.   // left part of original image has the exact same rectangle coordinates as
  10.   // the destination image and is 165 pixels width.
  11.   sameArea    := Bounds(0,0,165, Image1.Height);
  12.   // Copy rectangle area from image1 (leftmost part) to image2
  13.   Image2.Canvas.CopyRect(sameArea, Image1.Canvas, sameArea);
  14.  
  15.   // right part of original image is located 165 pixels from the left
  16.   srcRect := Bounds(165, Image1.Canvas.ClipRect.Top, Image1.Canvas.ClipRect.Width-165, Image1.Canvas.ClipRect.Height);
  17.   // copied image starts at topleft of canvas and is 200 pixels width
  18.   dstRect := Bounds(  0,                          0,                              200, Image1.Canvas.ClipRect.Height);
  19.   // copy rectangel from image1 (rightmost part) to image3
  20.   Image3.Canvas.CopyRect(dstRect, Image1.Canvas, srcRect);
  21. end;
  22.  
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018