[fpc-devel] Range check error in cthreads (make debug)

If i compile rtl with debug info (make debug), then i get at start of my multithreaded app: An unhandled exception occurred at $08062B3C : ERangeError : Range check error $08062B3C CGETCURRENTTHREADID, line 310 of ../unix/cthreads.pp $0805ADAD GETCURRENTTHREADID, line 136 of /mnt/progs/d

Re: [fpc-devel] Re: [fpc-l] type discussion

On 1 jun 2005, at 18:35, Gerhard Scholz wrote: X is just an example, more useful of course it is in situations like anArray[i,j]^ := anArray[i,j]^ * y ; Similar to "inc(x)" compared to "x:=x+1"; in C (and if I remember correct, ALGOL68 also) uses this as a hint for optimization: the refer

RE: [fpc-devel] Re: [fpc-l] type discussion

From: Gerhard Scholz Sent: woensdag 1 juni 2005 18:35 >- Original Message - >From: "Marco van de Voort" <[EMAIL PROTECTED]> >To: "FPC developers' list" >Sent: Wednesday, June 01, 2005 1:50 PM >Subject: Re: [fpc-devel] Re: [fpc-l] type discussion [big snip] >> > multiple assignments: >>

RE: [fpc-devel] Re: [fpc-l] type discussion

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of listmember >Maybe a few things should be borrowed from RemObjects Chrome, such as > >-- Class Contracts >http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30 D8} > >I like the 'require/ensure' aproach. > >It makes the

[fpc-devel] units precedence cthreads, variants

Hi I'm trying to track down 'Variant Array is locked' bug and during simulation on simple program i found the unit precedence problem. -- program pokus1; uses cthreads, variants, Classes; type TTr = class(TThread) procedure Execute; overr

Re: [fpc-devel] Re: [fpc-l] type discussion

Marc Weustink wrote: What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to "decode" a "a := b := c := d := 0" line. There might be a ; inbeween which results in a complete different assignment. With such lines I've to read them over and over to see

Re: [fpc-devel] type discussion

On Thursday 02 June 2005 13:04, Jamie McCracken wrote: > However, in general Pascal has poor developer productivity when > compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :-> Vinzent. -- public key: http://www.t-domaingrabbing.ch/

Re: [fpc-devel] Re: [fpc-l] type discussion

Jamie McCracken wrote: Marc Weustink wrote: What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to "decode" a "a := b := c := d := 0" line. There might be a ; inbeween which results in a complete different assignment. With such lines I've to read

Re: [fpc-devel] type discussion

Vinzent Hoefler wrote: On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :-> Dont kid yourself - a lot of my

Re: [fpc-devel] Re: [fpc-l] type discussion

Jamie McCracken wrote: > Marc Weustink wrote: > >> >> >> What is easier to read is a matter of taste. >> Being a pascal devel for years now, it takes time to "decode" a "a := b >> := c := d := 0" line. There might be a ; inbeween which results in a >> complete different assignment. With such li

Re: [fpc-devel] Re: [fpc-l] type discussion

___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel MyObject.Create is impossible with classes on the heap. You need to assign MyObject a pointer but you can't do that from within create.

Re: [fpc-devel] Re: [fpc-l] type discussion

Gerhard Scholz wrote: > Useful extensions I would see: > > bigger sets: set of -10..10 (e.g.) Ordinals are positive numbers, and only ordinals can become set elements. In rare cases I missed bigger sets myself, in detail in parser generators and other automatons with many states. > a wa

Re: [fpc-devel] type discussion

On 2 jun 2005, at 15:22, Jamie McCracken wrote: Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland being virtually bankrupt. Delphi as it is faces a bleak future so its looking increasingly like its ti

Re: [fpc-devel] type discussion

On Thursday 02 June 2005 13:22, Jamie McCracken wrote: > Vinzent Hoefler wrote: > > On Thursday 02 June 2005 13:04, Jamie McCracken wrote: > >>However, in general Pascal has poor developer productivity when > >>compared to modern languages like python and C#. > > > > In terms of _written_ or in ter

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thu, 2 Jun 2005, Jamie McCracken wrote: Marc Weustink wrote: What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to "decode" a "a := b := c := d := 0" line. There might be a ; inbeween which results in a complete different assignment. With su

