Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
General / The weird Rewrite bug
« Last post by fxeconomist on Today at 11:10:22 pm »
So I just hit this thing,

A file that was written cannot be Rewritten (the second time, creation works). Not only that, but assign & erase also don't do anything.
File just needs to be written once. assign(f,'fullpath'); rewrite(f);...close(f); Yes, rewrite is between {$I-} {$I+}. This had no effect.
Code: Pascal  [Select][+][-]
  1. procedure TToroidCoil.SaveToFile(fullpath:string);
  2. var f:text;i:word;
  3. begin
  4. assign(f,fullpath);
  5. {$I-}
  6. rewrite(f);
  7. {$I+}
  8. writeln(f,'# Coil Parameters');
  9. //
  10. close(f);
  11.  

I ran this similar code in FPC with no trouble:

Code: Pascal  [Select][+][-]
  1.   assign(f,'e:\testfilerewrite.txt');
  2.   rewrite(f);
  3.   write(f,random()*100000000);
  4.   except
  5.      on E: Exception do writeln('I/O error');
  6.   end;
  7.   close(f);
2
BGRABitmap and LazPaint / Re: TBGRABitmap.TextSize returns incorrect value ?
« Last post by circular on Today at 10:52:20 pm »
Quote from: hedgehog on Today at 06:29:29 am
Hi!

.... and also after installing a new version of BGRABitmap, the BGRA.TextRect() does not clip off text that is too long.
Could there be some problem on my computer? (Windows 10)
Can anyone check this?
Hi Hedgehog,

That can be the case if in a previous version the text was always clipped. Can you provide the code you use? In the text style, there is a Clipping boolean that enables clipping or not.

Regards
3
Graphics / Re: Demoscene Square dot flag fx
« Last post by circular on Today at 10:46:58 pm »
Quote from: Gigatron on April 15, 2024, 08:01:43 pm
Edit : ** In fact I don't need to do anything, I just tested your example and it works perfectly :)
Thank you very much :)
You're very welcome  :)

Quote
By the way , you certainly know the Amiga Blitter..
Can you include it in BGRA? We take part of the image and copy it elsewhere, it looks like Drawpart image like in javascript.
BGRABlit(x,y,x1,y1, dx,dy)
I don't know about Amiga Blitter, but I understand your wish. Would it be with BGLCanvas or with a TBGRABitmap? There is TBGRABitmap.PutImagePart that would do that.

Regards
4
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by domasz on Today at 10:21:52 pm »
Quote from: dsiders on April 12, 2024, 10:35:00 pm
ZDNet claims ARM64 will be 30% of the Windows market by 2026. But crystal balls sometimes lie.

Impossible. And I believe it was President and CEO of Canalys Steve Brazier, not ZDNet.

1) Windows 11 is shit. There is lots of people who still use Windows 10, 7 and even XP. Microsoft totally doesn't know how to progress with Windows.
2) The biggest value Windows has over MacOS or Linux is all the software and games. Most of these won't be ported to ARM
3) ARM is still slow. Macs are slow and their benchmarks aren't true
4) Windows is slow. It got too big, it needs power
5) MacOs and Linux are getting more and more popular on laptops. Windows is now most popular na home desktops, gaming laptops and other powerful machines.
5
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by VisualLab on Today at 09:41:40 pm »
Quote from: PascalDragon on Today at 08:17:32 pm
Quote from: msintle on Today at 06:32:02 pm
So yes, it is high time Free Pascal and Lazaru supports aarch64 targets on Windows - the only (and ironically, biggest) platform where they lack this support.

FPC 3.3.1 already supports aarch64-win64, however due to some bugs in the code generator that have yet to be investigated it can't cycle itself and thus is not really usable for developing larger applications (which includes Lazarus).

Quote from: VisualLab on April 12, 2024, 11:27:32 pm
I would be in favor if Windows was available for ARM64 and supported various devices such as Raspberry Pi, Organe Pi, etc. I mean the real one, not a substitute in the form of Windows IoT (earlier RT and even earlier CE). But these are more of a dream. Porting WinAPI from AMD64/EM64T to ARM64 is years of work (if it is technically possible).

Ehm, you are aware that this is already the case for many years? I'm even running a full blown Windows 10 natively on a Pi 4 (see also the WoR project).

