Re: [fpc-devel] don't you think it's time to update delphi modecompatibility?
| FPC has great amounts of compatibility with Borland Delphi. Unfortunately, | according to the FPC docs, it only supports Delphi compatibility until Delphi 4. | The object pascal enhancement on the next Delphi release is still not supported | by FPC. | | Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- which | has tons of great object pascal enhancement, don't FPC developers think that now | is the time to follow up the language enhancements? For example: the for..in | syntax, reintroduce keyword, sub class (class field), etc. | | Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that FPC | development won't go that direction yet. I'm just talking about the language | enhancement here, for more code portability. Say, I'll be able to compile my | Delphi.Net code using FPC running on Linux. Maybe I'm just dreaming about the | 'real' concept of "write once, compile everywhere". :D | | Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :) | | -Bee- I'm sorry to say but none of these things will make FPC a better compiler by a large part. Since freepascal doesn't have very many contributed units compared to something like Torry.net, I think that's what people need to work on! I don't actually think that it is the compiler team who needs to work more. they already have small bugs to repair, I think developers need to make contributed units and do work. The language is strong but more functions and wrappers need to be written. If you think about it, no one would use Delphi just for the "for if" part about it, but rather they would use delphi because of all the stuff available for it... like on Torry.net. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to updatedelphimodecompatibility?
| Totally agree with you! Let the FPC developer team concentrate on the compiler | and language enhancement, and let the rest of us do the supported units. If FPC | can do all the Delphi can do, then... viola!! all codes on Torry will be | compilable on FPC. And the concept of "write once, compile everywhere" will be | very much closer to the object pascal language. Isn't that nice? :) | Well this is somewhat a matter of prioritization I guess. Yes it would be good to prioritize compatibility with Delphi 5 and 6 since lots of code out there for delphi 5 and 6 exists already. Most of the code on torry is for delphi 3 4 5 that' I've used, though. Do you actually use any code that's for .net .. and if so, has it been rewritten for .Net or is it something that is special and totally unique? I think smaller compatibility issues are important, but nothing as far as the "for..in" stuff. If For In was classes, or object oriented programming, or dynamic arrays (big things.. that help someone significantly) then I could see it as something to prioritize. The sad thing is, people do not fork out 2000 dollars for Delphi 9 or whatever.. they just use their old delphi 3-4-5-6 compilers. Maybe the big corporations who love buzzwords.. but even applications like TotalCommander are still compiled in Delphi-3-4 as far as Stud_Pe tells me. I haven't even come across .Net myself: out of about 600 applications I have here and maybe about 50 I use often, none of them use .Net. I'm always wondering what in the world .Net is.. I think TCP/IP is important today in our applications and .Net is trying to make TCP/IP into something called .Net. The sad thing is, delphi components that do TCP/IP are out there for Delphi 3 or so. Internet ready applications... We just need to build TCP/IP wrappers for FPC, and forget the .Net fad. If TCP/Wrappers were out there that were extremely easy to use, FPC would be .Net.. i.e. it would compile everywhere and connect your apps to the internet. That, and we need to push freepascal as a dream for CGI developers. A lot of people still use PHP, who are delphi developers. What's up with that? Rewriting code for PHP that you've already written 5 years ago in delphi in Dos. And they need to come see the PSP project. I suppose someone could port PSP to kylix but PHP is free and PSP wouldn't be free on kylix. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]don't youthinkit'stimetoupdatedelphimodecompatibility?- IDispatch, implements
| yy[ Charset ISO-8859-1 unsupported, converting... ] | > > Nobody said that the same size can be reached, but I don't consider 132k | > > against 86k as a real problem. If you consider it as a problem, use | > > Delphi. | > | > That's not what I ment. I see a problem with a GUI app that's using FCL. | > This apps are really of size that's not acceptable. | | 1. To who? | 2. And why? | I think the guy is mixing up LCL with FCL. Lars aka L505 http://z505.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
| 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 and C# who are not generally compiled right there and then, was another reason. | most popular language on Linux and most of its syntax is derived from | object Pascal whereas Pascal on linux is virtually non-existant. Of | course Python is piss poor in both performance and memory usage but it Yes, it is. All the linux programs I tried on KDE are extremely slow compared to Windows 2000. A lot of linux apps are made relying on python or perl. i.e. kpackage relies on python, and the KDE CPU monitor program. It's so slow, I found. There was also a "visual php" program of some sort made in python which was about a 450MB download and wouldn't even load up on my pc in ample time. I deleted it before loading it. | does point the way to a revitalised Pascal. Adopting less verbose but | still clean and clear syntax ala python is IMHO the way to make Pascal | great again. You just can't have it both. Perl is shortform. But it's not easy to create a regex for the long term, for other programmers to read.. or even yourself. No matter how clear the regex seems to be for a split second when you first create it initially. | | Consider the developer unfirendly nature of Pascal/Delphi atm: | | 1) Forward declarations - they sux! Why should the developers have the | burden of making the code totally sequential declaration wise. All other | modern compilers dont need this. Sure your code might take a bit longer | to compile but thats peanuts compare to the time saved in extra typing | and reordering your code They don't suck, you just need a proper editor which let's you see your declarations without taking you away from your code editing. A proper IDE should have this. Virtual views of the text file, showing declarations in a little side window or side panel editor, which you can edit at any time. Not just dual view or dual opening of the file, an actual dedicated portion for declarations open at all times in some virtual window. So the editor needs to be improved, IMO. Also, how in the world are you going to find all your declarations scattered across the file? incremental search? or are you going to make notes at the top of the file about where things are? Index it? bookmark them? | | 2) I have touched on manual memory managaement of tobjects before so I | wont rehash it here (in summary ref count tobjects and they should have | good performance with c++ style exception handling). | I don't mind freeing a stringlist, something bigger and something I should feel responsible about. But I do mind freeing a string or an array. So I have no problems. I won't ask you if you've seen a fast and productive language used today with GC. | 3) loads of small and pointless additional syntax like EG for creating | an object you should just be able to say: | | myobject.create; | | and not | | myobject := Tobject.create; This is not a big deal. I found as a beginners it was a big deal. I find its' more clear this way.. You're creating a Tobject after all, not a object. | | also Begin..End blocks should IMO be replaced with python's indenting. You need to use python and forget about Pascal. What you are asking for here is Python! It's obvious. | | 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, I'd just look into finding a python compiler. Everything you say points to the fact that you like the way python is laid out. That's fine, there's nothing wrong with different taste. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
than
begin, because "{" requires the shift key and finger strain. Plus, I always
convert
"{" into "begin of code block" in my mind anyway.
I rarely find that fast typing helps my coding. It sure helps when writing
emails.. or
when doing bulk operations on big amounts of code. But when creating code,
usually you
have to stop and think.. and fast typing is useless. It helps when you are
typing
comments for the code. Pressing things like "End" and the arrow keys takes my
hand off
the home keys, and this cramps up my coding thought. But it's never the typing
speed
that helps my productivity when writing code. Just comments and bulk operations
on
code that was already written, that is now being changed.
What I find that takes more time then the typing, is running to the manual
trying to
figure out what this cryptic thing does, or what parameter goes where. For
example, if
you set(red,edit) how do you know it isn't set(edit,red)? So in php when I was
using a
text editor.. I didn't have code completion and I always had to look things up.
Or,
even with code completion, you still have to look up more detailed descriptions
of
what the parameters are. But it's not the typing that costs me time.
What also takes more time than the typing of code is writing comments for the
code.
Any language requires comments for the code, so there would be no advantage for
any
language there. Comments are comments.
Lars
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 TObjectList, etc. | | True and thats why I suggested ref counting Tobjects only so that no | manual memory management is required. I tend to make heavy use of TList, | Tstringlist and TFilestream objects so I cant do everything with | tcomponents alas. | | > | >>and a richer framework has made them switch to the dark side. We need | >>to fight back! | > | > | > Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). | > | > | >>>Python is hard to read, especially if multiple blocks are closed at | >>>once, then it's hard to see what block a line belongs to (because of | >>>missing 'end' or '}'). | >> | >>not true because of the indenting (use bigger indents!). Im not saying | > | > | > Bigger indents cause the text to go too wide. More functions also help, I agree. | > | > | >>python is great I just envy *some* of its shorter syntax and it would | > | > | > Ok, some, but not this one ? | | Well typing begin..end all over the place isn't a lot of fun :( Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | Especially as Im gonna have to indent them as well just to make em | readable. So yeah it seems they are more pointless syntax bloat. | Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | >>>I also don't like the magic. For example the 'mystrings.create;' | >>>example you mentioned, it's *totally* not consistent with regular | >>>syntax: mystrings.create means call "TStringList.Create" on the | >>>object pointed to by the mystrings variable. | >> | >>Well Pascal in the only mainstream langugae that does that - I dont | >>see the pont and it aint magic. | > | > | > 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? Why do you even bother using Pascal, it seems you obviously do not like one bit about it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
wonder as to your intention or goal here. It seems python or C# is the perfect
fit for
what you are describing.
By the way, remember that you will always convert "{" to "beginning of the code
block".
At least you don't have to type out "beginning of the code block" but rather
"begin".
Draw the line.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 creates a TStringList? | | Why can't I just go strlist = new Draw the line. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 a high resolution monitor, or you are reading the code in
small
print, that { could be a (.
It's not always clear.
On very short code blocks in PHP, I found myself always going
{
code
}
Anyways! for clairty. So the whole so called "advantage" of going {code} was
defeated.
Because I figured it could have been (code) too, on a blurry day when I just
woke up.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
| Kornel Kisielewicz wrote: | | > Angelo Bertolli 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. There's already a completely working regex unit for freepascal which I needed badly ;-). It was already written by someone else (I believe the lazarus/synedit for freepascal group), I just took the existing work and turned it into a contributed unit. Some of the contributions are just a matter of taking existing work and polishing them up a bit to turn them into a "contributed unit" for freepascal. Sometimes I create examples or programs for my own needs, but really they also could be posted up on the net for other people to use also. So now all the work I do is geared toward making a zip or gzip file for others. Some of the contributions will have to be completely original, but really we also have a lot already: mysql, CGI, regex, etc. I think if freepascal is to be used in greater quantity right now, people should use it for internet applications, servers, clients. I mean if lazarus isn't ready for GUI's as small as Delphi ones, freepascal has to excel at something, right? Since freepascal started out as being for Dos/linux commandline, it's really already ready for command line programs as it is.. and has been for a while. The thing about servers and web programs, is they basically are command line programs. But as lazarus matures and people have more time to contribute to it, then freepascal can also excel in GUI's. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fixes for win32 dlls smartlink
| Hello Florian and all FPC team, | | I finished patchs in pexports.pas and pmodules.pas fixing win32 dlls | smartlink. These patchs are based on latest 1.9 sources which differs | from current 2.0 and 2.1 only by bigger logs, therefore they should be | applicable for both branchs. | | Sincerely, Pavel V. Ozerski Was that why when I created a DLL it only worked with smartlinking off? ___ 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
| 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] 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
| 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
Re: [fpc-devel] Extend the libraries people!
- Original Message - From: "Nikolay Nikolov" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Monday, June 06, 2005 1:16 AM Subject: Re: [fpc-devel] Extend the libraries people! | Bisma Jayadi wrote: | | >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? :) | > | > | Why not both? Delphi is windows-only, so even if FPC became 100% | compatible with D7, the libraries already available for Delphi are | usually windows specific, and FPC libraries are cross-platform. And we all know they are already doing just that. What is needed is more help, action, and contribution. In fact many libraries out there already are working with FPC. We just haven't done anything about them (i.e. submitted them). It's the man work. We can talk all we want but when it comes time to code... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Some of the incompatibilities first need to be brought about through experimentation. So start figuring out what -specific- delphi units that you actually need to get working now. If you have a specific unit or source code that needs to be working -today-, then at least you can submit the exact incompatibility issue to the mailing list or wherever. Otherwise, isn't the incompatibility just low priority, until proven guilty? i.e. it's great that c++ has ways to do neat tricks with all sorts of templates and preprocessing, but does any of your code that you want working today, right now, rely on it? If so, then it's a higher priority.. but if it's something you haven't used in 5-10 years and would be "nice to have some day" then it's just more of a "wish" than a need. I definitely agree that it would be nice to have all delphi code compile in FPC (then maybe Borland might sadly go out of business and we all might be eating free food soon too).. but there are other alternatives in the mean time, which may only take 5 minutes to get working. Such as getting KOL working, which is a complete GUI toolkit for windows! I thought it would take me longer to get this working today. Well I've just got a KOL application working with FPC 2.0.0, just the date/time functions and KOL assembly version define isn't working properly yet. Since Vladimir offers us pure Pascal $define or an assembly $define, I turned $define_pas mode on and got a simple KOL app working after about 1 hour of commenting out date/time functions and changing a few things. I will submit a crumby KOL hello world zip asap. (next goal is to try an MCK app working, and a linux app working, but I"m not sure how far linux is supported with kol) Listen, 26KB for complete a hello world windows GUI program is not bad at all. Maybe we'll get around to making IDE for KOL/freepascal, or Lazarus could be hacked to use KOL. People might be able to cheat in the mean time by building their KOL/MCK applications inside delphi, then compiling with freepascal (since KOL does not use DFM files, rather pure on the fly component creation code just hidden inside include files). Lars | > | Why not both? Delphi is windows-only, so even if FPC became 100% | > | compatible with D7, the libraries already available for Delphi are | > | usually windows specific, and FPC libraries are cross-platform. | > | > And we all know they are already doing just that. What is needed is more help, action, | > and contribution. | > | > In fact many libraries out there already are working with FPC. We just haven't done | > anything about them (i.e. submitted them). It's the man work. We can talk all we want | > but when it comes time to code... | | Indeed :) | | ___ | 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!
Some of the incompatibilities first need to be brought about through experimentation. So start figuring out what -specific- delphi units that you actually need to get working now. If you have a specific unit or source code that needs to be working -today-, then at least you can submit the exact incompatibility issue to the mailing list or wherever. I see that it would be nice to have all delphi code compile in FPC (then maybe Borland might sadly go out of business and we all might be eating free food soon too).. but there are other alternatives in the mean time, which may take less resources too. Such as getting KOL working, which is a complete GUI toolkit for windows! I thought it would take me longer to get this working today. Well I've just got a KOL application working with FPC 2.0.0. Since Vladimir offers us pure Pascal $define or an assembly $define, I turned $define pascal on and got a simple KOL app working after about 1 hour of commenting out date/time functions and changing a few things. I will submit a crumby KOL hello world zip asap. (next goal is to try an MCK app working, and a linux app working, but I"m not sure how far linux is supported with kol) Listen, 26KB for complete a hello world windows GUI program is not bad at all. Where I see a big problem is lazarus not offering small EXE sizes.. since a lot of people do judge an exe by it's size. (not so much worry in GnuLinux... I don't mind shipping a 1MB linux app...since most Linux apps are usually KDE Python bloatware anyway) So until the LCL is smartlinked better or placed into a library file, I think if KOL was avail in the mean time as a temporary solution.. this would solve a lot of problems temporarily... in a quick and dirty manner (took me only 1 hour to get KOL working today...whereas LCL linked smart may take us a year). Maybe we'll get around to making IDE for KOL/freepascal, or Lazarus could be hacked to use KOL as an option. People might be able to cheat in the mean time by building their KOL/MCK applications inside delphi, then compiling with freepascal (since KOL does not use DFM files, rather pure "on the fly" component creation code just hidden inside include files). Lars | > | Why not both? Delphi is windows-only, so even if FPC became 100% | > | compatible with D7, the libraries already available for Delphi are | > | usually windows specific, and FPC libraries are cross-platform. | > | > And we all know they are already doing just that. What is needed is more help, action, | > and contribution. | > | > In fact many libraries out there already are working with FPC. We just haven't done | > anything about them (i.e. submitted them). It's the man work. We can talk all we want | > but when it comes time to code... | | Indeed :) | | ___ | 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] Re: KOL for freepascal (was: Extend the libraries people!)
| If you don't want to use the form designer, Lazarus is a capable code | editor with good support for include files for KOL/freepascal projects | too. Just use a program or custom program in Lazarus. | | Vincent. I use Lazarus all the time.. but form editor would be nice in the future. Creating components on the fly with KOL is not so bad, but it also takes time, and it's not as good for beginners who want to try freepascal quickly with no hassles. I'll see if MCK works with FPC 2.0.0.. if so, people could build applications in Delphi but compile in freepascal/lazarus. That would just be evil and nasty. While converting the KOL libraries and getting a hello world application running, I realized I did not have to do this! Someone has already done it already: http://members.chello.nl/t.koning8/fpc_in_kol_proper.htm So we at least have two people working on KOL for freepascal so far! Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: KOL for freepascal (was: Extend the libraries people!)
| I'll see if MCK works with FPC 2.0.0.. if so, people could build applications
in
| Delphi but compile in freepascal/lazarus. That would just be evil and nasty.
Well I tried it. MCK works first try on one of my projects I built with Delphi
over a
year ago. Therefore, I'm happy to announce that you can create
applications
in the Delphi IDE visually, and then compile them with FPC! using
KOL/MCK.
I'll upload a flash video of my PC and show you what I mean - when I get a
chance
(.swf format).
So basically using MCK/KOL one can
- visually create applications with Delphi
- open lazarus or any other IDE, compile the application that you built with
Delphi
- or compile the application with some other IDE, or command line FPC
- someone may build a plug in for the Delphi IDE to compile the application
with FPC
directly from Delphi IDE
- have an exe application who is only 50KB in size or so!!
All I had to do was open an old MCK application I built a few months ago and
add the
following lines to the code in each KOL/MCK source file:
{$MODE Delphi}
{$DEFINE KOL_MCK
What does this mean for us as FPC developers?
For Windows development, MCK/KOL applications can be created visually by RAD.
Exe size
is 40KB for a simple application. Lazarus is 1MB currently. People can use
KOL/MCK for
visual RAD on small-medium projects until lazarus is more mature with regards
to exe
size.
This is very big news.. because all my KOL/MCK applications right now will
compile
inside Lazarus with no modifications..and they were all built in Delphi
months/years
ago.
I will have to check to see if all the MCK components will compile though..
hopefully
things like KOL synedit and KOL synapse may even compile.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: KOL for freepascal (was: Extend the librariespeople!)
| Maybe we should: | 1. Put an entry in the FPC contributed units. | 2. Provide a link on the FPC links page ? | 3. Add an entry in lazarus-ccr ? | | Michael. We could put a link in the FPC wiki too. Yes I'm sure Thaddy will not mind at all.. I'm making some freepascal KOL demo programs that I will also add to contributed units section as I get them done. Thaddy already has some KOL exe demo's in his package too. I've put a link up on PasWiki and will be journaling some of what I'm doing. http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=KOL-for-Freepascal I'm ready to throw my delphi compiler in the garbage almost. Lots of my apps I have been working on for years are KOL based ;-) And now that they compile with FPC, and probably would have been compiling ever since FPC 1.9.0 era(I just didn't try) Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: KOL for freepascal (was: Extend thelibrariespeople!)
Yes I had to convert some constants to var's (and initialize them) in one procedure.. and I noticed Thaddy did this too. I assume delphi is a bit less strict in that it let's you get away with the below... but I'm not sure if it's good to be less strict in this case.. (poor style?) What do you think.. | | On 7 jun 2005, at 14:15, Marco van de Voort wrote: | | > procedure x (const str: string); | > begin | > filewrite (filedescriptor,pchar(str+#13#10)^,length(str)+2); | > end; | | I do not think this should work. You can't pass the address of a temp | like this. | | | Jonas | | | ___ | 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] Re: KOL for freepascal (was: Extend the librariespeople!)
| >> procedure x (const str: string);
| >> begin
| >> filewrite (filedescriptor,pchar(str+#13#10)^,length(str)+2);
| >> end;
| >
| > I do not think this should work. You can't pass the address of a temp
| > like this.
|
| Fixed for delphi mode only
{$MODE slacker}
Good idea, only for slacker mode.. real coders using real object pascal will
not abuse
this delphi slack-off style code ;-)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
| Do not look at delphi copyrighted source, but get info from public sources | like helpfiles for download on Borlands FTP etc. | | This should be enough to reconstruct a rough interface, details will then | later be found by testing real delphi code. | I was just wondering, are there any source code files that Borland company offers which doesn't have copyright and is public? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
| | | Do not look at delphi copyrighted source, but get info from public sources | | like helpfiles for download on Borlands FTP etc. | | | | This should be enough to reconstruct a rough interface, details will then | | later be found by testing real delphi code. | | | | I was just wondering, are there any source code files that Borland company offers | which doesn't have copyright and is public? | Another question: if someone already owns Delphi, they could compile any source code from their Delphi CD with freepascal? Is this legal? I'm not saying that you could distribute the sources, but you could compile it with FPC? Or is that not legal? For example.. one could try compiling the Delphi VCL as a Delphi product owner, but not distribute the VCL sources themselves, just what was compiled? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Silly syntax games
For all the keyboard wussies out there:
Note, for all you that are afraid of long reduntant begin/end typing, you could
go
{$define beg:=begin}
Or
program Project1;
{$mode objfpc}{$H+}
{$define b:= begin }
{$define e:= end }
{$define e:=end }
var
iLoc:integer;
b
b
for iLoc:= 1 to 60 do
writeln('test');
e;
e.
But.. for all the C wussies out there.. this won't work :
program Project1;
{$mode objfpc}{$H+}
{$define {:= begin} //this works
{$define }:= end. } //this doesn't work
{$define }:= end; } //this doesn't work
var
iLoc:integer;
{
for iLoc:= 1 to 60 do
writeln('test')
}
So how do you escape the } in a define?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Minor Error in $delphi mode for a unit I'm converting
While converting a KOL regular expression unit for use with freepascal, I came
across only one compile error, in {$mode delphi}
The error was here:
const
RegExprInvertCaseFunction :
TRegExprInvertCaseFunction=TRegExpr.InvertCaseFunction;
Error: Typed constants of the type "procedure of object" can only be initialized
with NIL
The code below seemed to fix the problem, as it compiled ok.
var
RegExprInvertCaseFunction : TRegExprInvertCaseFunction;
Is the error that I got correct even for delphi compatability? Is it bad code,
good code?
I have no idea myself.. looking for your guys' input.
Regards,
Lars
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor Error in $delphi mode for a unit I'm converting
| >> The error was here: | >> const | >> RegExprInvertCaseFunction : | >> TRegExprInvertCaseFunction=TRegExpr.InvertCaseFunction; | | Can you create a complete example and in the best case add it to the bug | repository please? Yes, just thought I'd first figure out whether the code was wrong, but I suppose even if it is bad code, Delphi may do something good with it for the user automatically, and compile it anyway. When submitting bug reports, do you guys like to see the line number and exact unit I was using or do you like to see small examples recreated in a short program of my own? (or maybe either or?) Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Silly syntax games
| > {$define {:= begin} //this works
| > {$define }:= end. } //this doesn't work
| > {$define }:= end; } //this doesn't work
|
| Are you sure that the first example really works? It might do somehting
| unexpected, even if the compiler doesn't complain.
I just tried it on short code, and it worked. Maybe not on longer code with
other comments further down, who knows. I don't really care though because I
find parenthesis hard to read on my monitors on hi res. I'd rather do
somethingelse useful with the macros.
| The problem with "{" and "}" is the conflict between these characters as
| delimiters of comments (the whole directive), and their use as
| identifiers inside the directives.
|
| As soon as you've redefined the meaning of "{" in the first line, it
| most probably becomes impossible to add any further compiler directive,
| because these start with exactly that redefined character!
Well that's why I was asking if any way to escape it like in a regex where you
go \escape , but again it's really not important for my needs.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
| | > Another question: if someone already owns Delphi, they could compile any source code | > from their Delphi CD with freepascal? Is this legal? | | Compilation for private use is legal. Borland disallows to distribute | their library source code, also in compiled (object) form unless as part | of applications. The exact license terms are part of every Delphi | distribution. But compiled with delphi compiler, or freepascal? I wonder if they have a specific restriction where you can only compile the code on their compilers... Not that I know of but.. I thought maybe you guys had come across something like that | Contributions to FPC, like to every other public project or library, | should be free from any special restrictions, so that a redistribution | can not conflict with the rights of the authors of the respective code | etc. I realize that the FPC should contain code free from restriction.. And we have to be careful with some people because some of us have copy/pasted code from the VCL and not marked it as so. I was more interested in discussing those who already have a copy of delphi and who are "thinking" about using freepascal.. then if say they could reuse all their delphi code in emergency, they could at least have that "safety" feeling in the back of their mind, when thinking about starting to use FPC. So the specific question I have is whether borland might have some restriction in the area that their source codes can only be compiled on a borland compiler... if sold commercially, or if used in freeware even. So far it seems this is not the case.. but I still don't know, there might be some little tiny wording we have missed somewhere. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fast ascii upper/lowercase
Are the linux results faster than windohs? Are stripped and smartlinking on or off? Makes no difference ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch to speed up Uppercase/Lowercase functions
Where do I find the cpu/cpu-timer unit guys... Directory? Download link? Thank you. | | On 12 Jun 2005, at 00:12, Martin Schreiber wrote: | | > Some more test results with PII 350MHz and | > two additional implementations with lookup table: | | Try also with register variables on (-O???r), it will probably more | closely match Kylix' results then in case of the loop versions. | | | Jonas | | | ___ | 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] Patch to speed up Uppercase/Lowercase functions
| Where do I find the cpu/cpu-timer unit guys... | Directory? Download link? | | Thank you. | Is this the one? ;-) http://members.yline.com/~tom_at_work/ | | | | | On 12 Jun 2005, at 00:12, Martin Schreiber wrote: | | | | > Some more test results with PII 350MHz and | | > two additional implementations with lookup table: | | | | Try also with register variables on (-O???r), it will probably more | | closely match Kylix' results then in case of the loop versions. | | | | | | Jonas | | | | | | ___ | | 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 maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch to speed up Uppercase/Lowercase functions
http://dennishomepage.gugs-cats.dk/LowerCaseChallenge.htm LowerCaseShaPas2_c This one here is in Pascal, using GOTO and LABEL which consistently work fast on both -Og and -OG But no one wants to maintain a GOTO and a LABEL.. [LowerCaseShaPas2_c] was slightly slower than [lowercase 6 ] (second fastest) in -OG mode [LowerCaseShaPas2_c] was slightly faster than [lowercase 9] (still second fastest) in -Og mode .. so it's more consistent across compiler options it seemed So maybe [lowercase 6 ] result should be submitted to fastcode to be tested? Also, if no one wants to use the assembly functions and GOTO/LABEL functions in the RTL due to code bloat/maintenance, we could always offer an optional unit where people could call the fast functions only if they needed them badly. Just like how fastcode does, external from the VCL. - Original Message - From: "Martin Schreiber" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Saturday, June 11, 2005 9:29 PM Subject: Re: [fpc-devel] Patch to speed up Uppercase/Lowercase functions On Sunday 12 June 2005 00.23, Jonas Maebe wrote: > Try also with register variables on (-O???r), it will probably more > closely match Kylix' results then in case of the loop versions. Kylix: lowercase execution time: 336887 lowercase 1 execution time: 380923 lowercase 2 execution time: 375411 lowercase 3 execution time: 369814 lowercase 4 execution time: 320665 lowercase 5 execution time: 300580 lowercase 6 execution time: 219047 lowercase 7 execution time: 356606 lowercase 8 execution time: 249913 lowercase 9 execution time: 252431 -OG1r lowercase execution time: 465596 lowercase 1 execution time: 378780 lowercase 2 execution time: 389711 lowercase 3 execution time: 375878 lowercase 4 execution time: 225029 lowercase 5 execution time: 228708 lowercase 6 execution time: 158026 lowercase 7 execution time: 264930 lowercase 8 execution time: 182939 lowercase 9 execution time: 165446 -OG2r lowercase execution time: 471705 lowercase 1 execution time: 378160 lowercase 2 execution time: 388112 lowercase 3 execution time: 395773 lowercase 4 execution time: 227191 lowercase 5 execution time: 227925 lowercase 6 execution time: 156750 lowercase 7 execution time: 258313 lowercase 8 execution time: 181842 lowercase 9 execution time: 165069 -Og1r lowercase execution time: 464843 lowercase 1 execution time: 486571 lowercase 2 execution time: 463269 lowercase 3 execution time: 472342 lowercase 4 execution time: 247544 lowercase 5 execution time: 399030 lowercase 6 execution time: 646651 lowercase 7 execution time: 263588 lowercase 8 execution time: 636059 lowercase 9 execution time: 170660 -Og2r lowercase execution time: 470038 lowercase 1 execution time: 487086 lowercase 2 execution time: 459035 lowercase 3 execution time: 476304 lowercase 4 execution time: 243678 lowercase 5 execution time: 399953 lowercase 6 execution time: 646284 lowercase 7 execution time: 265147 lowercase 8 execution time: 632796 lowercase 9 execution time: 169471 Martin ___ 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] Patch to speed up Uppercase/Lowercase functions
I use fastcode stuff some times, I just never spend too much time figuring out how all the code works. The way I do it is I create my software application first in Pascal.. Then if I find a huge bottleneck, I pull in a optimized function in place of the old one.. even if I dont' understand the optimized functions entirely. I'm sure lot's of people know and do this, but I want to make a point that sometimes 90 percent of your common GUI app doesn't need to be optimized.. only certain concentrated sections of the app need to be optimized, like search and replace routines, or especially with a compiler who is running through text over and over again (patronizing the compiler team here). With lowercase function I'm sure optimizations will help a lot if we are using it to do bulk translations of 1000's of MiXedCaSe text files from crackers/hackers whO wRiTe lIke tHiS. (ping Carl Eric ..j/k) More realistically, it could also help in a CGI app say if you were converting people's web posts to lower case (if hundreds of people posting at the same time for example). Lars Op Sun, 12 Jun 2005, schreef Daniël Mantione: > I can figure out how it works, but it is interresting and should be fast. I can't figure out... Sorry. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch to speed up Uppercase/Lowercase functions
> Borland's compiler does register variables better than FPC and can do > induction variables. This has a large impact on the code generation in > general. |>I thought I saw that FPC beat Kylix in several cases in the timings |>that were posted. I saw this too, so what do you mean Daniël .. in the -Og cases? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Pre-processing to Post-processed
I will be working on a feature or a program that outputs post-processed code when using macros. Just to verify that this feature hasn't already been implemented or a program hasn't already been created by someone? My ideas for a compiler feature or program: -If the -Sm option is on, and a user specifies some define macros -and if a macro dump compiler option is set, the compiler or program runs through the code, replaces all macros, and dumps the processed source code into files into some directory for the user. The source code that is dumped for him, is the post-processed code. i.e. the user will now get to see source code after his macros were dropped in place. Basically, a feature to create unit files with macros shown directly in place. Is there already a feature or program that does this? I don't want to reinvent the wheel. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$DEFINE x := something}
I've always wanted to find the most compact and readable font myself. Just never spent the time looking. Well today I did a bit of searching, and found some fonts that are more compact than at least Courier New http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Compact-Readable-Fonts Save about twice as much screen space if you just choose the right compact font. Courier new seems to waste a lot of space between lines. | > > There is a reason why the whole compiler sources are lower case: the | > > sources are rather complex with a lot of nested ifs etc. so we use a | > > very high screen resolution to edit the source. I use usually 70 | > > lines on a 17" TFT or 19" CRT ... | > | > A 17" TFT has usually a resolution of 1280x1024. To get 70 lines, you | > need a 7pt font, not really readable. On the other side, than the | > source have only 25% of the screen wide. You should use a rotatable | > screen, then you can use a readable font and use more than 25% of the | > screen. | | 1280/16 = 80. | | 16 is normal vga font iirc. | | ___ | 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] {$DEFINE x := something}
Have you guys heard of something called the GUI? I just heard about it yesterday
:-(
Common guys, the command line is useful but let's give Lazarus a run for it's
money here. Err... a run for it's code.
I find the GUI based tools more powerful over the command line in many cases.
Especially if the command line is there in the background for you at your
fingertips.
For example midnight commander can't do anything, compared to what Total
Commander can do. Midnight commander has absolutely no chance compared to Total
commander. I also find for example Apititude for Debian just sucks rocks.. the
command line fixed font just limits you so much. Scrolling through aptitude to
try and find my installed packages on Linux is a pain in the neck. Kpackage is
better visual wise, but it's written in bloaty python code so it also sucks
rocks. (more freepascal based GUI management tools are needed on Linux)
But command tools are useful as a back up, especially when X-windows crashes. I
use midnight commander to FTP files up to websites in emergency. But still, GUI
things like total commander kick its arse in the end. I think Linux needs more
compiled GUI programs, and less bloaty ones like Mozilla and Open Office.
Sometimes I want to use the command line on Linux just because their GUI
programs are slow and basically suck. I'm sorry, but windows with it's tacky
Windows 2000 look still beats GTK for screen space. I think that's why some guys
still use the command line too much on Linux... because many of the GUI programs
on Linux suck, and are slow. This will change though, as people figure it out.
Florian, what system do you run your IDE in? Linux in an Xterm window?
or a Dos windoh in Windohs?
I do use the console fp-ide on my slower Linux computers and servers who don't
have X-windows installed. If I want to compile something directly on the server
I just fire up the IDE in a TTY. Which is convenient.. but on the desktop, for
the main bulk of work.. I ditch many of the command tools.
My view is that the command line is extremely useful, but not so much in the
ways most Linux users see it as useful. I like it especially if you can build a
GUI program that wraps right around the command line (i.e. lazarus and the
compiler), so that if in emergency the GUI crashes, you still have the command
line as your back up. I love the networking available in linux for Apt-Get
installs and emergencies too. Dos sucks in this area.That and the fact that you
can't even boot to Dos anymore with Windohs.
- Original Message -
From: "Christian Iversen" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Thursday, June 30, 2005 1:19 PM
Subject: Re: [fpc-devel] {$DEFINE x := something}
| On Thursday 30 June 2005 21:34, Florian Klaempfl wrote:
| > Christian Iversen wrote:
| > > On Thursday 30 June 2005 20:15, L505 wrote:
| > >>I've always wanted to find the most compact and readable font myself.
| > >> Just never spent the time looking.
| > >>
| > >>Well today I did a bit of searching, and found some fonts that are more
| > >>compact than at least Courier New
| > >>
| > >>http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Compact-Readable-Fonts
| > >>
| > >>Save about twice as much screen space if you just choose the right
| > >> compact font. Courier new seems to waste a lot of space between lines.
| > >
| > > Clearly, the only right choise is FixedSys :-)
| >
| > Yes and a console IDE :) It does 120x70 easily :)
|
| Hehe, sounds sweet ;-)
|
| --
| Regards,
| Christian Iversen
|
| ___
| 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] {$DEFINE x := something}
Well I get 79 lines in FP-IDE http://z505.com/images/fonts/FPvsLaz.png ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$DEFINE x := something}
| Please move this thread to fpc-other. This has nothing todo with pascal. Neither did Florian's or Christians font related posts, and neither do the smiley's we posted have anything to do with Pascal. :o) I think the effeciency of your development environment and setup you are using to create pascal code does have everything to do with FPC-devel and even FPC-users. | Everybody needs to decide for himself what he prefers to use: commandline, | TUI or GUI. Everyone does not need to decide for himself in a lonesome, cold world. We can research the facts and information together, before making a decision about TUI or GUI. Which is why I went ahead and offered downloads and screenshots of the fonts that will make FPC development more effecient for many fpc and lazarus users. As I have indicated, I am very happy to have 83-88 lines of Pascal code on my screen versus even 70 or 55. And if it makes Pascal coding more effecient, then it should be posted for other -developers- and users to see. Regards, Lars p.s. I almost went ahead and removed all my contributed units from the FPC website, with fear of some of the source code comments even being partially off topic and non-pascal related. However, I realize this is just the internet and I do sometimes have a stronger pulse than usual when reading my email. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] low level function for pascal language
While working on some functions in the strwrap1.zip package I am upgrading, I have found the need for a new low level function I think. Something similar to ReadLn(F,Line) This one is slightly different: PassLn(F) Instead of reading the line, copying the text the line into a Line var, the PassLn function just passes by the line and sets the pointer up at the beginning of the next line. No copying of the string. This way you can skip copying the text of the line, and move on to the next one directly. I have made a whole bunch of patches to my Fpc sources and recompiled a lot of units, and have got a PassLn function working today :) All the error messages and some low level units needed slight modification (i.e. _readln_passln_writeln instead of _readln_writeln, fpc_PassLn_End addition, etc.). But it wasn't so bad really. Now the question I have is: does Pascal already have a function like this? I definitely need a function like this for some ideas I have with strwrap1 package. If there is already a way to do this, at least I know my way around the FPC low level string sources a bit more now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] low level function for pascal language
| | > Now the question I have is: does Pascal already have a function | > like this? | | Yes: readln(f) | | | Jonas | Wonderful.. Hmm, how do we add this to the FPDOC help safely, since it isn't doesn't seem to be created automatically by FPDOC? Maybe we could just make another example demo for people i.e. online fpdoc help just shows readln(args) but not readln(f) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] low level function for pascal language
| SeekEoln(Text) Ahh, so would this offer exactly the same functionality as Jonas' suggestion? | readln(f) | | Or would the "skips spaces" I read about in seekEoLn offer different different behavior? Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Patch: Exception handling without SysUtils
I think the idea is that exception handling should be kept separate in case a
user wants to use his own exception handling. If the user explicitly wants
to use exception handling, he just includes the sysutils unit.
However, I suppose if the sysutils unit involves some extra code bloat (due to
initialization and finalization), and the user doesn't want to use sysutils in
his project at all (but he does want exception handling) then there should be
an option to use exception handling without the sysutils unit?
(maybe a {$MODE HandleException} ?)
- Original Message -
From: "Yury Sidorov" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Thursday, July 07, 2005 10:48 AM
Subject: [fpc-devel] Re: Patch: Exception handling without SysUtils
| Hello,
|
| I had problems with my mailbox. Please resent your answer to this topic to
| my mailbox [EMAIL PROTECTED]
|
| Also, the previos patch was not complete. Here is complete and tested
| version.
|
| Yury Sidorov, [EMAIL PROTECTED]
|
| ___
| 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] small changes in math.pp (attach 6Kb)
| > and base2power func | If you know how to write it, you can put this function in an external unit of your own.. doesn't have to be in the original unit, if others don't want it there. I use an IP address converter function when using sockets that isn't in the sockets.pp, which is just a wrapper around shl. Handy in this situation, because Copy and Pasting ip addresses is not easy when you always have to convert to shl. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel] cross-compiling (linux program from Win32 platform)
Another option is to use CoLinux if you find "true" cross compiling too much tedious work. CoLinux acts like a real operating system at your finger tips, which means command line programs can be tested immediately.. There are advantages to both methods. The bottom line is you are going to have to test your app on a real linux at some point (ultimately, there's no sense denying this), so I have figured the best way to compile is to remotely compile programs through the network over to a real linux hardware box or to a fake colinux box (not true cross compiling, just that you hit compile on the windows machine, and -boom-, it compiles on the linux machine or fake colinux machine).. I will release some tools for this at some point. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Exporting from Elf okay?
[moved to devel]
|
| With regards to gnu linux:
| How about the Elf format?
| Is it possible to export code from an elf? (i.e. export functions)
|
Okay, I researched the topic. Of course, yes, you can export functions from an
executable
on linux. But freepascal doesn't seem to like it just yet. It must be done
supposedly
with the -E option to the linker (ld) or -export-dynamic
(gcc is -rdynamic)
This of course, was after modifying the compiler to parse the
exports keyword properly
[psub.pas]
else if islibrary or
(target_info.system in [system_i386_linux,system {<<]) then
read_exports
So after getting the parsing of the exports keyword set up to work, I tried
passing the -E
option in freepascal compiler (the -k option as also seen in the lazarus linker
options
tab)
After compiling a program, with an export it didn't seem to work properly. It
compiles
okay, but when I run it two writeln('test')'s appear instead of one, and the
program quits
without an error.
So now the next thing to figure out, is why exports from an executable on
linux won't
work
even when you pass the -E or export-dynamic option to LD.
I'm guessing the symbols aren't being placed in the object files correctly for
the linker
to use, or they aren't being placed there at all. If you guys have any tips let
me know..
I'll be looking into the compiler sources more, probably the sections that
write the
object files now.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Exporting from Elf okay?
| > Okay, I researched the topic. Of course, yes, you can export functions from an executable | > on linux. But freepascal doesn't seem to like it just yet. | | How do you intend to use the exported symbols of an stand-alone | executable? | As a shared library, or how else? A shared library can call functions from the executable that it is running from. Two way communication is very important to me. | Perhaps Linux and Windows executable files are not too different. On They aren't really, is what I found, after reseaching them. | Windows the file format (MZ) is the same for DLLs and EXE files, the | main difference is the invocation through the WinMain or LibMain entry | points. On Linux the shared libraries may have a similar implementation, | so that the exported symbols can be used only with shared library | modules. Functions can be used in executables in linux by calling the -export-dynamic or -E with the linker (LD), but it isn't working yet with freepascal. Works with GCC (also called -rdynamic). In windows, you can either get the handle of the exe using getmodule, and then getprocaddress(exehandle, 'myproc')or you can just call statically procedure myproc; external 'myprogram.exe'; (instead of mylibrary.dll ). I asked some GCC guys "can an elf executable export functions?" and they sort of laughed at me. They do it all the time, and they wondered why I was asking such an obvious question. But I honestly think a lot of people don't know you can do this. Without being able to export functions form an executable, I find it's sort of like having a client without a server. Why have a client without a server? To me, it is essential for the executable to export functions.. (this is where the true power can be squeezed out of plug-in systems - Lazarus RB Edition relies on this and would never work without it...unless I used sockets, interprocess communication, or something similar.) Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Exporting from Elf okay?
I have found a large PDF file to study which contains a lot of information about Elf and object file format. Hope to get my feet wet. Have also downloaded the Linker sources to see what exactly it does differently when it receives the -E option. > If gcc can do it also fpc can be made to do it. But for me it has no > priority to add support for this to fpc. Ofcourse patches are welcome. > Will work on one. I think it is an important feature maybe in plug-in situations specifically. But a lot of programs have plug in systems these days (and maybe not as well thought out ones, who don't utilize this trick). Not sure what else people use this feature for other than plug-in style situations - might ask the GCC crowd if I'm brave enough. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Exporting from Elf okay?
> > I implementing exporting from programs in svn trunk. Did someone test? are you trying to implement it now? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Exporting from Elf okay?
> > > > I implementing exporting from programs in svn trunk. Did someone test? > > > are you trying to implement it now? > nevermind, I see SVN log on August 13 testing and looking now ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] revision 939 broken
> ppc386 -FE. -FU/home/fpcfan/src/fpc-test/rtl/units/i386-linux -di386 > -dRELEASE ../unix/sockets.pp > sockets.inc(431,3) Error: Identifier not found "Result" > sockets.pp(69) Fatal: There were 1 errors compiling module, stopping > sockets.pp(69) Error: Compilation aborted > > Vincent. you guys probably know, but the fix is simple..compiles if you change line 431 'Result' to StrToHostAddr6' objfpc mode is off possibly on this unit? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Exporting from Elf okay?
>
> I implementing exporting from programs in svn trunk. Did someone test?
>
Okay, I envy you Florian. But we all do.
>From the minimal tests I have done - it works just as I had explained in the
>original mail :)
The big test will be when I compile the big ugly and beautiful Lazarus RB beast
on linux.
I have to familiarize myself with the syntax. You used "public" keyword you
after the functions.
That is required you think, in order for this to work on linux? And the
{$linklib } directive is
needed in all cases? Or just the way you chose to try it?
>From looking at your SVN mods, it appears part of the tricks in getting this
>to work was to make
sure certain things weren't stripped from the library? (which could have taken
me months to just
halfway figure out)
Regards
Lars
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] html doc bug
At http://www.freepascal.org/docs-html/ref/refsu55.html there is a little bug that I have been meaning to tell about Just change file:../prog/prog.htm to ../prog/prog.htm p.s. where is the best place to report documentation bugs/spelling errors/etc. In a bug report or on the list? or do we prefer diff patches to the docs? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
>Hello, > >I am trying to understand what exactly generics are. I read the wiki >page, but there are lot's of code examples and very few explanations. >Can someone explain it to me in a (relatively) simple way? > >What problem is it trying to solve? > >And how do generics relate to interfaces? I had the same problem for a few years. It took me a few months/years to first diagnose "what the fudge" templates/generics actually were, and what problem they exactly solved. All the information about generics is pretty non-real world and non-case study on the internet. It is also hyped by programmers who again seem to show no real world or case studies. But I can see how they can be useful in theory, nevertheless. I'm not going to give you a technical explanation on what they are, because someone else can do that (and I don't have experience with generics, so I'm not qualified to do so). Here is a vague non-technical explanation: Basically generics helps you save some Typing and syntax in your units. You can address several things at once with the same Type. Supposedly, this encourages code reuse. You can address and create things via a shortcut syntax sort of way. Myself, I won't be using generics any time in the next few months/year.. as I still have a lot of experience in the non-generic programming world to gain, before I even think about generics. Unless of course, I find a Delphi/freepascal unit or package that uses generics, then I will make an effort to learn generics. -- L505 Note to any visitors: z505.com is switching servers, site may be down in the next 24-72 hours ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
> > The Very Big Advantage (Tm), is that you get syntax checking, while still > using a type diversely. That's impossible to do (at compile-time) without > generics. > > Probably the best example of this is something like TList: > > Without generics: > > TOrange = class ... end; > TApple = class ... end; > > var > T: TList; > begin > T := TList.Create(); > T.Add(TApple.Create()); > T.Add(TOrange.Create()); > // Whoops, what was that? Now our program might crash. > end; > > Of course, we could create a specialized TAppleList that only accepts Apples, > but that's boring and hard work. A much cleaner way is generics: > > var > T: TList; > begin > T := TList.Create(); > T.Add(TApple.Create()); > T.Add(TOrange.Create()); > // This wont compile! The problem is prevented at compile-time! > end; > > I hope that answers your question as to why it's a good idea :-) > > -- > Regards, > Christian Iversen Sort of, but I don't see why people use TApple and TOrange examples all the time ;-) I mean when was the last time you actually programmed a software application that was organizing Apples and Oranges? I use things like strings, databases, integers, FTP, CGI, stringlists, etc. Sure apples and oranges can represent a sort of metaphor for ANYTHING, but I'd prefer just to cut straight to the real world example instead. I guess the real world examples are hard to display unless you have actually used generics in a software program, and you are willing to offer code snippets from the program. I wish for example, I could see someone using something more real world such as: -BEGIN OF CASE STUDY- (just a fake one) ---Description--- I used generics in my FTP uploader software application and it prevented an error for me. ---Code examples--- Here are some code examples taken right from my real world ftp application written in C++. Since Pascal doesn't have generics currently, this example is in C++ only to help you see why they are useful in an existing software application. .. ..insert code here .. ---Conclusion--- My executable size is now 1400KB whereas before when not using generics it was 1340KB. The 60KB gain was not a big deal. My conclusion is that generics offer significant advantages, but they shouldn't be used in some situations. If Pascal implements generics I estimate my executable will be about 1400KB too, and the syntax will be as follows if I was to convert my C++ application to Pascal using generics: .. ...insert code here... . ---Other notes:--- Generics don't work well in the following situations: A)using a type diversely can cause issues when... B).abusing generics could cause issues if you if... ... C).generally they shouldn't be used if ... -END OF CASE STUDY- However, I suppose I'm idealistic and too much of a real world guy some times. Case studies can be perfect if you have software program already in existence, or if you can create a small demo program that is fully functional and actually does something real on the computer. I helps more easily prove the advantages of a certain programming. paradigm. Then there are video case studies, but I won't get in to those since those are more to do with demonstrating visual advantages of GUI's and software features. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Systems fair
> I read the very interesting article about the Systems fair: > > http://www.freepascal.org/wiki/index.php/Systems_2005 > > One conclusion was that the web appearance needs to be improved: > ".. > The websites are a serious problem. They are quite ugly and not very > intuitive, and this is the case for years. The members present had quite > some difficulties to explain how to get the latest full installer for > Lazarus, for example. Not everybody knows Freshmeat, and the main > address www.freepascal.org won't help those people really much to get to > the right download location. sg will handle this issue as soon as possible. > ..." > > Are there any plans so far? > I think there should be more independent websites promoting freepascal in the mean time. When I volunteered and asked why there wasn't a "contributed programs" section in addition to the "contributed units" section, and why there wasn't more contributed units categories, they simply stated the answer to my problems was creating more pages on the FPC wiki. I've given up suggesting ideas for the FPC website since then, and now work on my own FPC based websites and put effort into them, instead of suggesting new ideas for FPC website. I think other people are encouraged to build FPC related websites if they can't help the freepascal site directly. I think like how torry.net, Delphi 3000, etc. work (but you obviously can create smaller websites than that) people should be building independent websites to promote freepascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR advancement
> >> > >>> 3. Are there any real world applications made with Free Pascal/Lazarus? > >> > >> > >> > >> I guess that even a "manager" is able to type "fpc" or "lazarus" into > >> google. > >> > > And he'll find a bunch of fanboy websites. True.. we can create directories more like Torry.net instead of things like PasWiki which sometimes are biased and fanboy-ish ;-) I guess I think its a good idea to outsource the web development to people like me, you, and freepascal users - so Michael, Daniel, Jonas, Florian, Peter, and all those others can work on the compiler and documentation instead of website designs. > > So what answer would you propose for the FAQ question "Are there any > real world applications made with Free Pascal/Lazarus" ? A huge list of > every program that was ever compiled with FPC ? A short list of "chosen > projects" ? Who will decide and maintain the list of "most bright > projects developed using FPC+Lazarus" ? "Contributed Programs" section. Let the users manage the directory (outsourcing the work, just like how "contributed units" section is outsourced and requires little/no maintenance from FPC team). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Systems fair
> >I think like how torry.net, Delphi 3000, etc. work (but you obviously can > >create > >smaller websites than that) people should be building independent websites to promote > >freepascal. > > > > > > > I would diagree. Up to now there a tons of sites concering FPC/Lazarus: > freepascal.org, sourceforge, stack.nl, wiki, ftp-sites, mirrors, cvs, etc. Mirrors and cvs are not at all like what I was talking about. > That produces much confusion. Of course, mirrors and cvs do cause confusion. And all the clone documentation sites out there do too. That's not what I was talking about. In order to see PHP in use, people build sites with PHP and put a PHP logo on it. PHP isn't successful because of the PHP.net website! > "One face to the customer". I'm talking about genuine, unique, freepascal user websites. Look how many PHP or Visual Basic sites there are, with "I'm a happy PHP user" written all over them. The extension myfile.php is marketing itself. If your websites had a myfile.pp or mysite.fp extension, that would be marketing via brand naming. The PHP extension on files itself is branding. Every time you see a PHP extension on a file, you are getting brainwashed with the word "php". That's marketing. Okay, I come from an internet marketing background. If you have one single domain name, your search engine rankings and traffic are pretty poor. If you have 5000 websites promoting freepascal, your search engine rankings and traffic improve greatly. It's similar to having 5000 ads in the paper versus one nice ad. And mirrors bring your search engine ranking down. If you have 100 mirrors, your search engine rankings and traffic do not improve greatly. Mirrors can cause google to see your website as clones, and this sometimes brings the ranking down. That's not really a big issue right now with the FPC website, since the mirrors don't seem to be affecting it's ranking. I don't think the GNU C compiler website looks all that good? In fact I don't even know if there is a GNU C compiler main website or homepage!? I probably wouldn't ever visit it, since there are so many other ways to download the GNU C compiler. I'm more interested in the people who USE and have had real world experience with the compiler, right? I don't think the GNU C compiler is popular because of one nice website. I think the reason GNU C compiler is successful is because of all the fan boys, their applications (gzip, midnight commander, linux, and 50,000 other applications made in C), and their websites, and of course directories like debian.org which link to several C applications. So in summary: one nice website is nice, but from a realistic internet marketing perspective, more importantly are huge databases of content, examples, and program/unit directories from the users. FPC documentation already exists well on the search engines, but examples of the applications or websites that are run off FPC engines or FPC code, do not exist. Don't get me wrong: one nice website, is not harmful in any way. It's not going to harm anyone. I just seek a realistic marketing perspective, where thousands of people are downloading software from word of mouth and real world examples, rather than a nice looking website. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [RFC] fpdoc output comment from the source
> Florian Klaempfl schrieb: > > > > Why ;)? Indeed, if you want generated docs from comments, better use pasdoc. > > the source scanner used by fpDoc supports reading of comments for quite > some time; but as I already told you (or was it Mattias?), the final > support in fpDoc is still missing. > If there is really interest in this feature, I will have a look at it. > (And no, I didn't inspect the sent patch yet.) > Any more opinions? Important, not so important? > I think comments will be useful and important for developer versions of the documentation. Users may not care about the comments in the source code, but it will be really useful for a "developer version" of the docs. Many times I write comments in the code describing what the code does, so this comment feature in FPDOC would help us make developer documentation clearer (users reading the docs, may not care about comments so much). Kind of unrelated, but I'll be working on a CGI program that taps on top of the FPDOC generated HTML files and allows users to make notes and comments via their web browser underneath the help documents. The way to get users do more work in writing documentation, is to have a comment system right up live on the website. Even the PHP manual does this ;-) Even though I'm not a fan of XML in many situations, I find FPDOC is a really useful and an awesome tool - this time XML fits the job well since the tags are sparse (lots of data between the tags). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Systems fair
> > I don't think the GNU C compiler is popular because of one nice > > website. I think the > > reason GNU C compiler is successful is because of all the fan boys > > I'm quite sure it's mainly successful because it's the default (and > often only) C compiler on Linux systems, as well as ported to pretty > much every other system out there. > > > Jonas I agree.. Actually, then, I should more so compare FPC to something like python or perl rather than GCC. Because GCC was available years ago when FPC was not. Whereas perl an python are newer. I think *part* of the reason perl is popular is because of all the websites out there saying "perl is so great because I did this and that with it". Of course there is a problem comparing a compiler with a scripting language, since scripting languages are used more for sysadmin. But what I'm getting at with my "fanboy" point, is that a lot of the FPC users are very quiet people and do not have as big of a mouth as they should. A lot of perl and python programmers do have big mouths and speak up about their language. But still, Pascal has it good - there are way more Delphi/freepascal projects than there are Smalltalk ones, for example. Regards. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [RFC] fpdoc output comment from the source
> > The way to get users do > > more work in writing > > documentation, is to have a comment system right up live on the > > website. Even the PHP > > manual does this ;-) > yeah the accuracy of said information leaves a LOT to be desired though > > imo if this is done someone needs to be resposible for looking at the > comments and checking they are factually accurate. > For sure. The comments are in a different color than the actual "fixed" documentation. It will be clearly stated that "these comments are from users and are not necessarily correct. Users make their best effort to make accurate comments, but occasionally there may be an error". When an major and important comment from a user is submitted, the docs are recompiled with the new changes. This way you get a fixed factual style documentation, along with user contributed comments. The main problem with FPDOC the way it is now, is that no FPC user in their right mind is going to spend 15 minutes - 3 hours recompiling the entire FPDOCS just to make a small spelling mistake change or add a small and useful comment. And you think the FPC user is actually going to mail the mailing list with a patch to the docs? Go to all that work and spend hours of his time figuring out how to make and send a patch? People are lazy.. they want to update the documentation right inside little Internet Explorer, Opera, or Konquerer, or ultimately a thin client ;-). I've not actually started working on this project but it's called LufDoc, and I've got all the framework/basics laid out of what the system is, what it will do, and how it will work. I just have too many other things to do right now... I think I will work on this at some point when I'm done fiddling with Syn text editor and PSP a bit more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [RFC] fpdoc output comment from the source
> Please make sure that the fpdoc commenting logic is clearly separated from > the CGI logic. This way your changes can maybe be incorporates in the FPC > sources and website. Yup that's what I planned on doing to modularize development.. A separate database of user comments will be "included" below the permanent FPDOC HTML documentation. The permanent documentation (or at least compiled, not exactly permanent) will exist separately from the database of user comments. This way none of the existing FPDOC source code needs to be changed. Only the CGI program gets installed on a server and it includes each FPDOC HTML page as if it were a PHP include file or a php Read(). Of course I'm not using PHP, so in Pascal terms.. WebFileOut(). We can have documentation mirrors via XML feeds.. but since I don't like XML so much I'd actually consider spitting out an SQL dump or an SDS (simple data storage) dump, or a CSV (comma delimitted) dump of the user comments. The user comments could be parsed by freepascal.org by getting the CSV dump or SQL dump just like an RSS feed does. In addition to live dumps, just a download of the current database dump will be available. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [RFC] fpdoc output comment from the source
> Did you miss something? > On the FPC homepage: > - Click "on-line documentation" > - Click "documentation table of contents with comments" > - Click "Add a comment" I think we went over this before. I was talking about the FPDOC "online reference" documents, actually. I think you are talking about the "online documentation" which is different than the online reference? I usually read the FPDOC documents, not the "Online-documentation" Tex generated ones. I do read the "Online" Tex generated ones sometimes, but most of the time I'm running back and forth to the actual FPDOC "unit references". In any case, the "online document" comment system doesn't work optimally the way it currently is on those online documents you speak of, either.. because all the mirrors out there usually have a higher page rank on google, and the mirrors don't have any comment system. So I end up reading the documentation at another domain name, where there are no option for me to add comments quickly. We need a syndication system anyway, where universities and other mirrors can parse User comments from a database or Rss feed. It doesn't really matter right now at this moment, though. I've talked about this for ages and I never seem to get my point across fully. What I'll do is run this system I speak of on Z505.com domain, and you'll see how it works there. I won't suggest that freepascal.org take a look into it until I have a real world working example to show you what I mean. I will also be documenting other things like the entire Windows.pas file, which freepascal.org does not document for good reasons. That's the Windows API reference project for Delphi and Freepascal programmers. I have the server space and bandwidth for thousands of documents so I have no problem hosting all of this. Again, I don't want to sound all talk and no action here.. so I think I'll save discussing my ideas until proven on Z505. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL's compiled by FPC(and some more info on bug #4538)
> >> Before we can say something, what functions do you call, what params, > >> what calling convention etc. > >> Does it happen in one specific sequence of calls, to specific > >> functions/methods etc. > >> > >> Please provide some more info. > > > > > > http://www.freepascal.org/bugs/showsource.php3?ID=4538 > > Whoops, I didn't saw that there was a bugrep. > > I'm not shure if FPC behaves the same as Delphi, but I think it does. > > In Delphi you cannot exchange ansistrings between dlls, unless you have > a shared memory manager. Normally each exe (or dll) has its own memory > manager. So when you pass a string to a dll and it it goes out of scope > there (since it is changed) it is released there. So a allocated memory > block from one manager is freed in another. This gives all kinds of > unexpected errors at strange places. > > IIRC the way constant strings are allocates it changed, so that may be > the reason that you didn't see the error on dlls generated by an older fpc. > > Marc > To the original person who posed the bug report: As Marc stated.. it is definitely a bad idea to use an ansistring as a function result in DLL's - unless it was a BPL or you were using shared memory. Did you include the sharemem unit in the delphi program maybe, which caused it to work there just fine but not in FPC? If not, how long was the program tested and how many users actually used the program without problems? Sometimes you can get away with strings temporarily, but the bugs pop up later or in random occurrences. The general safe rule is to never return a string into a function result when passing it to a DLL without shared memory. There are ways to use ansistrings without shared memory, such as using setlength calls in certain places, and taking extra caution (like using CONST parameters in some cases).. but I've learned that it takes extra brain effort to try and trick/escape the reference counter, so using pchars makes you extra safe. That is, assuming you study pchars thoroughly (and there are a lot of incorrect information out there so a book needs to be written on pchars). The other problem with trying to escape/trick the reference counter is you take extra CPU power to do it. The real disadvantage is not the extra cpu that it could cost, but the maintainability. Eventually your tricks catch up with you and you make a small mistake when trying to trick the reference counter. Whereas if you go in knowing what memory you are allocating, you can understand your mistakes and fix them rather than try to play more tricks. -- L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL's compiled by FPC(andsome more info on bug #4538)
> The usage of strings in the samples was just to verify which code was > executed and where things went wrong. I wasen't aware of the fact that > that alone could cause problems. In the actual application mainly > objects are passed to functions as regular and out parameters and a > boolean is returned to indicate success or failure. What kind of objects.. most objects cannot be passed without taking precaution or using sharemem. If any of the objects use ansistrings, dynamic arrays, there will be problems (also called "automated types", since the memory that the "type" uses is so to say "automated" for you, i.e. reference counted). > I don't think the sharemem unit is used anywhere in the origial code. I > could be wrong, though. I don't have the code here at home. I'll have a > look on Monday. > > The application is still under development, so it's not actually been > used/tested on a large scale. For as far as i know, the application, > compiled with Delphi, doesn't show any of the problems I get when the > app is compiled with FPC. But that could just as well be dumb luck. > > > The general safe rule is to never return a string into a function > > result when passing it to a DLL without shared memory. > > I'm not sure what you ment by that. Did you mean it's unsafe to return > an ansistring from a function exported by a dll per say? Or did you mean > passing an ansistring to a function imported from a dll, manipulating > that string and returning it? Both cases are cause for concern. I meant that sending a string as a paramater can be dangerous, and that returning a string as a function result can be dangerious too. Sometimes sending a string paramater can be done, but only if you take extra precaution. The DLL does not know what your EXE memory is doing. So by the time the string gets to the DLL it may be cleaned up and gone, kind of like a garbage collector. Same thing with returning a string.. if the string gets returned as the result of a function, it may have already been cleaned up and gone by the time you catch it on the exe side. Some times you can use setlength calls and other tricks to get around this, but I've found you spend too much time trying to trick the reference counter (like a garbage collector) - and its better to just allocate a pchar and KNOW what you are doing. This is the real advantage of KNOWING your memory, and why C programmers think they are king (but in every day applications that don't use DLL's, knowing your memory is a waste of time - compilers, dlls, operating systems is an exception where knowing your memory is more of a good thing and not a waste of time). I'm not sure if FPC has a sharing memory unit available - I've not looked into this, because most of the stuff I'm interested in creating, I want other programmers to be able to use too - gotta popularize the Pascal language by making DLL's available to other programmers than just our selfish selves. With a sharemem system I don't think you can share your DLL's with other programmers in other languages - but in your case maybe you are just using DLLs in your local application and would benefit from sharing memory. Again I don't know if FPC has this available - anyone know? This is a confusing topic though, and no problem being confused about it all, even for weeks or months after researching it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> > Concerning the shoutout test, simply adding a > SetTextBuf(input,1); > (or even higher) before the while loop should speed it up significantly. > The default buffer is 255 chars, which is simply too small. I'm also going to try this with my CPU-WARS email I sent to the mailing list a while ago, regarding StrLoadFile function comparison - thanks to Marco for suggesting this too. Regards, Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL's compiled byFPC(andsome more info on bug #4538)
> This does not make sense to me. When you return a string (from a > function in a DLL or anywhere else), this string will have a > reference count of at least 1 and thus will not be cleaned up by anyone. > > The only problem I can see that can occur is in case the program and > the DLL indeed use different memory managers, in which case you can > have a situation where memory allocated by the dll's memory manager > is freed "to" the program's memory manager, and that will probably > confuse the hell out of it (even if they are essentially the same > memory manager, just using different data structures). > > I apologize, I should have said that you'd not have exactly the same problems with returning a string - they are different problems but the basic point and idea remains the same: no matter what you do, strings will cause problems. What I should have said was there would still be all sorts of problems with returning a string - not necessarily the reference count problem, but other issues that cause similar havoc, such as two memory managers not communicating with each other. There are so many problems to consider, that a programmer once again spends more time thinking about the possible problems instead of programming a solution that works reliably. When it comes time to maintain your application in the future, or modify your DLL, and if you did some how manage to get strings working by using setlength's in the right place, and not returning a string as a result, you may not remember why these workarounds were in place and what workarounds must be left in the code if you change the code. If you go in and modify a DLL one day in the future, with a string that is just barely working as is with workarounds, the application might go BOOM when you make one little change to the DLL. In other words, even if you can get a string working as a parameter being sent, received, and allocated properly (but not as a function result), it may be a dangerous bomb waiting to tick off in the future when you try and maintain or upgrade your DLL. You must spend minutes/hours going through every possible problem that could happen with the modifications you make, every time you upgrade your DLL. If I change this code in my DLL, does that mess up the work around's that kept the bomb from going off? If I change this other code in my DLL, is the string still safe? There are just too many issues to think about. Unless, of course, there is a sharemem unit for FPC. And with a sharemem unit, since I've never used one in Delphi or FPC, I'm not sure how reliable they are. i.e are there bugs in the sharemem units that cause problems in Delphi, anyone know? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL's compiled byFPC(andsome more info on bug #4538)
I just tried the bug report source code at http://www.freepascal.org/bugs/showsource.php3?ID=4538 And I did not get an access violation or any errors. Which proves that it depends on your random luck on a random day ;) http://z505.com/images/BrokenDLLisWorking.png Unrelated note: The PNG I took was 26KB - a JPEG was 89KB and lower quality. Interesting. http://z505.com/images/BrokenDLLisWorking.jpg In cases where lots of similar colors are in the picture (such as lots of black or lots of white) it appears PNG's are superior. In other cases, JPEGs are smaller and seem to be more efficient. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> > Concerning the shoutout test, simply adding a > > SetTextBuf(input,1); > > (or even higher) before the while loop should speed it up significantly. > I'm also going to try this with my CPU-WARS email I sent to the mailing list // TEST 5 function StrLoadFile_test5(const FileName: string): string; var F: text; c: char; str1, Line: string; Buf : Array[1..10] of byte; begin result:= ''; //safety str1:= ''; if FileExists(FileName) = false then exit; Assign(F, FileName); //open file Reset(F); SetTextBuf(F, Buf); while not Eof(F) do begin Read(F, C); result:= result + C; end; close(F); //close file end; - Welcome to the CPU war for StrLoadFile.. Please wait... test 1 execution time: 9357464 <-- char by char test 2 execution time: 257074 <-- my blockread test 3 execution time: 265960 <-- my other blockread test 4 execution time: 2666055 <-- classes stringlist test 5 execution time: 9133218 <-- char w/buffer Done. Press to exit In this case, the 100,000 buffer helped a little, but not too significant. I think stringlist.loadfile should use block reading rather than the overhead of using streams. We've got way too much overhead with stringlists using classes on top of classes on top of classes. Although the current stringlist.loadfile is much faster than char by char, block reading still beats it hands down. Now as for Delphi's stringlist.loadfile and stringlist.text, I will have to do some tests and see. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> I think stringlist.loadfile should use block reading rather than the overhead > of > using streams. Of course stringlist is an array of strings so this may not work.. time will tell ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL's compiledbyFPC(andsome more info on bug #4538)
> I still have not seen a single actual problem mentioned with an > explanation by what exactly it is caused, only vague hand waving > warning for strange and inexplicable problems. I'm really interested > by what these problems are and can be caused. Does every dll have its > own memory manager data structures and is indeed the problem that > memory allocated by one is free "to" another (as I described in my > previous mail)? > > That would seem very strange to me though, since this could be easily > solved by making the RTL/system unit a dynamically linked library and > linking all other libraries to that (so there is only one system unit > with only one memory manager). > > Or is it something else? > > > Jonas What I originally thought one of the problems was, when trying to receive a function result, was that the DLL thinks that there is no need to keep the string in the memory. Why should it, if no other code in the DLL uses the string? Unless the DLL has some knowledge about the Exe using the string. Does it? Does it know about the reference count that the exe created? When the exe tries to use the function result, it goes in to the DLL space and tries to grab the function result in memory, but it isn't there because the DLL threw it away (unless hte DLL does know about the reference count the exe created.. does it?). On certain occassions, the DLL hasn't thrown it away and the program runs fine. That was my assumption, but not neccessarily the correct one. Can we confirm for sure that above is the wrong assumption? Where is the "reference count" actually stored anyway, and who as access to the reference count - just the dll/exe who created the string, or is it accessible by both of them? I do need to learn more about reference count science. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> test 1 (char) execution time: 1862654 > test 2 (blockread 1) execution time: 27080 > test 3 (blockread fsize) execution time: 46633 > test 7 (blockread tHandle) execution time: 18569 > test 4 (tStringList) execution time: 364999 > test 1 ln (tTextStream) execution time: 117256 > test 2 ln (readln) execution time: 182298 > > Done. > > Comment: > use Athlon 2.6G +Gentoo > > test 7 : read file via tFileStream -- this is the fastest way to read file > Neat! I'm testing on a Celeron 400 using Winblows 2000.. Do you have the source code for test 7 so we can run it through different CPU architectures? -- L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL'scompiled byFPC(andsome more info on bug #4538)
> Interesting. I'm curious about what version of FPC you used to compile > the samples. It is an SVN pull out from several months ago, of one of the FPC 2.1.1 releases.. Are you using an SVN pull out or a specific version? I don't think the code is safe until we discuss this further though, even if it works on my machine as is. -- L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> Do you have the source code for test 7 so we can run it through different CPU > architectures? nevermind, my bad, I see the email attachment. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> But why do you read char by Char? Why not > > read(f, line); > result := result + line; > > You can add a line break in between as well if you want. > > > close(F); //close file > > end; > > > Jonas Yes tried that, and on my computer readln with string concatenation actually locks up the computer (only on big files.. not on small)! Something is wrong with the string concatenation... I'll dig up some old FPC-Pascal mailing archives to show you what I mean. Actually on my computer reading char by char was faster than line by line! I am not sure what is wrong with the string concatenation.. but I commented out the concatenation and that was definitely the problem. As suggested by Vincent S. I tried putting it in brackets too... i.e. result + (line + #13#10); and it didn't help the speed of the concatenation by any significant amount. In my next post I will send you some links to the archives which discussed some of this if I can find them. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> > But why do you read char by Char? Why not > > > > read(f, line); > > result := result + line; > In my next post I will send you some links to the archives which discussed > some of > this if I can find them. http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg04686.html After trying Vincent's suggestion I did not see noticeable improvement. On the large MB file I tried, my computer locks up doing string concentration. Actually, it doesn't lock up.. it just takes several hours to complete. Lars p.s. sorry DarekM if I'm stealing your post. But maybe some of this is related to the benchmarks if there is any concatenation in any of the benchmarks ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation with nested DLL'scompiledbyFPC(andsome more info on bug #4538)
> The reference count is part of the ansistring itself. An ansistring > is simply a pointer to a record containing a reference count, the > amount of memory currently allocated for the string (i.e., maximum > length -1) and the string itself (a 0-terminated string). > > So when passing a string from a dll to somewhere else, its reference > count is passed along with it. > Instead of asking all the newbie questions, I will do more reading about reference count science on my own too.. but if it's easy for you to tell me here, how does the reference count know ahead of time that there will be no usage of the string when it sets the reference count to 0? i.e. how is the reference count decremented? Does the compiler know this at compile time? Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
> Athlon 2.6G +Gentoo Here are tests on a Celeron 400 Windows 2000 then Welcome to the CPU war for StrLoadFile.. Please wait... test 1 (char) execution time: 9287434 test 2 (blokread 1) execution time: 267230 test 3 (blockread fsize) execution time: 262710 test 7 (blokread tHandle) execution time: 265247 test 4 (tStringList) execution time: 2660387 test 1 ln (tTextStream) execution time: 624126 test 2 ln (readln) execution time: 831215 It appears the new Athlon processor takes extreme advantage of tHandle (test 7) while an old Celeron doesn't. Or, unless it is Linux versus Windows. I guess we can tell that test7, test3 and test2 are fastest so far. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation withnested DLL'scompiledbyFPC(andsome more info on bug #4538)
> In short (don't pin me on the names or on exact details in special cases): > > Assume you have a ansistring and you assign something to it > >S := 'SomeString'; > > the compiler generates something like > >DecStringRef(S); >S -> 'SomeString'; >IncStringRef(S); > > The DecStringRef() decrements the refcount and checks if the it reaches > zero. Ifso, the string is freed. The referencecounter of a strings lies Why does it generate a DecStringRef before you assigned the string? What if it is the first time and you are already at 0, it can't decrement it to -1 can it? Does the reference count start at 0, or 1? In this case, it decrements 1 and increments 1, so we will always end up with a very simple, easy, solvable problem. 1 - 1 = 0 1 - 1 = 0 That seems like it isn't doing anything useful, since we are incrementing and decrementing by one, every time we assign a string. What Jonas said was that the reference count would be 1 (one) when you pass it to a DLL. You are saying it will be 0 (zero). We have two people saying opposite things here, so I'm really not sure what is going on. What would be logical to me, is if the reference count was 1, not zero. I guess when I finally understand this science, I will write a diagram showing how it works in a Pascal procedure or function with comments beside each code snippet saying what the reference count is. If there is a PDF file that explains this or some good website let me know. I hate to embarrass myself here (maybe other people are confused too, though). -- Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation withnested DLL'scompiledbyFPC(andsomemore info on bug #4538)
> > In this case, it decrements 1 and increments 1, so we will always end up > > with a very > > simple, easy, solvable problem. > > > > 1 - 1 = 0 > > 1 - 1 = 0 > > Nope, since the string was nil, it isn't decremented, so you end up with > a refcount of 1 The string is 1, not nil 1 - 1 = 0 from your diagram indicates 1 is the starting refcount, not nil. When I responded to your mail, I didn't just mean if the string was nil, or at 1. I meant your diagram didn't seem to click in with me when any number was filled in the blank. i.e. 1, 2, 3, 4, 5 or any number. >From your diagram, I got this: String refcount: 2 Decrement(string) (1 - 1 = 1) string -> 'some string' Increment(string) (1 + 1 = 2) We are at 2 again. What was the point of doing it at all? Starting string refcount: 3 Decrement(string) (3 - 1 = 2) string -> 'some string' Increment(string) (2 + 1 = 3) We are at 3 again. What was the point of doing it at all? Starting string refcount: 1 Decrement(string) (1 - 1 = 0) string -> 'some string' Increment(string) (0 + 1 = 1) We are at 1 again. What was the point of doing it at all? I think we are just having issues communicating what is happening. The way Jonas explained below makes sense to me, as we get something useful out of the incrementing rather than ending up where we were in the first place. I'm still running it through my head to really understand it on a deeper level with the DLL situation, though - since that's what this thread is trying to solve in the end. > s := t; (-> reference count of ansistring to which s points is > decreased by 1 and freed if reference count became zero, the one to > which t points is increased by 1) > q := t; (-> reference count of ansistring to which q points is > decreased by 1 and freed if reference count became zero, the one to > which t points is again increased by 1) Marc, I think where our communication broke down was that in your diagram it appeared you were incrementing the same string, rather than a different one.. i.e. in Jonas' example he explained it with two string variables - one being decremented, and the other being incremented. Not the same one being incremented and decremented. The other problem I see with Marc's diagram was that somehow you showed the string being decremented before anything even happened. Shouldn't it decrement after something happens, such as in Jonas' example? i.e. it just looked magical to me, that decrementing could happen ahead of time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation withnested DLL'scompiledbyFPC(andsomemore info on bug #4538)
correction: 1 - 1 does not = 1 ... > From your diagram, I got this: > > String refcount: 2 > Decrement(string) (1 - 1 = 1) > string -> 'some string' > Increment(string) (1 + 1 = 2) > We are at 2 again. What was the point of doing it at all? Correction: What I meant was actually this: > String refcount: 2 > Decrement(string) (2 - 1 = 1) <-- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [RFC] fpdoc output comment from the source
> > Did you miss something? > > > On the FPC homepage: > > - Click "on-line documentation" > > - Click "documentation table of contents with comments" > > - Click "Add a comment" > I think I finally figured out your little comment system for the units generated with FPDOC that I seemed to magically find today: http://community.freepascal.org:1/docs-html/rtl/index.html The comment system *is* (and has been, for how long I don't know) in place - even if it took me 50 years to find. The major problem is no one reads those documents, or can find them easily. People read what is indexed by google: http://www.freepascal.org/docs-html/rtl/ I think the reason I've never landed on a comment document page is because google treats them as duplicates and doesn't index them. That, and as I said before, the fact that we have so many FPC mirrors out there with the exact same content makes google think there is no need to index the documents with comments. I'd force the comments onto people - they can't do any harm. Why offer the docs without comments? It'd be better for google, but not necessarily better for those people who don't like comments under the documents (who wouldn't?). Sorry if I couldn't find them - but if I can't find them, who can? (unless I'm a clutz, which is highly possible). -- L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violation withnested DLL'scompiledbyFPC(andsomemore info on bug #4538)
> One string is incremented, the other decremented. Your conclusion applies > only to > s:=s; That's what I was trying to get at.. in order for the example to make sense there must be two strings in action.. i.e. one is incremented, and another is decremented, rather than the same one. Which is basically what Jonas gave in his example. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access Violationwithnested DLL'scompiledbyFPC(andsomemore info on bug #4538)
> Ah now I understand your problem, but you miss the point that we are not > refcounting the variable S, but its contents. Thanks for clearing up - I understand, and these messages will be archived for future reference when my brain gets twisted up again. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-deve] PR: Advocates needed
It's not the advocacy that is needed but rather they need code for it to work. It says right in the article. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minimum installation requirements
> If I wrote a program like Notepad in Delphi, what would be the minimum installation > requirements to get the program up and running on a computer that just had > Windows freshly installed? If you use regular Delphi and VCL it can be anywwhere from 300-500K. If you use Delphi with KOL you can build a notepad clone which is about 40K-50K in size, which is smaller than the notepad that comes with Windows. Any program 40K-500K in size like this should work on a 486 66mHZ or pentium 75 or lower since it mainly relies on the operating system DLL's which are already in memory elsewhere. Delphi does not require any DLL's other than the operating system's for programs like this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Addtions for strutils
> I wish to add 3 new string functions for strutils: > 1. Check if a string is an integer (without + or - signs). My suggestion: Make your own unit and put it up on FPC contributed units or add it to one of my existing string extensions unit - I welcome it in my string projects if you want to place it there. I've done stuff like this before in StrWrap1.pas which is on SVN and in the contributed units section. StrWrap1 is not perfect the first time - it gets better as other people look at the unit and correct me or I do benchmarks with it. Any case the code is better online than offline - for me it is too much hassle to try and get something placed in the FPC core RTL so I experiment with my own units first, and then surely if it is useful it will eventually get absorbed into the RTL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Web language
Op Sun, 29 Jan 2006, schreef VisionForce: > You gave me this link: > http://www.delphibasics.co.uk/ByFunction.asp?Main=Strings > Are these methods supported by FreePascal, or would I need to be using Lazarus > (Delphi)? And in addition to Daniel's comment, the documentation for these units for FPC is more thorough even than the Delphi documentation and a lot easier to find on google, which is here: http://www.freepascal.org/docs-html/rtl/sysutils/index-5.html http://www.freepascal.org/docs-html/rtl/index.html etc. etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Web language
> Okay, I know this is a beginner questions, but how do I create a Pascal > program that only reads the text and sends it through some sort of CGI thing > (i.e. doesn't pop up that DOS-style window/shell). I already know how to do > the CGI part, I just need to know how to make a program without a user > interface. The Dos window doesn't matter, it will not pop up when the server launches the program. i.e. this is also a good thing, because you can run your CGI programs as Doss windows before you deploy them, and treat them just like a regular Dos program. You can post to the FPC users list you know, this list is more for the development of the Pascal language and the Pascal compiler. If you want to learn about sessions/gzip/headers/cookies you can take a look at the various CGI implementations for FPC, as they are existing working examples which take care of almost all basic CGI tricks. The toughest thing to implement is GZIP probably, so don't worry about that first. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] lNet in packages
>> > I'm all for it. The question is: base or extra. Or even FCL. >> >> fpnet package. The FCL is only basic stuff, some extended RTL. IMHO the >> fpimage,db and xml shall also be moved to fpimage, fpdb and fpxml >> packages. > > Why prefix everything with fp ? I think it will be more obvious as to why it is useful, when you start looking for DSO/DLL packages in the next compiler which has dynamic FPC packages working. i.e. on linux in /lib/ any DSO that starts with fp is easy to spot. If no FP prefix then RTL.so may conflict with many other DSO's out there. ___ 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] Web language
> > Okay, I know this is a beginner questions, but how do I create a Pascal
> > program that only reads the text and sends it through some sort of CGI
> > thing (i.e. doesn't pop up that DOS-style window/shell). I already know how
> > to do the CGI part, I just need to know how to make a program without a
> > user interface.
>
> On Unix platforms, you don't need to do anything. Just use read/write
> functions to communicate with the world around you.
>
> On Windows, you need to define that you are not working with a GUI program,
> which you do like this:
>
> {$APPTYPE console}
I think that is with Delphi.
Isn't freepascal the opposite, where in fact command line mode is default and
you
must explicitly specify app type of GUI if you want a GUI?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Web language
> > > On Unix platforms, you don't need to do anything. Just use read/write
> > > functions to communicate with the world around you.
> > >
> > > On Windows, you need to define that you are not working with a GUI
> > > program, which you do like this:
> > >
> > > {$APPTYPE console}
> >
> > I think that is with Delphi.
> > Isn't freepascal the opposite, where in fact command line mode is default
> > and you must explicitly specify app type of GUI if you want a GUI?
>
> Oh, I thought the original question was about Delphi - one of the recent
> questions were :)
>
Oh it might have been - I guess it depends on his decision to use fpc or
delphi? :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] DSO smartlinking finalization
When compiling a simple hello world DSO (dynamic link library) on linux Finalization did not occur for units in the uses clause. (testing on fpc 2.0.2) Is smart linking supposed to work on DSO's, or is it a known problem? When I tested on MS Windows, finalization did occur. Just wondering before I submit a bug report. A simple writeln call from the finalization area of a unit in the uses does not appear to work only when smart linking is on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug ID #4855
- Original Message -
From: "Peter Vreman" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Monday, April 10, 2006 12:18 AM
Subject: Re: [fpc-devel] bug ID #4855
> Buys Regarding this bug #4855 I need to get it fixed..
>
>
>
> The issue like this... I have 2 parts to my system...
>
>
>
> The EXE ... and a DLL
>
>
>
> In the DLL I have an exported function that returns an Interface...
>
>
>
> Function dosomething( const aObjectInt : ISomeInt ) : ISomeOtherInt
>
>
>
> This fails and causes the application to die..
>
> However if I put the same function inside the EXE it works fine.
> > The DLL has it's own memory manager. The EXE can't access the memory
> > allocated in the DLL.
I'm not familiar with interfaces and if they would work in this case, but how
about exporting the memory manager from the DLL or the EXE, and only using one
memory manager instead of two. We do it for ansistrings and it works fine in
PSP/PWU dll/dso.
Source code for working dso/dll that exports the memory manager (and is imported
by EXE) is here:
DLL/DSO main unit:
https://opensvn.csie.org/pspcgi/psp-1.6.0-release/LibraryUnits/pwu_lib.pas
Library wrapper that EXE uses:
https://opensvn.csie.org/pspcgi/psp-1.6.0-release/MainUnits/pwu.pas
But this is a summary of how it works below:
-
{ IN THE DLL }
// export memory manager from library for CGI program to use
procedure GetMemMan(out MemMan: TMemoryManager); stdcall;
begin
GetMemoryManager(MemMan);
end;
exports
GetMemMan name 'GetSharedMemMan';
-
{ IN THE EXE PROGRAM }
initialization
// always load library before program runs
MainLibHandle:= LoadLibrary(LibPath);
GetMemoryManager(OldMemMan); //store old memory manager
GetMemMan:= TGetMemMan(GetProcAddress(LibHandle, 'GetSharedMemMan'));
{ Get the shared memory manager which is stored in the library itself }
GetMemMan(GottenMemMan);
{ Set gotten memory manager up before import *any* functions from library. }
SetMemoryManager(GottenMemMan);
finalization
// always free library before CGI program closes
if MainLibHandle <> NilHandle then
begin
FreeLibrary(LibHandle)
end;
SetMemoryManager(OldMemMan); // restore original memory manager
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to add comments on FPC buglist?
> I think having an opensource pascal written bugtracking system would be > great! So please > hurry up and show us some code :) Probably something written from scratch with bare hands through existing fp cgi classes/objects. There is a bug reporting system written in EASY language, which is based all on freepascal since it uses TDBEngine. It could have been a good temporary system to place while the other one is being designed, since it is based on FPC. http://www.bug-a-boo.org/ It also requires shell account on server which is one reason I chose not to use it, as you must associate all TDBEngine programs with a CGI program (sort of like an interpretter but actually binary scripts). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to add comments on FPC buglist?
> > There is a bug reporting system written in EASY language, which is based > > all on > > freepascal > > since it uses TDBEngine. It could have been a good temporary system to > > place while the > > other one is being designed, since it is based on FPC. > > http://www.bug-a-boo.org/ > > Funny, I didn't know about it. Even more, it is developed by a company > located 30 km from here. I'm still waiting for them to respond to me about a TDBEngine interface for FPC without needing EASY. They said they were working on one. Currently you use EASY to access the database but it would be nice to also be able to just access it through Pascal code directly. In other words a Pascal unit interfacing into tdb. There is also this project too: http://sourceforge.net/projects/tdbsql/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] a shared library suggestion
> yeah that technique requires far less stubs but it means that the coder has
> to manually call an init function.
>
> also how does your code respond if one of the entry points isn't found?
Myself I use
{$IFDEF DEBUG}
if getprocaddress(somefunc) = nil then write('somefunc getproc error');
{$ENDIF DEBUG}
It does get very very tedious to type all this out for large libraries with 50
functions
or so.
If you want to economize the size of the library you turn off the {$DEFINE
DEBUG}
Do you know that FPC will have a Package system available in fpc 2.1.1, sooner
or later?
It will require shipping the RTL in a package, I think - which means we get
into Package
hell like BPL's offered. I'd rather have the ability to load one package and
not have to
ship the RTL as a package.
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] a shared library suggestion
> > Do you know that FPC will have a Package system available in fpc 2.1.1,
> > sooner or
later?
> > It will require shipping the RTL in a package, I think - which means we get
> > into
Package
> > hell like BPL's offered. I'd rather have the ability to load one package
> > and not have
to
> > ship the RTL as a package.
>
> That's the problem. The package _also_ requires the RTL. But maybe Borland
> only choice the "easy" solution and are there several.
I think you can manually load a single BPL - I haven't tried myself - but this
is manual
work again whereas we are talking about automated solutions I guess..
i.e. loadlibrary('somebpl.bpl');
(I wonder if you can manually load an FPC package.. ?)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