Re: [fpc-devel] type discussion

On Thu, 02 Jun 2005 14:22:55 +0100 Jamie McCracken <[EMAIL PROTECTED]> wrote: > > In terms of _written_ or in terms of _working_ lines of code? :-> > > Dont kid yourself - a lot of my fellow Delphi programmers have dumped it > for C# already so it is really worrying for me espcially with borland

Re: [fpc-devel] Re: [fpc-l] type discussion

Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) You must be a damn fast typer then :) Ironically python is perhaps the most popular language on Linux and most of its syn

Re: [fpc-devel] Re: [fpc-l] type discussion

Michael Van Canneyt wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal on linux is virtually

Re: [fpc-devel] Re: [fpc-l] type discussion

Jamie McCracken wrote: > Florian Klaempfl wrote: > >> >> I'am a poor delphi programmer, didn't use it for years, but I bet with >> any >> python programmer that I create any application faster than him :) > > > You must be a damn fast typer then :) I teached myself typing with 10 fingers, but

Re: [fpc-devel] type discussion

Vinzent Hoefler wrote: On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :-> Both in fact as they are direct

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 13:38, Jamie McCracken wrote: > Florian Klaempfl wrote: > > I'am a poor delphi programmer, didn't use it for years, but I bet > > with any python programmer that I create any application faster > > than him :) > > You must be a damn fast typer then :) No, that's a common m

Re: [fpc-devel] type discussion

Micha Nelissen wrote: On Thu, 02 Jun 2005 14:22:55 +0100 Jamie McCracken <[EMAIL PROTECTED]> wrote: In terms of _written_ or in terms of _working_ lines of code? :-> Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espci

Re: [fpc-devel] Re: [fpc-l] type discussion

Florian Klaempfl wrote: If that were the case then yeah it would sux (however pythons performance is due to bien a bytecode interpreter and dynamic typing neither of which we need in pascal). Ref. counting etc. eats time because you need good garbage collection to detect cycles and other ugl

Re: [fpc-devel] Re: [fpc-l] type discussion

Vinzent Hoefler wrote: On Thursday 02 June 2005 13:38, Jamie McCracken wrote: Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) You must be a damn fast typer then :) No, th

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thu, 2 Jun 2005, Jamie McCracken wrote: Michael Van Canneyt wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from obj

Re: [fpc-devel] type discussion

On Thu, 02 Jun 2005 14:52:13 +0100 Jamie McCracken <[EMAIL PROTECTED]> wrote: > > C# is very much like delphi, not at all like Python. What were their > > reasons to switch ? > > Because its so close to Delphi and they have switched because they > found it more productive. No forward declaration

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thu, 2 Jun 2005, Jamie McCracken wrote: Vinzent Hoefler wrote: On Thursday 02 June 2005 13:38, Jamie McCracken wrote: Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :)

Re: [fpc-devel] Re: [fpc-l] type discussion

Michael Van Canneyt wrote: I don't consider Ojbect Pascal to be verbose at all, so it's not an issue for me... Well I will typically spend about 25% of my development time with forward declarations, doing loads of try finaly blocks to free memory and other things instead of implementing m

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 14:01, Jamie McCracken wrote: > Vinzent Hoefler wrote: > > > What matters is designing und understanding the code, not writing > > it. I spend less than 10% of my time at work in actually _writing_ > > code, so even if someone can type in his/her code twice as fast, > > the

Re: [fpc-devel] type discussion

Micha Nelissen wrote: I don't understand, why are these forward declarations so evil ? More code bloat, more typing and they get in the way. They dont give me anything useful in return. Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList,

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 14:24, Jamie McCracken wrote: > Well I will typically spend about 25% of my development time with > forward declarations, doing loads of try finaly blocks to free memory > and other things instead of implementing my application. I typically spend 80% of my development tim

Re: [fpc-devel] Re: [fpc-l] type discussion

