Re: [fpc-other] Re: [fpc-pascal] Variable arguments, different types?
> > See docs: [http://www.freepascal.org/docs-html/ref/refsu47.html] > Just like one of those USENET trolls who spits out "read the man page", > even though the man page is incomplete. Still, most haven't read the incomplete bits either :-) > Manuals constantly need updating, along with examples needing to be > updated too. True. And that is a lot work. OSS answer to that is highlevel parallellism to manuals, but in practice that gives crappy manuals. > Makes me wonder what PHP people were thinking, adding a silly comment system > to > their main documentation URL's. How can that help anyone. The manuals are > already complete, and set in stone. They don't change. We have this with FPC too (select with comments), http://community.freepascal.org:8080/docs-html/ref/refsu47.html#x113-1210.3.6 this is mostly to submit feedback back to the doc maintainer(s) on a per subject basis, and avoiding a lot of routine work on maillists etc. That doesn't mean the lists can't be used for communicating over the docs, but for trivia the comment system could be handy (though I never heard back from Michael how it works in practice, and _if_ there are any submissions) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] fpcmake question
[ Charset ISO-8859-1 unsupported, converting... ] > Peter Vreman wrote: > > > Use a shell script with a for loop and pass the values to the Makefile > > on the commandline with INSTALL_PREFIX= > I was afraid of that, but was looking for a more elegant solution :-( Another logical solution is to install once to tempdir, and copy 10 times. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Mac Questions
> This is kind of not pascal related.. > > Can one use a Mac to compile BSD web programs and then upload these BSD > programs > to a BSD server? > > Can one create ELF on Mac and upload to a linux server fairly easily.. > (compared > to Windows where it is harder to make Elf's) No. The trouble of crosscompiling to *nix doesn't lie in ELF, but in the way of shared linking that requires (in the current form) libraries on the host. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: fpc-other Digest, Vol 10, Issue 3
> > Cross compiling on a Mac is no more difficult than cross-compiling on > > BSD or Linux. The only thing to keep in mind is that if you need to > > generate i386 programs, the host compiler has to be an i386 binary as > > well currently. > > Which Mac compilers/computers not capable of producing i386? > > Take the typical Mac user today, for example.. with a typical up to date Mac.. > or an older Mac from 2 years ago or similar time period. Afaik all of them. Has to do with bootstrapping the compiler, and different sizes of extended afaik. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: fpc-other Digest, Vol 10, Issue 3
> > No. The trouble of crosscompiling to *nix doesn't lie in ELF, but in the way > > of shared linking that requires (in the current form) libraries on the host. > Yes, but the bottom line is: > > -it is easier to create an ELF on a unix like system. Because? The base problem of having to have libs on host is actually worse on e.g. Linux, because of possible mixing of files. > I'm more interested in the bottom line of whether it is easier to build web > programs on a Mac for typical linux and bsd web servers than it is on a > Windows > PC. It's exactly the same. Even if Mac were ELF, which it isn't. > I've done cross compiling many times and it is a pain in the butt to > create the Elf on windows. I gave up and use CoLinux which is slow but > much easier than the painful process of cross compiling and running around > searching for all linux .SO and other files. It's a problem of the target, not the host. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] PCRE
> The fact that we cannot use JCL code inside freepascal is in fact very much on > topic. The fact that the freepascal compiler is distributed with a license > called GPL is in fact very much on topic since it relates to the Pascal > compiler, download, installation, etc. First, it is more likely because that we maintain a LGPL-with-exception distribution policy, not because of the compiler license. Second, the issue is symmetrical. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: Which operating system is used to develop FPC ?
> They use several operating systems. > > AFAIK Florian uses Windows often, Daniel uses Linux, Michael uses Linux, > Marco uses BSD, etc. > > You have to have several team members using different operating systems > and have at least someone obsessed or focused more on one than the other > team member.. other wise the cross platform support isn't as good. > > However, I will mention that cross compiling is easier on Unix because > you can make Win32 targets from a Unix box easier than you can vice > versa. One problem is the Windows file system is not like unix, so > things like symlinks and links and what not to .SO files are hard to > emulate without you just making exact copies of them instead of links. > This was my reason for saying even a unix Mac would be easier to create > unix elfs on than a Win32 machine which Marco never understood. It's > not just the unix file system though and the file links and symlinks and > such things, but the fact that the elf (or whatever binary format you > are creating) requires libraries and a bunch of unix related files to > exist in the lib search paths, which you have to chase down and find > from an existing unix system (but, easier to do on a unix like system > since the file system layout can be emulated easier). The main reason is that dynamic linking goes 100% by name on Windows, not anything file system related. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPC Hypocrisy: overloaded L505
> Florian Klaempfl wrote: > > > Skybuck Flying schrieb: > > > For records, I would use an extension field like: > > > > > > IP.Payload > > > > > > and > > > > > > UDP.Payload > > > > > > I would hardly call that obfuscation :) > > > > Having the same name for different things is always obfuscation. > > > procedure test; > procedure test(i: integer); > procedure test(s: string); > // oh shit, a STRING? Shortstring? or ANSISTRING!! UTF16 Widestring on Tiburon (D2008 when it comes out) even. (rest of rant skipped). You are partially right. If you encounter code that uses a "string" and its implementation expects a certain type, please file a bug. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Turbo51
> I just got a Google alert for a new release of the Turbo51 compiler. > It's a TP-compatible compiler for the 8051 microcontroller family. > It's freeware, but not open source. > > http://www.turbo51.com I browsed a bit there and it looks pretty cool! It seems to have full shortstring support at a first glance, and in general more of the BP dialect then most 8-bit dialects. T The extensions are what one would expect (segment modifier and bit access. It also supports "our" %110101 syntax). The only strange thing I found is this: * Local variables All local variables in normal (non-reentrant) procedures and functions are static. They are placed like global variables but are accessible only in local scope. Default memory type for local variables can be set with compiler directive $ML MemoryType (DATA, IDATA or XDATA) and defaults to DATA. This memory type can be overridden for each variable declaration. - (and same for params) I think it makes sense for embedded programming though, since it simplifies calling conventions. OTOH, they generally don't have that much fast RAM. Pitty that we use (16-bit) Microchip nowadays. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Turbo51
> I think that the biggest problem for using it in a commercial project > is that it is not open source and a hobby project. There is a risk it > gets abandoned. Yes. But that depends on the scale of you rusage. > For PIC microcontrollers there is a good amount of a Pascal compilers. For 8-bitters there are some, but for 16 none. Moreover I didn't like the that much. To be honest, there is no point also, since we mostly only instrument the hardware building blocks. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] [job] Porting Delphi XLS reader library to FPC/Win64
In our previous episode, Jonas Maebe said: > See http://www.getacoder.com/projects/porting_some_code_fpc_87172.html > for details The trick will probably be 32-bit <-> 64-bit ActiveX, since Office is 32-bit-only probably? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] What would your second language be and why?
>But there comes a time, when I like to extend my knowledge a bit. >Pick up some new skills and maybe ever carry those skills over to my >daytime job and programming language. First, on what primary grounds do you select the language? Commercial (iow something to put on your resume) or technical skills? If commercial, and aiming at larger business, pick either C# and Java. If technical, pick something that is complementary rather than competing to the skills you already have. But first, decide if you want to target larger or smaller companies. Smaller companies are less rigid in their language ways. Also, the languages you picked are geared at the straight administrative side of programming, where both the money and competition is biggest. If you go numeric, embedded (and there are several levels there), choices can be different. >From the start I have been a big fan of the Java programming language. >To me, it's a very clean and well designed language and is relatively >easy to learn and understand. Just a shame the GUI performance was so >bad, though that was many years back. I don't know if things have >improved since. I never really liked Java syntax. I don't mind the language itself so much, but there is no love lost there. >I don't want to learn some obscure > anguage like D or F# that nobody would hire you for - there just >isn't a commercial demand for such languages, no matter how good >features they have. So, the commercial angle. Well, blindly selecting, VB.NET or C# then. Maybe if you have a feel for the industry that you go to (say they are not typically MS shops, but IBM or Sun), Java could be a choice too. >Anyway, what I see as mainstream at the moment is Java and C#. Both >seem to be well designed, commercially acceptable (from a job hiring >point of view) and appears to be clean code. Scripting / interpreted >languages like Perl etc are out! So for me, it seems a choice between >C# and Java. So far I am leaning towards Java, because it's more open >(no big giant monopoly hanging over it), been around for years and is >commercially viable. Development tools, documentation etc are plenty >full! Plus it's well supported on just about any OS and device. Don't try to rationalize a commercial decision with technical arguments. It is pointless. > * What's your thoughts between Java vs C#? Roughly the same. Choice boils down to allegiance of your future employer to either MS or Sun/IBM. The size of the C# language scares me a bit though, specially the heaps of modifiers, and new syntax every two years. Though for the former one could argue where C# stops, and MSVC modifiers start. > * Have you got a better choice in mind and why? While learning C#, learn VB.NET too. Not that hard, and VB.NET shops are often in desperate need for that one programmer that solves the problems the hordes can't. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] What would your second language be and why?
In our previous episode, Marco van de Voort said: I forgot my own choice, though it is more a role that krept up on me over time then a deliberate choice. I spend roughly 25-33% of my time programming microcontrollers in C. The language skills required a pretty low though. It's more embedded/realtime programming that takes some getting used to. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] (Linux to pascal continued from fpc-pascal)
In our previous episode, Guillermo Martnez Jimnez said: > > I think the problem here (again) is not the language, it's the critical > > mass of users of the language. Using C for Linux was a good bet, not > > because the language is good (Pascal is way better for me), but because > > C has a wider user base who can fix/add features. > > I disagree. C is better for write operating systems *by definition*: > C was created to write UNIX, Pascal was created to learn good > programming techniques. C is low/mid-level language, Pascal is > high-level (and Object Pascal is even higher): OS are the lowest > software level. I don't see that at all. Sure original Pascal started and ended a bit higher (no lowlevel manipulation). But this is a Free Pascal list, and Free Pascal and Delphi can get down and dirty too. There sure isn't much in C that the FPC dialect can not do, or is still relevant. (C constructs directly mapping to PDP assembler constructions aren't that useful anymore) And the few bits that miss (if any) would probably be added soon when major OS development would start. I think it is more a matter of FPC being geared towards apps development as a compiler than a matter of language, and that most of the modifications would be in that space, and in the internal assembler. One could notice FPC lacking in those things already a bit when trying to port the si_* startup constructs to other platforms. Stuff like weak referencing is hard to do. > I'm not saying it's impossible: here you have MacOS and Toro. I'm > just saying that _I think_ it isn't the best option. Of course a > better option is to write the kernel in C and Assembler and the > utilities in Pascal and Object Pascal. Well, it is a pity that there is so much routine discussion in this thread that seems to boil down to a dogmatic kneejerk "C is better, C has always been better, because Linux/Unix was programmed in it", and so little real funded argumentation why this is really the case. Sure, C has a tradition there, but that tradition doesn't help one bit if you now start to develop a kernel in a new C compiler, that hasn't been used for kernel development before. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Re: Porting linux to pascal, would it be possible ?
In our previous episode, Micha Nelissen said: > > I disagree. C is better for write operating systems *by definition*: > > C was created to write UNIX, Pascal was created to learn good > > programming techniques. C is low/mid-level language, Pascal is > > high-level (and Object Pascal is even higher): OS are the lowest > > software level. > > That only proves the first versions of Pascal (in the 80s) were not > suitable. Not whether the current-day FPC can't do it successfully. And even if you accept that, it only means we really have to add that Modula2 mode, since M2 _was_ developed for system programming. > Also note that Linux depends so heavily on GCC that I can't see it being > compiled even by another C compiler. There are so many gcc (part of > those are also C99) specific constructs being used to do some things > more easily, efficiently (in space and time), and to add more type > checking to what C natively has. To be honest, I doubt it would be that different if we did it with FPC, seeing how much problems Delphi already has to compile FPC code. Trivialities often, sure, but quite a lot. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Re: Porting linux to pascal, would it be possible ?
In our previous episode, Micha Nelissen said: > >> Also note that Linux depends so heavily on GCC that I can't see it being > >> compiled even by another C compiler. There are so many gcc (part of > > > > To be honest, I doubt it would be that different if we did it with FPC, > > seeing how much problems Delphi already has to compile FPC code. > > Indeed, but my point was that even if C was designed for writing > operating systems, Linux still uses a lot of extensions (and rightly so, > it makes it safer and better). So, if they use extensions for C, then a > couple of extensions to fpc would certainly make it very suitable as > well for this task. Correct, and discussing what is missing or could be useful is more important then echoing "C is better", "Pascal is better". That was more or less the gist of my first reply. I really would like to make this point again: the si_pr* stuff might be a good candidate to testdrive FPC in this regard. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: Pascal Showcase Project/Education
In our previous episode, Richard Ward said: > beginners. It is also supports other languages like Java and C which > might be attractive for CS curriculums. Although it runs on Macs, I wouldn't do that if simplicity is an objective. It pulls in two additional different styles of building programs, which makes it hard to exploit the advantages of Pascal's autobuilding. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Other IDEs
In our previous episode, Paul Robinson said: > The IDE such as Delphi provides is fairly good, and unless you're going to > be developing for text environments it is the way to go. And the IDE such > as what was provided by Visual Basic is even better than the one for > Delphi because it gave a much better environment for doing on-the-fly > development. Anyone who dismisses what Visual Basic was as a toy never > used it in version 6 or in .NET as it can be used for professional > development. If you really want to further this, compare all contendents head to head, and make a deeper analysis of the differences and what they actually provide. (IOW does the typically use case of a feature really fit at all?) I never understood the heated debates over VB-the-IDE. The few times I used it (after Delphi) gave me a feeling of same old, same old. But typically I'm not a man that tries to solve everything designtime, also in Delphi. > But I think if all we want is a language to teach programming then we're > not going to get much attention or interest from professional developers. > As soon as someone goes through the language and the tools, and finds that > they can't get certain professional development done, they're going to > move on to something else. I'm afraid this is so vague and opinionated that it is next to useless. We need detailed data and comparisons, not opinions that are cast down from an ivory tower of "professionalism". And that is even stepping over the fact that the common paths might be exactly what you want to avoid, since the commercial IDEs already cover it. > My thought is, if we want people to consider FPC as a serious, > professional-class application, it needs to interface to a serious, > professional-class IDE and use as much of the provided features as is > available. And as I see it, that means that FPC should be able to be used > with Eclipse. Which has been said before, but nobody has said why? > I believe Eclipse provides a lot of nice features including identifier > lookup and run-time tracing and variable examination. Some of these are provided by Lazarus too. And worse, afaik it isn't Eclipse that provides these, but (partially) language dependant plugins. One can't expect them to cater to FPC automatically (or even at all) > are things that need to be done if they're not already. Better debugging > support so that applications which are not production can get better > "while running" analysis including real-time monitoring and control of > execution, variable values and code paths. I know some of this might not > be significant for some people but it will be to others. The debugging problem is mostly a GDB problem, and both Lazarus and Eclipse use GDB. So there is not much to be expected from Eclipse in that field. > I could probably say more but I think I'm still on point and so I'll stop > here rather than go on and bore people, although I might already have done > so. :) To be honest, I've seen nothing but the usual rants where something is compared to something where heaps of fulltime programmers work on, meaning Eclipse and the default plugins bundled with them. THAT is the crucial problem with FPC, not Lazarus vs Eclipse. If you are willing to fund such a team, by all means, do. You can even have a say about direction. Seriously, if you really want to contribute to this discussion, go into detail, describe problems, dissect Eclipse to see what makes it tick, and what is language dependant. THOSE are things that might give a new perspective on a changed situation. Not these kinds of gratituous comparisons. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Use the IDE for FORTRAN
In our previous episode, Arjan van Dijk said: > Some of my source-code is NOT in Pascal, but in Fortran. > I would really be very glad to develop my Fortran programs as effeciently > as my Pascal-projects (on a Windows box). > > Has anyone ever tried to modify the IDE that comes with FreePascal to > work as a Fortran workbench using e.g. the g95-compiler and GDB? Not that I know. > If nobody has tried this yet, can someone estimate how much effort > it would take to modify the IDE? The IDE has not been setup for multi-lingual support. Both the Pascal compiler and GDB are integrated, not external. But that doesn't mean it's impossible. Just unknown. > And where to start? ide directory in SVN, and the wiki page: http://wiki.freepascal.org/Textmode_IDE_development ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fwd: [fpc-pascal] fpGUI Toolkit source repository migrated to Git
In our previous episode, Tomas Hajny said: > although I share Florian's concerns about "magic" detection of proper > file type rather than combination of reasonably conservative and obviously > configurable default setting combined with possibility to mark other files > as plain text explicitly at the file level That also worried me a bit. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fwd: [fpc-pascal] fpGUI Toolkit source repository migrated to Git
In our previous episode, Graeme Geldenhuys said: [ Charset UTF-8 unsupported, converting... ] > On Wed, Apr 8, 2009 at 1:00 PM, Marco van de Voort wrote: > >> although I share Florian's concerns about "magic" detection of proper > >> file type rather than combination of reasonably conservative and obviously > >>... > > > > That also worried me a bit. > > Well then you and Florian must have been worried for a very long time. > How long has FPC been using SubVersion? ;-) SubVersion also does > automatic conversions via the eol-style property. Binary status and textformat automatic conversion based are not the problem. The problem is that it is based on automatic detection. And you'll see in FPC SVN faqs that setting the mime type is mandatory for this reason, though this can be automated based on extensions. > Like I mentioned before, you can disable the "magic" detection and > leave text files exactly as-is by simply setting autcrlf=False in your > .gitconfig file. Then simply make sure you use a half decent editor > and not Notepad. That's not the same. Then you still have the mess of crlf mistakes in your history. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Microsoft to ban Memcpy() :)
In our previous episode, "Vinzent H?fler" said: > > And of course, the move() procedure in FPC/TP/Delphi has exactly the > > same problems as memcpy() as far as bounds-unsafety is concerned (it's > > similar with fillchar/memset, indexbyte/memchr, etc). > > True. But in contrast to C an average programmer doesn't need it very often. > In Pascal there are easier ways to assign arrays to each other than doing a > raw byte copy. ;) Less, yes. > But I still fail to see the advantage of > > void * memcpy_s ( void * destination, > size_t dest_size, > const void * source, > size_t num ); > > vs. the original: > > void * memcpy ( void * destination, > const void * source, > size_t num ); > > Time will tell, if memcpy_s() is actually "safer". If the programmer didn't > think about the destination buffer's size before, why should he now? :-> That's the feeling I had too. It will only matter in a very small number of items, where the numbers are actually calculated on the spot in different ways. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Illogical automatic dereferencing
In our previous episode, Jonas Maebe said: > > Then another person pops up and asks why it is allowed only for > > pchar/pwidechar being illogical because this is not orthogonal. > > Undoubtedly. I guess the best solution is to have that Delphi switch > so everyone can set the behaviour he/she prefers. I guess some choice is fine, but I wouldn't change the default behaviour, except for Delphi mode. It breaks a lot of code (e.g. fcl-image uses it a _lot_) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Lazarus LRS to Delphi DCR
On Fri, Dec 18, 2009 at 09:29:13AM -0200, papelhigien...@gmail.com wrote: > I'm creating a set of components for lazarus/delphi. > Now I'm creating the icons for the component palette. So I drawed it on > inkscape, created a shell script to convert from svg => png => xpm => bmp > and from these xpm files I create a lazarus resource (LRS). I'm USING > LINUX. > > But now, I don't know how to create delphi DCR from LRS (or from BMP files) > without go to Windows. Note that like many Delphi binary formats, it might be version specific. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Free Pascal 2.4.0 released
Happy New Year!
As a special present, We have placed a new major release of the Free Pascal
Compiler, version 2.4.0 on our ftp-servers.
Changes that may break backwards compatibility are documented at:
http://wiki.freepascal.org/User_Changes_2.4.0
Downloads are available at:
the main FTP server at
ftp://ftp.freepascal.org/pub/fpc/beta/2.4.0/
and
ftp://freepascal.stack.nl/pub/fpc/beta/2.4.0/
Enjoy!
The Free Pascal Compiler Team
Free Pascal Compiler
Version 2.4.0
**
What's New in 2.4.0
**
Free Pascal 2.4.0 contains many fixes and new features. While we did not
manage to incorporate all planned additions, we believe this release offers a
nice collection of new functionality and bug fixes.
Please also see http://wiki.freepascal.org/User_Changes_2.4.0 for a list
of changes which may affect the behaviour of previously working code, and
how to cope with these changes.
Some highlights are:
Platforms:
* New platform: Mac OS X/PowerPC64
* New platform: Mac OS X/x86_64
* New platform: Mac OS X/ARM (iPhone)
* New platform: Haiku/i386
Compiler:
* Support for Delphi-style resource handling
* Whole-program optimization infrastructure, which initially supports
program devirtualization and unused virtual method removal
* Much faster compilation of units containing many type-sections
* The ability to suppress individual hints/warnings/notes
* Several improvements to the DWARF debug information generation
* Fixes to the generics support
* Fixes to the interface delegation (implements) support
* Improved cpu register allocation
* Improved ARM/EABI support
RTL:
* Linearly scaling multi-threaded memory manager
* Support for (advisory) file locking on Unix-based platforms
when using the SysUtils file creation/opening routines
* Support for ANSI ISO Extended Pascal ReadStr/WriteStr
* A UnicodeString type that, while not yet equivalent to Delphi 2009's
UnicodeString type, offers reference counted UnicodeString support on
the Windows, Linux, Mac OS X, FreeBSD and Beos/Haiku platforms.
Packages:
* Many improvements to the XML units
* Many improvements to the database units
* Updated the common Mac OS X Pascal interfaces to r241, including
header a translation of the CFNetwork framework
* The zipper unit now works correctly on big endian platforms
See http://bugs.freepascal.org/changelog_page.php for the list of reported
bugs which have been fixed in this release.
**
What's New in 2.2.3
**
Free Pascal 2.2.3 contains many bug fixes and some new features. The
main purpose of this release is to fix problems reported with FPC 2.2.2.
Please also see http://wiki.freepascal.org/User_Changes_2.2.4 for a list
of changes which may affect the behaviour of previously working code, and
how to cope with these changes.
Some highlights are:
All:
* Experimental packages-installation tool
Packages:
* Added support for TIFF reading/writing in fcl-image
* Improvements and fixes in CHM support
* Fixed linking the gtk2-package with gtk versions above 2.13.4
IDE:
* Added support for CHM help files
Documentation
See http://bugs.freepascal.org/changelog_page.php for the list of reported
bugs which have been fixed in this release.
**
What's New in 2.2.2
**
Free Pascal 2.2.2 contains many bug fixes and some new features. The
main purpose of this release is to fix problems reported with FPC 2.2.0,
and to remove all potentially tainted code from our source code base.
Please also see http://wiki.freepascal.org/User_Changes_2.2.2 for a list
of changes which may affect the behaviour of previously working code, and
how to cope with these changes.
Some highlights are:
All:
* All code potentially infringing on CodeGear copyrighted code has been
reimplemented using a cleanroom approach.
Platforms:
* Incompatibilities with Mac OS X 10.5's new default linker have been
resolved.
Compiler:
* PIC support for Mac OS X (on by default, disable with -Cg-)
* several bugs in the experimental generics support have been fixed,
but this feature is still in beta
* initialisation and finalisation of shared libraries has been fixed
for all Darwin platforms, and for Linux/i386
* support for {$packset x} directive to enable set packing
(use {$packset 1} for Delphi-compatible sets, but note that the
format is different on little and big endi
Re: [fpc-other] Re: [fpc-pascal] Apple forbids fpc applications on iPhone
In our previous episode, Henry Vermaak said: > > simply infeasible, not to mention stupid). In that utility they can either > > check for some signature code that their compilers generate, or per > > identified other compiler/framework add a check for signature code/data > > generated by that compiler/framework. > > So then I guess fpc can fake it? The whole thing just seems so absurd. That amounts to a constant cat-and-mouse game, requiring vast resources. Jonas: what are your plans regarding this? Formally (e.g. on the FPC website) publish the end of IPhone support? (starting with 4.0 at least?) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Apple forbids fpc applications on iPhone
In our previous episode, Henry Vermaak said: > > But that doesn't make sense what they write - A C program can be written by > > hand and by a generator. It's still a C program. No difference from the > > outside view. ?! > > Exactly, it's absurd. The worst thing about this fiasco is that > people aren't even surprised that this happened. For me the carbon deprecation, making it COCOA and thus primarily Objective C only was the writing on the wall. And not just for IPhone. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] compsci drops C (recommends Pascal/Delphi)
http://www.theregister.co.uk/2010/05/12/aqa_c_php/ many universities thinking about Java too? Ok, enough fun; who planted this ?? :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12y
In our previous episode, Graeme Geldenhuys said: > > The main goal is implementing stuff we care about. If Delphi already > > implemented > > something similar, then unless there is an extremely good reason for doing > > things > > differently, it is stupid to implement it in a different way simply because > > "you > > don't want to follow Delphi": > > This brings me to another question. Don't you guys feel that FPC is > good enough to stand on it's own feet. As far as I know it always has ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
In our previous episode, Felipe Monteiro de Carvalho said:
>
> It seams to me that they only standarize the language itself,
> something which could be done adding a {$Mode ExtPascal} or something.
>
> Having said that, think that Object Pascal as we know it should also
> have a standard.
Such discussions have raged several times. But most good standards are the
result of a multi-vendor effort, usually under the pressure of their
customers. (like the ansi C and POSIX standarization)
Unilateral standards rarely make sense, since the single vendor can deviate
from them at any time, and might not even implement it fully (e.g. OOXML)
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-devel] Parallel processing in the compiler
In our previous episode, Henry Vermaak said: > > how it should integrate with Windows, and how it should handle > > LineEnding characters etc. ?Nothing difficult about it, and the tools > > included work just fine. > > Yes, I'm talking about msysgit. It installs a whole msys tree, which > I am not interested in, as I've explained above. Perhaps I'll try and > build git inside my own msys. I have no idea why they just didn't > integrate it - I'm sure there must be a reason. Afaik, like cywin, msys has also started with keeping a global state. It might be possible that recent builds of GIT have problems with installing multiple versions (or just moving them), while olders (that Graeme uses) didn't. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
In our previous episode, Hans-Peter Diettrich said: > > To implement a complicated feature, you need to break down the > > implementation into a lot of patches to make it easy for review. > > This is a contradition, IMO. Big changes can not always be broken down > into smaller steps, when the result only compiles after a lot of such > small steps have been taken. [Wasch mich, aber mach mich nicht na? ;-] True. But then the corresponding advantages must be that much bigger. And more certain. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
In our previous episode, Adem said: > I don't mind the filter; this is life, it happens, > > But, I must say I am disappointed at the lack of management skills. You should ask yourself how management skills work in a community where nobody can force work on sb else. Graeme's last mail where he explains he just wants to drop quick and dirty patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, explains the fundamental misconception better than I could do here. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
In our previous episode, Adem said: > >> > >> But, I must say I am disappointed at the lack of management skills. > > You should ask yourself how management skills work in a community where > > nobody can force work on sb else. > > > It takes an infinite amount of patience. Yes. Forever, since it won't happen. Specially if the workpressure is increased several magnitudes because people don't bother to put in some minimal effort to present their work. > To conserve some of that patience for the real important things, it's > probably best for a manager/leader not to enter into nit-picking > discussions. I don't see why nto. > At times like these, I read 'Linus on kernel management style' [ > http://lwn.net/Articles/105375/ ]. I don't care what Linus says. (either the Snoopy or the penguin one). But I'm pretty, pretty sure, that Linus will throw back a bad patch in your face. > > Graeme's last mail where he explains he just wants to drop quick and dirty > > patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, > > explains the fundamental misconception better than I could do here. > Personally, I find it more useful to focus on the solution Graeme found > for himself and not on the complaints which must have grown out of > frustrations. I don't know what this means. Please answer to the actual quote. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
In our previous episode, Graeme Geldenhuys said: > > Graeme's last mail where he explains he just wants to drop quick and dirty > > patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, > > explains the fundamental misconception better than I could do here. > > And here I thought that is what a detailed commit log is for. Correct > me if I'm wrong, but it seems the norm of SubVersion users is to give > one liner commit comments. That is just wrong. The normal in Git > repositories, well at least git.git repo and our company repos, is to > give a much more detailed commit message. Makes applying patches a > breeze, as well as when you have no review a old commit. I don't understand what providing quick and dirty patches that are not cleansed in the bug tracker has to do with a VCS. Either SVN, GIT or etching sources into metal plates. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] News on Delphi x64
In our previous episode, Florian Klaempfl said:
>
> Actually sizeof(integer)=sizeof("alu register")
>
> There where multiple reasons why we left sizeof(integer)=4 on 64 bit
> architectures:
> - changing the size of data types always breaks a lot of existing code
> - sizeof(int) on Windows 64 bit is 4 as well
> - using 16 bit ints on i386 had a performance penalty while using 32 bit
> ints on x86-64 has none
> - there are probably a few applications which benefit from
> sizeof(integer)=8 instead of 4
> - code depending on sizeof(pointer)=sizeof(integer) might be broken
> anyways and it doesn't apply to 8 bit systems either (e.g. avr) or even
> TP, see above
See also http://www.stack.nl/~marcov/buildfaq/#toc-Section-5.1
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Typo in docs
In our previous episode, Jason said: > > http://www.freepascal.org/docs-html/ref/refsu60.html#x137-14700011.4.6 > > It looks like this line got truncated: > Writeln (?AnsiString, value :?,AnsiString(Args[I].VAnsiStr > > Should be: > Writeln (?AnsiString, value :?,AnsiString(Args[I].VAnsiString); Indeed it does. Fixed in the SVN version of the doc sources. Thanks. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] old installer
In our previous episode, P?ter, Bugledits said: > I'm searching for old 1.X (official) FreePascal installers for all > platform, especially for DOS (go32v1 and go32v2), OS2, win32 and > linux. But I can't found installers older than version 2.X. Can you > help me, where can I find these installers? All versions before 2.2.2 were retracted due copyright issues. The go32v1->go32v2 change happened years before 1.0.x. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: fpc-other Digest, Vol 62, Issue 1
In our previous episode, Mark Morgan Lloyd said: > > > > He unsubscribed from all FPC lists immediately after he sent his last > > message. > > Highly regrettable, but at least it happened /before/ all of the mailing > lists etc. were transitioned to a system which the core project > maintainers didn't understand and might not be in control of. > > That's not to say that the current system is perfect, in particular I > think that everybody agrees that better integration of forums and > mailing lists would be a Good Thing. Personally, I think the whole discussion has to be too tools centric. Content, that matters. That is not to say that the current website doesn't have problems (a TCL dependency to regenerate the makefiles, and the generator tool has a custom cwstring that needs regular fixing). IIRC I can't currently run all of it on FreeBSD, so I actually update the website from a work fedora machine. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: fpc-other Digest, Vol 62, Issue 1
In our previous episode, Jonas Maebe said: > > Highly regrettable, but at least it happened /before/ all of the mailing > > lists etc. were transitioned to a system which the core project > > maintainers didn't understand and might not be in control of. > > I don't think he ever insisted on that, and even if he did, that would > never have happened. He was offering to help, not threatening a hostile > takeover. As Tomas said, his proposal would have been a good candidate > for replacing the broken community site. Why run a separate forum from Lazarus? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Free Pascal 2.6.2 rc1
Hello, We have placed the first release-candidate of the Free Pascal Compiler version 2.6.2 on our ftp-servers. You can help improve the upcoming 2.6.2 release by downloading and testing this release. If you want you can report what you have done here: http://wiki.freepascal.org/Testers_2.6.2 Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.2 Downloads are available at: the FTP server at ftp://freepascal.stack.nl/pub/fpc/beta/2.6.2-rc1/ Enjoy! The Free Pascal Compiler Team Free Pascal Compiler Version 2.6.2rc1 ** What's New in 2.6.2rc1 ** Free Pascal 2.6.2rc1 is a point release from the 2.6.0 fixes branch. Please also see http://wiki.freepascal.org/User_Changes_2.6.2 for a list of changes that may affect the behaviour of previously working code, and how to cope with these changes. Some highlights are: Compiler: * Improvements and fixes for the ARM architecture Packages: * New package fpindexer (indexing engine) * Support for observer pattern added to fcl-base (and base classes in RTL) * Lots and lots fixes and improvements for fcl-db * Support for JSON dataset added among others * Fixes and improvements for fcl-passrc (and fpdoc) * Updates for PTCPas and gtk2 * fpmkunit improvements (better support for future switch to fpmake) * Several fixes for x11 * Several fixes for winunits (and winceunits) Platforms: * Improvements to the NativeNT target (newly introduced as alpha in 2.6.0) * Many fixes for OpenBSD and NetBSD (considered in beta state now) * Internal ELF writer supported for more BSD targets * Fixes and improvements for gba and nds See http://bugs.freepascal.org/changelog_page.php for the list of reported bugs which have been fixed in this release. ** What's New in 2.6.0 ** Free Pascal 2.6.0 is a new major version of the Free Pascal compiler. Please also see http://wiki.freepascal.org/User_Changes_2.6.0 for a list of changes that may affect the behaviour of previously working code, and how to cope with these changes. Some highlights are: Platforms: * iPhoneSimulator target Compiler: * Many new language features: * Objective-Pascal dialect, supported on all Mac OS X and iOS targets * constref parameter modifier for "const by reference" * Pascal boolean types with multiple sizes (boolean16/32/64) * ISO 7185 language mode (except for I/O). Features amongst others: * nested procedure variables * non-local goto's * Mac Pascal mode improvements * nested procedure variables * univ modifier * Intrinsics * sar (shift arithmetic right) * bsf/bsr (bitscan forward/reverse) * Delphi compatibility mode improvements * Nested types, class variables and class local constants * Advanced records syntax (no constructors yet) * (for..in) Enumerators in records * Class and record helpers * Generic records, arrays and procedural types * Delphi-compatibility of generics improved * Scoped enumerations * Custom messages for "deprecated" directive * Ability to use "&" for escaping keywords * New ARM code generator features * ARM VFPv2 and VFPv3 floating point unit support * Thumb-2 support Packages: * Many improvements to the rtl * Many improvements to the database units (fcl-db) * Objective-Pascal interfaces to Foundation, AppKit, CoreData and WebCore * OpenGL headers updated to OpenGL 4.0 Details about these new features can be found at http://wiki.freepascal.org/FPC_New_Features_2.6.0 See http://bugs.freepascal.org/changelog_page.php for the list of reported bugs that have been fixed in this release. ** What's New in 2.4.4 ** Free Pascal 2.4.4 contains most library fixes from early June 2010 till March 2011. There are also some compiler fixes, mostly relating to 64-bit. Please also see http://wiki.freepascal.org/User_Changes_2.4.4 for a list of changes which may affect the behaviour of previously working code, and how to cope with these changes. Some highlights are: Packages: * Many improvements to the XML units * Many improvements to the database units. * Specially sqlite got quite some fixes. * Many improvements to the chm units. * Including a commandline CHM compiler * Many improveme
[fpc-other] FPC 2.6.2 released!
Hello, Finally, FPC 2.6.2 has landed. FPC 2.6.2 is an update to 2.6.0 that contains most library progress in 2012 and some crucial compiler fixes, as well as a few new targets. Building is still in progress and some formats (deb,rpm) and targets might not be available yet. Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.2 For Downloads, please use the FTP server at ftp://freepascal.stack.nl/pub/fpc/dist/2.6.2/ and sourceforge https://sourceforge.net/projects/freepascal/files/ as much possible. Enjoy! The Free Pascal Compiler Team Free Pascal Compiler Version 2.6.2 ** What's New in 2.6.2 ** Free Pascal 2.6.2 is a point release from the 2.6.0 fixes branch. Please also see http://wiki.freepascal.org/User_Changes_2.6.2 for a list of changes that may affect the behaviour of previously working code, and how to cope with these changes. Some highlights are: Compiler: * Improvements and fixes for the ARM architecture Packages: * New package fpindexer (indexing engine) * Support for observer pattern added to fcl-base (and base classes in RTL) * Lots and lots fixes and improvements for fcl-db * Support for JSON dataset added among others * Fixes and improvements for fcl-passrc (and fpdoc) * Updates for PTCPas and gtk2 * fpmkunit improvements (better support for future switch to fpmake) * Several fixes for x11 * Several fixes for winunits (and winceunits) Platforms: * Improvements to the NativeNT target (newly introduced as alpha in 2.6.0) * Many fixes for OpenBSD and NetBSD (considered in beta state now) * Internal ELF writer supported for more BSD targets * Fixes and improvements for gba and nds See http://bugs.freepascal.org/changelog_page.php for the list of reported bugs which have been fixed in this release. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Goodbye, and thanks for the fishes
In our previous episode, Mark Morgan Lloyd said: > But I suppose all this begs the question: if one decides not to use > Object Pascal, what are the viable alternatives? While hobbywise, I won't let go of FPC (and Wirthian languages) that quickly, professionally it is different. Currently, for me it is not really a problem (small company, my preference has the most weight), but there was some discussion a while back of hiring more programmers and cooperating with certain other (SCADA like) companies, so there was some discussion. In my case the only viable alternative is C++, but I'm somewhat embedded with a bit of realtime requirement. Sometimes I think it would be easier even now, but I have previous MFC experience, and that still scares me a bit. (IOW, if you go back to C++, what will you use as GUI?) In my previous job, I was more standard business apps, and then the only viable alternative is C# IMHO. One doesn't have to like it, but if I'm leaving Pascal because it is too tiring to defend being in a niche, then you won't pick up some other niche, and the above are (to me) the only viable choices. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Goodbye, and thanks for the fishes
In our previous episode, Mark Morgan Lloyd said: > > Currently, for me it is not really a problem (small company, my preference > > has the most weight), but there was some discussion a while back of hiring > > more programmers and cooperating with certain other (SCADA like) companies, > > so there was some discussion. > > The SCADA package we inherited was written in a bastard mix of three > versions of MS C, plus a spreadsheet in MS Pascal and assembler > interfaces to an IBM communications controller. I replaced it by Delphi > code with PostgreSQL as backend, and am completely impenitent. As said, now it is not so much of an issue, but in my last job I got tired of every problem being blamed on Delphi and having to defend it, or worse, by default have to step up and fix it. That's the problem. Constantly having to defend it, having to deal with all your suppliers, and beg them for plain C API dlls, for examples (simple and console based so you can port them) etc etc. Not if you can do it, or if it is technically sane. In my currently job I'm the only programmer (though my boss is also somewhat able in that department), so that is less of a problem, at least Delphi has become even more of an island, or become totally backwards incompatible. OTOH, the lack of progress is bothering me. The fact that generics still don't do inline for instance. > > In my previous job, I was more standard business apps, and then the only > > viable alternative is C# IMHO. > > > > One doesn't have to like it, but if I'm leaving Pascal because it is too > > tiring to defend being in a niche, then you won't pick up some other niche, > > and the above are (to me) the only viable choices. > > But is MS really committed to C# and .NET, and if not could it drown > Mono etc. out of spite? Which leaves C++, which as I see it has the same > issues as Object Pascal except that lots more people use it. For pure businessprogramming, I think the chance that MS gives up C++ and the parts that belong to it (MFC) are way, way higher than MS giving up C#/.NET. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
In our previous episode, Sven Barth said: > > (reply-to set to fpc-other since this is getting off-topic) > Does not seem to work for Thunderbird... ^^ Use a decent mailclient, like ELM :-) > > But I never used the startmenu much in the first place, and I consider it an > > anti RSI measure (if you miss the startmenu in the default location, you > > probably use the mouse too much :-) > > > For me it's less the location of the startmenu (I'm mostly using the > keyboard for startmenu navigation btw.), but the fact that the Windows > Key opens that fullscreen abomination of that "metro desktop" instead of > a little window in some corner. I had that in the beginning too, and my usage pattern was the same too. Don't get me wrong, I still think it is all annoying, but there are workarounds to make it more bearable. I work with disappearing menu-bar, and I used windows key to pop it up. In most cases you can use win-T now, but that is less comfortable when standing next to a machine with the kbd in your hands. Most manual navigation in the start menu I did to get to the control panel, but I now get there via the new key combo win-I [enter]. I miss however configuring the startmenu to auto-expand network connections and have an easy kbd way to browse to them. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
In our previous episode, Marco van de Voort said: > > > But I never used the startmenu much in the first place, and I consider it > > > an > > > anti RSI measure (if you miss the startmenu in the default location, you > > > probably use the mouse too much :-) > > > > > For me it's less the location of the startmenu (I'm mostly using the > > keyboard for startmenu navigation btw.), but the fact that the Windows > > Key opens that fullscreen abomination of that "metro desktop" instead of > > a little window in some corner. > > I had that in the beginning too, and my usage pattern was the same too. > Don't get me wrong, I still think it is all annoying, but there are > workarounds to make it more bearable. Another fun fact, I was wondering why occasionally my win8 PC would wakeup during the night. Turns out it auto-wakes to do "maintenance", and the option to enable it is not in power options, but 3 levels deep in "action center". It probably assumes that all PCs are configured to go to sleep after a while, but since the settings are not next to eachother, if you disable auto-hibernation, your machine will just wake up and stay on forever. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Free Pascal 2.6.4-rc1 released!
Hello We have placed the first release candidate of the Free Pascal Compiler version 2.6.4 on our ftp servers. You can help improve the upcoming 2.6.4 release by downloading and testing this release. If you want you can report what you have done here: http://wiki.freepascal.org/Testers_2.6.4 Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.4 Downloads are available at the main FTP server and ftp://freepascal.stack.nl/pub/fpc/beta/2.6.4-rc1/ Enjoy! The Free Pascal Compiler Team Free Pascal Compiler Version 2.6.4rc1 ** What's New in 2.6.4rc1 ** Free Pascal 2.6.4 is a point release from the 2.6.0 fixes branch. Please also see http://wiki.freepascal.org/User_Changes_2.6.4 for a list of changes that may affect the behaviour of previously working code, and how to cope with these changes. Some highlights are: Compiler: Packages: * Lots and lots fixes and improvements for fcl-db * web and json packages synchronized. * improvements to the chmcmd compiler. * Several fixes for winunits (and winceunits) Platforms: See http://bugs.freepascal.org/changelog_page.php for the list of reported bugs which have been fixed in this release. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] FPC 2.6.4 release!
Finally, FPC 2.6.4 has landed. FPC 2.6.4 is an update to 2.6.2 and 2.6.0 that contains most library progress over the 2.6.2. It will probably conclude the 2.6.x branch. Building is still in progress and some formats (deb) and targets might not be available yet. Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.4 Due to issues with mirroring, please use sourceforge as much as possible, http://sourceforge.net/projects/freepascal/files/ or the main (Hungarian) FTP server at ftp://www.hu.freepascal.org/pub/fpc/dist/2.6.4/ We hope the freepascal.stack.nl mirror will come into sync again in the coming days. Enjoy! The Free Pascal Compiler Team Free Pascal Compiler Version 2.6.4 ** What's New in 2.6.4 ** Free Pascal 2.6.4 is a point release from the 2.6.0 fixes branch. Please also see http://wiki.freepascal.org/User_Changes_2.6.4 for a list of changes that may affect the behaviour of previously working code, and how to cope with these changes. Some highlights are: Packages: * Lots and lots fixes and improvements for fcl-db * web and json packages synchronized. * improvements to the chmcmd compiler. * Several fixes for winunits (and winceunits) Docs: * Many additions * fpjson documented. See http://bugs.freepascal.org/changelog_page.php for the list of reported bugs which have been fixed in this release. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] SuperPascal and FPC: a gross calumny :-)
In our previous episode, Mark Morgan Lloyd said: > According to http://en.wikipedia.org/wiki/SuperPascal#Implementation, > Per Brinch Hansen's SuperPascal can by compiled by GNU Pascal but not by > FPC. Does anybody have time to look at this (I certainly don't right now). I did, and it compiles fine with trunk and -Miso. (2.6.x has this mode already but it is less complete than trunk) It needs slightly more modifications than GNU Pascal, but probably that is because GPC accepts "C" preprocessor commands and extended pascal reset/rewrite statements also in iso lev 1 mode. (probably you need pass some "strict" flag to get GPC to error on that). All things needing fixing were marked in the original source as non standard except for the C preprocessor (probably because it is considered part of the build process, not the dialect) I updated wikipedia with the needed modifications. > The source is apparently available as a shell archive at > http://brinch-hansen.net/software.shar, which implies that it would be > easiest to start on a unix (rather than Windows) system. I routinely install cygwin with the complete "archiver" section on Windows machines, and I had unshar readily available without additional actions. A habit that saves a lot of time :-) The "clock" problem is easily fixed on Windows by using gettickcount. (which matches the description of time in ms, though maybe not relative to what) I zipped the whole shebang and put it on http://www.stack.nl/~marcov/superpascal.zip ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Pascal and GCC: ancient history
In our previous episode, Ralf Quint said: > And then went on to write the abomination called EMACS... Well, EMACS is a great OS, it's just a shame that the editor sucks :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] PROLOG written in Pascal
In our previous episode, Mark Morgan Lloyd said: > Is anybody interested in a PROLOG interpreter written in Turbo Pascal, > plus a couple of typeset articles which outline how it works internally? > > When I found it I was wondering whether it could be usefully used to > handle inference rules in a Delphi/FPC/Lazarus program, in the same way > that MS use Prolog for some of their network configuration stuff. > However it turns out that it is coded explicitly for Turbo Pascal with a > garbage collector on top of the normal heap, which I think implies that > porting it to FPC would need either a mark/release facility or multiple > heaps which could be "thrown away" when no longer needed. I don't understand why interested people couldn't implement mark/release for the base TP compatible level of FPC ? What is so different between TP and FPC there? Of course it wouldn't scale, but TP didn't scale further than 16MB anyway (64MB with 386 tricks). Basically you only need an own heapmanager that allocates all allocations in-order from a 16MB block, and mark and release procedures that call that heapmanager and are declared in some unit preloaded wiht -Fa? > I was reminded of this by the discussion elsewhere on refcounted > objects, which would obviously be another way to do it. Timothy Budd's > book on Leda gives an interesting example of using the unification > operation which underpins Prolog to process graph structures. Prolog is an interpreter, and I assume its structures are movable. Native languages allocations usually aren't. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] PROLOG written in Pascal
In our previous episode, Hans-Peter Diettrich said: > > I don't understand why interested people couldn't implement mark/release for > > the base TP compatible level of FPC ? What is so different between TP and > > FPC there? > > Perhaps it's the effort to support it for multiple architectures? Afaik only if you try to optimize it it gets OS and arch specific. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] PROLOG written in Pascal
In our previous episode, Mark Morgan Lloyd said: > > I don't understand why interested people couldn't implement mark/release for > > the base TP compatible level of FPC ? What is so different between TP and > > FPC there? > > > > Of course it wouldn't scale, but TP didn't scale further than 16MB anyway > > (64MB with 386 tricks). > > > > Basically you only need an own heapmanager that allocates all allocations > > in-order from a 16MB block, and mark and release procedures that call that > > heapmanager and are declared in some unit preloaded wiht -Fa? > > The main issue is that dynamic memory is used by the Prolog > implementation in several different ways. The first way is that as rules > are being entered, they go into memory and usually stay there. The > second way is that as queries are evaluated a lot of temporary stuff > (variable bindings etc.) is put into memory, this is all thrown away on > completion. The third way is that during query evaluation, rules could > potentially be added/deleted/changed which shouldn't be thrown away. How does this work in TP? Mark/release would remove all variables, not just the temprary ones. Or are the persistent and temporary orders not mixed, and is only the temporary part under mark/release? > I think that in practice this could be handled by normal OO techniques, > since these days the amount of (virtual) memory is significantly larger > than typical embedded problems. If somebody wanted to e.g. process the > entire collection of Wikipedia titles and categories as a set of rules > then they should probably be using specialist tools. (in case it wasn't clear, the problem is that mark/release either requires memory to be available as one contageous block. There is no guarantee that an existing block can be expanded later, so you need to allocate it up front (the 16MB above). To work around it, in theory one could allocate a new heap on every mark (if free mem< a certain threshold), and maintain a linked list of blocks that are scanned through for mark/release operations, but that is (1) costly, so you would need to pace your mark/releases (2) you still need an upper limit. If address space is large enough (read: 64-bit) you might only reserve relatively large blocks, regardless of much you use. > >> I was reminded of this by the discussion elsewhere on refcounted > >> objects, which would obviously be another way to do it. Timothy Budd's > >> book on Leda gives an interesting example of using the unification > >> operation which underpins Prolog to process graph structures. > > > > Prolog is an interpreter, and I assume its structures are movable. Native > > languages allocations usually aren't. > > Up to a point. A typical Prolog implementation acts as an interpreter > since rules and queries are entered interactively, however the > underlying unification algorithm can equally well be embedded in > compiled code My point is more that if the prolog interpreter can move its allocations so that the program remains working IOW if I do mark new(persist); new (temp); <--- release can I run a routine at the <--- point that moves all persistent allocations from the block of mark..release to a new or existing, persistent heap? Does it keep track of what is temp and what is persistent? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Use of ARC
In our previous episode, Hans-Peter Diettrich said: > > 1) ARC has been introduced in Delphi for *mobile* platforms (only), so a > discussion of its impact on such (small) targets is useless. I'm not > sure which requirements of such platforms make ARC inevitable or > desireable, but I suspect that it's not only Delphi compatibility that > suggests such a feature. We should know more about the Delphi rationale > for adding ARC! > > 2) I'm not sure whether ARC will really simplify things, as opposed to > traditional coding techniques. As long as Delphi restricts ARC to > specific targets, I see no real pressure to implement ARC in FPC for > *all* targets at once. I think ARC is mostly driven by the Mac side of things, keep in mind that Delphi mobile started as iOS only. I wouldn't start moving in that direction till there are clear signes that Embarcadero wishes to lift this to the general suite. > 3) I don't think that ARC can be safely implemented at compiletime only. > Every chance for zombies or premature destruction is a show stopper for > every ARC implementation, or for ARC at all. > > 3a) Instead I'd vote for a dynamic implementation, as with Interfaces, > by adding a refcount field and (virtual?) counting methods to TObject. > This overhead should be acceptable, just like for other managed types > (dynamic strings, arrays...). Adding dynamic strings and arrays did not make older (short-) strings and static arrays obsolete or slower, so IMHO this is strange analogy. Because that is the problem with integrating it deeply, there is no escape anymore from the overhead. Personally if we must go that direction (which I'm definitely against, since I fail to see the point, both wrt direct benefits and delphi compatibility), it should be IFDEFed in the RTL, and work with a two RTL system and compiler switch. IOW do it delphi compatible and have two independent versions :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Google Code closing down
In our previous episode, vfclists . said: > Now Florian, considering your preference for GUI tools, won't the > development of cross platform Git GUI surpassing Tortoise Git, Github and > Atlassian's tools, SmartGit and whatever be the best advert for Lazarus and > FPC? There would such a major flow of patches coming in that you would have > to stop coding actively and review the patches going in like Linus does. Yeah, and I have interesting property on the moon to sell. I've a feeling you are the perfect guy for it :-) Arguments on "change your infrastructure like this and the hordes will come" are considered with very big scepticism. Call it Voort's law if you will. Since somehow those hordes never materialize. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Google Code closing down
In our previous episode, Graeme Geldenhuys said: > > A better metric might be finding somebody who offers a selection of VCS > > protocols (possibly with a common backend- I believe such things exist?) > > and then looking at the relative use for checkouts etc. > > You can start by looking at the following Wikipedia page > > http://en.wikipedia.org/wiki/Comparison_of_source_code_software_hosting_facilities > > See the "Popularity" section. GitHub sits and 19.8mil projects. If you look on the github referenced page, its repositories, not projects. The translation to projects is wikipedias own. The fact that github+gitlab projects >people and by others the other way around should ring a bell. I get the feeling these stats are meaningless because github has a large excess of personal repositories that skews stats, while sf was more collaboration oriented. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Anybody using ultra-wide or square monitors for programming?
In our previous episode, Graeme Geldenhuys said: > Or something like the Eizo FlexScan EV2730Q which is a 27" 1920x1920 > resolution monitor. Giving you back that critically important vertical > space we lost since wide screen monitors got introduced. > > http://www.eizoglobal.com/products/flexscan/ev2730q/index.html > > I really like the idea of the Eizo square monitor. Anybody using any of > these (or similar) for programming? I use a 27" Ilyama Prolite fullhd screen rotated to portrait with a secondary fullhd screen (a cheaper one) for the few cases that rotated dimensions are annoying for about half an year now. I'm quite happy about the setup. (for work at home, Delphi, Windows) Not just the programming benefits, but also e.g. PDF reading (specs, datasheets) is improved. It is just a matter of learning the keybindings to toss apps quickly between screens for e.g. design work that needs the full width. If the landscape screen is not in use, I usually have a notepad with notes or so open in it. Lazarus is even easier than Delphi, since it has no sidebars to hide or make autohide. Just make whatever you don't need floating again, and use F11 etc to pop them up again. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Anybody using ultra-wide or square monitors for programming?
In our previous episode, Graeme Geldenhuys said: > On 2015-03-22 20:54, Marco van de Voort wrote: > > I use a 27" Ilyama Prolite fullhd screen rotated to portrait with a > > secondary fullhd screen > > Would you mind sharing a photo of you screens with the apps laid out in > the usual way you work? Well, Delphi on the portrait screen on the right, and a big notepad on the left landscape one ? :-) The virtual desktop connects both screens at the top, so the landscape right side connects to the upper 1080 lines of the left side portrait mode. I use the same virtual desktop arrangement under Windows and Linux. I was happy that it even survived an Ubuntu upgrade without reconfiguring. (radeon card with radeonsi driver) > Searching the net I see quite a few posts where they mention the same > layout as you. One vertial, one horizontal. But there seems to be a > mixed case between which monitor should contain the IDE (source code) etc. Well, my main reason for the portrait mode was vertical lines in the source editor, because before I had a 2048x1536 21" CRT. Going to fullhd (landscape) would have meant decreasing in vertical resolution, and other solutions were specialistic and high cost. Moreover, the portrait option wasn't that much extra, and I didn't like portrait, I could just put it in landscape mode. I only got the second lcd after I decided to keep the monitor in portrait mode. Some things to pay attention too: - if you care about USB HUB and audio functionality in your monitor, check that the connections are on a sane side (and not like my monitor 69cm above the desk in portrait mode:-) - The vertical viewangle (in landscape mode) of my monitor is a bit limited, so in portrait mode I really have to align it a bit towards me, instead of just flat against the wall. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] $100, 000 for C++ implementation of FPC's -CR option
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > Well, now all they need is a decent equivalent to Pascal's units (instead of > > relying on preprocessor hacks such as #include), > > Meet the C(++) Modules proposal: > http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf And Stroustrup is considering modules for C++17: http://www.infoq.com/news/2015/04/stroustrup-cpp17-interview ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] $100, 000 for C++ implementation of FPC's -CR option
In our previous episode, Nikolay Nikolov said:
> > http://www.infoq.com/news/2015/04/stroustrup-cpp17-interview
> Yes, I know about that too, but I'm still wondering why it took so long.
> C++ has an "everything but the kitchen sink" approach, where they
> introduce every programming language feature they can think of into the
> language (they had generics before everyone else, they have multiple
> inheritance, esoteric class inheritance modes ("protected inheritance",
> wtf), template metaprogramming, etc.), so it's surprising modules took
> so long.
I'm not deep in the C++ scene, Nico is probably better at answering this,
but if I would have to guess probably a matter of demand. Till now legacy
requirements outweight demand for a solution to this. Also because most C++
don't know or don't want to know the problems.
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Delphi may have Linux support next year
In our previous episode, Graeme Geldenhuys said: > > What might be interesting is if the Delphi command line compiler could run > > on AMD64 Linux, but that's yet to be seen. > > [I would assume your message is off-topic, so I set the reply-to of this > message to FPC-Other] Correct. > I doubt it will actually run on Linux, because then they would also need > a debugger, which then begs for an IDE to make debugging easier. So in > all likelihood, you would need a copy (and license) of Windows to > develop for Linux - just like you need for OSX/iOS development. Yes, it is a crosscompiler with their paserver remote debug solution. Also afaik the compiler is the same as for mobile targets, with probably the same limitations, and not the win32/win64 delphi compiler. > Just stick with FPC and have native tools for each platform. I see no > benefit of having Delphi these days. Delphi is outshined by Free Pascal > and Lazarus IDE for some years now. The debug experience under Delphi is still several times better than Lazarus. More expressions evaluate directly, and types are more easily browsed and inspectable (specially under D2010+ which has proper debug support for collection types) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Delphi may have Linux support next year
In our previous episode, Graeme Geldenhuys said: > > > Also afaik the compiler is the same as for mobile targets, with probably the > > same limitations, and not the win32/win64 delphi compiler. > > :-/ Note that I heard this when it first came on the roadmap. I haven't seen any confirmation/repitition of that tidbit in the newer rounds of roadmap news (this summer) yet. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Missing messages
In our previous episode, Graeme Geldenhuys said: > They even allow "limited commercial use" with it. I don't know the > details though. iirc up to Eur/$ 1000 turnover. I don't know if you can use it in a big corporation inhouse to send 3 values to your PLC via serial though (since how to calculate turnover in that case?) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git repository of FPC not syncing with SVN
In our previous episode, Victor Campillo said: > I mostly use Git to checkout FPC development and today I saw that the > Git repository created by Graeme is not in sync with Subversion since 6 > days ago. > Graeme, could you check the issue? Considering the date, that might be the 3.0.2 branching it choked on. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git repository of FPC not syncing with SVN
In our previous episode, Victor Campillo said: > > Considering the date, that might be the 3.0.2 branching it choked on. > > So, this means that 3.0.2 will be released soon or there will be an > another RC? Relatively soon, one or two weeks, depending how building goes, final, no RC2. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Anyone using Orange PI
In our previous episode, Mark Morgan Lloyd said: > > I agree. Most of our RPis are actually running Debian, but in extremis > it's always possible to roll back to Raspbian as a baseline configuration. > > There are of course other small boards: Olimex, Odroid and now Asus. > However RPi does offer a fairly flexible and cost-effective range, and > unless the OP is considering shipping hundreds rather than 10s of boards > I suggest that getting onto both the Linux learning curve and one for > minority hardware is quite simply not cost-effective. The problem is that rpi has no fast storage interface (like SATA), some of the more expensive orangepis have sata. (though I'm not entirely sure if it is not bridged via usb) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Orange Pi vs. Raspberry Pi vs Banana Pi vs ASUS Tinkerboard vs. Odroid
In our previous episode, Graeme Geldenhuys said: > The 1st gen Raspberry Pi had 256MB shared RAM (128MB for GPU and 128MB > for CPU). Later a 512MB model RPi v1 was also released. The 512MB model was called B+ iirc. The partitioning of the memory was a firmware setting and could be configured IIRC in 32MB block steps. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Your thoughts on cloud based server instances?
In our previous episode, Graeme Geldenhuys said: > > 100 bucks, I'm not complaining, since a standard T1 is only 1.54MBPS. > > Here in the UK they have been trial'ing 1Gbps fiber-to-the-home > connections in a single town for a couple months now. The rate is > ?30/month. I can't remember the exact upload speed, I think it was 100Mbps. In most Dutch cities too. I'm currently on 60/60mbps for 65 eur/month triple play. (fullhd TV, internet, telephone landline). 100mbps and higher speeds are also available. It is a bit expensive though, and I want to downgrade, but they seem to have abandoned their cheaper offerings. So probably back to cable again soon. P.s. the best thing about fiber is the latency and general reliability. (ssh's never time out) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How to set library search path ?
In our previous episode, Fred van Stappen said: > > Is it possible to set the search-path for library without to edit-change the > config file ? No, since then having a search path at all would provide no security value at all, since all "infected" programs could just change it. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Graeme Geldenhuys said: > As with any new applications or technologies, there is always some > learning curve (big or small). There are tons of bad habits ingrained in > SVN users. Those do not translate well to Git (thank goodness). Git > works fundamentally different to SVN (for the better). So you need a > change in mindset - some refuse, hence they struggle with Git. And then > wrongly blame Git for it. I fear this is most likely what happened with > Florian. That is your very colored view about it, that automatically declares non-gits stupid. However in the last discussion we showed you various faqs (like from LLVM and FreeBSD) that mirrored the FPC core teams. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Mark Morgan Lloyd said: > Now I don't deny for a moment that Git has its advantages for > distributed working. But am I correct in my understanding that it has > nothing that maps directly onto the monotonic revision list of > traditional VCSs including Subversion? Nope. There is only some hash, and various hacks to emulate with post commit hooks, which is not at all the same in behaviour. some info is at http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git merging, external repos were some of the other issues. (Potentially) solved issues since the previous discussion were repo dictated configuration (for linefeeds), and the ability to avoid certain branches to have multiple ends (thus leaving the next committer with the unenviable choice to wait or potentially make the situation even more complex). All from memory of ourse. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > Git just doesn't do KISS. > > You need an SVN server to start working with SVN. With Git, you go to a > directory, do "git init" and start committing. Everything is local. Not > sure how that's not KISS. (You can add a remote later, and then push to > it, with the full history intact. This remote can even be an SVN repo.) The previous discussions were about team use of GIT, to be specific, FPC core repo. The problem is that if problems get practical the advocatists suddenly step back and aren't really able to do more than regurgitate either the standard beginner "wisdoms" or "you shouldn't want this" or "this is the new improved ways" or similar platitudes. To get get back on track, I'll restate the question I posed in the last message unambigously: how to avoid that a push of member X doesn't leave a branch in an undesirable state that leaves member Y three choices: 1. push anyway and make the mess worse 2. hold the commit/push 3. clean the mess himself. In your own repository that is no problem, and even in companies this only takes only a few LART/cluebat applications to fix. However in distributed teams this is a pain. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > how to avoid that a push of member X doesn't leave a branch in an > > undesirable state that leaves member Y three choices: > > How to avoid that member X with commit write access doesn't leave a branch > in SVN in an undesirable state? :) You have to trust people, and choose > who you give write access to a given branch/repository, really. This > didn't really change and not an argument against git. Trust is that people are not deliberately doing things. For accidental things there are tools (except GIT, apparently) > And well, in Git you don't push, but people who want to contribute, have a > pull request. Then you can review that, and either apply to your tree or > reject it. It's important to understand that in git all repositories are > equal, and that I have a "make-amiga-great-again" branch, doesn't mean > that you should have it, I could still send a pull request against your > master branch, or whatever branch. All pull requests are just a set of > changes, really. Yeah, blabla, distributed, anarchy, world domination. I though I did mention I wanted practical info? > > 1. push anyway and make the mess worse > > 2. hold the commit/push > > 3. clean the mess himself. > > Well, ideally I was not asking for ideally. I was asking very specifically how a GIT in a FPC team group would work. And no, sending 40+ pull requests to all members of core does not count. So there is one golden repo and that is what I'm talking about. > easily. It's the responsibility of the maintainer of a given branch to > accept that pull request or not, or request further changes before its > accepted. So tool failure is fixed by throwing manpower at it? We don't have an approval person now, so a requirement to that would IMHO be a dealbreaker for GIT. > And talking about myself - as much as I enjoy just committing my crap to > trunk, I sometimes would really prefer review. Not because I'm not a > senior engineer, but especially because of that... Now if I don't want to > do a branch in SVN which are huge and expensive (Git branches are cheap > and small), I either have to commit it first anyway to trunk, then ask for > a review, or send a patch for review first in e-mail, which is quite > cumbersome. Plus there's absolutely no warranty, that I later commit the > same patch which was reviewed. I would like to have lots of extra manpower too, but I rather not spend it on what in practice would be rubberstamping commits (and delays in distribution till something is approved if the reviewers are AFK). This is exactly what I wanted to avoid with the primary case posed in this subthread: how to avoid blocking the central repo for commits (from a practical viewpoint) > At work, I don't even push against master, but I do a pull request against > my own repository, and ask one of my senior colleagues to review... I > don't know about you, but to me this sounds a lot more like teamwork, than > going around beating up people "for wrongdoing" with a cluestick. Then you don't understand what I mean. In the job you go see the person, work something out, and problem sorted in a few minutes. The odd impossible person is usually swiftly dealt with. In distributed, volunteer driven, projects, people are away/nonresponsive for extended periods of time, working hours (and days) don't match. Also working this out via mail is much less productive. > Of course in the end it's just like crypto - you need to have a chain of > trust from the top, a group of trustees who will do the actual merging of > the pull requests, reviews and then push it upstream/mainline/trunk. If > one of these maintainers do a bad job, then you need to sort out that > problem, but that doesn't mean the whole system is broken. It's similar to > giving commit access to a developer who doesn't deserve it in SVN, really. I know what an honor-system is. It doesn't protect against mistakes the day before holiday. Remember the old locking VCSes ? > Now, how the actual process would look with the FPC team, that's hard to > define at this point. But the tools are there for it. > > Was this a proper answer, or I was beating around the bush in your views? > :) Sorry to say, but I didn't find anything new or usable in this post. It is the standard "think different" nonsense from a very idealist viewpoint, little practical details. So I now give up this thread (and GIT). ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, nore...@z505.com said: > >> impossible person is usually swiftly dealt with. > > > > > Honestly, I can't even... You sound like the Expert Beginner Twitter > > account. No personal offense intended, but you just do. > > > > He's talking about Army of Programmers in a Building, an article I wrote > years ago ;-) > > Sometimes it's better to just walk over and talk to a real programmer in > a real building than it is to send some email over the christmas > holidays and wait 2 weeks for a reply for him to commit his changes.. > since he's in Barbados or Cuba on vacation. The scenario was based on older commercial VCS systems (VSS, that Team thing from Borland etc etc) that required explicit locking, and people would lock files, change some formatting and then go on holiday before their real work started. During that time nobody could make changes to those files, and even back then we already had some form of CI to a testserver that worked from the VCS, so that also hampered testing your own mods. Locks were notorious hard to break, and persons with the required rights were often also rare during those periods. And yes, if you did that, specially if the file was something central (like a file that listed all commands accepted by the command processor), people could get somewhat aggressive ;-) The DVCS scenario is not as bad, but some simple prevention of this would prevent some mistakes, and make the minefield for new devels a bit smaller, thus save a lot of annoyance on all sides. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
In our previous episode, nore...@z505.com said:
> Pascal and C are actually twin brothers with slightly different
> syntax...
>
> But my biggest hate for C is not C itself but just the one fact that it
> lacks strings.
That, and the fact that while (a=b){} goes through undetected. In general
it relies too much on symbols !^%&===?{}, etc etc. While that might be my
Pascal bias, I program C very regularly for over 10 years now, and I haven't
gotten used to it.
C also shares some of (IMHO) Pascal's failings, like not distinguishing
procedural end from other blocks "end" and complex blockstructure.
(different syntax for 1 and multi line blocks).
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Florian Kl?mpfl said: > > If you haven't found the Git project documentation on this workflow, I'll > > find it for you and post > > the URL. > > The workflow will not change. If the tool does not fit the workflow, it is > the wrong tool. Period. Even if we will change workflow more GIT like in time, the required leap of faith and transition is too large. I think the Git advocatists should focus more on a workable model for a transition and not some ideal in the far future. Even a limited change is already a massive operation, let's keep it managable. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How do you keep up with FPC discussions?
In our previous episode, nore...@z505.com said: > > How in the world do people (you) keep up with reading email lists and > not waste the entire day? Avoid the following - long discussions about new features -> design by committee was never successful anyway. - anything with "Schnell" and "unicode" - preferably anything with "huys" and 'git" :-) Seriously, just be selective, and use a threaded reader that allows you to skip/ignore threads. Speed read and if not interesting, immediately skip the lot. p.s. though I use ELM which isn't threaded, with "l" you can get a view of all msgs with one subject, which I use. For Lazarus for which I read much fewer threads I do use MUTT though. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Graeme Geldenhuys said: > On 2017-05-24 21:21, Marco van de Voort wrote: > > Even a limited change is already a massive operation, let's keep it > > managable. > > So how large is the FPC team really? I'm talking about active developers > on a day-to-day basis who have commit access to Trunk. ... > So this definitely doesn't convince me that compiler development is so > different to other projects. And definitely doesn't rule out that Git > couldn't work, or that an improved workflow couldn't be applied (freeing > up time in the long run). You are mixing up your replies. I only excluded the Linux kernel as model (since it was written to their workflow). BSD afaik still uses GIT, and like LLVM experiments but haven't moved to GIT. Actually infrequent committers make the change harder, since they spend a higher percentage of their freetime on the move :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Santiago A. said: > Workflows are designed according with the tools you had when you > designed it. Sometimes you improve your workflow as you improve your > knowledge of tools. And sometimes you create new tools to improve your > workflow. > > But sometimes other people create a new tools that improves the system > but requires a dramatic change of workflow for better. I know Changing > of mindset is never easy, but the attitude of "I won't change my > workflow" closes the doors to any improvement. > > Many projects are using Git, we are not talking about early adopters or > isnewisbetter guys. It has been tested in real world for several year, > and may projects are moving to it. So I would give it a second chance. > I'm doing so, in spite I'm not exactly a young boy and early adopter, I > can see some advantages in git easy branching and merging. > > Evaluate git and workflows again as for the first time, as if it were > the first time you have heard about it. Forget Graeme Geldenhuys, > sometimes he says things with manners that well, sometimes is looks > like seducing people is not among his virtues but the other way around > ;-), Take a new fresh look to Git. I've done so every time the discussion looks up. I also have some DVCS experience with Mercurial, and I still don't see it. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Florian Kl?mpfl said: > > donate a month of our time. > > Indeed, it depends on the person who does it. It requires knowledge about the > specific workflow > requirements of a compiler project. And that this is not easy is proven by > the fact that gcc as well > as llvm still use svn as canonical repository. They probably have a lot more > man power than FPC. So does FreeBSD, (though IIRC they also use Perforce internally), so even it is not pinacle of OS kernel development either :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Sven Barth via fpc-other said: > Of course the biggest obstacle is the building and running of the > testsuite. I think running the testsuite is a waste of time and cycles for anything outside compiler/ and rtl/. And even for half of the RTL. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] What makes a Compiler project (like FPC) special?
In our previous episode, Graeme Geldenhuys said: >Just to be clear, I'm not pushing Git here - I know you guys will >not change - Florian made that very clear. Yes, boundless leaps of faith are out of the question. Git should be a tool, not a religion. >But Florian's statements just bugged me, and I see no proof to >convince me otherwise - a compiler is just a complex project. >Nothing "special" as he claimed it to be. I do think Nikolay's point of it being more interconnected describes it fairly well. There are no narrow interfaces that are natural seams for modularization inside the compiler. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] What makes a Compiler project (like FPC) special?
In our previous episode, Graeme Geldenhuys said: > > Yet the ?packages? and ?rtl? directories is just that - which by the way > is part of the FPC project. Yes, except some of the parts directly connected to the compiler and its features (like exceptions, RTTI etc) > And that is also where most commits have been going - based on the history > I queried for the last 4-6 months. That overview is skewed by a high amount of work done on pas2js by Michael and Mattias. It is atypical, and strictly speaking pas2js is ALSO a compiler. Nikolay and Karoly (+ rest of Amiga committers) have been persistently high this cycle though. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Object Pascal Interface Delegation, but in Java
In our previous episode, Graeme Geldenhuys said: > > Does anybody familiar with Object Pascal and Java know if Java supports > something similar to Object Pascal's Interface Delegation "implements > syntax" functionality? That is often called delegation, and if you search for java and delegation, it seems not (which is not THAT surprising IMHO): https://stackoverflow.com/questions/2989005/delegation-example-regarding-java-context ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Object Pascal Interface Delegation, but in Java
In our previous episode, Graeme Geldenhuys said: > > That is often called delegation, and if you search for java and delegation, > > it seems not (which is not THAT surprising IMHO): > > Thanks Marco. So it is actually similar to Object Pascal where you use > object composition, but with Object Pascal's "implements" keyboard the > interface is automatic in the new class's interface. Where-as with Java > you have to define the interface and then delegate the calls to the > composition object. I'm sure Eclipse must have that code-generation > functionality built-in or an add-on that can do that. > > So Object Pascal is just a bit more convenient, but the end-result > (functionality) is the same in. Well, with Pascal's syntax you could link through VMT fragments, without actually bouncing through additional code. And you don't risk forgetting adding a method to existing classes if you add one to the interface, always a risk with manual workarounds like the codegeneration tools that assume everything is designed at once top-down and only then implemented. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Firebird vs PostgreSQL
In our previous episode, Santiago A. said: > That's my point. Why Firebird is not more popular? > > Once I read two point about Firebird lack of popularity: > * In early days, firebird documentation was almost inexistent, there > were a few .txt with new features but you had to rely on Interbase 6.0 > docs, that weren't very good either. So it looked like an almost > abandoned software maintained by a few fans. > * It had no administration tool, you had (and you still have) to rely on > third part tools. I think flamerobin is the administration tool "de facto" * it was x86 only for a long time. Which is why I ended up with postgresql, having powerpc and later arm servers. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] M$ has bought GitHub
In our previous episode, Graeme Geldenhuys said: > What a sad day it is. It seems that one day the whole Internet will be > owned and run my four companies: Apple, Google, Microsoft and Facebook. Well, there is always Amazon and Oracle :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] M$ has bought GitHub
In our previous episode, Graeme Geldenhuys said: > > Oh God, yes I forgot about those. Amazon is also spreading its tentacles > everywhere and with microphones (smart speakers) planted in every other > home. What is this world coming too? Everybody so eager to loose their > freedom and privacy. Seems Richard Stallman was right all along. Even the Stasi could never have dreamed of victims buying the devices they are eavesdropped by :-) Personally the whole github thing is a non story. Github was not making money and sooner or later the pushing towards from free towards premium services would have started. Now, if your company has Office 365, it might in the future also include github 365 :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] M$ has bought GitHub
In our previous episode, Mark Morgan Lloyd said: > > What a sad day it is. It seems that one day the whole Internet will beowned > > and run my four companies: Apple, Google, Microsoft and Facebook.I guess > > I'll be doing what the Free Pascal project has done all along...Host my own > > repositories and bug tracker. Less sh*t and in full controlor my work. > > I've had plans to move many of my projects off SourceForge to GitHubbecause > > of SourceForge's performance problems and frequent outages. Nowthat plan > > will NOT happen and I'll most likely start hosting my ownpublic > > repositories instead. > > Another problem with Sourceforge is the fact that they enthusiastically > block access to any country that's currently on the US government's > *hitlist. I don't know what Github's policy was on that but it's pretty > sure what MS's will be... which is absolutely correct in the context of > an American corporation, but not in the context of non-American users or > paying customers. Actually Microsoft is quite a large cloud provider, and can afford to partition its offerings and isn't as dependent on a single point (or continent) hosting as others. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
[fpc-other] Delphi 10.4
Some early info about new Delphi 10.4 features https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription 1 Language Server Protocol for Delphi 2 Language Enhancements: Managed Records 3 Unified memory management across all platforms my guesses: 1: no idea. 2: management operators for records, maybe also simple record inheritance to reuse e.g. a refcount record pattern 3: (also?) having some of the iOS refcounted classes system for the windows targets? ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Delphi 10.4
Op 2020-04-11 om 14:45 schreef Sven Barth via fpc-other: 2: management operators for records, maybe also simple record inheritance to reuse e.g. a refcount record pattern Yay me, we got something incompatible again... 3: (also?) having some of the iOS refcounted classes system for the windows targets? I personally think the other way round. But we'll see... Yes, some people on the Delphi forum also pointed me to https://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html so it seems that ARC is dodo. ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] ARM is the future of desktop
Op 2020-07-04 om 23:14 schreef Sven Barth via fpc-other: Here is an interesting article by a ex-windows boss. He thinks that in a few years even desktops will be ARM and Intel will be residual. And obviously it will be a mayor problem to Microsoft, whose software is very tied to Intel platform. https://www.zdnet.com/article/ex-windows-boss-apples-arm-based-mac-will-be-the-ultimate-developer-pc/ Windows 10 nowadays supports both ARM and ARM64, so I see no problem there. And it is from Sinofsky, who is considered to be good in the tech department, but bad in the visionary department (he was resposible for the tanked Windows 8 "vision", and Microsofts failed ventures in the phone and tablet world) ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] PostgreSQL index tuning
Op 25-9-2021 om 16:00 schreef Graeme Geldenhuys via fpc-other: Does anybody know if there is a tool I could use to analyse queries to a PostgreSQL database, so I could tune it's performance. eg: detect table scans in the execution plan, suggest creating, dropping or altering indexes etc. MS SQL server comes with loads of tools and options to do this, but I'm fairly new to using PostgreSQL as the data store, so not sure what tools are out there. Any suggestions would me much appreciated. The default postgres admin too "pgadmin" seems to have some query analysis that yields plan insights according to https://www.pgadmin.org/docs/pgadmin4/5.2/query_tool.html ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] I thought it was going to get better, but no
On 28-4-2023 23:20, Nikolay Nikolov via fpc-other wrote: After reading this email that I am replying to here, and revisiting the #fpc logs, the only conclusion I can make is that Nikolay Nikolov == "Joanna". Are you joking? I actually smiled. Let's just say that what I see from Joanna doesn't resonate at all with knowing Nikolay IRL. ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
