Re: [fpc-pascal] Traits Proposal

This seems possibly a *little* too similar to the existing Interface type in Object Pascal, however, I *would* really like to see some kind of functionality that basically amounts to "has the same capabilities as Interfaces and works on records and objects too, but does NOT require any kind of

Re: [fpc-pascal] fpcmake packaging

What you want is FPMake, not FPCMake. FPCMake is just a generator of GNU makefiles. As Michael said elsewhere though, FPMake is an API designed specifically for compiling FPC programs, basically. You write a program using the API, put it in a file that should always be called "fpmake.pp", and then

Re: [fpc-pascal] Generic type conflicts

On Fri, Nov 8, 2019 at 11:18 AM Ben Grasset wrote: > I know what you mean, and I'm aware, but you actually kind of can to the > fairly straightforward extent that I'm concerned about with Ryan's patch > (i.e. simply passing constant results as constraints rather than function >

Re: [fpc-pascal] Generic type conflicts

On Fri, Nov 8, 2019 at 11:04 AM Jonas Maebe wrote: > You can't. It's the main difference between C++ templates, which is a > Turing-complete programming language, and generics, which is simply a > parametrising mechanic. > I know what you mean, and I'm aware, but you actually kind of can to the

Re: [fpc-pascal] Generic type conflicts

On Fri, Nov 8, 2019 at 1:33 AM Michael Van Canneyt wrote: > As an aside: > In my opinion (keep in mind I am not a big fan of generics) the above code > would be a prime example where one should not be using generics, but > simple overloads. > If you need to use GetTypeKind in a generic, I think

Re: [fpc-pascal] Generic type conflicts

On Thu, Nov 7, 2019 at 10:23 AM Michael Van Canneyt wrote: > If I understood Sven's example correct, then the compiler does exactly this > already. > It does in the sense of *code generation* for things that are specifically compiler intrinsics (which I was aware of), but not in a sense that

Re: [fpc-pascal] Generic type conflicts

On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > If there is no type checking, then it is *not* verified by the compiler. > Perhaps "no type checking" was not the write way to put it. A better way to describe it might be: Since the compiler

Re: [fpc-pascal] Generic type conflicts

On Wed, Nov 6, 2019 at 7:33 PM Ben Grasset wrote: > Encouraging typecasting (which cares only about the sizes of the types > involved, nothing else) at the programmer level is far more error-prone in > a variety of ways. > Also: it's slower in many cases, because it tend

Re: [fpc-pascal] Generic type conflicts

On Wed, Nov 6, 2019 at 12:44 PM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Pascal has a strong type safety, thus something like the if-expression > won't be used/allowed to weaken that. > > If that means that some things can't be implemented in generics the "easy" >

Re: [fpc-pascal] Generic type conflicts

On Wed, Nov 6, 2019 at 2:01 AM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > A normal if-statements has the same non-evaluation. > Not in the way I meant, though. Like, I thought the difference between "normal if" and "ternary if" was supposed to be the same as the

Re: [fpc-pascal] Generic type conflicts

On Tue, Nov 5, 2019 at 5:24 PM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Does this really work? Cause the compiler should nevertheless typecheck > the code in the other branch and thus without casts that shouldn't compile. > Also if it should indeed work, it would also

Re: [fpc-pascal] Generic type conflicts

On Sat, Nov 2, 2019 at 11:51 AM Ryan Joseph via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Are there any solutions for this currently? I feel like generics need to > support some compiler directives so different blocks of code can specialize > different depending on the type. >

Re: [fpc-pascal] for-in loop cast

On Thu, Sep 26, 2019 at 11:59 AM Ben Grasset wrote: > -snip- > I meant to change the last part of the revised code example to: for value in list do because obviously the pointer cast is no longer necessary in that case. ___ fpc-pascal ma

Re: [fpc-pascal] for-in loop cast

On Thu, Sep 26, 2019 at 11:37 AM Ryan Joseph wrote: > Question I’ve always had. Why do I need to cast “value” to “pointer" > otherwise I get: Incompatible types: got "Pointer" expected “TObject” > error?. I don’t find this very helpful and it doesn’t really make sense > even. > Well,

Re: [fpc-pascal] [Lazarus] Tests results of several pascal based JSON parsers

On Sat, Aug 31, 2019 at 9:40 AM Anthony Walter wrote: > > Could you include https://github.com/BeRo1985/pasjson in the comparison? > > Sure. I also have a few other people have requested. I will also list the > license of each in the first table. > Note that I'm not sure if it's FPC-compatible,

