[fpc-pascal] String error on Windows

Why isn't this syntax valid on Windows? Very confused. {$mode objfpc} program WindowsTest; var s: String; begin s += ';';// Syntax error, ";" expected but "const char" found end. ___ fpc-pascal maillist - fpc-pascal

[fpc-pascal] ExtractStrings by line in Windows

On Mac I had used ExtractStrings([LineEnding], [], str, list); to split a string by line but on Windows LineEnding is 2 chars long so the char set parameter doesn't work. What is the solution to this on Windows? ___ fpc-pascal maillist - fpc-pascal@li

[fpc-pascal] JSON RPC on Mac M1 fails

I don’t know where to start debugging this yet but I found that compiling for the aarch64 target now breaks my Pascal language server which uses JSON RPC. It breaks early on when sending the first message (initialize) which I register like this: JSONRPCHandlerManager.RegisterHandler('in

Re: [fpc-pascal] JSON RPC on Mac M1 fails

> On Mar 9, 2022, at 10:48 PM, Michael Van Canneyt via fpc-pascal > wrote: > >> It breaks early on when sending the first message (initialize) which I >> register like this: >> >> JSONRPCHandlerManager.RegisterHandler('initialize', TInitialize); > > So you get an exception here ? No th

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 21, 2022, at 3:48 AM, Mattias Gaertner via fpc-pascal > wrote: > >> Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR >> Writeln(Apply(@NegFunc, 42)); // will write -42 >> end. > > Mind boggling. :) This was actually your idea if I remember correctly. :) I think you said even

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

If you want to pass a pointer to ^T in a generic function is there anyway safe to do this currently? Pascal doesn’t allow ^ types in function arguments (why?) and generics don’t seems to support pointers either (why?). generic TValues = array[0..0] of T; generic PValues = ^specialize TValues

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 20, 2022, at 1:15 PM, Sven Barth via fpc-pascal > wrote: > > Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR > Writeln(Apply(@NegFunc, 42)); // will write -42 For Sven, this reminds me, since we got this merged in now does that mean closures are ready? :D Regards,

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal > wrote: > > How many percent of the users need this feature? > Is it a feature that is a must? > Can everyone get also a solution without the feature? > Does it justify the risk of the whole language (has the potential to break >

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 23, 2022, at 5:18 AM, Martin Frb via fpc-pascal > wrote: > > Done > https://gitlab.com/freepascal.org/fpc/source/-/issues/39684 > https://gitlab.com/freepascal.org/fpc/source/-/issues/39685 It looks like I need to do some cleanup phase. I can’t remember how it works right now but I

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 23, 2022, at 3:40 PM, Sven Barth via fpc-pascal > wrote: > > For 2) I'm also of the opinion of the others: this is unneeded syntactic > sugar. There is already a way to declare arrays with a specific size and for > a language it's in nearly all cases not good to provide multiple ways

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 23, 2022, at 10:30 PM, Marco van de Voort via fpc-pascal > wrote: > > Btw since you are afaik an Apple user, did you actually use conformant > arrays, or do you base this on UCSD/Borland dialects only? I started with THINK Pascal on classic Mac OS but I never heard of conformant a

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 23, 2022, at 9:09 PM, Hairy Pixels wrote: > > The two languages I use commonly these days are Swift and C#, both of which > do implicit function specialization by default. After you use a generic > function a couple times it becomes apparent the compiler could infer the > types and

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 25, 2022, at 2:39 PM, Martin Frb via fpc-pascal > wrote: > > Actually, it's dealing with SmallInt (or ShortInt). And if the programmer > does not know that, then it might be an issue... > > Imagine the generic code (something more complex than "Add") would somehow do > something t

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 25, 2022, at 4:11 PM, Sven Barth wrote: > > Then you don't think creative enough. Think about (de)serialization code for > binary data which needs to use the correct size. If done correctly this can > very well be handled with a generic. > Oh yes that’s right. I guess I would need

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 25, 2022, at 7:14 PM, Sven Barth via fpc-pascal > wrote: > > For some reason I don't get all mails by Ryan, so I reply here: > > Helpers currently can't be generic and even if they could be (which I do plan > to add) it would require an explicit specialization of the helper to be u

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 25, 2022, at 8:27 PM, Hairy Pixels wrote: > >> For some reason I don't get all mails by Ryan, so I reply here: >> >> Helpers currently can't be generic and even if they could be (which I do >> plan to add) it would require an explicit specialization of the helper to be >> used becau

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 30, 2022, at 7:02 PM, Mattias Gaertner via fpc-pascal > wrote: > > AFAIK it is planned for mode objfpc to support distinguishing types via > template count as in mode delphi: > > type > TMyClass = class > end; > generic TMyClass = class > end; > generic TMyClass = class > end; > > S

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On Apr 30, 2022, at 6:17 PM, Hairy Pixels wrote: > > 2) Right now helpers only support single types but they would need to be > extended to support “array of T”, “set of T”,which by, why aren’t those > supported as it is? I can’t seem to think of any reason they should be > disallowed. The

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> On May 1, 2022, at 10:36 AM, Hairy Pixels wrote: > > Not sure what the best solution is but here are the ones I can think of: > > 1) allow the helpers to use “array/set of T” syntax. Sorry for the noise, one last point on this. So it looks like type helpers are already so strictly typed th