Vinzent Hoefler wrote: On Thursday 02 June 2005 14:01, Jamie McCracken wrote: Vinzent Hoefler wrote: What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as

Re: [fpc-devel] type discussion

var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? For 2 reasons: First, with strlist.create; It is not clear whether strlist is already initia

Re: [fpc-devel] type discussion

On Thu, 02 Jun 2005 15:31:51 +0100 Jamie McCracken <[EMAIL PROTECTED]> wrote: > Micha Nelissen wrote: > > > I don't understand, why are these forward declarations so evil ? > > > > More code bloat, more typing and they get in the way. They dont give me > anything useful in return. Please sho

Re: [fpc-devel] type discussion

On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: > Vinzent Hoefler wrote: > > On Thursday 02 June 2005 13:04, Jamie McCracken wrote: > >>However, in general Pascal has poor developer productivity when > >>compared to modern languages like python and C#. > > > > In terms of _written_ or

Re: [fpc-devel] type discussion

Micha Nelissen wrote: On Thu, 02 Jun 2005 15:31:51 +0100 Jamie McCracken <[EMAIL PROTECTED]> wrote: Micha Nelissen wrote: I don't understand, why are these forward declarations so evil ? More code bloat, more typing and they get in the way. They dont give me anything useful in return.

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 14:44, Jamie McCracken wrote: > My point is to to reduce or remove *redundant* syntax that serves no > useful or productive purpose (to the programmer). Well applied redundancy is a good thing. > Forward declarations are redundant - they exist purely for the > benefit of

Re: [fpc-devel] type discussion

