Re: [fpc-pascal] Linux library access violation
> int testreturn(const char *thename, char *rcity, char *rstate)
> {
>
> memcpy (rcity,"Boston",7);
> memcpy (rstate,"Massachusetts",14);
>
> return strlen(thename);
> }
First thing to check is it declared CDECL or STDCALL in the C library?
I think the default C declaration mode is CDECL if it is not defined
explicitely.
> I click OK and its fine. It returns everything correctly. That message
> box is a pain though. I tried:
> try
> retint := testreturn(pchar(ganame), pchar(rlines[0]), pchar(rlines[1]));
> except
> //do something
> end;
>
> But the program just quits.
Whelp..exceptions are a false sense of security, and many elite programmers
refuse to use them
because they are like GOTO statements (Chen, Spolsky, and others). It's even
worse when you
cover things up like using
//do something
instead of handling the exception. Whereas if you skip exceptions all
together, and just do
real checks with regular code, old school error codes - it might end up being
more of a solid
program. However, this is no place for exception pros/cons flamewars ;-)
In general, for troubleshooting a problem in these beginning stages, I wouldn't
even use
exceptions - they just complicate things until you find the error using other
trial and error
code checks such as:
- nil checks.. is something nil, why?
- length checks.. is the pchar the right length before and after, or is it
damaged somewhere?
- sizeof checks..
- declaration checks
- operating system error checks such as getlasterror (in this case it don't
help, but in
general)
- other trial and error through real code instead of exception code
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Makefiles vs Pascal Automation
> > check out the fpmake.pp and fpmake.inc file scattered all over the source > trees; and the sources in utils/fppkg do what you describe 'TInstaller' > TBuildEngine etc. > > We are working on a 2-stage approach: > > fpmake: > compile/install/zip one or more packages (loosely defined as a group of > units) > fppkg: > package manager like smart/yum/yast/rpm with download capacity. > > fpmake works already. fppkg is under construction. > > We'll base the 2.2 release on it, if all goes according to plan. > > Michael. Ahh.. I thought maybe I was nuts for thinking up such a thing - and I needed verification that developers think alike ;-) It's too bad I spent so much time thinking about how to implement a psuedo example it when it is already in the works. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Rename executable extension MAKE or FPC
> Is there any way tell FPCMAKE to rename all PROGRAMS to have a different > extension? I just had to study up on how fpcmake RULES worked by looking at other existing fpcmake files.. hmm fpcmake files seem to resemble python - 8 space indentation for execution instructions. For win32 [rules] all: fpc_all copy *$(EXEEXT) *.abc And then remove all the exe files using rm or the dos equivilent command. For unix.. something like [rules] all: fpc_all rename $(EXEEXT) .abc * The docs should note that execution can be done like this. I was under the impression makefiles were config files, but really they are a scripting language with bizarre syntax. The docs mention tools available such as cp, upx, but no information on how to execute or use the tools in the fpc makefile. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Makefiles vs Pascal Automation
> > So basically my main point is that make files have become executable > > INI files - something INI files really aren't intended to be - with > > less power and clarity than a real pascal program. > > That's why FPC is switching to fpmake.pp files. And eventually/probably > lazarus too. Ohh.. I didn't hear about it yet. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Makefiles vs Pascal Automation
In many cases makefiles take about just as long to create as
shell scripts or pascal programs - they just offer a nice framework to
automate compiling in an easy way - but in sort of a funny syntax. But
makefiles kind of become ugly when they get big - and because they have a poor
syntax compared to pascal programs - couldn't one just write a pascal program to
automate the compilation process, instead of a makefile? (if a good framework
was in place).
A reusable "automation" unit or framework would need to
be created so that automating the compile process from within a pascal program
was easy.
After thinking about it, I determined that makefiles are
actually PROGRAMS in disguise - not config files, as their syntax seems to lead
us to believe. They are config files on steroids. Config files generally
don't execute instructions.. config files are more geared toward storage of
settings. But makefiles do execute instructions! Makefiles are programs,
not settings files.
So if makefiles are actually mini-programs, why couldn't we
simply write makefiles in pascal instead of writing makefiles in
makefile-language/fpcmake-language?
Psuedo Example.. let's consider I have to make four CGI
programs in one shot. I want to rename EXE or ELF programs to CGI programs after
the compilation is done. Compiling four programs using Make is possible, writing
up a makefile.. but it could also be done this way:
program Maker;uses CompileTools; //the framework
that simulates MAKE
const
targets : array of [1..4] = ('index.pp',
'main.pp', 'login.pp', 'logout.pp');begin // compile several
programs Compile(targets); if OStarget = linux
then writeln('compiling 4 programs for
linux..'); // 4 could actually be "CompileCount", if framework
implemented such a thing
if OStarget = windows then
writeln('compiling 4 programs for windows..'); for i:= 1 to 4
do
RenameFile(CompiledEXE[i], CompiledEXEName[i] +
'.cgi'); DeleteFiles('*.ppu', '*.a', '*.o');end;
At the command line:
maker all
Instead of using make:
make all
The framework in the maker program would handle "all",
"clean", etc.
Instead of writing a new makefile each time we wanted to
automated compilation, we would simple write a new pascal program which used the
maker framework.
Why did I come across this idea? The same reason I sometimes
build a pascal program instead of using a shell script!
The same reason that HTML files would make poor executables!
The same reason that config files are really not meant to be programs... but
rather settings files. Similarly, a config file is really not a program - and
makefiles are becoming INI files on steroids - programs!
If compiling the MAKER program each time is too much
work, then maybe this would be a good use for PascalScript.
So basically my main point is that make files have become
executable INI files - something INI files really aren't intended to be - with
less power and clarity than a real pascal
program.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Rename executable extension MAKE or FPC
Hi all, it's been a long time.. but I have a question. Is there any way tell FPCMAKE to rename all PROGRAMS to have a different extension? Example: On Windows: someprog.exe --> someprog.abc On Linux/BSD someprog --> someprog.abc Or is there any predefined macros that I can use with the -o (output) option to tell fpc compiler to rename the current executable being compiled, for example fpc test.pp -o$(targetexe).abc -- L505 http://z505.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Fw: Ask about FPC
From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 27, 2006 7:12 PM Subject: Ask about FPC Hi! I want ask something i use PSP 1.6.0-release, but i don't know where i can find the tutorial, i just find documentation for function. Can you tell me how to using variabel function(getcgivar,getcgivar_s), md5enc and POST / GET ? Thx ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
ject - then you finally get around to writing the project and you find out that the project is a no-go. People don't want the project. Your software idea was good for a few folks - but the product isn't needed on the market - there was only 1-5 people who needed it per city. So you wasted all that time writing tests when you could have wrote a quick demo program and see if people needed it at all. In summary, "test-driven development" is not going to magically solve any problems like they say it will in the books and on those web pages. Writing tests using common sense will help you - but reading into the magical test-driven quack out there will just slow you down. Learning that you must SAVE and write your tests down is smart - but following word for word some quackery like TDD is going to make things worse for you. Just my opinion. Beware of the TDD consultants. -- L505 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning ansistring with shortstring
> On 27 May 2006, at 09:46, Arne Hanssen wrote: > > >> setlength(last3, 3); > >> last3[1]:= filename[length(filename)-2]; > >> last3[2]:= filename[length(filename)-1]; > >> last3[3]:= filename[length(filename)]; > > > > As already explained, you must tell 'last3' its length. As you > > already > > are using a somewhat "lowlevel" approach, you could replace the state- > > ment 'setlength(last3, 3);' with 'last3[0]:=chr(3);'. > > Note that the setlength will generate exactly the same code as the > 'last3[0]:=chr(3);' statement, so it's better to keep the setlength > (in case the string would ever become an ansistring, or just for > readability) I didn't think the compiler would let you access string[0] directly anyway, even with range checking off - since that's a compiler thing - but I haven't checked for sure. (using i:=0; string[i] could work but calling setlength is fine for me for this purpose). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning ansistring with shortstring
> > var > > filename: string; > > last3: string[3]; > > last4: string[4]; > > > this is not short strings > use > last3: shortstring[3]; In delphi 5 and FPC in objfpc mode it doesn't accept that. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning ansistring with shortstring
> > I'm lacking some memory concept here. Below program doesn't work
> > unless setlengths
> > are called first on the shortstrings.
> >
> > program Project1;
> >
> > {$mode objfpc}{$H+}
> >
> > var
> > filename: string;
> > last3: string[3];
> > last4: string[4];
> > begin
> > filename:= 'test';
> > filename:= filename+ 'ing.pas';
> > setlength(last3, 3);
> > last3[1]:= filename[length(filename)-2];
> > last3[2]:= filename[length(filename)-1];
> > last3[3]:= filename[length(filename)];
> > writeln('debug last3: ' + last3);
>
> The length bytes of those shortstrings aren't initialised if you
> don't do setlength(). It has nothing to do with memory allocation,
> but with initialisation.
>
Learn something new today - I unfortunately don't have a turbopascal background
and in
this case it would really help - I guess I made the silly assumption that
shortstrings
were ready to go without ever needed a setlength. Of course I had the nerve to
turn off
range checking and try accessing outside of 255 bounds but it didn't work, as
expected :-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] assigning ansistring with shortstring
I'm lacking some memory concept here. Below program doesn't work unless
setlengths
are called first on the shortstrings.
program Project1;
{$mode objfpc}{$H+}
var
filename: string;
last3: string[3];
last4: string[4];
begin
filename:= 'test';
filename:= filename+ 'ing.pas';
setlength(last3, 3);
last3[1]:= filename[length(filename)-2];
last3[2]:= filename[length(filename)-1];
last3[3]:= filename[length(filename)];
writeln('debug last3: ' + last3);
setlength(last4, 4);
last4[1]:= filename[length(filename)-3];
last4[2]:= filename[length(filename)-2];
last4[3]:= filename[length(filename)-1];
last4[4]:= filename[length(filename)];
writeln('debug last4: ' + last4);
readln;
end.
I'd never have thought to use a setlength on a shortstring???
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C callable library
> Krishna wrote: > > Hi all, > > > > Is FPC ready for writing libraries callable from C/C++ on Win32 and Linux? > > > > Yes. Just that C++ objects aren't compatible, since the implementation of object orientation is slightly/majorly different between languages so you would have to use mainly procedural code and simple symbols if interfacing with/from C++. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] rotating bits
There is this page which might help some http://www.merlyn.demon.co.uk/del-bits.htm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] const parameter writeable
> > >
> > > But in this case I'm wondering why you want to give a pointer instead
> > > of the real type?
> >
> >
> > did you mean this ? :
> >
> >procedure ChangeRec1(const Rec: TSomeRec);
> >begin
> > Rec.a:= 'string A';
> >end;
>
> Yes.
Well, this is a Precord. That doesn't work. That is why I was confused.
>
> > Because I can't pass a PSomeRec to that function, only a TSomeRec
>
> Where is the problem? If you allocated the memory by new() as in your
> example you could call
> ChangeRec1(RecPtr^);
> and the compile (hopefully) uses the pointer.
Yes, but you are repeating what Jonas says - if you would have told me this
first, you
would have gotten the brownie points. But Jonas gets them. :-)
>
> But in this case you will get an compiler error because you can't
> change a constant value.
>
> It seemed that I didn't get the point from your original mail:
> Name the procedure CHANGERec1 and change a value but declare the
> parameter as constant.
I was asking why I could write to a const. But in fact I was not writing to the
CONST, I
was actually writing to the const data it pointed to. With SomeRec^ I cannot
write to
const. Problem solved.
I was using sloppy Delphi style code without ^ since Delphi enforces this
sloppy style of
coding, and now I know why not to use sloppy delphi style code.
What I was confused about was why you recommended TSomeRec when we are dealing
with
PSomeRec.
I also stated that I knew you can pass TSomeClass as a const, you can still
access it's
properties even though it is a const.
program project1;
{$mode objfpc}{$H+}
type
TSomeClass = class
a: string;
b: string;
end;
procedure ChangeClass(const SomeClass: TSomeClass);
begin
SomeClass.a:= 'string A';
end;
var
SomeClass: TSomeClass;
begin
someclass:= TSomeClass.create;
ChangeClass(someclass);
writeln(someclass.a);
someclass.free;
readln;
end.
This is normal, because we are passing a pointer when dealing with a class -
not passing
the class contents. Which is really what I should have thought about before
asking the
question, because I have discovered you can write to a const class *contents*
before.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] const parameter writeable
> > > did you mean this ? : > > > >procedure ChangeRec1(const Rec: TSomeRec); > >begin > > Rec.a:= 'string A'; > >end; > > > > Because I can't pass a PSomeRec to that function, only a TSomeRec > > Then pass a PSomeRec^ to it if you don't intend to change the pointer > anyway. > That works, I was getting sloppy with Delphi style code who doesn't always require the ^ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] const parameter writeable
> > Only the pointer itself is the parameter and read-only. Where the pointer > > points to is irrelevant. I remember this from using classes where you can still access the class properties - should have thought about that before posing the question :). > > But in this case I'm wondering why you want to give a pointer instead > of the real type? did you mean this ? : procedure ChangeRec1(const Rec: TSomeRec); begin Rec.a:= 'string A'; end; Because I can't pass a PSomeRec to that function, only a TSomeRec Otherwise, I don't know what you mean.. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] const parameter writeable
Are const parameters supposed to ensure read only access?
If so how come one can write to a typed pointer?
program project1;
{$mode objfpc}{$H+}
type
PSomeRec = ^TSomeRec;
TSomeRec = record
a: string;
b: string;
end;
procedure ChangeRec1(const Rec: PSomeRec);
begin
Rec^.a:= 'string A';
end;
var
RecPtr: PSomeRec;
begin
new(RecPtr);
ChangeRec1(RecPtr);
writeln(RecPtr^.a);
dispose(RecPtr);
readln;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recursive unit/include search path
> -Fu/home/fpc/packages/base/*/units/$fpctarget > > Recursive is too error prone and therefor not usefull thanx to all who replied, that's what I was looking for, not true recursive, just wildcards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Recursive unit/include search path
-Fu/home/me/project1/units/*.* Is there an existing recursive option like this for -Fu and -Fi? Could be useful, but dangerous if directories contain different versions of the source file in different places. Still, in many projects I get sick of continually adding new directories to the search path - and in many projects there are not more than one version of a source file kicking around. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]size/speed/compiler - Was:another fpc RAD: MSEide
> 3. speed - not a big deal. Hardware cheap enough. > > If you ship programs, it's not you who decide whether hardware is > > cheap. I agree - some of my website visitors still use Win98, for example.. so can't say everyone has a 2Ghz PC with windows XP on it. I don't like buying hardware every year. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]size/speed/compiler - Was:another fpc RAD: MSEide
> > 3. speed - not a big deal. Hardware cheap enough. > > Speed definitely does matter for some apps: application servers, > database servers etc. So you can't generalize this. This is my view too.. purely playing devils advocate there.. :-) > > > 4. size - shipping an interpreted file usually smaller than exe/elf > > Not if you count the interpreter. Granted, you must download that only once. > This advantage can be had with compiled languages if you have a packages > system. > > > 5. uploading - uploading a 30K script file on a 56k modem is easier than > > uploading a 5MB > > binary > > Not if you count the interpreter. Try installing Python, perl or PHP, plus > all of the 'packages' you need. > > > > > What advantage of compilation? There must be something. > > You know your code is syntactically correct. With interpreted, you don't. I wonder why they haven't invented a pre-compiler that checks your script for you first.. well I think Zend IDE might do something like this.. but I've never tried Zend as I don't do that much PHP programming lately. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] kol/compactutils: was - another fpc RAD: MSEide
> It's always a trade off. Neither KOL nor FCL is better, they are simply > designed different and comparsion is useless. The intention is purely to be compact, and I didn't mean to compare or compete with FCL. I was just mentioning that those who need a convenient compact StringList without the bloat of 60-70K being hauled in compactutils is there for you. Free for your usage. p.s. There is err.pas for KOL exception handling. Adds a few kilobytes. Still not comparable to FCL exception handling probably. But that's not the intention at all. The intention is purely to be compact, not to compete with classes.pp. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]size/speed/compiler - Was:another fpc RAD: MSEide
Okay so we have to now consider these points: 1. interpreted languages can take up less memory if engineered right (says Florian) 2. compilation and linking is a hassle - compared to shipping or uploading an interpreted file 3. speed - not a big deal. Hardware cheap enough. 4. size - shipping an interpreted file usually smaller than exe/elf 5. uploading - uploading a 30K script file on a 56k modem is easier than uploading a 5MB binary What advantage of compilation? There must be something. I know Microsoft use to love compiling those EXE's because you couldn't see the source code to the EXE's. Is this the advantage of FPC? That we can hide our sources? :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
> L505 wrote: > > > > I think this is poor marketing for FPC: telling people that size/bloat is > > not an > > issue. > > Then what good is FPC for us? FPC is a compiled language! The whole point > > of a > > compiled > > language, is to have SOME advantage over an interpreted language. What is > > this > > advantage, > > if not size/memory/footprint? I don't see any advantages. > > The memory footprint of a good interpreter is lower than that one of a > compiled program. Guess why a lot of programs in the 80s were written in > interpreted basic :) Only the bad design of most interpreters cause big > memory footprint. There was also USCD pascal .. but people complained it was too slow? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] another fpc RAD: MSEide
> > Very nice compact stringlist in there to use... > > Standard Classes stringlist adds about 60K-70K to your exe/elf while > > CompactUtils > > PStrList only adds maybe 1-5KB. > > Please compare what is comparable: > > The Classes unit contains more than just the TStringlist and TList. > > It contains a whole lot of other classes as well: streams, collections, > components, threads, and the whole streaming system. All things which > are commonly used in Object Pascal programs. KOL contains Streams, Threads, Stringlists, TLists (actually PList) and almost every single function implmented in the Classes unit. They are pretty comparable. (CompactUtils doesn't contain threads yet because I didn't work on that area - just not enought time.). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] another fpc RAD: MSEide
> > On Wed, 19 Apr 2006, ??? wrote: > > > > > I do neither use Lazarus, nor MSEide, but if executable size is really > > > important, there is something called KOL (I didn't use it either). As I have read, it's currently compilable by FPC. > > > > > > Speaking of bigger applications, I don't see much difference between 6 or > > > 30 Mb executables... > > > > Try downloading them over a 56k modem ;-) > > Try downloading a 6M one using a trained parrot (read: 300 baud). Where do > you put the border of what is "normal"? I ask, why are we promoting compiled languages then? It sounds like interpretters would suit us better. Because 1. hardware is so cheap 2. size and memory are not all that important any more. Since we are not in the DOS/640K memory days any more - tell me one advantage of a compiled language, if size/footprint/etc are not important any longer? "With today's new hardware at low prices, who needs FPC or any other compiler?". I think this is poor marketing for FPC: telling people that size/bloat is not an issue. Then what good is FPC for us? FPC is a compiled language! The whole point of a compiled language, is to have SOME advantage over an interpreted language. What is this advantage, if not size/memory/footprint? I don't see any advantages. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] another fpc RAD: MSEide
> > > On Wed, 19 Apr 2006, ??? wrote: > > > I do neither use Lazarus, nor MSEide, but if executable size is really > > important, there is something called KOL (I didn't use it either). As I have > > read, it's currently compilable by FPC. KOL GUI stuff is not cross platform. But I have made a project for us all which allows you to compile all the KOL non-GUI stuff on linux. https://opensvn.csie.org/pspcgi/psp-1.6.0-release/Extras/CompactUtils/CompactUtils.pas Very nice compact stringlist in there to use... Standard Classes stringlist adds about 60K-70K to your exe/elf while CompactUtils PStrList only adds maybe 1-5KB. But for those people who think classes are just so superiour to old Pascal objects and for those who only do pure object oriented programming (whatever the heck that is) .. please ignore this project. This compactutils project is definitely not for you. > > > > Speaking of bigger applications, I don't see much difference between 6 or 30 > Mb executables... > > Try downloading them over a 56k modem ;-) > And I personally don't like buying a new hard drive and CPU every year.. first thing I do when looking for space on my hard drive is find all exes/elfs that are bigger than 5MB, then I strip them. A few 30MB lazarus exes/elfs take up a lot of space. Especially when you have to compile two executables. One for linux, one for windows. That adds up to 60MB for each program, if you support two OS's on one hard drive. I buy a computer every 5 or so years, not every 6 months to support the latest bloat. A $2000 computer each year could add up to a small downpayment on a house. $2000 X 5 - $10,000 dollars. Not to mention laptop and LCD upgrades, and motherboard failures. For those who say it is cheaper just to buy hardware - then please tell me one advantage of using a compiled language. Speed and memory are not important - because you can buy hardware. So give me one reason to use a compiled language. No advantages. Source is more closed with binary files than it is scripts. (I'm playing devil's advocate. Personally, I like small compiled programs in one package that I can choose to ship with or without sources. ) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero - not raised exception
> > If you can't find jobs > > out there that use Pascal then you have to be really brave and start > > your own business and start hiring people with Pascal skills. > > Yeah right. Sorry to bring that up again, but if I would do that I would > never hire people that claim to have such specialized skills. What is I didn't say pure pascal programmers with no other skills. most pascal programmers know databases, Assembly, and C. They also usually know at least one scripting language such as PHP. > needed are people who can actually engineer software and that > particular skill has nothing to do with language skills (of course, if > all else fails, I'd rather hire a Pascal guy than a "There *are* other > languages than C?"-guy, because the Pascal guy might grasp the concepts > much easier). I plan to hire/pay Pascal programmers at some point for future commercial projects. Who will I hire? Probably the folks that have worked with me on open source projects before. If not hiring per hour - I mean contract jobs too. Or people who I've found helpful on a mailing list. People even get jobs by visiting wiki's.. a few people have gotten jobs off c2 wiki and others. It's all about networking isn't it? Lots of linux guru's get hired off by microsoft simply by starting up yet another linux distribution. (sorry to the fellow at gentoo, who now does not work for microsoft). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
> L505 wrote: > >> MSEgui has a distinct advantage over Lazarus. It compiles under Delphi. Just > >> tried it. Fiddled with one or two lines in the code, but I got the IDE to > >> compile and run and then built a small hello world app that also ran. Pretty > >> impressive really. > > > > And the exe's/elf's it generates are reasonable in size. Going to check it out > > today, again. > > Smaller than FPC ? That shouldn't differ too much, I think. I mean smaller than lazarus generated ones. BTW How does borland put the debug info into the exe without increasing the exe size? Not to mention, there is no such thing as a smartlinking option in my delphi compiler. They just assume you always need smartlinking - why would you not need it. As for how their compiler/linker is so fast with smartlinking on and debugging on... mystery. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
> MSEgui has a distinct advantage over Lazarus. It compiles under Delphi. Just > tried it. Fiddled with one or two lines in the code, but I got the IDE to > compile and run and then built a small hello world app that also ran. Pretty > impressive really. And the exe's/elf's it generates are reasonable in size. Going to check it out today, again. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and Lazarus as a main RAD tool?
> > Disadvantages of Delphi: > > 2. It's closed source, if it's buggy you're lost. > > Main problems comes from RTL and VCL, not a compiler - it is > stable, at least for D7. As D7 Pro+ comes with RTL and VCL sources, it is > easy to fix and recompile both. And there is many excelent free and > OpenSource third-party components available. I would personally pay $50-$200 for a FPC compiler myself, if it came with sources to RTL/VCL and didn't even include lazarus. If it came with compiler sources too, that would be a bonus. I would also buy FPC t-shirts to support the team. Problem is then how do you split the money? Which person is pulling more weight than the other and gets a better salary? This is the problem with business: it's unfair and requires accountants, lawyers, etc. Then get all sorts of emails on the mailing list from FPC-DEVEL team telling about how their shareholders are more important than developers. So it's not really greener grass on the other side. > > D7 IDE however is only problematic for non-English users (regarding saving > it's own translations codes in .DFM when developing applications and using > executables on different localized machines). > > > 6. Runs on machines with relatively low memory, compared to D7 (e.g. > > 256MB for development, 64MB on target here) > > D7 run IDE under 128MB and work without resource problems with any project > complexity or number of added components. > > > 7. Saves you a huge amount of licence costs. > > Buying Delphi Studio 7 Pro was good investion so far. As the future is > unknown for now, serching alternative in FPC and Lazarus. > > > 8. Has a mailing lists with a lot of funny people to talk to. > (As well taking banal insults...) > > Even not directly provided personal support, Borland have excellent suppors > from newsgroups (Delphi users and TeamB people). Sometimes - but I find they are also full of loonies who keep talking about shareholders, and the latest stock price of Borland, and why it is wrong to use any open source software (even though the VCL itself is open source, after you pay for a copy of Delphi it is truly an open source variant (not GPL but still opened up source code). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero - not raised exception
> If FreePascal founders are registrated as a company, contract would have > legitimity in the law, otherwise will not. Incorporating into a registered company doesn't really help secure anything down - for example Borland could cut off the Delphi product at any time (or sell it) even though they are a "legal" company. Companies spend more time yapping about their shareholders and what would be best for the shareholders instead of what would be best for the developers (read the Borland news groups - everyone always comes up with the excuse that "but what the developer wants isn't always good for our shareholders". Even though developers are buying the software and supporting the figurehead shareholders. Doesn't make sense to me.). Or maybe you mean a foundation, like a non-profit organization? Obviously FPC is not out for profit, but out to help the developer. So I can see a non-profit organization working - but this would mean that FPC team would spend more time on things like Accounting, Lawyers, etc. Look how free software foundation is spending time hiring lawyers and etc. for their foundation. Although I do agree that freepascal should not just be a hobby for all, and some of us should start using it within their jobs to make it a better compiler. I'm sure lots of people rely on GCC and PHP at their jobs every day - and this helps make it better because it must be high quality at work, higher quality than just hobby. I use FPC for some of my work (websites, misc tools), but not experienced enough to be a development team member yet. I'm guessing there are a few others that use FPC in their real jobs. If you can't find jobs out there that use Pascal then you have to be really brave and start your own business and start hiring people with Pascal skills. Someone has to do the work. Or use FPC internally in your home/small business yourself without worrying about the current work available. How to balance a clash of free vs open vs closed vs commercial? Some people could care less about source code (customer at home who has never programmed in his life, looking for a paint program on download.com, let's say). So sell software to those folks who don't need the sources. But keep some software open, such as the compiler and RTL - because in this case developers do care about the sources and fixes are easiler to apply with them. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpdoc document *.pas;*.inc
> > > > It would be nice if I could build it right into the fpdoc tool though, so > > it's just one step. > > I'll have a look at it. It should be easy to do. > I was looking into dw_html and I'm not sure if my object orientation theory is right but: Would this be the way to go: -create a dw_htmlsnip file, or dw_htmlbody -inherit the HTMLWriter and make a HTMLSnippetWriter object, or HTMLBodyWriter, overriding the THTMLWriter.CreateHTMLPage with your own procedure, that basically skipped the footer, skipped the header, skipped the body tag, etc. I see all the header tags are basically created in THTMLWriter.CreateHTMLPage ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpdoc document *.pas;*.inc
> tidy --show-body-only yes test.html > test-body.html That'll work in the mean time while I wait for responses and comments on the snippet feature. FastHTMLParser could also work, find the Body tag (OnTag event) and record all text between body. It would be nice if I could build it right into the fpdoc tool though, so it's just one step. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpdoc features
> > What command would be used to run FPCdoc on all files in a directory.
> > PSEUDO EXAMPLE: (crashes fpdoc)
> > fpdoc --package=Test --input=*.pas;*.inc;
> fpdoc --package=Test $(ls -1 *.pas *.inc | awk '{printf("input=%s ", $1)}')
AWK for the one liner.. I was going to build a program that sucked all the *.pas
file names out of a directory and made an fpdoc command out of it.. then launch
the command.
Other question about FPDOC: is there a way to skip the HTML head and footer so
the page is not a complete html document but just a snippet of html? If not,
would it be allowed for me to build this feature and send a patch or would I do
it privately? I'd like html snippets instead of an HTML page so I can build the
docs into a CGI program.
For example, skipping the html body, head, head closing, and body closing tags
at minimum.
Maybe a --snippet option.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpdoc document *.pas;*.inc
What command would be used to run FPCdoc on all files in a directory. PSEUDO EXAMPLE: (crashes fpdoc) fpdoc --package=Test --input=*.pas;*.inc; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] When are used units recompiled?
> > Vote where? :) > > The bug reporting system is very limited, once the bug is opened or closed you > > can't make any additional comments. > > I know, but sometimes developers who know the system inside-out get > 'out-of-touch' with the users who are just starting to use it. So 'voting' > is essentially "proving" somehow that this situation needs (some) attention. Sure and that's what I meant: no way to add a comment to your bug once it was "fixed". ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] When are used units recompiled?
> Tom Verhoeff wrote: > > Can someone explain to me under what circumstances FPC will (attempt to) > > recompile a unit for which *.ppu and *.o are already available? > > I couldn't find this in the documentation. > > Wrong target (OS) or incompatible compiler version, usually. Vote for: > > http://www.freepascal.org/bugs/showrec.php3?ID=4691 > > :-) > > Micha Vote where? :) The bug reporting system is very limited, once the bug is opened or closed you can't make any additional comments. p.s. anyone seen this? http://www.bug-a-boo.org/ Written in pascal/easy btw. Our friends at tdbengine our going to make tdbengine accessible from FPC programs soon, not just from the EASY programming language. I have been talking to them about it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpc-pascal Digest, Vol 19, Issue 24
> One of the things I think works best for lazarus is that it is written in the > same language it uses - so every user is a potential contributor (unlike most > programs and IDE's users typically CAN program) which is why I think it has > such an amazing rate of expansion - we must be averaging about 5 or 6 patches > on most days. I always harp on this fact - for example perl is written in C, python is written in C, php is written in C, but if you want to learn from the sources why shouldn't it be python is written in python and php is written with a php compiler. And we all know delphi ide kernel and compiler is written in lots of C and some Delphi for the gui parts, but not all of them. Java is written in C. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: OpenDelphi.org
- Original Message - From: "Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> To: "FPC-Pascal users discussions" Sent: Thursday, March 16, 2006 9:02 AM Subject: Re: [fpc-pascal] Re: OpenDelphi.org > I'm not complaining, just saying that the source is sometimes hard to > figure out for some people, like me (I must say I did not went in it > that much). > > The problem is not include files, the problem is that the code needs > > better comments and better documentation. You know what, I hated include files because I came from delphi. Now I've learned to love them and yes we could make something for synedit that made the include files go inline.. Also I think the lazarus developers should NOT be so afraid to implement more source code comments into the code.. there is no harm in being a bit more verbose.. I found a lot of stuff would be more easily understandable with a simple hint about what the function does in there. > No, include files have nothing to do with multiple GUI / OS support. They do.. It allows you to use less IFDEF WIN32 And IFDEF GTK ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: OpenDelphi.org
On 3/16/06, Alexandre Leclerc <[EMAIL PROTECTED]> wrote: > > Is there any way to simplify that and still be multi-platform very > > easely? Indeed, that is very much hard to track down the units. (In > > comparison, Delphi is cleaner, but it is not as multi-platform / > > multi-GUI as laz is.) > This kind of reorganization cannot be done without a detailed view of > how LCL code works. > Maybe we need a general map of how things are connected to each other > on LCL, but this can take some time to build and very few people know > LCL well enougth to create it. I started making a diagram of what procedure inherited from what object and what subroutine called what other subroutine. It's hard to keep it all in your head, so might as well make a little map or diagram of the code. It works, but hundreds of little maps need to be created for several functions. Delphi source code is probably similar, but a few less layers since they are not supporting multiple OS any more. The Delphi open tools API was always a nightmare to work with, having to always tap into bizarre classes just to do simple things, so we know they aren't perfect at implementing the simplest possible solution. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: OpenDelphi.org
> FPC is Ok but a few years ago I examined Lazarus > codebase and I saw Lazarus is hacking Class parents > on-the-fly for its normal operations so I immediately > lost my interest. > Is this changed recently? What do you mean hacking class parents? What I noticed was tons and tons of abstraction and tons and tons of layering. So much layering that when I try to find a bug, I go into the code and start chasing hundreds of units looking for the real piece of code where the bug exists, but since there are so many snippets that inherit from other snippets and objects, you don't really know where to begin. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] opendelphi.org
Who gets the $22,000 they have raised so far, if their plan doesn't work out? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free commander
> Does anyone have a copy of it? > > http://web.archive.org/web/20021122022650/http://fc.freepascal.org/ Found an old version http://193.125.152.110/pub/windows/fileutil/fc070b7.zip Started it up with fc.exe c: c: Looks pretty nifty, no sources in this zip - I was going to convert it to English and try compiling. Is this open or closed source? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Free commander
Does anyone have a copy of it? http://web.archive.org/web/20021122022650/http://fc.freepascal.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] scope error? duplicate identifier property andparameter
> I am getting an error compiling with fpc 2.1.1 under lazarus with duplicate identifier > that seems to be a scope error. Under lazarus all you have to do is add > any dataset and add an onposterror event handler. > it doesn't like that "Action" is both a property of an object and a parameter of a procedure in that object. > Action is defined as a published property in form. > then it is also defined as ... > property Action: TBasicAction read GetAction write SetAction; > published property Action; > procedure MemDataset1EditError(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction); > procedure MemDataset1PostError(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction); I think I've come across this before, it is in OBJFPC mode. AFAIK the solution is usually to use something like procedure MemDataset1EditError(DataSet: TDataSet; E: EDatabaseError; var AAction: TDataAction); procedure MemDataset1PostError(DataSet: TDataSet; E: EDatabaseError; var AAction: TDataAction); procedure Something(AYourParam: string; ASomeOther: integer); 'A' prefix for temporary stuff that could conflic with more permanent stuff such as properties. You know, it is really clearer this way because who says you are not referencing Action property? How do you know? This way, you are sure. OBJFPC mode is more obvious/strict. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Variable arguments, different types?
I don't see what all the arguments are about the C language being able to rewrite writeln (printf, etc.) but in Pascal not. I don't see any limits with what Pascal can do - you could rewrite writeln procedure and other low level calls with several options - textrec tricks, or this array of const trick. Let's put those Pascal myths to shame. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Variable arguments, different types?
> > Isn't this exactly what array of const is for? It allows you to use > > anywhere from 1 to unlimited parameters. > > Yes. Still, it's only one argument. You can't just suddenly pass two > "array of const", can you? Okay but why would you need that (humor me). > > > Vin"Nitpicker"zent. > LOL ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Variable arguments, different types?
- Original Message - From: "Michael Van Canneyt" <[EMAIL PROTECTED]> To: "FPC-Pascal users discussions" Sent: Thursday, March 09, 2006 9:36 AM Subject: Re: [fpc-pascal] Variable arguments, different types? > > > On Thu, 9 Mar 2006, L505 wrote: > > > > > > >> > >>> I have also read people stating things like this before: > >>> > >>> "you can use array of const but you can't make functions like writeln > >>> because writeln accepts multiple types". > >> > >> Usually the statement is about different _numbers_ of arguments, not > >> different types. Writing subroutine which accept different types for > >> their arguments has never been a problem in Pascal. > > > > I was talking specifically about array of const, not Pascal in general. The docs > > do not make it clear that array of const can accept different types in "one > > call". We are talking purely about "array of const" here, not the Pascal > > language in general. Of course I know the Pascal language can accept multiple > > types in one call. > > > >> > >>> But in fact, with array of const, you can use multiple types. > >> > >> You can, just as you can use different types in record types. > >> Still, the actual argument type would be the type of the record or, as in > >> your case "array of const" then. Don't confuse that. > > > > Well you are nitpicking my email :-). I'm not confused at all - the docs are. > > As the author of the docs, I feel compelled to protest: > > "This is a special case of the Open array construction, where it is > allowed to pass any expression in an array to a function or procedure." > > The "any expression" is the keyword here... > > But, to make it more explicit, I have added > "Each element of the array can have a different type." > > And have added some examples where the elements have different types. Sorry Michael, my emails sound a bit harsh some times. I was just wondering if this was actually supposed to be possible? I don't think I've ever seen anyone use this trick before. It's kind of like Perl. Dangerous, weak typing. I wonder how slow it is since it is a run time check :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Variable arguments, different types?
> > > I have also read people stating things like this before: > > > > "you can use array of const but you can't make functions like writeln > > because writeln accepts multiple types". > > Usually the statement is about different _numbers_ of arguments, not > different types. Writing subroutine which accept different types for > their arguments has never been a problem in Pascal. I was talking specifically about array of const, not Pascal in general. The docs do not make it clear that array of const can accept different types in "one call". We are talking purely about "array of const" here, not the Pascal language in general. Of course I know the Pascal language can accept multiple types in one call. > > > But in fact, with array of const, you can use multiple types. > > You can, just as you can use different types in record types. > Still, the actual argument type would be the type of the record or, as in > your case "array of const" then. Don't confuse that. Well you are nitpicking my email :-). I'm not confused at all - the docs are. All I was asking was why specifically in array of const's case, the docs did not make it clear I could pass multiple types in the same call. If you look in the examples in the docs page, all the examples show the programmer passing arguments of the same type in one call. They only make it clear that you can pass multiple types in separate calls, not in the same call. // passing multiple types, but in separate calls test([TRUE, FALSE, TRUE]); test(['string1', 'string2', 'string3']); // passing MULTIPLE TYPES IN ONE CALL, not stated anywhere in docs test([TRUE, 'string1', 342, -456, 1.653]); > > And you still can't just pass two arguments when the subroutine expects > only one Isn't this exactly what array of const is for? It allows you to use anywhere from 1 to unlimited parameters. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Variable arguments, different types?
> > > > In other words you can reinvent your own writeln style procedures and pass > > parameters of *different types* simutaneously. I was under the impression you > > could only pass parameters of the same type through this [] square bracket > > trickery. > > > > See docs: [http://www.freepascal.org/docs-html/ref/refsu47.html] > I already RTFM actually :-) My point was that the docs do not state that you can send multiple types within one shot. test([1, 1.456, 'test', -64, 'some string]); I have also read people stating things like this before: "you can use array of const but you can't make functions like writeln because writeln accepts multiple types". But in fact, with array of const, you can use multiple types. Note the difference between: test(['string1', 'string2', 'string3]); // all the same types And: test([1, 1.456, 'test', -64, 'some string]); // different types ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Variable arguments, different types?
Hi, This below seems to work.. I got the impression you couldn't do this.
program HelloWorld;
var
I : Integer;
procedure test (args : array of const);
begin
writeln('test');
For i:=0 to High(Args) do
begin
case Args[i].vtype of
vtstring:
Writeln ('String value: ',args[i].vSTRING^);
vtinteger:
Writeln ('Integer value: ',args[i].vINTEGER);
end;
end;
end;
begin
test([1, 'test']); // variable types work
readln;
end.
In other words you can reinvent your own writeln style procedures and pass
parameters of *different types* simutaneously. I was under the impression you
could only pass parameters of the same type through this [] square bracket
trickery.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GPL advertising - was Scripting in FPC
> > The GPL only requires that you keep the credits in the sources, not > that you advertise other people's work or products inside your own > program, even if your program somehow uses that functionality. > Imagine otherwise the credits list required for programs like the > GIMP or so if each used library would have to be mentioned along with > a link to some home page. You'd spend more time on maintaining that > list than on actually adding new functionality. > In all my source files I at least like to give a web address so people can find out where to find more information, such as essays, articles etc. I've written about the source. If my website just so happens to contain some commercial product on it then that is too bad, I was just trying to leave my web site address in the source files so people could find more info about the unit. In fact a web address is usually more reliable than an email address since email addresses go dead or change and the user must visit the site to get the new email address. It also tracks how many users are actually using the unit and you can focus attention on the units that more people are using. What I don't agree with is having to say "this software was made in California" when in fact it was not. I think that was purely a local issue with BSD and they then changed it later, because their license was no longer created only by users in California, but spread worldwide. Maybe they just didn't expect the license to make it out of California and thought it would be a local license in the university. I think in remobjects case all he was doing was pointing people to the website just like how I point people to my website. There are articles on remobjects on how to use the software, and useful info. No problem with giving web address according to human instinct, but problem with giving it according to GPL. Hey look at me, we are wasting all this time discussing whether it is "right" or not, this is the same problem as wasting time deciding whether we should put the list of web addresses in or not. I guess we are back at square one: * in gpl people waste time debating the license * in freebsd people waste time maintaining a list of URL's pointing to useful websites I guess you choose which one is more a waste of time. Personally I think wasting time discussing a license is in fact more waste of time than just programming and adding some URL's to the file. Spam me? Sure if it is related to the software. I love targeted spam in source files. As Michael says this is just a discussion though so don't take my comments too negatively :-) It's all in good nature. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Scripting in FPC
> > What does 'advertise' mean in this context ? > > 3. You must have a visible line in your programs aboutbox or >documentation that it is made using RemObjects Pascal Script and >where RemObjects Pascal Script can be found. > > i. e. You must put a link to RO homepage in your about box or your readme. > Since i won't have an about box then the choice left is to put it in the > readme, not a big deal since i do that sort of thing anyway, but is > GPL-Incompatible nevertheless. > > I don't see how this is incompatible, as I have no recollection of > > a clause in the GPL that says that you should not credit parts of the > > system... ? > > > > But never mind, that's probably me being stubborn ;-) > > > > Michael. Take a look at Stallman's page about FreeBSD license and how freebsd "advertises Berkley and California unreasonably" or whatever. Personally I'm more of a FreeBSD style guy and I might even switch to FreeBSD over linux because of religion. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Computer Language Shootout - updated to Free Pascal2.0.2
Some of the tests place sysutils in the uses clause but in fact it is not needed in the uses clause for some programs to work. Removing it from the uses clause where not needed would improve the memory footprint of the program, since sysutils hauls in initialization for things like widestrings and etc. i.e. this program here does not need sysutils at all, according to when I compile it: http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lang=fpascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal error 200312122
> When I try to compile the MSEgui demo for arm (using fpc 2.0.2, MSEgui > 0.7) I'm getting that error when compiling msegui.pas. Where should I > look to solve this ? Try to rebuild all units. use the -Ba compiler option I think I had this same issue when I tried MSEgui long ago, and it only occurred if I did not request -Ba option. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is there anything like PyChart for FPC?
> > I can send you a project which does exactly this for the FPC testsuite. > > The code is 100% FPC, no external libraries. > > > > Michael. > > Please yes! Send to me off list. > > Cheers > > Terry > I'd like to see too, post it somewhere public if possible. Hey, that's why we have websites - share it with the world! :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Build date stamp
>See "$I or $INCLUDE : Include compiler info" in docs Thanks much: http://www.freepascal.org/docs-html/prog/progsu30.html ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OOT: Pascal (especially FPC) on Linux community
> If you really want the job that would be great. I was > going to work on that myself but, I would have done it > in PHP. But, since you are willing to write the site > using FPC, I would be willing to set up hosting (Unix) > and a domain name. (or just a domain name if you > already have hosting). > Are you thinking about a community website? (forums, > showcase, calendar, etc) Would you need a particular > Database? sqlite, mySql, postgres? If the site got bigger, probably mysql. To start off, we can use a nice text database format called SDS from psp project which relies on no external database, and is great for starter sites who think they need a real database but not sure they want to commit to one. It as full capabilities to export to SQL later if the site gets bigger :) I guess they call this "scaling" and "backwards/forwards compatibility". As for you going to do the development in PHP? Instead, I would force you to help me in Pascal :) And then I would go about changing your email signature to this: -- Ronald Weidner http://www.techport80.com PHP/PSP Software developer for hire. And mine to this: -- Lars (L505) PHP/PSP Software developer for hire. Hit two birds with one stone: FPC gaming + FPC website development instead of FPC gaming + PHP website development ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OOT: Pascal (especially FPC) on Linux community
> What can you do? program the website in pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A simple "exception handling" question
> > SmartLinking to be active? The Docs, imply NO, that this is the default; > > your reply > above > > implies Yes. > > > > Bob Also, if your exe/elf is still not smaller after you find the .A files, try using the -Ba option which rebuilds all units, incase your old .O files are sticking like molasses. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A simple "exception handling" question
> > This brings up another nagging question I have had. If I set SpartLinking ON, > my > executables are no smaller! Your reply here seems to suggest, that I do not > have any of my > units compiled with SmartLinking enabled. There are no ".A" files in my source tree. > > To enable Smart Linking, do I need to recomplile the sources with some switch allowing > SmartLinking to be active? The Docs, imply NO, that this is the default; your > reply above > implies Yes. > > Bob > > Sometimes with Lazarus you get *no* smartlinked units on Win32. Which installation/ide are you using for FPC, just FP-IDE or commandline, or Lazarus? If you do need to recompile your units, use the OPT="-CX" with the "make" command. But you really shouldn't have to do this, unless you are using Lazarus win32 and you want to rebuild the default non-smartlinked shipment. .A, .O, .ppu files and etc. will be in a special folder called "units", whereas the source code is actually in several directories all over the place. The "units" directory is more like a "build output" directory for storage of the object/binary files. Example: C:\pascal\FPC_2.0.2\units\i386-win32\rtl\ This is where my .A files are for Winblows. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A simple "exception handling" question
> > First, thanks for the reply; I applied the patch, it applied without a > > problem, verified > > the new StrUtils.pp source, all OK as per the patch. Recompiled > > strutils.ppu. The function > > still returns a zero on error. > > You are aware of the fact that the .o's belong to units too? > > Delphi .dcu = fpc .ppu + fpc .o ! And also, in addition to Marco's comment, are you aware that you must copy the files to the correct folder after compiling them, i.e. not just compiling them and leaving them in the actual Source directories. And if you have dual compilers installed on your system of course, make sure you copy to the right folder and not the wrong one. And also, smartlinked units contain .A files in addition to .O and .PPU files ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Null characters in ansistring
If there is a null character in the middle or somewhere inside an ansistring, this does not affect it's length, correct? Unless casting with pchars in play. Reason I ask is that I wonder if it is a good idea to strip all incoming null characters for web/internet security reasons. If someone inserts a null character and they get stripped, this is safer than keeping them there and offering some compatibility in case some odd person chose to store null characters in his string. Probably that would only be used in rare cases such as a delimited file with null characters. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OOT: Pascal (especially FPC) on Linux community
> Hi all... > > Reading Linux community media (mostly lists and forums), I've seen that Pascal > language is still considered as non-serious and toyish programming language. > No > wonder if Linux people hardly know about Pascal. Though they're already knew > about it, the ignore it. Besides, Pascal they knew is the old primitive Pascal > we know 20 years ago. They even can't distinguish Pascal (as the language) and > Delphi (as [object] Pascal IDE)! Poor Pascal. :( > > Typical Linux people are always talking about C/C++, Python, and Java as the > chosen powerfull and unbeatable programming language for any kind of needs! > No, > I don't mean to start a language flame war here. But, I think we -Pascal > lovers > and developers- should enter Linux community and promote Pascal, especially > our > beloved FPC. > > Since UBUNTU now is the most Linux distro talked about these days, I think we > should promote our FPC in their community as well. UBUNTU web forum > (www.ubuntuforums.org) may become a good start. :) > > Let's do it! :) > On my local Linux user group I mention Pascal and speak up about it once in a while (not in a zealot way, just once in a while). Some of them thought that Pascal was the same now as it was back when they took it in university, i.e. no Units, no ansistrings, no ability to use include files, etc. etc. But if you speak up about things and mention that your website is programmed in it or that Total Commander program was built in Pascal, or that Macromedia used Pascal for one of their software applications, etc. etc. There are times when it is constructive to speak up rather than keep quiet. Bisma you know this I was just posting this message to encourage others.. The fact is if you join a local linux group or a linux list that isn't even local, you will still have some sort of influence. A lot of people start programming based on word of mouth (or try new languages based on word of mouth). Lars ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings DLL/DSO hack (memory manager)
Sorry for the double posting, the emails took a long time to get through. > It's exactly the same principle as using cmem, just that you are > using another memory manager than the one of the standard C library. > It has the same advantages (can return and accept ansistrings to/from > FPC-compiled programs and libararies) and problems (must not return > and accept ansistrings to/from programs not compiled with FPC). Well, > another advantage is of course for OS'es where the interface to libc > changes all the time (although I doubt the interface to malloc/free > etc will change anytime soon). > > And this case we use FPC mem manager rather than relying on our operating system friend - just makes me feel better to be able to utilize FPC mem manager if I can! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Ansistrings DLL/DSO hack (memory manager)
> I will throw up > a PasForum clone (code named Bubble2) using this tactic, and see what happens > with > this > sort of set up. Here it is:(BUBBLE2) http://z505.com/cgi-bin/Bubble2/index.psp Forgive the colors, I haven't played with the CSS file for more than 2 seconds :-) And the old one which used NO memory manager at all:(BUBBLE1) http://z505.com/cgi-bin/Bubble/index.psp And the one that does not use a DLL/DSO so is not worth even discussing, is the original PasForum so I won't mention the link to there. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Ansistrings DLL/DSO hack (memory manager)
Trustmaster sends me a trick/hack (as shown below) to avoid using CMEM in a
dll/dso in order to get ansistrings working through a dll/dso.
Comments? Find anything that could possibly be wrong with this trick we pull
off?
i.e. the ability to use strings in a DLL/DSO without ever using Pchars, nor
CMEM!
The trick/hack:
> Hi Lars,
>
> I've just read an article how to solve the memory management problem with FPC
> without using CMEM unit. It is done by exporting memory manager in the
> library and using it everywhere simply this way:
>
> // psplib.pp
> {$H+}
> {$MODE OBJFPC}
> library psplib;
> { ... }
> procedure GetMemMan (out MemMan : TMemoryManager); stdcall; export;
> begin
> GetMemoryManager (MemMan)
> end;
> { ... }
> exports
> { ... }
> GetMemMan name 'GetSharedMemoryManager';
> { ... }
> end.
>
> // pspunit.pp
> {$H+}
> {$MODE OBJFPC}
> unit pspunit;
> interface
> { ... }
> implementation
> { ... }
> procedure GetMemMan (out MemMan : TMemoryManager); stdcall; external 'psplib'
> name 'GetSharedMemoryManager';
> var MemMan : TMemoryManager;
> { ... }
> initialization
> GetMemMan(MemMan);
> SetMemoryManager (MemMan);
> { ... }
> end.
>
> // pspapp.pp
> {$H+}
> {$MODE OBJFPC}
> program pspapp;
> uses pspunit;
> { ... }
> begin
> { ... }
> end.
Lars' comments:
Seems to make a simple hello world project with strings in it work as a DLL/DSO
for
now without requiring Cmem, but further testing will need to be done. I will
throw up
a PasForum clone (code named Bubble2) using this tactic, and see what happens
with
this
sort of set up.
When using no shared memory manager and using strings, PasForum (code named
Bubble)
would
run but random access violations would occur every so often. I assume this is
why the
PSP4UM (psp.furtopia.org) has been running without issue for several while now,
because it does work,
sort of - but obviously not recommended.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parameter names local, global, glocal
> Maybe it helps to trust in Delphi mode > and makes porting to FP easier. I've grown to like ObjFPC mode for understanding Pascal at a greater level but using Delphi mode is a good idea with code coming from Delphi. Many of the objfpc mode choices were made with Pascal philosophy in mind, whereas Delphi syntax is generally getting lazier for programmers, while making some code less clear but lazier to type on the keyboard. For example the whole lack of @procedure confuses me in Delphi - I find the @ helps jump out and let me know it's a procedure in the code and makes code easier to read anyway. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parameter names local, global, glocal
> > Is it possible the Apple/Mac line feed could be causing your name > > to be rammed into > > the text below :-) > > No. Mac OS X uses the same line feed as every other *nix out there. >From the FPC ReadLn sources I was under the impression that the Mac used #13 >for line feeds and unix used #10 for line feeds, but I've heard that sometimes certain unix systems used #13. I've always wanted to clarify this.. And then there is the end of file delimiter which also came to mind. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parameter names local, global, glocal
> > ... use the underscore, although a bit messy looking: > > > > function SubstringData(const Offset, Count_: Integer): WideString; > > virtual; > > ... > > Thanks. Matches to the habit of the guy, who has written > the Delphi code, that I am working on. He usually begins > each private class item name with an underscore. Meanwhile > is habit seems appropriate to me. Now I will probably > change my habit, concerning parameter names as well, by > ending with >an underscore, as you proposed. I dunno it is a religious thing, read the other messages too :) I guess too many underscores in the code I find messy so I've fallen for the 'A' prefix now. I use underscores only where there is really a need, and have found that too many of them in code causes messiness and hard to read code. Either solution is okay, but since there is lots of existing Pascal code out there that uses the A prefix, it's probably best to use it. I'm not stubborn and am willing to change for the better. I do prefer underscores in very special special cases, such as when you have a very similar function but it does something special in addition to the other function: Parse (input: string); Parse_SF(input: string); SF stands for secure and fast implementation, whereas ParseFastAndSecureImplementation() is way too long, and you cannot tell whether it is Parse Fast, the secure implementation or Parse the Fast, Secure, implementation or Parse, and please do it securely and fast Also ParseFastAndSecureImplementation() looks extremely different than Parse() whereas Parse_SF looks extremely similar to Parse() so you know that Parse_SF() and Parse() are two similar functions, with one just being special. So the underscore helps suffix and separate function and keep the code logical without being extremely verbose. This is the sacrifice I've made for making underscores useful in some areas - some prefer to skip underscores altogether for religious reasons, I prefer to include underscores in code when they have some extreme advantage. And the brackets? Yes I know it is a sin in Pascal to use Procedure() and only Java programmers do that, I was just using the brackets in this text so that the text was easier to read, i.e. distinguish Pascal procedure from English text. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parameter names local, global, glocal
Is it possible the Apple/Mac line feed could be causing your name to be rammed into the text below :-) No big deal, I just wondered from an academic perspective, whether the line feed on the Mac would cause this issue on a PC, or whether it was for other reasons. Lars --- Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: parameter names local, global, glocal
>> Prefixing an 'A' seems to be an (un)official delphi naming convention > Does this make it official? > http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures_Parameters > > " The 'A' prefix is a convention to disambiguate when the parameter name > is the same as a property or field name in the class. " > Looks good, I'm not a fan of underscores in significant quantities, and should only be used in special cases. In this case, I find the 'A' prefix is a neater solution than the messy underscore hack. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parameter names local, global, glocal
> Conclusion: never call any parameter of any procedure or function exactly > like any property of any class and its ancestors. So far I thought, > parameter names of functions and procedures are always local, i.e. valid > for this function or procedure block only. Is this a bug or feature of FPC > vs. Delphi? I've seen this before while doing ports from delphi to freepascal. What I did, just to get it quickly working, was use the underscore, although a bit messy looking: function SubstringData(const Offset, Count_: Integer): WideString; virtual; procedure ReplaceData(const Offset, Count_: Integer) ... or function SubstringData(const Offset, _Count: Integer): WideString; virtual; procedure ReplaceData(const Offset, _Count: Integer) ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CMEM experiences in DLL
In linux I get a segmentation fault at the very end of an executable program when using cmem.pp in a DSO and executable combination. (simple hello world not even calling the function - just importing it itself is the problem). If the imported function is commented out, there is no segmentation fault. When using cmem in regular executable elf programs and not calling a library that uses cmem, the cmem works without trouble. On MS Windows using cmem does not seem to cause segmentation fault on simple hello world dll and exe combination program. I tried fpc version 2.0.2 and 2.0.0 and 2.1.1 with all the same behavior. I guess I'll file a simple bug report since any function doesn't work (even when not using ansistrings). Actually the program seems to run fine, i.e. the functions work and the programs run through till the end, just at the very end of the program you get a segmentation fault. Probably something to do with a variable being freed. I don't think it's the SetMemoryManager (OldMemoryManager); function in cmem's finalization section, because I commented that line out and it still gave segmentation fault. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] source file size ?
>
> > are there any know limits on how big a source file can be for the FPC
> > compiler ?
>
> interesting question... hmm did you try a 3GB file which calls
> writeln('test')
over
> and over and over again?
> That's the stupid way of doing tests - the smart way would
> be waiting for an answer from the FPC team.
> > hmmm ... i'm sensing some sarcasm.
None intended, I was serious.. personally, I tried the test and what will limit
you
is the memory on your pc. Thousands of writeln on my windows machine said "you
are
out of virtual memory". So this will only be your problem, as far as I tested..
>i'm not usually one to post dumb questions to a list because i'm lazy
>or have nothing better to do.
It wasn't a dumb question - I'm a user too, I'm not a developer (yet).
>in any event ... i have no idea if putting 3GB's of "writeln"
>statements in a file is a good test.
It sort of is, at least I found out something new.. the virtual memory blew up
on my
PC at 180704 lines of source code ... with writeln('test');
> in my case, the data would have to have structure.
That too, you could try something like a simple record over and over again.
Your data
wouldn't be over and over again, but it would still tell you quickly if FPC can
handle 400MB of source code, 4GB, etc. A writeln('test') would still cause you
to
place thousands of strings into the exe and etc.
My idea was to let the FPC team tell you more about it than doing a silly test
like
this.. because I'm just a user and they know more. But I suppose it's not that
silly
because I learned something about virtual
memory when I tried it.
>
> Here are my prefered colors for your website (take it or leave it):
>
> body bgcolor="#1E1E1E" text="#D7D7D7" link="#006699" alink="#006699"
> vlink="#006699"
>
> Gotta love dark backgrounds.
>
> hmmm website Sigs really do work because I went ahead and clicked on your
> site.
hmmm ... i just don't know if i'm reading into the intent of your
comments very well.
I've experimented with dark backgrounds and found an "off black" to be nice on
websites. I've found white on black is nice especially when it's an "off black"
and
an "off white". I was complimenting your site.. here I have written about this a
while back:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=black%20backgrounds
Only advantage with the old corporate black on white is that it is easier to
send to
the printer.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] source file size ?
> are there any know limits on how big a source file can be for the FPC
> compiler ?
interesting question... hmm did you try a 3GB file which calls writeln('test')
over
and over and over again? That's the stupid way of doing tests - the smart way
would
be waiting for an answer from the FPC team.
Here are my prefered colors for your website (take it or leave it):
body bgcolor="#1E1E1E" text="#D7D7D7" link="#006699" alink="#006699"
vlink="#006699"
Gotta love dark backgrounds.
hmmm website Sigs really do work because I went ahead and clicked on your site.
--
L505
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> i learned a few things from here: > > http://velthuis.homepage.t-online.de/articles/articles-pchars.html > http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_howto5 > I have seen Rudy's article too, and am reading the other website now, though. I'm at the point where I feel 100 percent confident using Pchars at this point and have started to write pages about pchars too. The mystery was why Trustmaster's website has been working for 2-3 years now (or so) using ansistrings - defying all the laws and warnings and hand wavings from people. Also, I wrote this a while back and update it with new info too: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Clearing-Up-PChar-and-DLL-Confusion But it is overwhelming and mainly just notes for my own purposes, so some people might find it too verbose to wade through. With Cmem, and according to my current knowledge, Cmem should allow one to safely export strings from one Pascal program to another Pascal program (but only Pascal programs, or programs who have compatible reference counting - i.e. maybe Delphi). Even if trustmaster's website does work fine with exporting strings without any Cmem, it would be wiser to just use Cmem - as it doesn't really cost you anything, and ensures things should work better than they are now, even if there are no problems now. When considering a C program or library will interface in to the DLL, of course pchars will be needed - one cannot use ansistrings even with cmem. And I'm fine with that - since confident with pchars. I didn't know about cmem and glad Jonas mentioned it. I still have to test it out though, to make sure things work in real life like they do in theory, when having two pascal applications talk to each other via cmem using ansistrings. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> simple and small unit. Advantages over sharemem are with cmem you wouldn't > have to > ship sharemem.dll with the application. > In fact, if someone has not already done it, the cmem.pp unit could be converted for use with delphi too (cmem.pas), since no one enjoys shipping sharemem dll. I wonder if anyone had the guts to standardize ansistrings so that every language had access to a standard ansistring system, which was defined as a standard to follow. Could work in a DLL too with a shared memory manager with multiple languages. Oh well, those are the blues and woes of using multiple languages and multiple compilers. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> > If a Pascal program returns a reference counted type to a C library, > then you get a memory leak, sharemem/cmem or not. If a C program > passes a pchar to a function that expects an ansistring, you can get > any sort of behaviour ranging from no problem to program crashes > (which is logical, since the C program is passing a variable of a > wrong type). > > You cannot declare a function as returning an "ansistring" in C, > since C doesn't know the ansistring type. So you cannot properly use > functions which accept or return values of that type from C programs. > It's as simple as that. You simply have to declare your functions > which you want to be callable from C with types that also exist in C > (or which can be constructed to be 100% the same in C). > > > Jonas > Thanks, and after looking into cmem.pp source code, I see why - it is simply calling a few simple functions from the operating system libraries. cmem is a very short simple and small unit. Advantages over sharemem are with cmem you wouldn't have to ship sharemem.dll with the application. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Executable size question
> Helo everyone, I would like to ask why are exes generated by FPC so big?
> Simple writeln('Hi'); has about 28 KB. Old FPC 1.0.0 for example created
> for the same code only 14 kb exe.
> What Should I do to reduce the file size (without compression)
> Pianoman
You can work on a custom System unit to get the size down - I was thinking of
doing
this for CGI applications to help uploading speeds, but I'm not sure yet
whether it
is worth the efforts. My first priority is to take all the functions out of
Sysutils
which don't rely on finalization, because sysutils hauls in 60K, and is a bigger
priority for size. Uploading a 60K CGI program is annoying for modem/lite speed
Cable
users. Project is called CompactUtils and not completed yet.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> > On 03 Jan 2006, at 18:29, L505 wrote: > > > I can post the psp 1.0 sources online if anyone is interested, but > > probably it is > > only me who is so curious ;-) > > A very easy way to solve all problems in FPC is to simply use the > cmem unit in the dll(s) and in your main program. It should have the > same effect as Delphi's sharemem unit. > > > Jonas Would that work with C programs that called a library? I think sharemem only works for borland applications (i.e. pascal and C++ builder). Just wondering if it would have an advantage over sharemem, in this case. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> L505 wrote: > > Can it be something in FPC 1.0 compiler that allowed this to happen? I > > guess I'll > > have to do more digging. I wish I could put an end to this and just use > > Pchars in > > these DLL situations - but there's always some evidence of ansistrings > > working, > > somewhere. > > There is an important difference between working and not-crashing. ;-) > > Micha True, but who was that person who tried exporting a string recently and got an error immediately? He reported it as a bug - Unless that was a specific compiler that really did have a bug? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings exported in DLL's - mystery
> On Mon, 2 Jan 2006, L505 wrote: > > > Trustmaster from PSP project tells me he's been using Ansistrings in DLL > > without > > problems. The entire psp.furtopia.org website is running a DLL with > > ansistrings in > > it, he says. > > > > He says he compiled it with FPC 1.0 a long time ago.. > > > > So the psp.furtopia website has been using ansistrings in DLL for ages now. > > > > How can this be? How is it possible a website can run without any problems, > > using > > ansistrings? > > > > i.e. exporting functions like this: > > > > function something(param: ansistring): ansistring; > > > > > > Can it be pure luck that a website is running this long with ansistrings? > > It all depends on how the DLL is used. > It's impossible to say something definite without this information. > > If it's used by a C program such as Apache or so, then it should not > present a problem at all. > > Michael. Its just a dll/so that a CGI is calling on - it's not an apache module or anything. i.e. place a dll in a directory, and have a CGI program call on it.. I got a copy of the psp 1.0 sources and what he is doing is calling the functions from an SO/DLL from a cgi executable.. There are tons of functions like this that another fpc program is calling from the SO/DLL: function something(param: ansistring): ansistring; It's just funny, because a website is the thing you'd think would be the first thing to crash down: a website is accessed by several people at different times in the day, whereas a desktop is not. I visit his forum every day and have never once had a crash! I can post the psp 1.0 sources online if anyone is interested, but probably it is only me who is so curious ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Ansistrings exported in DLL's - mystery
Trustmaster from PSP project tells me he's been using Ansistrings in DLL without problems. The entire psp.furtopia.org website is running a DLL with ansistrings in it, he says. He says he compiled it with FPC 1.0 a long time ago.. So the psp.furtopia website has been using ansistrings in DLL for ages now. How can this be? How is it possible a website can run without any problems, using ansistrings? i.e. exporting functions like this: function something(param: ansistring): ansistring; Can it be pure luck that a website is running this long with ansistrings? I guess I'll have to try and get a copy of some of the source code that is running his DLL. I just find it hard to believe that the website has been up that long and hasn't crashed with a memory management issue - the one Jonas and Marc and I talked about earlier - the EXE/DLL freeing memory it didn't allocate, during a reference count decrement. Can it be something in FPC 1.0 compiler that allowed this to happen? I guess I'll have to do more digging. I wish I could put an end to this and just use Pchars in these DLL situations - but there's always some evidence of ansistrings working, somewhere. -- L505 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] const pchar parameters?
When using pchars, what happens when one does this: function test(const input: pchar): integer; Is this a pointer to a pchar? Or is it just a pchar? i.e. below is bad: function test(var input: pchar): integer; So what about a const pchar paramater... Is it a read only pchar, or a read only pointer to a pchar? -- L505 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Quake 2 for Freepascal
> If anyone is interested I can post the Quake 2 freepascal port up online. >> i'm interested in looking at the code from an academic perspective. >> >> please do post. >> >> i could even help mirror it if need be. http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Quake2FreePascal Remember everyone, to read instructions.. if you don't, you will get an error saying "software refresh blah blah" because the Quake PAK file is missing (similar to a doom WAD file). -- L505 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling library / Win32 DLL
>i had started doing development using the FP console IDE. > >i then "discovered" Lazarus, and wanting to be able to use a GUI IDE, > >i downloaded and installed it. > >i then took the exact same code, compiled it, which produced a DLL for >me, and when i tried to get my hosting application to load it, it >complained, saying it wasn't a DLL. > >i then loaded the FP IDE, recompiled the same code, and it went back to >working. > >i posted to the list, asking questions about my problem, but no one >seemed to know why i might be having the problem. >someone even sent me a "dll loader" tool to test whether my DLL would >load with their testing tool. I had sent you that tool, and it was extremely simple but it has solved some problems I've had before. I recalled having the same problem as you, once with lazarus.. lazarus didn't create a good DLL for me but for some reason my problem went away after a while, and lazarus was producing OKAY dll's. I should have written down what if anything I found out?? One of my issues was smart linking. The compiler did not generate good DLL's when you had the smart linking on. But this was later repaired by someone.. And again, it may not have to do with your issue. I am just guessing maybe you had smartlinking on in lazarus, but not in the FP ide. Or maybe the FP Ide was a different version of compiler than your compiler included with Lazarus in /pp/bin/ >the DLL _did_ load with the tool, but the application i was using >still wouldn't deal with it, until i recompiled it with the FP console >IDE. Since the IDE has it's own compiled in compiler, maybe the compiler that was compiled in was a different version than the one you were using with Laz? If you have time, try pointing lazarus to use the exact same version of compiler that the FP IDE was using (in environment options). >stuff that is really hard to explain in any detail in an e-mail ... >but things like "enumerators" within the API suddenly stopped >enumerating ... without error ... function calls that returned enums >were returning the wrong enum value ... stuff like that. >after alot of head scratching and poking and prodding ... i ended up >cleaning up a bunch of "dot o" files from some of the units for the >third party API wrappers that are implemented in pascal, and which >were being compiled by FP. > >my problems went away. I've had the FPC config file problem before, where FPC config file is referencing my old FPC units in other directories. It will pick up old .PPU/.o/.a files especially if the FPC.CFG file has not updated the -FuC:\wherever\ to the new directories. It's not actually in FPC config file problem as much as it is a user error problem (my fault, really, for not updating the FPC cfg file in all the directories - the problem is when you have two or more compilers running on one system) > some kind of weird issue between 2.0.1 and 2.0.2 in the object files. They are simply generated from the compiler with the PPU files, so if you use 2.0.0 .o files with 2.0.2 ppu files this will definitely cause issues AFAIK, and I've had this problem before when the FPC.CFG file is pointing to old directories, as far as I can remember. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Quake 2 for Freepascal
- Original Message - From: "Jonas Maebe" <[EMAIL PROTECTED]> To: "FPC-Pascal users discussions" Sent: Thursday, December 29, 2005 2:07 AM Subject: Re: [fpc-pascal] Quake 2 for Freepascal > > On 29 Dec 2005, at 04:27, L505 wrote: > > > Seems FPC always has graphics related issues for some reason when > > compiling Delphi > > code - I've not had problems with FPC/Delphi compatability when > > working with text, > > since I mainly work with text programs and not graphics. > > There's no inherent difference between "graphics" and "text" code. It > simply means that there is a bug somewhere, either in the code > generator or in the Windows-related units. > > > Jonas Right, I hope it is maybe something simple in the Windows related units which is being called over and over again.. If anyone is interested I can post the Quake 2 freepascal port up online. I'm working on other things at the moment so don't have much time to peak at the moment.. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Quake 2 for Freepascal
>I have Quake II. That happens to be my favorite FPS. >Anyway send me the source code and the EXE and I'll >test it for you. I figured out that the demo should in fact work.. Felipe was right. The delphi port of Quake2 works just fine with the demo Quake files. I'm compiling basically exactly the same source code on the two compilers side by side and the FPC one loads the game, but doesn't let you play the game when selected, nor does it play the video intro, or display graphics perfectly in the menu areas. Seems FPC always has graphics related issues for some reason when compiling Delphi code - I've not had problems with FPC/Delphi compatability when working with text, since I mainly work with text programs and not graphics. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sax.pp
>second, for hoots and hollers, i subclassed/extended the SAXFilter >class ... thinking that it looked like the descendent of everything >else, thinking that it was itself the parser and handler, and tried to >override some of the callback functions ... but when i call parse on >it, i get an error about abstract methods. If you forget the override keyword after a function declaration, you may get abstract errors. You can't call an abstract function directly. I'm not sure if this has anything to do with it, but maybe Java's class ancestor/inheritance system is a bit different causing you issues since you come from that background and have memorized how to code classes that way. Would need to see some sample code that is giving you the abstract error, though. I just finished dealing with an "abstract error" and all I did was forget to place the override keyword after the function declaration in the *derivative* class. Just to add to the confusion: Tstrings is abstract.. so calling something like TStrings.create isn't right but TStringList.create is okay. begin ObjectOrientation:= confusion end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Quake 2 for Freepascal
Hi, Does anyone have a copy of Quake 2? I got Quake to compile with freepascal, but I don't have the quake game files. I need it, in order to test the exe! Otherwise, the exe is useless. So if anyone has a copy of Quake 2, maybe you will you test the FreePascal Quake port for me? All that needs to be done is you copy the freepascal quake exe into your already existing quake directory... -- L505 Possible ADD ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New Pascal cross platform GUI library with IDE
> I hate to bring this up since it isn't the most important issue in our lives > these > days, but just for fun.. > > Demo.exe I got a 604KB exe > After UPX 187KB > > That was with the -CX and -XX options in the command line, along with > > strip demo.exe > > Anyone get similar results? > > Pretty good size for a cross platform app, and I wonder if Martin has already worked > on tweaking the libraries for smartlinking, or whether there has been no work > done > there (i.e. room for optimization or is this already been optimized? ) In addition to my above comments, measuring size is actually different in this case, because we have to consider that the program above is a special program in that it does not use native windows controls AFAIK? i.e. not using ComDlg32.dll and similar (whereas notepad and delphi apps do, so this hides some of the exe size in the dll with delphi programs and it isn't a fair comparison). So a 600kb exe may actually mean that there is 600kb of true native controls in the exe, whereas notepad/delphi applications store a lot of their native controls in other dlls on the windows machine. Martin, are components mostly custom windows API graphic screen calls? My tools tell me your programs do not rely on ComDlg32.dll and ComCtl32.dll (which is obvious considering there are no windows-ish looking dialogs and controls in the program). Hey I'll look into the source too, to try find out, but it's also interesting to discuss these issues in english too :) i.e. in a delphi hello world Exe you immediately pull in comctl32.dll whereas in this IDE you do NOT pull in comctl32.dll, so considerations need to be made. One other thing I noticed is mpr.dll gets pulled in with demo.exe but in a delphi hello world it does not. What code in demo.exe does rely on mpr.exe, is I wonder? Again, none of these issues are *really* important at this point in time. I'm really just over-analyzing - but interesting none the less. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New Pascal cross platform GUI library with IDE
I hate to bring this up since it isn't the most important issue in our lives these days, but just for fun.. Demo.exe I got a 604KB exe After UPX 187KB That was with the -CX and -XX options in the command line, along with strip demo.exe Anyone get similar results? Pretty good size for a cross platform app, and I wonder if Martin has already worked on tweaking the libraries for smartlinking, or whether there has been no work done there (i.e. room for optimization or is this already been optimized? ) p.s. Martin I may use this IDE in the PSP project - we are looking for an IDE to build Pascal web projects, and currently lazarus is i candidate, and Syn too.. maybe this IDE is another option! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New Pascal cross platform GUI library with IDE
> My Pascal cross platform GUI library and IDE has reached 'near beta' state. > I plan to release the IDE under GPL and the library under LGPL or similar. > > - Compiles on FPC 2.0.2 or FPC 2.0.3. > - Tested on i386-linux SuSE 9.0,9.2,10.0 and i386-win32 98 and 2000. > - Links to xlib and gdi32, no external widget library needed. > - Internal character encoding is UCS2. > - Uses anti aliased fonts on Linux (XFT). > - All screen drawing is double buffered. > - Has docking forms. > - Has embedded forms (similar to TFrame). > > IDE: > - Integrated debugging. > - Source code highlighting. > - Source code navigation with support for include files. > - Integrated visual form designer with source code update for components and > events. > - Flexible and practical build system with switchable macros. Neat.. saves a lot of screen space with the fonts and menus you use. I'll write a page about it when I get a chance after playing with it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Remote FreePascal compile service, feedback requested
> > Here is my first fpc DOS attack: > > > > type > > TMyClassA = class; > > > > TMyClassA = class(TMyClassA) > > procedure DoSomething; override; > > end; Email Abuse Syndrome: This makes me think we should start up something accepting emails as input to the compiler interface. Every time someone sends an email to the FPC list, the compiler compiles any code snippets in the email. All bugs are tracked for us immediately. No need to copy and paste any more. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOOM game for FPC
> Such issues has usually nothing to do with good/bad code generation. I meant bad code by the author/creator... not the compiler :) Sometimes delphi has been known to clean up bad loops that people create, and speed them up.. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOOM game for FPC
> > > > Keyboard handling is not something which is cpu-bound in any way, so > > I doubt that is caused by a code generation issue. > > > > > Only think I could think of is if maybe there are some non-standard loops > running > waiting for the keyboard, that are sucking up CPU, it is weird .. > There are quite a bit of keyboard code snips... "// Respond to keyboard input events, // intercept cheats. " And there is also a unit called "unit i_input;" which does a lot of keyboard translation/input Something like that might be checking too often or not often enough for keyboard input - I won't be able to look into it for a while. Jimmy might find something too. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOOM game for FPC
> > Keyboard handling is not something which is cpu-bound in any way, so > I doubt that is caused by a code generation issue. > Only think I could think of is if maybe there are some non-standard loops running waiting for the keyboard, that are sucking up CPU, it is weird .. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