Yes, I read about it some time ago. I also watched videos on YouTube showing Windows 10 running on the RPi. But it was proof that it was (technically) possible. However, the work was far from comfortable (it was basically a "slide show"). Can ARM64 processors cope with such work?

The RPi Foundation specially "trimmed" and adapted Linux (Raspberry Pi OS) so that it could run on their board. I have an RPi 3B. From my own experience, I know that RaspberryPi OS works well, but it is not comfortable to work with (although Lazarus works quite well there). Another thing is that I don't use it as a desktop replacement, but for hobby purposes related to electronics (which is what the RPi foundation designed this board for).
6
FPC development / Re: Have anyone develop UEFI API for Free Pascal at current times?
« Last post by 440bx on Today at 09:39:52 pm »
Quote from: PascalDragon on Today at 09:00:04 pm
but that uses the same 64-bit PE format as AMD64 does (except for the machine type field and the relocations).
and, IIRC, the exceptions directory.
7
Beginners / Re: For-in loop over constant array of strings - limited to length of first string?
« Last post by VisualLab on Today at 09:15:53 pm »
Quote from: PascalDragon on Today at 08:33:12 pm
Quote from: VisualLab on Today at 04:51:14 pm
But I believe this:

Quote
Contrary to ordinary constants, a value can be assigned to them at run-time. This is an old concept from Turbo Pascal, which has been replaced with support for initialized variables.

 should only be possible in TurboPascal mode. In modes Fpc and ObjFpc should not be supported. Or this:

Quote
Support for assigning values to typed constants is controlled by the {$J} directive: it can be switched off, but is on by default (for Turbo Pascal compatibility). Initialized variables are always allowed.

in Fpc and ObjFpc modes it should be disabled by default.

The FPC and ObjFPC modes derive from the TP and Delphi modes and both had by default writable constants enabled, thus the FPC-specific modes had as well and nowadays this counts as backwards compatibility, so this will not change.

This was to be expected, i.e. a continuation of "historical events" due to the amount of existing code. Honestly, I've never had the need to use writable constants. But I also never turned off the option in the code. This means I have to remember to add appropriate compiler directives to the modules of my own programs and libraries. Well, that's what programming is all about, you have to remember a lot of different little things :-)
8
Other OS / Re: BUG REPORT: Unable to generate DEB/RPM/TAR installation package from FPC source
« Last post by PascalDragon on Today at 09:02:49 pm »
Quote from: gasensor on April 15, 2024, 06:03:15 pm
It feels like no one here cares about FPC.

What makes you think that on the main forum for FPC?

Quote from: gasensor on April 15, 2024, 06:03:15 pm
I've also found a couple of bugs and I'm worried that some of them will be ignored if they are released together.

And did you report them?
9
FPC development / Re: Have anyone develop UEFI API for Free Pascal at current times?
« Last post by PascalDragon on Today at 09:00:04 pm »
Quote from: TYDQ on April 15, 2024, 06:54:34 am
Quote from: PascalDragon on April 14, 2024, 09:19:08 pm
Quote from: TYDQ on April 14, 2024, 02:37:02 pm
Quote from: PascalDragon on March 29, 2024, 02:16:40 pm
There is no timetable.
I know the trunk version of fpc can make PE-64 files,so how long do the fpc publishs 3.3 stable version so I can use PE-64 format files as a UEFI bootable files?

But FPC already supports 64-Bit PE files for nearly twenty years already? After all it had been the first open source compiler to support Win64.
No,trunk is published in this year and only trunk supports 64-bit PE format files.

First of trunk is the current development version and as such it's never “published”. Releases will be split of from it, but even then there is no major release planned this year (only a minor release from the 3.2.x branch).

Second, no not only trunk supports 64-bit PE executables, cause otherwise FPC wouldn't be able to support Windows 64 and that is already supported for nearly 20 years as I said.

What is only support in trunk is support for Windows on ARM64, but that uses the same 64-bit PE format as AMD64 does (except for the machine type field and the relocations).
10
macOS / Mac OS X / Re: Lazarus project made on Mac OS 12.5.1 crash on MAC OS 10.7.5
« Last post by Odacir on Today at 08:56:58 pm »
You are the best Jonas!!! Solved!!! Thanks a lot!!!!
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018