Re: [fpc-pascal] Tests results of several pascal based JSON parsers

On Fri, Aug 30, 2019 at 5:16 AM Michael Van Canneyt wrote: > The shootout benchmarks for example are dismally coded for FPC with as a > result that they perform badly. > Not all of them! At least, not anymore:

Re: [fpc-pascal] Virtual object methods

On Thu, Jun 27, 2019 at 5:57 PM Ryan Joseph wrote: > > Heap allocate how so? Calling the constructor seems to fix this and puts > the VMT table on the stack (I think anyways). Btw I’m doing this > specifically as testing for a possible “advancedobjects” mode switch and > the only reason to use

Re: [fpc-pascal] Virtual object methods

On Thu, Jun 27, 2019 at 4:17 PM Ryan Joseph wrote: > Why do I get a runtime error with this? > If you specifically need inheritance (combined with virtual methods) you should probably just use classes, because doing it with objects will require heap allocation regardless.

Re: [fpc-pascal] String conversions

On Wed, Jun 26, 2019 at 5:36 PM Ryan Joseph wrote: > Yes indeed. FPC already has an overwhelming amount of string types. As I > said though a SetCapacity option for growing would be nice (for dynamic > arrays also) because += is such a common operation. As it stands I often > don’t use dynamic

Re: [fpc-pascal] String conversions

On Wed, Jun 26, 2019 at 3:28 PM Ben Grasset wrote: > I think Ryan probably meant his own custom types. And certainly, you can > do some interesting stuff with operator overloading that mostly avoids the > normal AnsiString overhead. Here's an example. > <https://godbolt.o

Re: [fpc-pascal] String conversions

On Wed, Jun 26, 2019 at 5:48 AM Michael Van Canneyt wrote: > I second that. > > Michael. > I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. Here's an example.

Re: [fpc-pascal] not inlined?

On Wed, Jun 19, 2019 at 3:40 PM Ryan Joseph wrote: > What are the rules with he calling context? I didn’t even know that was a > factor! I’ll have to look to get some examples. > Basically, if you're calling a function marked inline from another function, the implementation of the function to

Re: [fpc-pascal] not inlined?

On Wed, Jun 19, 2019 at 2:36 PM Ryan Joseph wrote: > The method TDictionary.IsSet is not able to be inlined but why not? What > are the rules to inlining in FPC? I know calling inherited is not possible > (makes sense) but I often get this warning and I don’t always understand > why. > It

Re: [fpc-pascal] class operator enumerator

Seems like it's mixed up in some way with the FPC-style enumerator operator, so the "class" version is recognized but not actually implemented currently or something. The normal way for classes/records/objects is to implement a GetEnumerator function, anyways. Here's an expanded-on version of

Re: [fpc-pascal] mode switch madness

I dunno about setting them globally, but generally I do find modeswitches rather annoying, as the combination of features is pretty arbitrary, and they mostly just *disallow* things that couldn't break the code of people who weren't using those features to begin with if they were allowed. E.G, I

Re: [fpc-pascal] Constants in generics

Also, there's: pgenutil.pas(158,28) Warning: Class types "tenumdef" and "torddef" are not related which breaks compilation because the compiler is built with -sew turned on if you do it through the normal makefiles. I think you need tests before you do a patch, also? (Unless you already have

Re: [fpc-pascal] Constants in generics

You still have two C-style operator += instances in pgenutil.pas FYI, that don't compile with the default settings. On Sun, Jan 6, 2019 at 8:36 PM Ryan Joseph wrote: > I updated the github with the requested changes. Is that everything? I’ll > submit a patch if so. > >

Re: [fpc-pascal] Constants in generics

On Sun, Jan 6, 2019 at 4:23 PM Ryan Joseph wrote: > This is exactly the reason I added the feature, there’s no way to extend > static arrays otherwise! Beyond this one thing I have no idea what to use > them for. ;) > I've got a bunch of stuff in mind actually that I'm waiting on the "final"

Re: [fpc-pascal] Constants in generics

Just wanted to say, I've been playing around with Ryan's github branch that contains this functionality and I'm loving it! It really opens up a ton of interesting possibilities in general, and also a lot of potential for optimization via constant folding for generic containers that wasn't really

Re: [fpc-pascal] Default properties wiki

Nice! Very thorough. I think most of these are very useful. On Tue, Dec 18, 2018 at 2:32 AM Ryan Joseph wrote: > I decided to make a wiki going over all the details of default properties > which I’ve covered so far, including various usage examples. There’s some > questionable stuff in here and