On Thu, 02 Jun 2005 15:54:54 +0200 Sebastian Kaliszewski <[EMAIL PROTECTED]> wrote: > The studies show that in high level languages (C nothwithstanding) there is > very evident but simple correlation -- number of programmer errors per > language construct (typically in not obfuscated code it's v

RE: [fpc-devel] type discussion

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jamie McCracken Sent: donderdag 2 juni 2005 16:32 >var strlist : TStringlist; >strlist := Tstringlist.create; > >I know strlist is a Tstringlist, the compiler knows it too as I have >declared it so why do I have to spell it out in the cr

Re: [fpc-devel] Re: [fpc-l] type discussion

Michael Van Canneyt wrote: This is only 'logical' if the hypothesis "productivity is inversely related to the syntax verbosity" is correct. And it's not. What is correct is "productivity is directly related to the number of separate language constructs developer has to put in program to aco

Re: [fpc-devel] type discussion

On Thursday 02 June 2005 17:07, Marc Weustink wrote: > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jamie > McCracken > Sent: donderdag 2 juni 2005 16:32 > > >var strlist : TStringlist; > >strlist := Tstringlist.create; If the goal is this, I'd prefear a way to declare objects aut

Re: [fpc-devel] Re: [fpc-l] type discussion

Vinzent Hoefler wrote: > manual memory management of tobjects is redundant as you can get good performance with ref counting tobjects. That can be a point, yes. But it is somehow not related to any syntax. It means not having to bother with my pet hate the try..finally..free All in all

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thu, 2 Jun 2005, Sebastian Kaliszewski wrote: Michael Van Canneyt wrote: This is only 'logical' if the hypothesis "productivity is inversely related to the syntax verbosity" is correct. And it's not. What is correct is "productivity is directly related to the number of separate langu

Re: [fpc-devel] type discussion

> >>>Sorry, the only language that does what ? > >> > >>var strlist : TStringlist; > >>strlist := Tstringlist.create; > >> > >>I know strlist is a Tstringlist, the compiler knows it too as I have > >>declared it so why do I have to spell it out in the creation process? > > > > In C++: > > > > TStri

Re: [fpc-devel] type discussion

On Thursday 02 June 2005 15:16, Uberto Barbini wrote: > If the goal is this, I'd prefear a way to declare objects > autocreated: > > varauto: > strlist: TStringList; > begin > //some stuff > end; [...] > > It could be a problem to pass parameters to the constructor. Yes, exactly. So why both

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 15:13, Sebastian Kaliszewski wrote: > So here is some little idea which seems to me Pascalish enough to be > considered: > > how about new keyword: local > Class variable declared local will be automatically freed upon every > exit from the scope (i.e. something along the

Re: [fpc-devel] Re: [fpc-l] type discussion

Michael Van Canneyt wrote: But the compiler needs to check many things: 1. Initialize the S with Nil. 2. Check that S is assigned only once during the lifetime of the procedure. This is actually a bigger restriction than you might think, unless you want to introduce reference counting.

Re: [fpc-devel] type discussion

Vinzent Hoefler wrote: On Thursday 02 June 2005 15:16, Uberto Barbini wrote: If the goal is this, I'd prefear a way to declare objects autocreated: varauto: strlist: TStringList; begin //some stuff end; [...] It could be a problem to pass parameters to the constructor. Yes, exactly.

Re: [fpc-devel] Re: [fpc-l] type discussion

> Marco van de Voort wrote: > > Some of these target functionality (specially in the linking section) might > > require restructures > > related to > > * introduction of an internal linker for some core platforms (no more > > LD) > > * Rewrite of module (unit) handling > > Yes, these wou

Re: [fpc-devel] type discussion

Vinzent Hoefler wrote: On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: No, they aren't (or let me put it this way: It depends on what you measure). For instance, studies indicate that there are ten times more errors code in C code then in Ada code once you've delivered the softwa

Re: [fpc-devel] Re: [fpc-l] type discussion

> Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice, > Mozilla etc. use ;), definitively not python ... Python is a usuable scripting > language but nothing more. Well.. you should think so. But parts of Gnome are written in Python. And a lot of the configuration-tools

Re: [fpc-devel] Re: [fpc-l] type discussion

> > I totally agree with you in this case - we dont want or need cryptic c > > stlye syntax in any version of Pascal. > > > > However, in general Pascal has poor developer productivity when compared > > to modern languages like python and C#. > > I'am a poor delphi programmer, didn't use it for

Re: [fpc-devel] Re: [fpc-l] type discussion

> >> fpc-devel maillist - fpc-devel@lists.freepascal.org > >> http://lists.freepascal.org/mailman/listinfo/fpc-devel > >> > > MyObject.Create is impossible with classes on the heap. You need to > > assign MyObject a pointer but you can't do that from within create. > > sorry myobject is the poi

Re: [fpc-devel] type discussion

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=fpascal&lang2=ocaml&sort=fullcpu Here comes Pascal (FPC) vs Ocaml (hybrid functional/imperative language with OO). Ocaml is significantly faster although it havily uses GC. Ocaml code is significantly shorter too (they can be c

[fpc-devel] modernizing pascal discussions

I think we should put these kind of threads to an end. We get several different request which conflict or need a lot of time: - Packages - Better optimizer - Better smartlinking (internal linker) to reduce executable size - Easier cross platform (internal linker/assemblers) - Faster (C++ like) e

Re: [fpc-devel] Re: [fpc-l] type discussion

> On Thursday 02 June 2005 13:38, Jamie McCracken wrote: > > Florian Klaempfl wrote: > > > I'am a poor delphi programmer, didn't use it for years, but I bet > > > with any python programmer that I create any application faster > > > than him :) > > > > You must be a damn fast typer then :) > > No,

Re: [fpc-devel] Re: [fpc-l] type discussion

Marco van de Voort wrote: Also, I simply don't see the use of it. Borland Pascal's have the forward directive for those really few cases where it is annoying. Also, forward declarations mostly mean shitty code / design. Atleast in my case it does. ___

Re: [fpc-devel] type discussion

> On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: > > probably the greaytest impact on Objective Pascal productioveness > > would come from allowing programmers to declare classes like self > > managing (self freeing, not needeing explicit destructions). > > Maybe, yes. But I'm old sc

Re: [fpc-devel] Re: [fpc-l] type discussion

> > > Begin..End is redundant - you have to indent them to make em readable > > anyways. > > No. This makes the code more readable like normal english text. It > states much more clearly what it intents, at least much more than just > indenting or putting curly braces around it. Not every synt

Re: [fpc-devel] type discussion