[fpc-pascal] alloca

Is there an “alloca" like function in the RTL which allocates memory from the stack? For example https://man7.org/linux/man-pages/man3/alloca.3.html Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.

Re: [fpc-pascal] alloca

> On May 13, 2022, at 11:08 PM, Michael Van Canneyt via fpc-pascal > wrote: > >> Is there an “alloca" like function in the RTL which allocates memory from >> the stack? For example https://man7.org/linux/man-pages/man3/alloca.3.html > > No such function exists in FPC. Is alloca something wh

Re: [fpc-pascal] alloca

> On May 14, 2022, at 1:03 PM, Michael Van Canneyt via fpc-pascal > wrote: > > As far as I can see, it can only be implemented in the compiler. > Only the compiler knows how much stack it uses for a certain routine. the > alloca needs to interact with this. FPC also has the nostackframe > mo

Re: [fpc-pascal] alloca

> On May 14, 2022, at 1:01 PM, Jonas Maebe via fpc-pascal > wrote: > > It *requires* compiler support for... The RTL has get_frame but that just tells you the start of the frame right? If you had the stack pointer address you could advance that pointer x bytes and get a new location in the

Re: [fpc-pascal] alloca

> On May 14, 2022, at 4:04 PM, Jonas Maebe via fpc-pascal > wrote: > > No, because most modern OSes don't allow you to address memory below the > stack pointer (and for the ones that do to a limited extent, the compiler > could be using that memory already). I thought the stack had a fixed

Re: [fpc-pascal] alloca

> On May 15, 2022, at 12:00 AM, Dennis Lee Bieber via fpc-pascal > wrote: > > Non-portable would be in-line assembly supporting "PUSH"/"PULL/POP" > operations on the stack. But would they be able to ensure the unwind works > properly? After all, one could POP data all the way back into t

[fpc-pascal] Element type of set at compile time

Is there a compiler intrinsic to get the element type of a set at compile time? So if you have “set of T” it should return T. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/

Re: [fpc-pascal] Element type of set at compile time

> On May 15, 2022, at 2:03 PM, Michael Van Canneyt via fpc-pascal > wrote: > > Type > TMySet = set of (one,two,three); > > The element type does not exist as a separate type. I mean if you had code like this T would be the anonymous enum (one,two,three). Maybe element is not the correct te

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

> On May 27, 2022, at 2:47 AM, Sven Barth via fpc-pascal > wrote: > > Further RTL enhancements like the declaration of TProc<> or the addition of a > TThread.Queue() that takes a function reference will come in the near future > now that the basics on the compiler side are done. Maybe we can

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