Re: [fpc-pascal] Default record const values

On Sat, Nov 10, 2018 at 9:03 PM Ryan Joseph wrote: > Not sure how default fields in generics help here. I just thought it would > be nice if FPC supported this so we can init records at compile time > easier. I’d prefer default struct fields like C++ has but typed const > defaults would be an

Re: [fpc-pascal] Constants in generics

On Thu, Nov 8, 2018 at 11:50 PM Ryan Joseph wrote: > Question: should other consts besides integers be allowed? I don’t think > it makes sense personally to use strings, floats or sets but maybe I’m > wrong. > As a daily FPC user there's nothing I find more annoying than compiler restrictions

Re: [fpc-pascal] Default record const values

On Sat, Nov 10, 2018 at 4:06 AM Ryan Joseph wrote: > Should’t this work? This would be a good way to set default record values > but it doesn’t seem to be supported. Personally I think the answer here is keep working on your new/alternate implementation of default field functionality! It's a

Re: [fpc-pascal] Default properties first draft

AFAIK you need to submit a ".patch" file with your changes against the most recent trunk revision to the bugtracker (with the category set to "patch", obviously.) I doubt it'll get considered seriously or looked at at all otherwise. For what it's worth, I did do a checkout of your branch and then

Re: [fpc-pascal] Indexing into records using [] property

If the absence of dereferencing is the most important thing to you, you could do something like this: program Example; {$mode ObjFPC}{$H+} {$modeswitch AdvancedRecords} type TVec2 = record X, Y: Integer; end; TVec2Array = array of TVec2; TVecArray = record strict private

Re: [fpc-pascal] Operator overload bug

On Sat, Aug 4, 2018 at 10:38 AM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > On 28.07.2018 16:38, John Doe wrote: > > On Mon, Jul 23, 2018 at 1:49 PM, Sven Barth via fpc-pascal > > > > wrote: > > > > Ryan Joseph >

Re: [fpc-pascal] Operator overload bug

It's still open by my view, with "new" status: https://bugs.freepascal.org/view.php?id=34021 On Tue, Jul 31, 2018 at 11:47 AM, Ryan Joseph wrote: > > > > On Jul 30, 2018, at 4:11 PM, Ben Grasset wrote: > > > > If you don't have an SVN patch utility ha

Re: [fpc-pascal] Operator overload bug

By looks like I meant, "is", not sure why I wrote that. (I'm Akira1364, by the way.) On Mon, Jul 30, 2018 at 6:11 PM, Ben Grasset wrote: > If you don't have an SVN patch utility handy you could probably just look > at it and apply it to your sources yourself. The final version l

Re: [fpc-pascal] Operator overload bug

If you don't have an SVN patch utility handy you could probably just look at it and apply it to your sources yourself. The final version looks like it's just two lines changed in a single file. On Mon, Jul 30, 2018 at 11:29 AM, Ryan Joseph wrote: > > > > On Jul 28, 2018, at 8:38 AM, John Doe >

Re: [fpc-pascal] Syntax changes suggestions

How is auto more "ugly" than literally any other modifier in the entire language? They're all just english words, of varying length. Also building features on top of a language will always result in worse performance than having them be a part of it. On Wed, Jul 25, 2018 at 10:05 AM, R0b0t1

Re: [fpc-pascal] Operator overload bug

e type: > > > > TIntArray = array of Integer; > > > > operator + (left: TMyClass; right: TIntArray): TMyClass; overload; > > > > and with retyping it works: > > > > c := c + TIntArray([1, 2, 3]); > > > > V. > > > > > > _

Re: [fpc-pascal] Operator overload bug

Also, one other thing: you should *really* be specifying the right-hand-side array parameter as "const" there. If you don't, it will be copied in its entirety instead of being passed by reference. Basically just always pass everything as "const" (or "constref" if it's specifically a record)

Re: [fpc-pascal] Operator overload bug

I'd say it's a bug in the sense that the compiler assumes something starting with "[" and ending with "]" can only possibly be a set in that context. On Sun, Jul 22, 2018 at 12:10 PM, Ryan Joseph wrote: > I mentioned this as an aside a while ago but I don’t remember getting a > response so I’d

Re: [fpc-pascal] Syntax changes suggestions

Isn't Delphi compatibility a major ongoing goal of both FPC and Lazarus, though? On Fri, Jul 20, 2018 at 10:01 AM, R0b0t1 wrote: > On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal > wrote: > > Am 20.07.2018 um 00:53 schrieb Ben Grasset: > >> > >>