On Thu, 2 Jun 2005, Ales Katona wrote: > > > > > http://shootout.alioth.debian.org/benchmark.php?test=all&lang=fpascal&lang2=ocaml&sort=fullcpu > > > > > > > > Here comes Pascal (FPC) vs Ocaml (hybrid functional/imperative language > > with OO). Ocaml is significantly faster although it ha

Re: [fpc-devel] type discussion

Marco van de Voort wrote: I think the time spent doing the manual compilation is overestimated, and the time problem solving in automatic allocation is underestimated. How many Java programmers routine set references to NIL ? Really a lot... This only shows the implementation (and std library

Re: [fpc-devel] Re: [fpc-l] type discussion

> Michael Van Canneyt wrote: > > This is only 'logical' if the hypothesis > > > > "productivity is inversely related to the syntax verbosity" > > > > is correct. > > And it's not. > > What is correct is "productivity is directly related to the number of > separate language constructs developer

Re: [fpc-devel] Re: [fpc-l] type discussion

> Michael Van Canneyt wrote: > > > > > This is not so easy, and reference counting is always a mess... > > Well you already have the code for ref counting for com objects so its > not like its a ton of work and therefore we dont need to worry about > your four points. Adding C++ style exceptio

Re: [fpc-devel] type discussion

> The difference was that the same task could be coded in some languages > using significantly lesser number of lines. But that doesn't necessarily equal to less overall time. Also specially the size of the testing code pieces. The troubles typically only start when the program grows larger.

Re: [fpc-devel] type discussion

> Marco van de Voort wrote: > > I think the time spent doing the manual compilation is overestimated, and > > the time problem solving in automatic allocation is underestimated. > > > > How many Java programmers routine set references to NIL ? Really a lot... > > This only shows the implementatio

[fpc-devel] How to manually control debug information

Hello, I'm writting a custom preprocessor and I would like that the line number information maps to the original file. An example (not real, only an example): ...original.pas... 21 procedure AddFive(var a, b: Integer); 22 begin 23 a := ++b; 24 end; After preprocessor: ...proces

Re: [fpc-devel] Re: [fpc-l] type discussion

| However, in general Pascal has poor developer productivity when compared | to modern languages like python and C#. Ironically python is perhaps the I disagree strongly, this is one of the reasons I chose Pascal. The fact that it creates compiled programs in a productive language versus python a

Re: [fpc-devel] Re: [fpc-l] type discussion

L505 wrote: | Yeah I know this sounds like a hybrid Pascal/python but I believe thats | the way to go - marry Delphi's speed and component framework with less | verbose python style syntax and you will have the best RAD language ever | written. | You are asking to reinvent python. If I were you

Re: [fpc-devel] type discussion

> > This only shows the implementation (and std library design) is bad (and > > that's true at least to java 1.4) > > I hear this from nearly any language with automated allocation (C#, Python, > Perl, Java). The concept is simple and attractive, the practice seems to > be different. I'm not a gre

Re: [fpc-devel] Re: [fpc-l] type discussion

| > | >> | >> I'am a poor delphi programmer, didn't use it for years, but I bet with | >> any | >> python programmer that I create any application faster than him :) | > | > | > You must be a damn fast typer then :) Sometimes it's which keys are near the home key. I don't care if "{" is shorter

Re: [fpc-devel] type discussion

Jamie McCracken wrote: > >>However, in general Pascal has poor developer productivity when > >>compared to modern languages like python and C#. > > > > > > In terms of _written_ or in terms of _working_ lines of code? :-> Can't stop refraining that fact ;-) > Dont kid yourself - a lot of my fell

Re: [fpc-devel] Re: [fpc-l] type discussion