I’ve had some time to play with this now and my first piece of feedback is that given my experience with other languages, the most common usage of closures is by passing them as arguments to functions. Compared to the other languages I’m using now I’d say that we should be inferring more of the

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

> On May 28, 2022, at 2:06 PM, Michael Van Canneyt via fpc-pascal > wrote: > > Ah... > > The desire to make a programming language terse and unreadable as a > consequence. > If you want that, use C#, Javascript or one of the ubiquitous languages for > bracket fetishists. > Scala & Rust top

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

> On May 28, 2022, at 6:39 PM, Michael Van Canneyt via fpc-pascal > wrote: > > And I'm sure it finds these very understandable (live examples): > > [s: string]: ((s: string, cb: (done: any) => void) => void) & ((cb: (done: > any) => void) => void) & {only: any, skip: any}; > load: (url: stri

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

> On May 28, 2022, at 7:04 PM, Benito van der Zander via fpc-pascal > wrote: > > The "result" variable is also ugly. You could make "if" an expression: > > Sort( @(left, right) begin > result := > if left < right then -1 > else

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

> On May 27, 2022, at 6:31 PM, Marco van de Voort via fpc-pascal > wrote: > > Ditto! https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39774 > > This ticket also contains an experimental patch for anonymous method queue > and synchronize. (required to reproduce) Yeah code tools is

[fpc-pascal] "Is nested" vs "of object" compatibility with global functions

I’ve been testing out all the different function pointer types in FPC to test their compatibility with each other and I noticed that “is nested” can accept a global function declaration but “of object” can not. What is the reason for this exactly? I wouldn’t expect nested function types to accep

Re: [fpc-pascal] "Is nested" vs "of object" compatibility with global functions

> On May 29, 2022, at 2:26 PM, Martin Frb via fpc-pascal > wrote: > > Actually afaik you push an extra param in for "is nested" as well as for "of > object. > > But for "of object" it is the first param, for "is nested" it is the last. Then “references to” is the only universal function poi

Re: [fpc-pascal] "Is nested" vs "of object" compatibility with global functions

> On May 29, 2022, at 2:26 PM, Martin Frb via fpc-pascal > wrote: > > Actually afaik you push an extra param in for "is nested" as well as for "of > object. > > But for "of object" it is the first param, for "is nested" it is the last. So you can cast nested or object to each other and the

[fpc-pascal] Code tools and function references

Is this issue addressing the fact that the Lazarus code tools is not working with the new syntax? https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39774. If not I’ll open another one. I use code tools for my Pascal language server and it’s basically not usable anymore if you merely a

Re: [fpc-pascal] Be careful of too many features

> On May 31, 2022, at 1:59 AM, Steve Litt via fpc-pascal > wrote: > > The example code I've seen in the "Feature Announcement: Function > References and Anonymous Functions" not only doesn't look like any > Pascal I've ever seen, but it resembles Perl (the "one language on a > desert island"

Re: [fpc-pascal] Be careful of too many features

> On May 31, 2022, at 9:12 AM, Steve Litt via fpc-pascal > wrote: > > I think function references and to a lesser extent anonymous functions > are necessities. Things I consider Perlization are things like > inferring context of the receiving function, "Sort( @(left, right) > begin", and other

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 6, 2022, at 2:02 AM, Jonas Maebe via fpc-pascal > wrote: > > On 2022-06-05 18:20, Anthony Walter via fpc-pascal wrote: > >> As the "reference to" feature was recently added to fpc trunk, I'd like to >> ask if internally there are any penalties (performance perhaps) or drawbacks >>

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 6, 2022, at 8:26 AM, Hairy Pixels wrote: > > I think what the compiler needs to do is internally support a variant record > type and switch to the correct function type at runtime. Something like this: > > TCallback = record > kind: byte; > case byte of > 0: (proc: procedure); > 1: (

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 6, 2022, at 8:26 AM, Hairy Pixels wrote: > > First off I didn’t see Anthony’s original email, just like Sven says he > doesn’t see mine. What’s going on here? I’m using a Gmail account because my > personal domain was getting rejected for some reason, is Anthony on Gmail > also? We

[fpc-pascal] Calling undefined function pointers in generics

This code snippet will give a compiler error "Syntax error, ";" expected but "(“ found”. It’s an unspecialized generic type so I would think it should compile and only attempt to validate the parameters when the function is specialized. generic procedure Perform(func: T); begin func(1); end;

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 19, 2022, at 7:01 PM, Sven Barth via fpc-pascal > wrote: > > As I can see neither Anthony's nor Ryan's mail, but I can see them in the > archive, I'll use Jonas mail for some general replies (please CC me when > replying): Firstly unrelated, I posted a question about generics which

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 19, 2022, at 10:04 PM, Sven Barth wrote: > > As you can see the allocation only happens once and not all the time. > What might be worse however is the optimization behavior as in this example > the compiler wouldn't optimize the counter variable into a regvar with > enabled optimiz

Re: [fpc-pascal] Calling undefined function pointers in generics

NOTE: I’m replying to this and CC’ing Sven so hopefully he can see it. > On Jun 19, 2022, at 10:05 AM, Hairy Pixels wrote: > > This code snippet will give a compiler error "Syntax error, ";" expected but > "(“ found”. It’s an unspecialized generic type so I would think it should > compile and

Re: [fpc-pascal] Calling undefined function pointers in generics

> On Jun 20, 2022, at 7:12 PM, Sven Barth wrote: > > Please report a bug. > Done. https://gitlab.com/freepascal.org/fpc/source/-/issues/39794. I may actually try to fix this myself since I may know what the problem is. And on that note did you notice I made a PR for your idea of a generic

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 20, 2022, at 12:44 PM, Sven Barth wrote: > > If the compiler can proove that the function reference never leaves the scope > (that means no assignment to global variables, out/var parameters, the Result > variable, passing on to some other function or conversion to pointer (and I'm

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

Can anyone explain why this works? TProc is a normal function pointer so how did it capture gVar? My understanding is that only nested proc vars could do this. {$mode objfpc} {$modeswitch anonymousfunctions} program anonymous_functions; type TProc = procedure; procedure Call(proc: TProc); b

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 20, 2022, at 8:30 PM, Michael Van Canneyt via fpc-pascal > wrote: > > My point is that if someone creates an API where he/she uses "reference to > procedure" then the consumer of the API is stuck with the creation of an > interface. > > So it's not always a choice whether an interf

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

> On Jun 20, 2022, at 8:39 PM, Michael Van Canneyt via fpc-pascal > wrote: > > It allows you to run callbacks without having to declare variables globally: > > Function DoSomething : String; > > var > L : TStringList; > > begin > L:=TstringList.Create; > SomeCallBack(procedure(s : string) >

Re: [fpc-pascal] Mail Test

Yes I can see this one. I sent this reply to fpc-pascal@lists.freepascal.org and didn’t CC you. > On Jun 21, 2022, at 4:08 PM, Sven Barth via fpc-pascal > wrote: > > This is just a test of the mailing list. > > @Ryan: if you can see this, would you please reply with only the list, but > not

[fpc-pascal] Arguments gets corrupted with anonymous nested function

The following program uses an anonymous nested function which captures a local variable. It seems the arguments get corrupted (likely because of the hidden first param for the nested function signature) and prints garbled data. I reduced this snippet down from another project but I’m not sure if

Re: [fpc-pascal] Arguments gets corrupted with anonymous nested function

> On Sep 4, 2022, at 1:36 PM, Sven Barth wrote: > > Does this also happen if you don't use a class? Otherwise it might be related > with the other error you already reported. But report this anyway, I'll > simply mark it as duplicate if necessary... > I only reproduced using a class with g

[fpc-pascal] Get TMethod from function reference

A function reference can call a class method but can you get the TMethod data from function references? It was possible with “is object” to cast to TMethod but that doesn’t seem to be possible with references. = type TMyClass = class constructor Create; procedure DoThis; end

Re: [fpc-pascal] Get TMethod from function reference

> On Sep 8, 2022, at 9:09 AM, Michael Van Canneyt > wrote: > > To me it seems logical that you cannot do this, since a function reference is > actually an > interface, and there is no actual object to back it up. > > Your function reference could also be a regular procedure (no data at all)

Re: [fpc-pascal] Get TMethod from function reference

> On Sep 8, 2022, at 11:14 AM, Michael Van Canneyt via fpc-pascal > wrote: > > It must keep this information somewhere, but this does not mean you can > typecast it to a TMethod. Indeed. I wonder if this information could be exposed by some method in the interface? It would be useful to int

[fpc-pascal] Why does nested function get corrupted?

Curious more than anything, if is nested captures state in a record and passes it as an hidden self param, why does returning the variable and calling from outside the calling stack frame corrupt the data? It seems like it technically should be there. == type TProc = procedur

[fpc-pascal] Internal error 2019022201 from function reference

This program gives internal compiler error 2019022201 (Free Pascal Compiler version 3.3.1 [2022/05/27] for aarch64). Something is wrong with the PPU. This is a very basic program using function references so it seems unlikely it could not be known. Any ideas? {$mo

Re: [fpc-pascal] Why does nested function get corrupted?

> On Sep 9, 2022, at 4:48 PM, Sven Barth wrote: > > How about you simply report such corruptions as bugs? I can always close them > as "not a bug" or duplicate if necessary. > Well I thought the data may have been saved on the stack and thus lost when the function exits. What is the expec

Re: [fpc-pascal] Get TMethod from function reference

> On Sep 15, 2022, at 12:28 PM, Sven Barth wrote: > > As mentioned elsewhere function references are in fact interfaces. And you > can't retrieve a method pointer to a interface function, cause relying on > that would result in either memory leaks or premature release of the > interface, bec

Re: [fpc-pascal] Get TMethod from function reference

> On Sep 11, 2022, at 3:28 PM, Ondrej Pokorny via fpc-pascal > wrote: > > You should be able to get the Invoke procedure pointer from the RTTI. Sorry Sven mentioned this I must have glossed over it. So yes I am storing the function reference in a class so it’s not going to get freed. Given

Re: [fpc-pascal] Internal error 2019022201 from function reference

> On Sep 11, 2022, at 4:22 PM, Sven Barth wrote: > > Why do you think it's not known if there is an internal error? Internal > errors are precisely there to cover cases that should not be taken, but are > then triggered by some code path that was not thought about. > As a general rule: alway

[fpc-pascal] Function reference doesn't capture in thread

Can anyone explain why this program doesn’t capture the state of the local variable “I” and execute in order? It will return something like this: Invoked: 3 id: 0001029D41C0 Invoked: 0 id: 0001029D42C0 Invoked: 0 id: 0001029D44C0 Invoked: 0 id: 0001029D43C0 It works if you call S

Re: [fpc-pascal] Function reference doesn't capture in thread

> On Sep 17, 2022, at 7:40 PM, Sven Barth wrote: > > It seems you haven't read the part about capturing variables in my > announcement mail, cause you have two problems: > First the specific problem your code has: i is a global variables and global > variables are *never* captured, because th

Re: [fpc-pascal] Function reference doesn't capture in thread

> On Sep 17, 2022, at 9:43 PM, Sven Barth wrote: > > Then you didn't read my announcement mail deeply enough, cause it's mentioned > there! Yes I just read that over and I remember it now. I feel like this not the same behavior in other languages although I’d need to test. Most recently I’m

Re: [fpc-pascal] Get TMethod from function reference

> On Sep 17, 2022, at 10:57 PM, Sven Barth wrote: > > === code begin === > > type > TProc = reference to procedure; > TMyClass = class > procedure DoThis; > end; > > TCapturer = class(TInterfacedObject, TProc) > m: procedure of object; > procedure Anonymous1; > > proc

Re: [fpc-pascal] Function reference doesn't capture in thread

> On Sep 17, 2022, at 10:51 PM, Sven Barth wrote: > > Complain to the developers of Delphi then. > > I do however plan to extend anonymous (and nested) functions with a syntax > that allows to select whether a variable should be by-reference or by-value. > But that's still a bit off, cause I

[fpc-pascal] $modeswitch declared before $mode fails without warning

One more thing today working with closures. Declaring the modeswitch before the mode does not actually enable the feature and gives no warning. What happens then is basic syntax fails and you’re totally confused as to why. Shouldn’t this be illegal or give a warning at least? {$modeswitch funct

Re: [fpc-pascal] $modeswitch declared before $mode fails without warning

> On Sep 18, 2022, at 7:37 PM, Florian Klämpfl via fpc-pascal > wrote: > > This is in general the case that $mode overrides all previously set switches > i.e. it simply sets the switches as defined by the given mode so I am not > sure if this is really worth a warning. Is there ever a time

Re: [fpc-pascal] Get TMethod from function reference

> On Sep 19, 2022, at 4:17 PM, Sven Barth wrote: > > === code begin === > > Proc1 := @c.OnChange; > Proc2 := @c.OnClick; > Proc3 := @c2.OnChange; > > === code end === > > Will result in the following capture object: > > === code begin === > > type > TCapturer = class(TInterfacedObject,

[fpc-pascal] Enum property can't be published

I just tried to build a lazarus project using 3.3.1/ppca64 and I’m getting an error that an enum can’t be published. This was working on 3.2.2/ppcx64 so what changed? === lazbuild ./pasls.lpi --widgetset=cocoa --compiler=/usr/local/lib/fpc/3.3.1/ppca64 --cpu

Re: [fpc-pascal] Enum property can't be published

> On Sep 27, 2022, at 4:17 PM, Marco van de Voort via fpc-pascal > wrote: > > 3.2.2 compiles without warnings, 3.3.1 (i386-win32 from 17 sept:) > > ptt.pp(14,44) Warning: This property will not be published > > Possibly enums with assigned values (which can have gaps) are not safe to > pub

Re: [fpc-pascal] Enum property can't be published

> On Sep 27, 2022, at 5:19 PM, Pierre Muller via fpc-pascal > wrote: > > TDiagnosticSeverity = ( NoError { will be 0}, > Error {will stay equal to 1}, > Warning {will stay equal to 2}, > Information {will stay equal to

Re: [fpc-pascal] Enum property can't be published

> On Sep 27, 2022, at 5:31 PM, Ondrej Pokorny via fpc-pascal > wrote: > > published > property MyEnumOrd: Integer read GetMyEnumOrd write SetEnumOrd; // > gets/sets MyEnum as ordinal value Yeah I guess that work also albeit with some boiler plate. Thanks. Regards, Ryan Joseph __

[fpc-pascal] JSON RPC changes in 3.3.1

So I got the project building after changing the enums but now after running the server breaks after sending the first request and I get the error "'No class "initialize" with method "initialize" was found”. Here’s a little snippet of the messages I got back but I don’t even know where to start

Re: [fpc-pascal] JSON RPC changes in 3.3.1

> On Sep 28, 2022, at 1:34 PM, Luca Olivetti via fpc-pascal > wrote: > > Maybe related to this? > > https://lists.freepascal.org/pipermail/pas2js/2022-September/00.html The question then is did they change something in 3.3.1 in regards to how parameters can be sent? The error "Parameter

Re: [fpc-pascal] JSON RPC changes in 3.3.1

> On Sep 28, 2022, at 1:51 PM, Hairy Pixels wrote: > > The question then is did they change something in 3.3.1 in regards to how > parameters can be sent? The error "Parameters must be passed in an object or > an array.” Suggests maybe I was sending the params as some other type and > this

[fpc-pascal] TJSONParser crash

Ok I narrowed down this bug I get with 3.2.2 to TJSONParser. I’m so confused as to what changed. FormatJSON prints the JSON as expected but AsString crashes and gives the error I was seeing from the RPC which it trapped as an exception. When it’s send across the RPC layer it must call AsString

Re: [fpc-pascal] TJSONParser crash

> On Sep 28, 2022, at 10:32 PM, Michael Van Canneyt > wrote: > > Of course, as AsString will not work on a TJSONObject. AsString will only > work on the simple types, not on the object or array types or null. Of course. :P Ok I was just being stupid and let one of those calls slip in as I

Re: [fpc-pascal] JSON RPC changes in 3.3.1

> On Sep 28, 2022, at 10:56 PM, Michael Van Canneyt > wrote: > > The error "Can't find class 'initialize' with method 'initialize'" is an > error (uninitialized variable) that has now been fixed. You mean you just fixed it in trunk? I hope so. It was driving me crazy trying to figure out we

Re: [fpc-pascal] JSON RPC changes in 3.3.1

Thanks Michael! > On Sep 29, 2022, at 9:29 PM, Michael Van Canneyt via fpc-pascal > wrote: > > Yes. It was committed & pushed yesterday. > Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepa

Re: [fpc-pascal] JSON RPC changes in 3.3.1

Yes you indeed fixed it! Thanks again. > On Sep 29, 2022, at 9:35 PM, Michael Van Canneyt > wrote: > > > First see if it fixes your problem, then thank me ;-) > > Michael. > > On Thu, 29 Sep 2022, Hairy Pixels wrote: > >> Thanks Michael! >> >>> On Sep 29, 2022, at 9:29 PM, Michael Van Cann

[fpc-pascal] JSONToObject with array of any type

I have some JSON with a “arguments” value which can be an array of JSON type. When it’s received and parsed with TJSONDeStreamer.JSONToObject how can I represent this “any” type? I tried using TJSONArray but it always returns an empty array. The JSON is parse: { "command": "do_stuff",

[fpc-pascal] JSON RPC send server request to client

Quick question, I’ve been using the JSON RPC package to receive messages from the client and dispatch methods but I need to send a request from the server to the client now. Is this possible in the library? I can’t find a method in TCustomJSONRPCDispatcher which seems appropriate. Thanks! Regar

Re: [fpc-pascal] JSON RPC send server request to client

> On Oct 2, 2022, at 9:16 AM, Michael Van Canneyt > wrote: > > There is no way to send data from server to client, only responses to client > requests. > > What's more, HTTP 1 and 1.1 simplu do not allow this. > You'd need HTTP2 and/or websockets in order to send data from server to > client

Re: [fpc-pascal] JSON RPC send server request to client

> On Oct 2, 2022, at 10:23 AM, Hairy Pixels wrote: > > So I need to send the message manually back to the client (the IDE) with the > ID which JSON RPC requires also. I’m confused about the ID in particular and > if it can be anything or it needs to be generated in the same stream as > exist

Re: [fpc-pascal] JSON RPC send server request to client

> On Oct 3, 2022, at 10:48 PM, Michael Van Canneyt via fpc-pascal > wrote: > > FPC's JSON-RPC is designed to be used using HTTP(s) transport only, i.e. > synchronous request and answer. > > Hence Ryan's failure to achieve what he wants to do. > > But if changes need to be made to make it usa

[fpc-pascal] CodeTools complete code

I’m trying to use the CompleteCode function in the CodeTools library and doing some formatting I don’t want. Calling it over the “MyProcedure” method in the class it added a comment and moved the declaration under the variable section instead of directly under the class declaration like I would

Re: [fpc-pascal] CodeTools complete code

> On Oct 4, 2022, at 2:40 PM, Mattias Gaertner via fpc-pascal > wrote: > > If you don't want the comment above the class, use > > with CodeToolBoss.SourceChangeCache.BeautifyCodeOptions do > begin > ClassHeaderComments:=false; > ClassImplementationComments:=false; > end; > Great thanks.

Re: [fpc-pascal] CodeTools complete code

Testing now and I found a potential bug in CodeTools. With this code here: Request := specialize TLSPStreaming.ToJSON(Params); I get the error "illegal qualifier . found" @ 146:53. Does CodeTools not understand generic class function calls? Here is the class in question: generic TLSPStream

[fpc-pascal] Variants with classes and records

Is it possible to assign a class to a variant? I tried and get a crash. If not, why not? It’s just a pointer so I would expect it to work. I also see a “varRecord” constant (in varianth.inc) which suggests you could assign a record to a variant but I get an error trying to do this, and honestly

Re: [fpc-pascal] CodeTools complete code

> On Oct 5, 2022, at 4:23 PM, Bart via fpc-pascal > wrote: > > On Wed, Oct 5, 2022 at 8:33 AM Hairy Pixels via fpc-pascal > wrote: > >> Does CodeTools not understand generic class function calls? Here is the >> class in question: > > CodeTools is part

Re: [fpc-pascal] CodeTools complete code

> On Oct 5, 2022, at 7:19 PM, Bart via fpc-pascal > wrote: > > Ok, that makes me kinf of curious wether you and I mean the same when > we refer to CodeTools. > I mean the part of the Lazarus IDE that does code completion etc. > Since you don;t use Lazarus, you must mean something else? I have

Re: [fpc-pascal] Variants with classes and records

> On Oct 6, 2022, at 12:45 PM, Sven Barth wrote: > > Am 05.10.2022 um 14:16 schrieb Hairy Pixels via fpc-pascal: >> Is it possible to assign a class to a variant? I tried and get a crash. If >> not, why not? It’s just a pointer so I would expect it to work. > > T

Re: [fpc-pascal] iOS

> On Oct 6, 2022, at 7:12 PM, Adriaan van Os via fpc-pascal > wrote: > > I would be pleased to know where I can find the latest iOS parsed headers and > possibly a hello program. Also, the cross compilers for iOS don't seem to be > available at on

Re: [fpc-pascal] iOS

> On Oct 6, 2022, at 7:12 PM, Adriaan van Os via fpc-pascal > wrote: > > I would be pleased to know where I can find the latest iOS parsed headers and > possibly a hello program. Also, the cross compilers for iOS don't seem to be > available at on

Re: [fpc-pascal] iOS

> On Oct 6, 2022, at 10:27 PM, wkitty42--- via fpc-pascal > wrote: > >> The last ones I did are ancient now at iOS 8 (where at 13 now!). > iOS 16 is out now... at least for iPhones... i currently have iOS 15.7 > installed... but maybe i'm misunderstanding something? idk... Typo, that’s the m

[fpc-pascal] Iterating over elements from GetDynArrayProp

How can I iterate over the pointer that is returned from GetDynArrayProp? I tried to cast it as a dynamic array of the element type but calling Length() on the returned value gave garbled data. For example with a property of the type “array of TObject": type TObjectArray = array of TObject;

Re: [fpc-pascal] Iterating over elements from GetDynArrayProp

> On Oct 15, 2022, at 3:03 PM, Michael Van Canneyt > wrote: > > as far as I kbow, this should be > ObjectArray := TObjectArray(GetDynArrayProp(AObject, PropertyInfo)); > i.e. you get the actual array as a result. > You’re right, I didn’t need that pointer cast. I’m still curious though why

  1   2   3   4   >