Re: [fpc-pascal] Syntax changes suggestions

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > Because a feature might change the language in a way that's not in the > spirit of the language. Look at how Delphi implemented attributes: they're > declared in front of the types, fields,

Re: [fpc-pascal] Syntax changes suggestions

If a feature works as intended and is useful (which is all that matters), how is it "blind copying"? On Thu, Jul 19, 2018 at 7:25 AM, Marco van de Voort wrote: > > In our previous episode, Ryan Joseph said: > > > > That?s pretty disheartening honestly. So there was a useful feature users > >

Re: [fpc-pascal] Syntax changes suggestions

July 2018 23:30:19 Ben Grasset wrote: > > > > For example, does *anyone *actually think the strange "lowercase > > everything" capitalization style the compiler uses is "readable" > nowadays? > > Yes. > > Martin > ___

Re: [fpc-pascal] Syntax changes suggestions

Yawn, more F.U.D. On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski wrote: > On Wed, 18 Jul 2018 16:12:41 -0600 > Ryan Joseph wrote: > > > Personally for my taste I would like to just add a little keyword to the > end of the variable so I don’t have to worry about it later. > > 1) little,

Re: [fpc-pascal] Syntax changes suggestions

> For high performance in a game engine you should not allocate/deallocate memory in the game loop at all (can be done, have done it*, so no arguing there). This is a massive oversimplification. Many *modern* game engines do not even have the kind of loop you're thinking of. > Outside the game

Re: [fpc-pascal] Syntax changes suggestions

Well, the array TFPGList uses for storage would still be allocated on the heap in any case no matter what... On Wed, Jul 18, 2018 at 3:10 PM, Ryan Joseph wrote: > > > > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > A point against

Re: [fpc-pascal] Syntax changes suggestions

Ironically, type safety is a good argument for the further development of various generics related things. Yet unfortunately I don't think anyone is going to stop using the Contnrs unit in new code anytime soon... ___ fpc-pascal maillist -

Re: [fpc-pascal] Syntax changes suggestions

The "I might have to read code I don't like" argument people seem to keep resorting to comes off as rather childish, frankly. It's entirely subjective and specific to each person. For example, does *anyone *actually think the strange "lowercase everything" capitalization style the compiler uses

Re: [fpc-pascal] Syntax changes suggestions

They observably *are* good though, now that they've been implemented, especially in combination with management operators. These are features that objectively make FPC better. I'm unsure what the original concern could have even possibly been, other than some vague notion of "well, records didn't

Re: [fpc-pascal] Feature announcement: default namespaces

Cool I guess. Kind of seems not very important at all though. FPC lacks compatibility with current Delphi in various other far more significant areas... Virus-free. www.avast.com

Re: [fpc-pascal] Proposal for new Free Pascal logo

I'm not at all getting why people think it's "kitten-like." Have you guys ever actually seen a kitten? This logo looks like a cheetah, as it's presumably supposed to. And a much better/more tasteful cheetah than that ancient, annoying "running" GIF at the top of all the Free Pascal websites

Re: [fpc-pascal] GUI confusion

branding in products are more important that the look of the OS. Many products use different looks and feel to stand out above a saturated market. But I guess you can't please everybody. ;-) Ben. ___ fpc-pascal maillist - fpc-pascal

[fpc-pascal] why is FPImage dog slow reading jpeg's?

file: img/babies/full/babies.04.jpg 1 2 16:01:28.859 (start reading) snip ---[ end ]--- -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman

Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?

On Mon, May 30, 2011 at 4:16 PM, Michael wrote: snip That should work much faster. The reason is probably that the default image Ah, thanks Michael that did the trick. I knew I had to be doing something wrong. --   Ben

Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?

this occurs obviously), could be to default to UsePalette = False instead. --   Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?

the many replies, it seems everybody expects UsePalette to be False by default (instead of what it is now True). Maybe a new default should be considered. --   Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http

[fpc-pascal] Re: better understanding of fpdoc

. Is there a way to create a link for a remote site (for example wikipedia, specific RFC etc) ? You use the url tag. eg: descr p For more information, see the FPC website at: url href=http://www.freepascal.org; / /p /descr 3. How can I compile fpDoc using fppkg ? no idea. -- Ben

[fpc-pascal] Re: RE : Re: URIParser

