Re: [fpc-devel] using strupper,strlower on german words
- Original Message -
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Sunday, June 05, 2005 4:23 PM
Subject: Re: [fpc-devel] using strupper,strlower on german words
Hans-Jörg Vasold wrote:
- Original Message - From: "Florian Klaempfl" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Sunday, June 05, 2005 3:59 PM
Subject: Re: [fpc-devel] using strupper,strlower on german words
Hans-Jörg Vasold wrote:
StrUpper, StrLower will not work for the german "äöüß".
Are any equivalent functions like Delphi's AnsiUpperCase or any fix
AnsiUpperCase?
AnsiStrUpper
The AnsiStr* functions operate on pchars.
http://www.freepascal.org/docs-html/rtl/sysutils/ansistrupper.html
Yes but
// Tested in Lazarus
Edit1.Text := AnsiStrUpper ( 'Ärzte' )
results in 'äRZTE'
Edit1.Text := AnsiStrUpper ('ärzte')
results also in 'äRZTE';
cu Hans-Joerg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Object pascal is a mature language. Some languages even adopt the concept, such as C# or Java, with different syntaxes and styles. Do not listen to people who said pascal is a toy language, they just don't know what they're talking about. Then, if we are talking about the object pascal compilers... we must admit that Delphi/Kylix is the most popular pascal compiler. In fact, it becomes some kind of industry standard for pascal based software engineering. But, now we have another pascal compiler alternative. The open source and free one, it's FreePascal aka FPC. Since it released the v.2.0, it got more popularity. Some people even think that it's gonna replace Delphi domination. But, I think it's not that easy as it said. Delphi has more experiences, more developers and community, more library supports, more products, and many more. If we want to make FPC as popular as Delphi and more developers interested to use it, then we have 2 ways to do it: 1. Make FPC 100% compatible with latest Delphi release (I think at least D7). Automatically, FPC will get all Delphi resources, including the codes and the developers! There's no need to write new specific libraries for FPC. 2. Make FPC own environment and community. We don't need to keep up with Delphi compatibility, make our own syntaxes and styles, build our own libraries, have our own dignity and destiny. :) Which way we gonna choose? The first one? Which I think we only need to more concentrate on the compiler development, but with ability to share the code and community with current Delphi code and community. This will make FPC = Delphi, or even FPC >= Delphi. :) Or the second one? Which I think requires more works, keep up with some "selected" Delphi compatibility, build our own libraries, but with freedom to have our own "special" pascal. This will make FPC > Delphi, or FPC < Delphi, or even FPC <> Delphi. So... which one? :) -Bee- has Bee.ography at: http://beeography.modblog.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
> > using them hard or impossible becomes a toy language. > > But it doesn't. The only time they are a problem is when the stuff you > are storing in the tree or list is an *object* and that *object* points > back to either the container or the list that stores it (which is very > rarely done). The most likely case for that is if you added a self > reference - I prefer languages that work, not that most likely work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMySQLConnection.LoadField field length
Sorry for the late reply.. On Thu, 2005-05-19 at 19:03 +0200, Bram Kuijvenhoven wrote: > After understanding what a VARCHAR is (namely some sort of shortstring > with a fixed maximum length), I wanted first to know whether a newer > MySQL server reports proper field lengths for fields like 'FORMAT > (mydoublefield,3) AS myalias', so I switched to a 4.1 server. If you store the string 'hello' in a varchar(1000) it only needs 9 bytes of storage-space, while using char(1000) you would need 1000 bytes. In memory, however, fpc indeed uses a shortstring. > However this didn't work, because I needed a newer client also, > because the older client didn't support the newer authentication > protocol requested by the server (according to the error message I > got). > > So I used a newer libMySQL.dll file and adjusted mysql4dyn to > accepting this version. But now I got a authentication error for user > [EMAIL PROTECTED] However I didn't connect as user ODBC?!? That check isn't there for nothing. > The I figured out the TMySQLConnection object connected twice to the > database, once in ConnectToServer and once in PrepareStatement. The > second time it tries to fetch the Host, UserName, Password from the > FMySQL:PMySQL field. But there seem to be nil values in there... and I > guess MySQL somehow tries user ODBC because no username is given. That's because they've changed the PMySQL-type. (Like they change everything, always - just like they want) > I also tried loading the newer dll statically, but then I had to > comment out a lot more functions in mysql4 and mysql4_com than before, > in particular some slave, master and the hash_password functions. > > So my findings are: > - the fpc mysql headers contain way too much function headers, which > causes 'entry point of function blablabla not found' error when > statically loading the library. I think it's better only to try to > import the functions which are also documented as part of the C API at > http://dev.mysql.com/doc/mysql/en/c.html. > - the fpc headers contain declarations of structs (records) that are > not in the MySQL documentation. The only struct described there is the > MYSQL_FIELD struct (or: TMySQL record), besides the other types of > which no members are listed. Perhaps using the other structs isn't > very safe and prone to change. > - mysql4dyn only accepts a 4.0 library and no a 4.1 library; I hope > this can be made more flexible... > I understand the fpc team has become tired of mysql header changes and > incompatibilities, but this problem does not seem to exist with e.g. > the php mysql interface. Maybe the problems can be solved by only > importing and functions that are also in the documentation. (This > would require manual action instead of simply applying h2pas to > mysql.h) > Do you think this is an approach with a chance to success? No. The idea is good though. I think I can use it with the problem of what functions/procedures need to be put into the headers. But, the largest problem is all those things which aren't documented. Example, in http://dev.mysql.com/doc/mysql/en/c-api-datatypes.html you can find that 'field' can be one of the following: FIELD_TYPE_TINY, FIELD_TYPE_SHORT etc.etc. But it could be that for MySQL 4.0 FIELD_TYPE_TINY is defined as 0, while in 4.1 it's defined as 1. So for 4.0 it should be: const FIELD_TYPE_TINY : 0; FIELD_TYPE_SHORT : 1; while for 4.1 it is: const FIELD_TYPE_TINY : 1; FIELD_TYPE_SHORT : 0; And why they keep changing that sort of things, I really don't get. And these differences you can only see in the .h's. (I made this example up, but those differences do exist) > MySQL is widely used and therefore it would be nice if it can be > supported by fpc. (In fact, I've seen people asking things about mysql > on the Lazarus mailing list several times) Me too. > After getting the mysql headers right and 'compatible', I could try to > create a better TMySQLConnection. I'm gonna throw out all non-documented procedures. (Well, they are documented mostly, but elsewhere) And use diff on the .h's -- Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using strupper,strlower on german words
On Sun, 5 Jun 2005, Florian Klaempfl wrote: > Hans-Jörg Vasold wrote: > > > > > - Original Message - From: "Florian Klaempfl" <[EMAIL PROTECTED]> > > To: "FPC developers' list" > > Sent: Sunday, June 05, 2005 3:59 PM > > Subject: Re: [fpc-devel] using strupper,strlower on german words > > > > > >> Hans-Jörg Vasold wrote: > >> > >>> StrUpper, StrLower will not work for the german "äöüß". > >>> > >>> Are any equivalent functions like Delphi's AnsiUpperCase or any fix > >> > >> > >> AnsiUpperCase? > > AnsiStrUpper > The AnsiStr* functions operate on pchars. > > http://www.freepascal.org/docs-html/rtl/sysutils/ansistrupper.html > > For Michael vC: the remark is wrong/outdated, if you include cwstrings, > language settings on linux are taken care of. This is not so, because the cwstrings is for WideStrings only, and the AnsUpperCase is AnsiString. We'd need a separate unit to load the conversion tables for ansistrings. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using strupper,strlower on german words
Hans-Jörg Vasold wrote: > > - Original Message - From: "Florian Klaempfl" <[EMAIL PROTECTED]> > To: "FPC developers' list" > Sent: Sunday, June 05, 2005 3:59 PM > Subject: Re: [fpc-devel] using strupper,strlower on german words > > >> Hans-Jörg Vasold wrote: >> >>> StrUpper, StrLower will not work for the german "äöüß". >>> >>> Are any equivalent functions like Delphi's AnsiUpperCase or any fix >> >> >> AnsiUpperCase? AnsiStrUpper The AnsiStr* functions operate on pchars. http://www.freepascal.org/docs-html/rtl/sysutils/ansistrupper.html For Michael vC: the remark is wrong/outdated, if you include cwstrings, language settings on linux are taken care of. > > > Oh ? Sorry, wrong question! > > What i really want to know is : Are any equivalent functions like > AnsiUpperCase avaliable for pChar parameter and result > (StrLower,StrUpper works with pChar) ? > > cu Hans-Joerg > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using strupper,strlower on german words
- Original Message - From: "Florian Klaempfl" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Sunday, June 05, 2005 3:59 PM Subject: Re: [fpc-devel] using strupper,strlower on german words Hans-Jörg Vasold wrote: StrUpper, StrLower will not work for the german "äöüß". Are any equivalent functions like Delphi's AnsiUpperCase or any fix AnsiUpperCase? Oh ? Sorry, wrong question! What i really want to know is : Are any equivalent functions like AnsiUpperCase avaliable for pChar parameter and result (StrLower,StrUpper works with pChar) ? cu Hans-Joerg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using strupper,strlower on german words
Hans-Jörg Vasold wrote: > StrUpper, StrLower will not work for the german "äöüß". > > Are any equivalent functions like Delphi's AnsiUpperCase or any fix AnsiUpperCase? > available ? > > thx > > Hans Joerg > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] using strupper,strlower on german words
StrUpper, StrLower will not work for the german "äöüß". Are any equivalent functions like Delphi's AnsiUpperCase or any fix available ? thx Hans Joerg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Sun, 5 Jun 2005, Jamie McCracken wrote:
> Michael Van Canneyt wrote:
>
> > I suggest you create an external preprocessor, and limit yourself to
> > that.
> >
> > I don't consider your construct to be Pascal, so I will fight inclusion
> > of it in the compiler, not even under some {$Mode} construct.
>
> Well all I ask is you wait til I have written it then give it a chance. If you
> still feel bad about it then we can discuss what to do then. If it turns out
> that you all insist on begin..end being mandatory then i will respect your
> wishes and no feelings will be hurt.
Look, it's a matter of principle. I consider ANY language which uses the amount
of whitespace in it's grammar to be inherently badly designed.
> I believe it will help Pascal and breathe
> new life into it especially as its a dying language.
It has lived longer than most languages, so I don't think this is so.
> I also note there is no
> such thing as "Pascal" as such even Delphi has significant syntax differences
> with earlier pascal variants so I hope that's taken into account.
No it is not. The change you suggest is fundamentally different from the
dialects
we have till now; you are changing one of the fundamental principles, namely
whitespace is irrelevant, just as casing is. This is, in my eyes, a different
language - anything BUT pascal.
>
> >
> > The compiler is GPL, so you are free to change it, but that doesn't
> > necessarily mean your changes will make it back in the compiler main
> > sources.
>
> If not I can always maintain a branch that does. (though I would prefer it if
> it is included of course)
Not if I can help it.
I realize this may come over quite hard, but I prefer you would do something
USEFUL
which actually contributes to Free Pascal. Creating yet another obscure dialect
is not
helpful. We are having enough problems getting in Delphi compatibility stuff.
It would
be MUCH more appreciated if you would help with that.
It's a simple fact:
90% if not more of all pascal code out there is Delphi code. Being able to
compile and
re-use that is FAR more important than changing the fact that begin/end is
required in
pascal.
You want to be useful ? Do one of the following:
- Complete Variant support.
- Implement Packages support.
- Overloading for property indexes.
- DISPINTERFACE support, plus OLE automation calls.
- Extend the Optimizer.
You want to make some 'Auto-Maintained' variable support, of the kind:
Autovar
S : TStrings;
begin
S:=TStringList.Create;
end; // compiler disposes of S.
Please, go ahead. Anything that is useful. But not creating another dialect.
I've been on the compiler team for almost 10 years, and we've heard lots of
crazy
offers in that time. We've ignored most of them, and good too, or else we
wouldn't
be where we are today. Yours just happens to be one of them. Sorry.
I prefer to let you know in advance instead of letting you work hard and then
shoot
off your efforts.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| will respect your wishes and no feelings will be hurt. I believe it will | help Pascal and breathe new life into it especially as its a dying | language. I also note there is no such thing as "Pascal" as such even | Delphi has significant syntax differences with earlier pascal variants | so I hope that's taken into account. | Things like smalltalk, tcl.. those are dying according to sourceforge (40 projects or so.. whereas Delphi has hundreds or 1000's. If you want to tell smalltalkers that they are dying because there are only 30 or 50 projects on source forge.. well go to c2.com wiki, there are plenty of them programmers there, doing work for banks and all sorts of places. If you want to tell Borland that Delphi is dying due to dotNet, then just download any popular Delphi application out there like the latest version of totalcommander and you tell me if it has any significant amount of dotNet code in it. What is said to be "dying" is most likely a rumor placed out by foolish of fools like Bryan Kerinighan who even sell books on Pascal themselves. In fact Pascal/Delphi is still one of the most popular languages - at one time I think there were more projects in Pascal than visual basic on source forge.. now VB has slightly more. But it's not as if there are 50 projects in Pascal... like other languages. No there are hundreds, thousands in Pascal/Delphi. I guess the problem is that once you start changing a language, what is it anymore? When does a Mercedes car become no longer a Mercedes car when it has 80 percent your own parts on it? Wouldn't you kill the Mercedes name and call it something else.. a new breed of car? i.e. why would you even call your language Pascal or why would it have anything to do with Pascal in the first place.. why not call it something else, since it is a new breed.. Wouldn't want to carry the Pascal "bad name" anyway, right? Maybe because there is already a compiler and you want to re-use code? I don't know. I think maybe even a better place to start then might be python mailing lists or python compiler sites if there are any. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[moderator] Re: [fpc-devel] Re: [fpc-l] type discussion
On 05 Jun 2005, at 15:22, Jamie McCracken wrote: I believe it will help Pascal and breathe new life into it especially as its a dying language. And with the above insightful and undoubtedly uncontroversial comment I think we can close this thread here. I would therefore like to ask all people who wish to continue this thread to either move to fpc- other, or to continue in private. Thank you. Jonas FPC mailing lists moderator ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote:
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
Well all I ask is you wait til I have written it then give it a chance.
If you still feel bad about it then we can discuss what to do then. If
it turns out that you all insist on begin..end being mandatory then i
will respect your wishes and no feelings will be hurt. I believe it will
help Pascal and breathe new life into it especially as its a dying
language. I also note there is no such thing as "Pascal" as such even
Delphi has significant syntax differences with earlier pascal variants
so I hope that's taken into account.
The compiler is GPL, so you are free to change it, but that doesn't necessarily
mean your changes will make it back in the compiler main sources.
If not I can always maintain a branch that does. (though I would prefer
it if it is included of course)
jamie.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Sun, 5 Jun 2005, Jamie McCracken wrote:
> Michael Van Canneyt wrote:
> >
> > On Sun, 5 Jun 2005, Jamie McCracken wrote:
> >
> >
> > > Hans-Peter Diettrich wrote:
> > >
> > >
> > > > > Not at all; I certainly don't indent them, and I'm a fanatical
> > > > > indenter.
> > > >
> > > >
> > > > Agreed. I really can't understand why some people indent like
> > > > this:
> > > > if ...
> > > > then
> > > > begin
> > > > ...
> > > > end
> > > > else
> > > > if
> > > > ...
> > >
> > > lol - thats not what I meant. If you want readable code you indent
> > > inside the
> > > begin..end blocks ergo the begin..end syntax becomes redundant cause
> > > its the
> > > indentation that provides the visual cue.
> >
> >
> > Visual, yes. But not for the compiler: it folds whitespace.
> > The compiler NEEDS the begin...end to check your syntax. How is it
> > supposed to know where a stament block begins/ends ? Based on indendation
> > alone ? That would not be Pascal...
>
> yes you are right it exists for the benefit of the compiler rather than the
> developer.
>
> My plan in the RAD Pascal dialect is to preprocess each line and put back the
> begin/end where the indentation occurs/varies without altering the line
> numbers. The compiler already has an internal preprocessor so I will simply be
> extending that. If the end result is not to your liking then continue using
> other dialects as none of my changes will affect them. Of course there is
> nothing stopping you from continuing to use begin end blocks in RAD Pascal if
> you really want to but they will be optional whereas indenting will be
> compulsory (you will get an error if your indenting is not consistent!)
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
The compiler is GPL, so you are free to change it, but that doesn't necessarily
mean your changes will make it back in the compiler main sources.
Things that are considered constructive, may make it in.
This does not fall under that category, in my opinion.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Daniël Mantione wrote: Op Sun, 5 Jun 2005, schreef Jamie McCracken: yes but isn't it fair to say that such developers that require such structures would be knowledgable enough to make it safe by using weak refs? What is a weak ref? Allows you to make a reference without increasing or affecting the ref count of an object. My point is that the everyday structures that most developers (and in particular the more naive and less knowledgable ones) will use are not vulnerable to cycles and its only the more obscure and specialised use cases that will need to use weak refs. In those cases like building a compiler is it reasonable to assume that they will be smart enough to handle cycles with weak refs? I don't know, anyway, structures like trees, graphs, stacks, ringbuffers, linked lists etc. etc. are the basis of programming. A language that makes using them hard or impossible becomes a toy language. But it doesn't. The only time they are a problem is when the stuff you are storing in the tree or list is an *object* and that *object* points back to either the container or the list that stores it (which is very rarely done). The most likely case for that is if you added a self reference - EG mylist : Tlist; mylist := TList.create; mylist.add (mylist); // now you have a self referencing cycle The above could still be implemented safely in the add method of Tlist by testing for a cycle and using a weak ref to add mylist to mylist. BUt of course why would you ever want to add a self referencing cycle to a TList? Hmmm... Is a double linked list a cycle? I think yes. I dont think so. The list nodes are usally a record/struct not an *object* and whilst they do form a chain, the items pointed to in the list dont point back to that list so no it is not a cycle. Cycles are rare by the nature in objects however they are more common in GUIs where widgets and components link together. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler/utils/samplecfg, FPCWiki
05-06-04 08.41, skrev Tom Verhoeff följande: > In the source repository, the current version for > trunk/compiler/utils/samplecfg > has a line > > #-Fu~/fpc/packages/base/*/units/$fpctarget;~/fpc/fcll/units/$fpctarget;~/fpc/r > tl/units/$fpctarget > > Since it is commented out, it does not matter much what is on that line; it > is just an example. > > But should /fcll/ not be /fcl/ ? It probably should. Anyway its fixed it now. > By the way, I contributed a page about FCL to the FPCWiki. Could someone > add `(FCL)' to the Main_Page after the heading `Free Component Library' done > under Main components (the page is locked). That way, it will be more > in line with FPC and RTL. It would also be good to include > `Free Component Library' before FCL on the page FCL (I could not find > out how to edit that part); similar for FPC and RTL pages. Just listing > the abbreviation as a title is not convenient for those unfamiliar > with FreePascal. The full headings is not present in the header of FPC and RTL either. The reason is that the header shows the wiki page name which is RTL and FPC adn FCL. However ive now added an explanation of the abbreviations for RTL and FPC int the ingress of theses pages. Olle ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Sun, 5 Jun 2005, schreef Jamie McCracken: > yes but isn't it fair to say that such developers that require such > structures would be knowledgable enough to make it safe by using weak refs? What is a weak ref? > My point is that the everyday structures that most developers (and in > particular the more naive and less knowledgable ones) will use are not > vulnerable to cycles and its only the more obscure and specialised use > cases that will need to use weak refs. In those cases like building a > compiler is it reasonable to assume that they will be smart enough to > handle cycles with weak refs? I don't know, anyway, structures like trees, graphs, stacks, ringbuffers, linked lists etc. etc. are the basis of programming. A language that makes using them hard or impossible becomes a toy language. Hmmm... Is a double linked list a cycle? I think yes. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
L505 wrote: Now there are some bondage discipline languages and Pascal is considered one.. even though it's not case sensitive.. isn't indentation sort of bondage-discipline? of course it is - any formal language will have some "bondage" in their syntax. Indentation and Begin..End are such examples but in my case forcing developers to write properly indented code (which is essential for legibility as im sure you will agree) is not a disadvantage as such if you consider it a neccesity anyhow. I suggest you wait until I have something working then we can discuss the finer points. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Daniël Mantione wrote: Op Sun, 5 Jun 2005, schreef Jamie McCracken: Its not a black or white issue IMO its a shade of grey. At the end of the day you have to make a judgement call based on the facts. Im asserting that with non-component objects the incidence of cycles is so rare that provided we have a means of adding weak refs so that knowledgable developers can overcome them when they do occur then the issue of cycles can be ignored - after all if the probability of leaks is based on a one in a million occurance of a cycle (Im not saying thats an accurate probability!) coupled with an ignorant or naive developer then thats an acceptable risk to me. If it turns out that cyclic occurances are far more common than that then yeah that could be a killer. There are of course workarounds but I dont like any of them - EG python 2.3 does ref counting but also uses a mark sweep GC to mop up cicrular refs but I really dont think we need to consider that. H... I don't think a programming language where one cannot safely build graphs or ringbuffers will be very powerfull. Writing a compiler in it would be impossible to give an example. yes but isn't it fair to say that such developers that require such structures would be knowledgable enough to make it safe by using weak refs? My point is that the everyday structures that most developers (and in particular the more naive and less knowledgable ones) will use are not vulnerable to cycles and its only the more obscure and specialised use cases that will need to use weak refs. In those cases like building a compiler is it reasonable to assume that they will be smart enough to handle cycles with weak refs? jamie. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Neat, I haven't come across these yet. If you -have- got some working under FPC you should upload them to "contributed units" section. Because if other people convert the units which have already been done by someone else, we would be doing double work ;-) Plus it gets code into a central repository this way, again so that people don't do double the work. >Have a look at Fundamentals (http://fundementals.sourceforge.net/). It >has libraries for strings, data structures, unicode, xml, etc. It's >was written for Delphi, but I've gotten some way to compile under >FreePascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| yes you are right it exists for the benefit of the compiler rather than | the developer. incorrect. When reading code I always use the bold begin/end's. Why do you think they are bold? Are they bold because the compiler likes them bold? See, a bold begin and end is a lot easier to see than a parenthesis. Parenthesis is tough to see on a high res monitor. There is a reason begin and end are bold, and that has nothing to do with the compiler. They are useful also for the developer. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Op Sun, 5 Jun 2005, schreef Jamie McCracken: > Its not a black or white issue IMO its a shade of grey. At the end of > the day you have to make a judgement call based on the facts. Im > asserting that with non-component objects the incidence of cycles is so > rare that provided we have a means of adding weak refs so that > knowledgable developers can overcome them when they do occur then the > issue of cycles can be ignored - after all if the probability of leaks > is based on a one in a million occurance of a cycle (Im not saying thats > an accurate probability!) coupled with an ignorant or naive developer > then thats an acceptable risk to me. If it turns out that cyclic > occurances are far more common than that then yeah that could be a > killer. There are of course workarounds but I dont like any of them - EG > python 2.3 does ref counting but also uses a mark sweep GC to mop up > cicrular refs but I really dont think we need to consider that. H... I don't think a programming language where one cannot safely build graphs or ringbuffers will be very powerfull. Writing a compiler in it would be impossible to give an example. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
| | lol - thats not what I meant. If you want readable code you indent | inside the begin..end blocks ergo the begin..end syntax becomes | redundant cause its the indentation that provides the visual cue. | That's like taking question marks out of sentences that you know are questions. Why have question marks if you know it is a question? If there is a space after the question, and the question always starts with something like "what", "where" "when" why", then -what good- is a question mark? There are plenty of reasons. One is that the human brain doesn't have time to figure out whether or not it is a question.. it is just a extra helper symbol to verify that. The other is that if you are looking specifically for questions and you don't have time to read the entire article, at least you can easily see them ( ¿even easier in spanish?). The other is that when you start deleting words from the sentence, at least the question mark still is there after you've deleted some text. And you know that the structure of words is still supposed to be a question, even if after deleting things. You would have less change of knowing it was a question if there was no question mark.. because after deleting some stuff and reorganizing your article, it may appear as though it is a regular sentence, not a question. Personally I like spanish upside down question mark, because it would help me when I was scanning articles for questions from forward to end. English question marks only help me when I am scanning the article from backward to forward. I've never taken or learned spanish though, so I am not bias. So maybe you think spanish is redundant, but I think even one question mark is sometimes not enough. Start deleting your code without begin end blocks and reorganizing things.. if these visual pointers are not there you may end up putting code in places that are not correct, because you accidentally lost that indentation while hitting delete key, and while the editor wasn't indenting the way you thought it would. If the begin end were there, at least you'd have a secondary opinion from the code telling you.. "hey.. wait, this is supposed to be a begin end block here, even if your indentation is wrong after refactoring." I lost my indentation, but at least I know where it goes, due to the secondary helpers begin and end. Just because my text editor was acting funny with tabs today, all my code is not broken? Because of the secondary savers. begin Ididntindent:= 'yes'; afterrefactor:= true; end; Where does this code go below? I lost my indentation, so where does it go in the code??? Just because my text editor was acting funny with tabs one day all my code is broken now? Ididntindent:= 'yes'; afterrefactor:= true; Personally, I use indenting for other parts of organizing code once in a while.. not just for begin end. So if was to write: othervar:= 'test'; othervar2:= 'test2'; setting1:= true; for i:= 1 to 5 do begin edit1.color:= red; ... ... end; othervar:= 'testa'; othervar2:= 'testb'; setting2:= true; for i:= 1 to 5 do begin edit1.color:= red; ... ... end; See how setting1 and setting2 is tied to the for statement using indentation of the for statement? I do that because the for statement only applies to setting 2. Helps organize code. Helps show that setting2 only really applies to that for statement. So if I had forced indentation on me, that may be illegal and that may initiate a begin end when I didn't even want it to. Now there are some bondage discipline languages and Pascal is considered one.. even though it's not case sensitive.. isn't indentation sort of bondage-discipline? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Michael Van Canneyt wrote: On Sun, 5 Jun 2005, Jamie McCracken wrote: Hans-Peter Diettrich wrote: Not at all; I certainly don't indent them, and I'm a fanatical indenter. Agreed. I really can't understand why some people indent like this: if ... then begin ... end else if ... lol - thats not what I meant. If you want readable code you indent inside the begin..end blocks ergo the begin..end syntax becomes redundant cause its the indentation that provides the visual cue. Visual, yes. But not for the compiler: it folds whitespace. The compiler NEEDS the begin...end to check your syntax. How is it supposed to know where a stament block begins/ends ? Based on indendation alone ? That would not be Pascal... yes you are right it exists for the benefit of the compiler rather than the developer. My plan in the RAD Pascal dialect is to preprocess each line and put back the begin/end where the indentation occurs/varies without altering the line numbers. The compiler already has an internal preprocessor so I will simply be extending that. If the end result is not to your liking then continue using other dialects as none of my changes will affect them. Of course there is nothing stopping you from continuing to use begin end blocks in RAD Pascal if you really want to but they will be optional whereas indenting will be compulsory (you will get an error if your indenting is not consistent!) jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
On Fri, 03 Jun 2005 01:26:34 -0400, you wrote: >> 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 number of standard >> available routines. > > >Exactly! Thanks for brining this up. If you just want more people to >use Pascal, just > >1) Make it simple >2) Have lots of nice tools >3) And most of all, have lots of units to do different thing Have a look at Fundamentals (http://fundementals.sourceforge.net/). It has libraries for strings, data structures, unicode, xml, etc. It's was written for Delphi, but I've gotten some way to compile under FreePascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Sun, 5 Jun 2005, Jamie McCracken wrote: > Hans-Peter Diettrich wrote: > > > > Not at all; I certainly don't indent them, and I'm a fanatical > > > indenter. > > > > > > Agreed. I really can't understand why some people indent like this: > > if ... > > then > > begin > > ... > > end > > else > > if > > ... > > lol - thats not what I meant. If you want readable code you indent inside the > begin..end blocks ergo the begin..end syntax becomes redundant cause its the > indentation that provides the visual cue. Visual, yes. But not for the compiler: it folds whitespace. The compiler NEEDS the begin...end to check your syntax. How is it supposed to know where a stament block begins/ends ? Based on indendation alone ? That would not be Pascal... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Hans-Peter Diettrich wrote: Not at all; I certainly don't indent them, and I'm a fanatical indenter. Agreed. I really can't understand why some people indent like this: if ... then begin ... end else if ... lol - thats not what I meant. If you want readable code you indent inside the begin..end blocks ergo the begin..end syntax becomes redundant cause its the indentation that provides the visual cue. Two cons for reference counting: - It fails on circular references. Fatal :-( Its not a black or white issue IMO its a shade of grey. At the end of the day you have to make a judgement call based on the facts. Im asserting that with non-component objects the incidence of cycles is so rare that provided we have a means of adding weak refs so that knowledgable developers can overcome them when they do occur then the issue of cycles can be ignored - after all if the probability of leaks is based on a one in a million occurance of a cycle (Im not saying thats an accurate probability!) coupled with an ignorant or naive developer then thats an acceptable risk to me. If it turns out that cyclic occurances are far more common than that then yeah that could be a killer. There are of course workarounds but I dont like any of them - EG python 2.3 does ref counting but also uses a mark sweep GC to mop up cicrular refs but I really dont think we need to consider that. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: > Those lazarus tools are great but they require advance knowledge of > those tools that new users wont have (at least somebody using lazarus > for the first time is not going to know all the keyboard shortcuts). Not > having to rely on hacks around the coding inefficiency of a language > with keyboard shortcuts is always a plus in my book too. Editors with macro capabilities are not hacks, and the shortcuts for macro invocations are not built into the editors. You'll need equivalent macros for maintaining an indentation structure, and, even worse, you're almost lost without such macros, due to the lack of redundancy! DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Angelo Bertolli wrote: > > Begin..End is redundant - you have to indent them to make em readable > > anyways. > > > Not at all; I certainly don't indent them, and I'm a fanatical > indenter. Agreed. I really can't understand why some people indent like this: if ... then begin ... end else if ... > I don't think you're going to convince anyone to change THIS > part of Pascal--it's essential. You change begin and end, and you just > don't have Pascal anymore. Some things could be changed, and have been changed for good reasons, in subsequent designs (Modula, Oberon). When all arbitrary occurrences of statement and statement_sequence in the Pascal grammar are replaced by a unique statement_list, where a statement list is terminated with an "end", the whole language becomes simpler and much clearer. It also will eliminate the "dangling else" ambiguity, that exists in the majority of all existing language designs. You'll notice the difference neither by looking at the code, written according to this syntax, nor by simply looking at the grammars. But you'll notice the difference when you're writing the parsers and find the semantics actually different from the syntax. In many languages the syntactical grammar is a simplified and generalized picture of the semantics, so that the parser has to check for specific cases in many places. In good designs, as provided by Wirth, no difference between syntax and semantics can exist. This unfortunately is no more true for OPL, where optional semicolons must be introduced into to the syntax in very many places. Then only the parser can decide, whether in such places a semicolon is actually mandatory, optional, or illegal, depending on whether a semicolon has already been consumed by some preceding optional occurence. Consequentially the meaning of some code can change dramatically, only depending on the occurence or absence of a semicolon in a specific place! My favorite example: case i of 0: if a then b ; //<--- illegal, optional or required? else c end; > > manual memory management of tobjects is redundant as you can get good > > performance with ref counting tobjects. > > > Oh yes, this old argument. I remember reading this on the list before. > I guess it's still on your mind ;) I really don't know about the pros > and cons for ref counting, so maybe someone can explain it. Two cons for reference counting: - It fails on circular references. Fatal :-( - Counting operations increase with the number of executed statements. Mark/sweep collections, in contrast, increase with the number of object creations, not with the number of object uses. But their execution time depends on the number of existing object references, regardless of whether objects really can be removed. Both kinds of garbage collection can work (reliably) only under specific conditions, which are not satisfied in OPL :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