listmember wrote: > Inline variable initializers, such as: ... > function Something(...): Boolean = False; > var >Integer1: Integer = 15; >Boolean1: Boolean = False; >String1: String = 'SOME TEXT'; > begin > end; Such constructs are subject to frequent misinterpretation :-( I assume

Re: [fpc-devel] Re: [fpc-l] type discussion

Jamie McCracken wrote: > > For me I prefere clarity above less typing (besides if you want to write > > realy short code, you sould use APL) > > > > I totally agree with you in this case - we dont want or need cryptic c > stlye syntax in any version of Pascal. ACK. > However, in general Pascal

Re: [fpc-devel] type discussion

| More code bloat, more typing and they get in the way. They dont give me | anything useful in return. Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | | > Garbage collection is largely no issue when using the Owner concept in TComponent, using TOb

Re: [fpc-devel] Re: [fpc-l] type discussion

| Begin..End is redundant - you have to indent them to make em readable | anyways. Typing "type" is reduntand to, so is "integer" You could use "i" instead of integer, you could use "T" instead of type. Draw the line. Draw the line. I feel you do not like any part of the Pascal language, so I

Re: [fpc-devel] type discussion

| > In C++: | > | > TStringList strlist; | > | > strlist = new TStringList; | > | > How is that shorter ? | | okay but its still redundant. Why does the compiler need to have it | spelt out twice? Why cant the compiler deduce that as the pointer is | declared as TStringlist therefore it crea

Re: [fpc-devel] Re: [fpc-l] type discussion

| | > Begin..End is redundant - you have to indent them to make em readable | > anyways. | | No. This makes the code more readable like normal english text. It | states much more clearly what it intents, at least much more than just | indenting or putting curly braces around it. And when you have

Re: [fpc-devel] Re: [fpc-l] type discussion

-- Class Contracts I like the 'require/ensure' aproach. It makes the code more robust and more debuggable, IMHO I think the checks you can do there are to limited. I also wonder what will happen if a require isn't met. Personally I don't want exeption in my released app. No, these are asserti

[fpc-devel] Re: strlist.create [was: type discussion]

First, with strlist.create; It is not clear whether strlist is already initialized or not; there is no way it can now this. Why not, what stops you from checking 'strlist <> Nil'.. ? Second, with strlist.create; It is not clear from reading whether create is a constructor or not. Create(

Re: [fpc-devel] modernizing pascal discussions

If you want to modernize the language you can take the current fpc code and extend it yourself. If the extension is clear and we agree on it it can eventually be put in the main fpc release. Discussions are useful. Before one starts coding away, a consensus would be nice to have. I would not

Re: [fpc-devel] Re: [fpc-l] type discussion

Op Thu, 2 Jun 2005, schreef Jamie McCracken: > So am I. My point is not changing the language so that it incurs > additional maintenance or is harder to read or harder to fix bugs or > make bugs more likely. In fact its the complete opposite. > > My point is to to reduce or remove *redundant* sy

Re: [fpc-devel] How to manually control debug information

At 19:36 2-6-2005, you wrote: Hello, I'm writting a custom preprocessor and I would like that the line number information maps to the original file. An example (not real, only an example): ...original.pas... 21 procedure AddFive(var a, b: Integer); 22 begin 23 a := ++b; 24 end; Aft

Re: [fpc-devel] Re: [fpc-l] type discussion

Daniël Mantione wrote: Granting all those wishes would turn the language in an enourmous monster. That doesn't look like a good idea. We've also a limit amount of developers whos time needs to be spent well, or we'll get behind. So, we're very convervative. Good ideas though, that will really

Re: [fpc-devel] type discussion

On Thursday 02 June 2005 21:28, L505 wrote: > | > In C++: > | > > | > TStringList strlist; > | > > | > strlist = new TStringList; > | > > | > How is that shorter ? > | > | okay but its still redundant. Why does the compiler need to have it > | spelt out twice? Why cant the compiler deduce that as t

Re: [fpc-devel] Re: [fpc-l] type discussion

Op Thu, 2 Jun 2005, schreef Jamie McCracken: > Daniël Mantione wrote: > > > > > Granting all those wishes would turn the language in an enourmous > > monster. That doesn't look like a good idea. We've also a limit amount of > > developers whos time needs to be spent well, or we'll get behind. >

Re: [fpc-devel] Re: [fpc-l] type discussion

Daniël Mantione wrote: Op Thu, 2 Jun 2005, schreef Jamie McCracken: Daniël Mantione wrote: Ok! We'll be happy to assist anyone doing interresting developments with Free Pascal. Keep in mind though that implementing ideas can take "a lot" more time that thinking out ideas. The Free Pasca

Re: [fpc-devel] Re: [fpc-l] type discussion

Op Thu, 2 Jun 2005, schreef Jamie McCracken: > Daniël Mantione wrote: > > > > Op Thu, 2 Jun 2005, schreef Jamie McCracken: > > > > > >>Daniël Mantione wrote: > > > > > > > Ok! We'll be happy to assist anyone doing interresting developments with > > Free Pascal. Keep in mind though that implement

Re: [fpc-devel] Re: [fpc-l] type discussion

Yes. Too bad it is not possible. One of the problems you can expect is with cyclic units. Normally the interfaces of the units form a tree, which define how they get called. So the compiler can compile the interfaces in the depth first order, then it can do the implementations in any order it w

RE: [fpc-devel] Re: [fpc-l] type discussion

> > Well I will typically spend about 25% of my development time with > forward declarations, doing loads of try finaly blocks to free memory > and other things instead of implementing my application. > > jamie. Well, you are quite a machine. If you say so, sure it's so, but that's not the proble

[fpc-devel] fpc-svn177-units-Mysql broken

Hi the latest version (177) of fpc in svn does not compile on Mac OS X 10.3.9. The make all ends with following: /Users/j/fpc/fpc-svn/compiler/ppcppc -Xs -O1 -n -S2 -Fu/Users/j/fpc/fpc-svn/rtl/units/powerpc-darwin -Fu/Users/j/fpc/fpc-svn/packages/base/ibase/units/powerpc-darwin -Fu/Users/j

Re: [fpc-devel] Range check error in cthreads (make debug)

Date sent: Thu, 2 Jun 2005 10:30:25 +0200 From: [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Subject:[fpc-devel] Range check error in cthreads (make debug) Send reply to: FPC developers' list

Re: [fpc-devel] type discussion

the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol := means "assign to", += means "add to" etc., I cannot find any inconsistency here. Also, += and such were created to make it easier to convert C code. If y

Re: [fpc-devel] type discussion

And do you think they dumped Delphi because Borland is virtually bankrupt and is basically only trying to become yet another .Net platform, or because they think they are so much more productive with the C# *syntax* ? No, of course they're using it because Microsoft said so ;) __

[fpc-devel] Extend the libraries people!

What makes python interesting are the many classes it offers by default to perform standard tasks, especially in the text treatment department; regular expression stuff etc. The same goes for most languages; Mostly it's not the language syntax that determines the productivity factor; it's the n

Re: [fpc-devel] type discussion

Jamie McCracken wrote: > >>>I don't understand, why are these forward declarations so evil ? > >>> > >> > >>More code bloat, more typing and they get in the way. They dont give me > >>anything useful in return. > > > > > > Please show me a piece of code where they are "in the way". Code bloat? >

[fpc-devel] Re: [fpc-l] type discussion

What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum (s)he would gain would be five percent in overall performance. you are missing th

Re: [fpc-devel] type discussion

Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. Jamie, now I KNOW I don't understand where you're coming from Pascal? Mainstream? ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] Re: [fpc-l] type discussion

Forward declarations are redundant - they exist purely for the benefit of the compiler. I agree. I hate prototyping. That's why you use top-down design. What's wrong with that? Begin..End is redundant - you have to indent them to make em readable anyways. Not at all; I certainly don't

Re: [fpc-devel] fpc-svn177-units-Mysql broken

there is an inconsistency: TDateTimeRec = record case TFieldType of ftDate: (Date: Longint); ftTime: (Time: Longint); ftDateTime: (DateTime: TDateTimeAlias); end; TTimeStamp = record Time: integer; { Number of milliseconds since midnight } Date: integer;

Re: [fpc-devel] Re: [fpc-l] type discussion

> P.S.: > BTW: Never heard of anybody doing serious programming in GNU Pascal (and I > know many a programmer doing serious programming in FPC and even VP) As far as I can see (from their maillists), most serious GPC users are academics working with large numeric-related legacy ISO codebases. VP

  1   2   >