window to a remote application window? In such cases one should supply the username and password with the origin host. Or like Qt4 DND and newer Windows DND applications uses. eg: text/url-list mime type file://ben:password@192.168.0.14:/home/ben/myfile.txt I presume (though that always tends

[fpc-pascal] Re: FPC_PASCAL

://www.freepascal.org -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Next major FPC release?

to take up the challenge of doing development and packaging. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Next major FPC release?

. I would like to use some of those features in a production environment, but don't like to use Trunk for production code. So I would like to try and plan/estimate how long we need to delay the usage of those language features in our code. -- Ben

[fpc-pascal] Re: Next major FPC release?

, As I mentioned above, we have already started doing this, but such changes to our code must be kept in a separate branch until such time as those FPC features are in a stable FPC release. Knowing that we only have to wait a few more months is great news. -- Ben

[fpc-pascal] Re: TMenu - barbreak Delphi Compatbility.

On 13/04/2011 00:08, Paul Ishenin wrote: This is a windows only feature and it is not implemented in lazarus. Actually, OS/2 also supports that feature (though rarely used)...but then Lazarus doesn't have an OS/2 native port yet. ;-) -- Ben

Re: [fpc-pascal] regex unit and word boundaries

, or is that unit abandon-ware. Can't the FPC developers include TRegexpr library as part of FCL? It will save them a lot of development effort. --   Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org

[fpc-pascal] regex unit and word boundaries

the words I want to match might appear in the middle of the text. --   Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] wiki page confusion with Ordinal to Word conversion

. -- -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: wiki page confusion with Ordinal to Word conversion

for explaining Jonas. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Embedded web server

with the following command, using FPC 2.4.3. I changed some deprecated calls like Bind() to fpbind() etc, but still no luck compiling. fpc -B -FUunits -Fu../../main/ aservia.dpr -- Ben. ___ fpc-pascal maillist - fpc-pascal

[fpc-pascal] Re: Embedded web server

Op 2011-02-25 10:27, Ben het geskryf: I checked out the whole 'dev' tree sitting at revision r444. That code [Aservia] doesn't compile at all... I read the readme file and OK, after looking at the FPC code to see how the old socket functions map to the newer fp* functions I managed to fix

[fpc-pascal] Re: Embedded web server

looks like a good choice. We just need to test its CGI support thoroughly. Now, does anybody know if one can run a [embedded] webserver like nYume as a standard desktop user under Linux? Without doing something like: $ sudo ./nYume -- Ben

[fpc-pascal] Re: Embedded web server

the Sockets unit (if I remember correctly from the header comment), so will probably find it very is to fix too. :) -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Embedded web server

with a standard user! Thanks a million. :) -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Embedded web server

servicing, repair or correction. - -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Embedded web server

. So can a software licence really be applied to something like that [webserver functionality - implemented protocols]? Just a thought. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman

[fpc-pascal] Re: Embedded web server

. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Embedded web server

Op 2011-02-25 14:06, Jonas Maebe het geskryf: Or should someone with a more official capacity (part of FPC team) rather contact the author? It doesn't matter. OK done. If I get feedback, I'll let you guys know. -- Ben. ___ fpc

[fpc-pascal] Re: Embedded web server

...Or maybe I just missed the fact that it moved to a new location? -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Is LNET dead?

in implementing it, if LNET is a viable option. My immediate needs are the SMTP and HTTP client support. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Is LNET dead?

0.6.4 Almindor 2010-05-08 * fix potential problem with invalid socket being u Almindor 2010-05-08 * add Qt4 lazarus integration Almindor 2010-02-13 * update changelogs Almindor 2009-11-17 * refactoring of visual ftp example * make use of O ... -- Ben

[fpc-pascal] Re: processing quote-printable text...

looking at LNet and Synapse I spotted the latter having a MIME processing unit. So maybe you could use that, or at least find it a somewhat useful. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http

[fpc-pascal] Name of the programming language used in/with FPC

language? -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: New multicast event implementation

) at the bottom of your website excludes all the source code examples - making the printout rather useless. Just thought I would mention that. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman

[fpc-pascal] Re: New multicast event implementation

(and it seems neither has many others - good or bad language feature, I don't know?). I'm just pointing out that there are multiple ways of doing the same thing. Observer could very easily be used too, and without the pitfalls listed in the Stack Overflow article. -- Ben

[fpc-pascal] FPC + Haiku

Hi, Anybody here using FPC on Haiku? If so, how well does it work compared to under Windows or Linux? -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Permuted index (KWIC) of function descriptions

, HTML etc). --   Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal