Re: [fpc-pascal] Type-casting a class variable

In addition to what Martin said: as long as you have a non-static class method the value of the variable you call the class method on (e.g. myClass in your example) will be passed as Self parameter. So no need for extra parameters. But how can myClass be passed ? myClass.CreateNew

Re: [fpc-pascal] Type-casting a class variable

Martin Frb via fpc-pascal wrote: Silly question, but did you assign the value to the variable? myClass := TWindow; That's what I did. TWindow(myClass).CreateNewWindow; And this is what crashes. I can report this, if the type-cast is supposed to work. Regards, Adriaan van Os __

Re: [fpc-pascal] Type-casting a class variable

Martin Frb via fpc-pascal wrote: My example (2nd part of it) was actually wrong. It was mentioned before On 01/05/2024 19:43, Jean SUZINEAU via fpc-pascal wrote: I didn't tested but I imagine it could be done with something like this ? type TWindow_Class= class of TWindow; begin

Re: [fpc-pascal] Type-casting a class variable

Olivier Sannier via fpc-pascal wrote: Hello, You should cast to TWindowClass as TWindow is used to cast an instance, not a class reference. Note that you may not have TWindowClass, in which case you need to declare it like this: type TWindowClass = class of TWindow; OK. A typecast w

Re: [fpc-pascal] Sub-millisecond time measuring

Hairy Pixels via fpc-pascal wrote: I had a large function which I was profiling with MilliSecondsBetween but I split it to be called many different times and now it's not accumulating the total time correctly because time is being lost to due millisecond precision. Is there anything in the RTL

Re: [fpc-pascal] Sub-millisecond time measuring

Michael Van Canneyt via fpc-pascal wrote: Is that a function in the RTL? I can't find it. No, these are platform-specific functions. g_get_monotonic_time is probably just an alias for the linux/freebsd unit functions clock_gettime(CLOCK_MONOTONIC_RAW). g_get_monotonic_time is in glib

Re: [fpc-pascal] Sub-millisecond time measuring

Sven Barth via fpc-pascal wrote: I wouldn't introduce a dependency for something like GTK (especially GTK!) on macOS only to receive some timings. Simpler and more straight forward to just use the correct functions of the OS. Of course not, Unless you are doing some cross-development, develo

[fpc-pascal] Building for Arduino

I am trying to build fpc for Arduino on MacOS 10.8.5, using the fpc-3.0.4 sources and fpc-3.0.4 as bootstrap compiler. GNU binutils have been built and installed (but not yet avrdude). As suggested here I use make clean crossa

Re: [fpc-pascal] Building for Arduino

Christo Crause via fpc-pascal wrote: The level of support for AVR in 3.0.4 was rudimentary, only atmega128 is supported in the MakeFIle. The support for AVR is still improving with time so use either the development branch, or the latest release version (if you prefer release versions). The

Re: [fpc-pascal] Building for Arduino

Christo Crause via fpc-pascal wrote: The assembly line you showed above is obviously missing a closing parenthesis, so the error from avr-as is correct. I tested building ppcrosssavr 3.2.2 with all your cross options and added -a to retain the generated assembler source. This worked fine and

Re: [fpc-pascal] Building for Arduino

Christo Crause via fpc-pascal wrote: PS. My avr binutils version is 2.26 - old, but your version is about 10 years older still. WIth avr binutils 2.26 built and installed, the compiler builds ! adriaan% /usr/local/bin/ppcrossavr -v Free Pascal Compiler version 3.2.2 Compiler date : 2024

Re: [fpc-pascal] Building for Arduino

Adriaan van Os via fpc-pascal wrote: Christo Crause via fpc-pascal wrote: PS. My avr binutils version is 2.26 - old, but your version is about 10 years older still. WIth avr binutils 2.26 built and installed, the compiler builds ! /usr/local/bin/ppcrossavr -i says Supported FPU instruction

Re: [fpc-pascal] AllocateThreadVars ?

In a small test program, exception handling works, in the main thread, with BeginThread as well as with pthread_create. In the big program, it doesn't. So the mystery still to solve, is why Maybe this is related to as the code r

[fpc-pascal] AllocateThreadVars ?

I have a program on MacOS that calls CoreAudio which calls the application back in a so-called AURendererCallback in a separate (com.apple.audio.IOThread.client) thread. This is a pthread created by the system software, not by the FreePascal RTL. In that thread, a FreePascal try except block do

Re: [fpc-pascal] AllocateThreadVars ?

Sven Barth via fpc-pascal wrote: Adriaan van Os via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Mi., 9. Okt. 2024, 16:44: I have a program on MacOS that calls CoreAudio which calls the application back in a so-called AURendererCallback in a

Re: [fpc-pascal] AllocateThreadVars ?

Adriaan van Os wrote: In that thread, a FreePascal try except block doesn't catch an exception. A globally installed TExceptProc does. if I look in the RTL code, it looks like a thread created with BeginThread does some extra things, like calling SysAllocateThreadVars. A comment notes that exc

Re: [fpc-pascal] AllocateThreadVars ?

Sven Barth via fpc-pascal wrote: You already wrote that you might have found a different cause, but nevertheless to clarify: the RTL initialization for the thread (which includes AllocateThreadVars) should already be done transparently by the RTL through hooks provided by pthread. Yes, I fo

Re: [fpc-pascal] AllocateThreadVars ?

In a small test program, exception handling works, in the main thread, with BeginThread as well as with pthread_create. In the big program, it doesn't. So the mystery still to solve, is why Maybe this is related to as the code r

Re: [fpc-pascal] Library packages

Sven Barth via fpc-pascal wrote: The main difference is that a program or library compiled without dynamic packages will each have a statically linked copy of the RTL (and any other code it uses). If a binary uses dynamic packages then the binary itself will not contain code that is contained

[fpc-pascal] type helpers in trunk

Has something changed for type helpers in fpc trunk ? I don 't see a note of it in . I have code that compiles with 3.2.2, but the trunk compiler doesn't recognize (or doesn't accept) dot operations on the type. Very strange. Regards, Adriaan van

Re: [fpc-pascal] type helpers in trunk

Thomas Kurz via fpc-pascal wrote: Do you have `{$MODESWITCH TYPEHELPERS}`? Yes ! Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Library packages

Can someone tell me what the status is of Library packages, aka "Delphi packages" ? I found the WIki but it looks like a preliminary document. My questions 1. For MacOS, are there any differences at the Mach-O level between a dynamic library and a library

[fpc-pascal] Namespace collisions

In ObjectiveC we have the infamous namespace collision problem. I am wondering how this applies to Objective Pascal. For example, I have a plugin, written in Pascal, with only one global external symbol, the plugin entry point a6d0 (__TEXT,__text) external _MyPluginEntryPoint

[fpc-pascal] dlmopen on MacOS

I have a shared library on MacOS written in FPC. It needs to be loaded multiple times, that is each time with its own set of global (dylib) variables. On Linux I would use dlmopen with LM_ID_NEWLM, but MacOS doesn't have dlmopen and dlopen doesn't have LM_ID_NEWLM. I can create a copy of the dyl

Re: [fpc-pascal] Printing unicode characters

Hairy Pixels via fpc-pascal wrote: ChatGPT is saying I can print unicode scalars like that but i don’t see it works and no compiler warnings even. Did it make this up or did I do something wrong? Writeln('Unicode scalar 1F496: ', #$1F496); // 💖 Writeln('Unicode scalar 1F496: ', WideChar($

Re: [fpc-pascal] Power operator fails in ordinal range definition

Hairy Pixels via fpc-pascal wrote: On Nov 14, 2024 at 1:53:17 PM, Sven Barth via fpc-pascal > wrote: The **-operator is not *implemented* by the compiler. It's provided through the Math unit. Thus you can't use it in constant declarations. Why is that

Re: [fpc-pascal] Incremental compiling not working in new version

Sven Barth via fpc-pascal wrote: Hairy Pixels via fpc-pascal > schrieb am Mi., 4. Dez. 2024, 13:56: Were there known changes in that area since March 3rd 2023? Honestly they were causing so many crashes maybe they got pulled for incremental bu

Re: [fpc-pascal] Procedural parameters

Michael Van Canneyt via fpc-pascal wrote: Also, I wonder if "ISOPROGRAMPARAS" in the Programmer's Guide is spelled correctly. It is, as that is what is used in the compiler: globtype.pas:736 I don't mind, but it is rather weird/amusing Webster's dictionary para noun A piece of Turkish

Re: [fpc-pascal] Procedural parameters

Hairy Pixels via fpc-pascal wrote: On Dec 15, 2024 at 1:22:25 AM, Adriaan van Os via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> wrote: Similarly, you also cannot write: function A(B : (one,two,three)) : double; Not really. The function type declaration is a Borland inven

Re: [fpc-pascal] Procedural parameters

Michael Van Canneyt via fpc-pascal wrote: On Sat, 14 Dec 2024, Adriaan van Os via fpc-pascal wrote: It's not because something is in the pascal standard, that FPC has it. It is. Appendix D6 of the Programmer's Reference says "This mode is selected by the $MODE ISO

Re: [fpc-pascal] Procedural parameters

Hairy Pixels via fpc-pascal wrote: On Dec 15, 2024 at 12:21:29 PM, Adriaan van Os via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> wrote: You mean the original pascal only allowed function declarations to be parameter types? Yes. And it is still true in the ISO 7185 Pascal

Re: [fpc-pascal] Procedural parameters

Michael Van Canneyt via fpc-pascal wrote: On Sat, 14 Dec 2024, Adriaan van Os via fpc-pascal wrote: Macpascal and Iso pascal have procedural parameters, e.g. function A( function B: double): double; Is there a $modeswitch to allow this ? I searched "procedure parameter

[fpc-pascal] Procedural parameters

Macpascal and Iso pascal have procedural parameters, e.g. function A( function B: double): double; Is there a $modeswitch to allow this ? I searched "procedure parameter" and "procedural parameter" in the Language Reference, but could not find anything. Also, I wonder if "ISOPROGRAM

Re: [fpc-pascal] InterlockedExchangeAdd64

Sven Barth via fpc-pascal wrote: Am 10.01.2025 um 15:43 schrieb Adriaan van Os via fpc-pascal: I have an arm64 (aarch64) test program on MacOS that calls InterlockedExchangeAdd64 with a target variable that is not 8-byte aligned. Running the test program emits "EBusError: Bus err

Re: [fpc-pascal] External library name

Hairy Pixels via fpc-pascal wrote: I see this pattern in C translated header often but I’ve honestly never understood it entirely. Why does this “cDllName" need to be added to every single function which you could just use {$linklib }? This is a habit from the WIndows and Delphi world. In

[fpc-pascal] InterlockedExchangeAdd64

I have an arm64 (aarch64) test program on MacOS that calls InterlockedExchangeAdd64 with a target variable that is not 8-byte aligned. Running the test program emits "EBusError: Bus error or misaligned data access". So far so good. But now I install a system.ErrorProc and run the same progr

Re: [fpc-pascal] InterlockedExchangeAdd64

Is this really a bug? This depends on what you do in your ErrorProc implementation, doesn't it? Do a writeln the runtime number and break. But normally, a bus error, doesn't call into System.ErrorProc. Regards, Adriaan van Os ___ fpc-pascal mai

Re: [fpc-pascal] Exception handling and .dylibs on MacOS

Sven Barth wrote: Adriaan van Os mailto:adri...@adriaan.biz>> schrieb am Do., 3. Apr. 2025, 14:47: Well, in what form will a patch along these lines be accepted ? I really need this to be fixed. In no form, cause this is not a way in which we want to see this fixed. So, how are you

[fpc-pascal] Exception handling and .dylibs on MacOS

I recall this thread from last October I reported this, with a test program, as bug #40950 . The problem is that the fpc RTL, with its global variables, is duplicated in the .dylib as well as in the main program, which confuses the

<    1   2