[fpc-other] What would your second language be and why?
Hi I thought that by asking this question here, I will get unbiased answers. My daytime job is secure and I am a very happy Object Pascal developers. I'm a firm believer in rather learning one language and being very proficient in it, that being a "jack of all trades, but master of none". I have learned and used my share of languages over the years, but prefer Object Pascal a lot more than any of the others. 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. >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. Anyway, I want to extend my skills in the new years and start learning a new language (make no mistake, Free Pascal is still what's paying my bills every month, and that's not going to change any time soon). My requirements is something that supports multiple platforms and that is one of the mainstream languages. I don't want to learn some obscure language 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. 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. * What's your thoughts between Java vs C#? * Have you got a better choice in mind and why? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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?
On Sat, Dec 6, 2008 at 12:48 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > First, on what primary grounds do you select the language? Commercial (iow > something to put on your resume) or technical skills? It's something I would like to put on my resume and that makes me employable in other areas. Make no mistake, my current job using Free Pascal is rock solid. Delphi / Object Pascal developers are scarce in this country, and I am the sole developer at the moment, plus I worked for this company before some years back. So our relationship is very good and trusting. So my choice for learning another language is not out of fear of loosing my job, it's simply my enjoyment of programming and wanting to learn new skills. I have used Object Pascal and Delphi for the last 10 years and thoroughly enjoyed it - and will continue using in for the foreseeable future. I've just rewritten our flagship product using Free Pascal and we have a lot more (smaller) projects in the pipeline. > But first, decide if you want to target larger or smaller companies. > Smaller companies are less rigid in their language ways. I'm not a big fan of large companies. Where I work now, we have around 35 employees. That's one of the largest "small" companies I worked for over the years. > So, the commercial angle. Well, blindly selecting, VB.NET or C# then. Maybe The project I just rewrote was partially implemented in VB6 (by me many years back). I sure hope VB.NET has improved on that? :-) > 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. I have worked for a few MS shops (abroad and local), but I'm really not a fan of MS. In South Africa the software companies are quite varied, though the open-source uptake is huge at the moment. > Don't try to rationalize a commercial decision with technical arguments. It > is pointless. You are correct on that point. :-) But I would still like to enjoy what I learn. ;-) > 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 That's a very good point. I don't know much about C#, but from what I have read, many people seem to agree on that point. As for the C language. I really enjoyed that (many many years ago). But since I got hooked on Delphi / Object Pascal, productivity has increased a lot and the syntax is just so much easier to read. So I doubt I would return to C any time soon. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] [fpc-pascal] Porting linux to pascal, would it be, possible ?
On Fri, Dec 5, 2008 at 5:19 PM, Skybuck Flying <[EMAIL PROTECTED]> wrote: > > 1. Using automatic conversion from C to Pascal but then the code would still > have to be checked by humans. I can just imagine it will generate ugly code. I would much rather imagine that a clean design with a good objects structure would be a much better solution in the long term. > 2. Only convert certain portions which are most interesting to people. > For example: > Linux's tcp/ip stack. > Linux gui. You are jumping the gun here! You FIRST need a kernel. Then you need file system support. Then you can start with networking, utilities and GUI applications. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Porting linux to pascal, would it be, possible ?
On Sat, Dec 6, 2008 at 9:46 PM, Skybuck Flying <[EMAIL PROTECTED]> wrote: > >> I would much rather imagine that a clean design > > Are you suggesting to design a new operating system ? Difficult ?! No, I just saying that maybe you can take advantage of some of the Object Pascal language features. Doing a automated conversion will surely not do that. > > I was wondering if it's possible to mix C and Pascal in Linux. > > For example, leave kernel in C and make other things in Pascal. I thought the whole point was to create an OS in Pascal. So to me the kernel is the heart of the OS, so that should be in Pascal as well. That's what will be the impressive part for me. Porting the other OS utilities are simply not that impressive. They are standard applications, which we all know Object Pascal can already do. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Other IDEs
On Thu, Dec 11, 2008 at 1:05 PM, Felipe Monteiro de Carvalho wrote: > > Turbo Pascal 5? > > I think you don't know what Lazarus is. Every once in a while someone > takes a look at the Free Pascal IDE and thinks it is Lazarus. I agree. I think people get confused between Lazarus IDE (GUI based and separate project) and the Free Pascal IDE (console based) programs. > This is Lazarus: > > http://wiki.lazarus.freepascal.org/Image:Lazarusmac0.9.25.jpg > > http://wiki.lazarus.freepascal.org/Image:Lazarus_Windows_XP.PNG And the Linux screenshot... ;-) http://upload.wikimedia.org/wikipedia/en/5/59/Lazarus_software_sshot.png http://en.wikipedia.org/wiki/Lazarus_(software) Paul, I believe you got confused. I cleaned by glasses and double checked... and still can't see the resemblance of the Lazarus IDE to Turbo Pascal. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Other IDEs
On Thu, Dec 11, 2008 at 3:24 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote: >> 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. Correct. Simply adding new language support into Eclipse is not going to magically solve all the problems. For example: after adding new language support, you need to *also* add new debugger support. Not a trivial task! http://www.eclipse.org/articles/Article-Debugger/how-to.html Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Fwd: [fpc-pascal] fpGUI Toolkit source repository migrated to Git
-- Forwarded message -- From: Graeme Geldenhuys Date: Tue, Apr 7, 2009 at 3:45 PM Subject: Re: [fpc-pascal] fpGUI Toolkit source repository migrated to Git To: FPC-Pascal users discussions On Tue, Apr 7, 2009 at 3:25 PM, Paul Ishenin wrote: > > I am wondering what are that needs for project with *the only one developer* > that svn cannot serve well and that alone developer need to install another > source control system? Imo just a waste of time. And not only your time but SVN does not fit my workflow! It's plain and simple... Git makes my live easier. Lets give a few examples where SVN fails and Git proves much better: * I often want to commit only partial changes in a file. Why, because i was debugging something and added lots of writeln() commands. i don't want to revert those writeln() immediately because the next bug hunt would also require them. Under svn I have to create a patch of all changes for that file. make a copy of the patch and and pick the hunk I am interrested in. Revert my changes and apply the new modified patch. Check that all is ok and then commit. Ah, no I need to re-commit the original patch, so I can get my writeln()'s back. A sh*t load of work for something that should be simple. Using 'git gui' I simply right-click the hunk I want to commit and select stage. now execute 'git commit' and I'm done. How easy was that!! * I often work on something that takes a while or experimenting with someting. Using SVN I can't commit my changes as I work without affecting the server history. With git I can. And don't mention svn branches, because they suck! Yes I have tried 'svnmerge.py' which is simply a band-aid on a big problem. * I like to take work home on a pen (flash) drive. I can now simply clone my work PC repository to the flash drive and work at home. Next day I simply push changes from pen drive to work PC again. * Merging is a lot more intelligent - I seem to get much less conflicts. * I love the syntax highlighting in 'diff', 'log', 'show' and 'status' commands. All built into git. * I can't do the following in SVN. In Git I can, and the result is instant! $ git log --since="1 week ago" --until="yesterday" * I can't do the following in SVN: (regular expressions on the actual diffs) $ git log --pickaxe-regex -S"some.*code.*change" * My internet connection at home is not very fast. Git is a LOT faster at pushing or pulling changes. Even on our work internet connection (4Mb line) I can see the speed difference. > all other developers who need to update from your repository. Now they need > to learn git and to install it on their systems. I push to the SourceForge repository and they collect updates from there... Currently my local repository is off-limits to the public. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] asciidoc written in Free Pascal
Hi, Has anybody thought of doing this or maybe done it already? I noticed the Git help is written in plain text and uses asciidoc to generate Unix ManPages, HTML, PDF, DocBook etc... I guess in a way it's similar to LaTeX or wiki's. Plain text content which gets used to generate various other formats (yes I know LaTeX is a lot more advanced than that). I've already written a wiki in Free Pasacl which uses a subset of the Creole markup, which is the same idea as asciidoc I guess. The nice thing of asciidoc and Creole is that it's very readable, even in the plain text format. The not-so-nice thing about asciidoc is that it has a huge dependency list just to get it to run. If only those asciidoc developers knew about Free Pascal, they could have removed pretty much all dependencies and only require FPC. Those idiots. :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Tue, Apr 7, 2009 at 8:46 PM, Florian Klaempfl wrote: > > I know, but I don't want some crappy algorithm to guess if linefeed > conversion is needed or not, this feels so cvs like *g* In that case, all you would need is an editor that supports Unix line endings and not try and convert them to crlf as you edit the file - then everything would work fine, even if autocrlf=False under Windows. So Windows NotePad is NOT an option. ;-) The 'syn' editor which is based on the original TSynEdit component works perfectly. Did you know that crlf conversion occurs in SVN as well. Hence the 'eol-style' property in SubVersion. Git tries to auto detect text files and ONLY applies the crlf conversion on those. fpGUI repository should not contain any binary files other than images, and they work correctly even with 'autocrlf=True'. And if a binary file is detected incorrectly as a text file, you can tell git about it using .gitattributes file. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Tue, Apr 7, 2009 at 7:55 PM, ik wrote: > Another better feature is the way tagging and brunching works. You can mix > everything without making a copy of the whole tree all over on each Yeah, that is great. Purely to play with git, I checkout out a very old state (v0.4 of around mid 2007) of fpGUI. The v0.4 code was very different and had a very different directory structure. In under 3 seconds the checkout was complete with the new directory layout. I had a few "untracked" files lying around which were compiled .ppu files from the HEAD fpGUI, but that was it. All the old memories came flooding back while I browsed the history version. Then a simple 'git checkout master' and 3 seconds later I was back to todays version of fpGUI. Awesome!! :-) > And there are even more features, but the question is if it good for all > projects. I don't know the answer, I only know that I moved to git in my Very good question. Most of the times when you read about Git, it's all about large projects like Linux Kernel, Wine, Gnome etc... But the nice thing of Git, is that it works just as well for small one-man-band projects. To start using git you only need to know about 5 or so commands (similar to SVN) but then as you get more familiar with it you venture out into new territory and start experimenting with more features. Bottom line is -- no matter if git is a "distributed version control system" and designed for large projects with a huge hierarchy of developers. Git simply fits my workflow better than SVN ever could. Git makes my life easier! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Wed, Apr 8, 2009 at 11:48 AM, Tomas Hajny wrote: >> > > In this context, any editor which doesn't use LF by default (e.g. for new > files) is not an option unless you require Unix users to use an editor > supporting CRLF as well or unless you never expect non-Unix users to > contribute to the project directly. Well that shouldn't be a problem, because most unix editors I know or use adheres to whatever line ending is in the file. So if a Windows users commits a new file, my system should manage it just fine. But saying that, by default msysGit uses the Windows line ending style and committing a new file will then automatically be converted to a Unix line ending on the Git repository at SourceForge (they run unix servers there). Line endings for text files are handled correctly under Git by default, so I don't see the issue. SubVersion has the exact same problem, so it's not like Git is doing something stupid. Git has option for handling this issue and with a default install, the user doesn't need to do anything. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Wed, Apr 8, 2009 at 12:26 PM, Tomas Hajny wrote: > context of notes about great advantages of Git, not in the context of your > announcement about fpGUI) that this is a limitation currently and that Maybe a limitation for projects like FPC yes, but not for fpGUI. OS/2 (even though I loved it in it's day) is not a supported platform of fpGUI. But yes, after reading your last post I understand what you mean. > I wouldn't be able to contribute any longer, because no (usable) Git > client for OS/2 / eCS exists at the moment as far as I know. Ignoring the fact that some exotic platforms like OS/2 doesn't have git support (has anybody actually tried to compile git under OS/2 yet?), learning a new version control system is not that hard. I found CVS more confusing than Git. And from a developer point of view, you only need about 5 commands to do most day-to-day work using git. Oh Tomas, I only remembered now. There is a native port of Git in the Java language. It's called 'Java Git' and can be found at: http://www.jgit.org/ I have no idea how far they are, but if it supports up to Git v1.5 features you are good to go on OS/2 or any other platform supporting Java. :-) Alternatively we can always implement a native Free Pascal Git, which should solve this whole Git + FPC issues. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Wed, Apr 8, 2009 at 1:18 PM, Marco van de Voort wrote: > > That's not the same. Then you still have the mess of crlf mistakes in your > history. Well, if it's fixed in a later revision, then there is no problem. And even worse - if you submit a patch where every single line has changed (due to some screw-up in line ending settings), then you don't deserve to be called a programmer. You (the developer) made the changes you want to submit and alarm bells should have rung when you reviewed your patch before submitting it. It's called common sense or Programming 101. BTW: In git you can also rewrite the history and probably fix such issues - but don't ask me how, I haven't attempted that yet. :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Wed, Apr 8, 2009 at 12:00 PM, Tomas Hajny wrote: > > I certainly don't want to discuss usefulness of git to individual users or > projects, but it doesn't seem to be very fit to widely multi-platform > projects (yet) because much fewer platforms are supported (directly or > indirectly) at the moment than with e.g. SVN. At this point it's not something I need to worry about. fpGUI officially only supports Linux and Windows. Unofficially it supports *BSD and some embedded devices too. Git already runs on more platforms than what fpGUI supports: Windows, Linux, MacOS-X, Solaris etc... So I really don't see the problem. I wasn't trying to convince every other project to switch to Git. The original thread was simply to notify FPC+fpGUI users that the fpGUI source is now in a different repository. The users that regularly contribute have already switched to Git and have not raised any issues. I did post a message in the fpGUI newsgroup mentioning the move before it was done - nobody raised any concerns. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
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. And yes we have all seen what a mess the patches look like if you forget to set that on certain files. I have seen this in my own projects and in Lazarus repository. 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. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
hehe... OK, lets try this one more time... On Wed, Apr 8, 2009 at 2:12 PM, Florian Klaempfl wrote: >> In that case, all you would need is an editor that supports Unix line >> endings and not try and convert them to crlf as you edit the file - > > Oh, maybe at the end I should switch to linux to use git ;) ? Only if you want a descent OS, but I thought we were only talking about descent editors. ;-) > Windows uses #10#13 as newline marker, period. A program which cannot > handle this well (and svn shows that it is perfectly possible) is simply > crap and is not suitable for windows development. And Linux uses #10 as newline marker, period. A program which cannot handle this well (and git shows that it is perfectly possible) is simply crap and is not suitable for Linux development. So what's you point??? Git *does* handle it correctly - it's perfectly possible. My reading of the description of `crlf` in gitattributes(5) is: == `crlf` ^^ This attribute controls the line-ending convention. Set:: Setting the `crlf` attribute on a path is meant to mark the path as a "text" file. 'core.autocrlf' conversion takes place without guessing the content type by inspection. == Note the "without guessing" part. I got it slightly wrong before - by default git treats all files as text. It only tries to auto detect *binary* files. And if for some reason git does do a good job or you are overly paranoid you can help git out. For example, if you want all *.foo files to be treated as binary files you can have this line in .gitattributes: *.foo -crlf This will mean all files with a .foo extension will not have carriage return/line feed translations done. Simply add the .gitattributes into the root directory of your project so it's a tracked file. Now everybody using that project will also get the .gitattributes file. >> 'eol-style' property in SubVersion. Git tries to auto detect text >> files and ONLY applies the crlf conversion on those. > > And that's what sucks: *auto detection* :) As i mentioned earlier, I got this slightly wrong. By default git treats all files as text. It only tries to auto detect *binary* files. >> should not contain any binary files other than images, and they work >> correctly even with 'autocrlf=True'. And if a binary file is detected >> incorrectly as a text file, you can tell git about it using >> .gitattributes file. > > How can I prevent that I forget this? By creating the .gitattributes file in the root of the project and adding it to your project. $ (create your .gitattributes file in root directory of project) $ git add .gitattributes $ git commit -m "added gitattributes file to project" Which means the file is now part of the project. Anybody cloning the project will now automatically get the .gitattributes file and have all the correct settings that the project managers decided on. The same thing is done with the '.gitignore' files in the fpGUI directory. Cloning fpGUI, git will automatically ignore all *.lps;*.ppu;*.o;*.a files when you commit or do a status check. The user doesn't need to do anything on their side. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On Wed, Apr 8, 2009 at 3:41 PM, Florian Klaempfl wrote: > > As pascal shows, something proven is often better as some hype ;) Good answer. :) > exactly into my picture of git being a big design failure as a general > purpose scm: besides being a posix hack (see also file names: > ".gitattributes") it does not help users to avoid mistakes. I admit, as Well with all due respect, Git was designed in the beginning to solve a problem of one specific project - the Linux Kernel. So don't you think they were allowed to have Linux specific features in it's design. Even so, now that more people start liking the idea of Git (you excluded obviously ), it is being amended to play nicer on other platforms as well. So far they are going a great job. BTW: I understand FPC was Windows only in the beginning. ;-) What's wrong with the file names? And if you tell me it's because it doesn't have an extension well then... Linux like most other OS's (excluding Windows) can detect a file type very easily. It doesn't need to use the ridiculous 3 character extension to tell it what file type it is or if it may or may not be executable. I see this as a strength in *nix based OS's, not a weakness. As for the prefixed dot (.), well that is simple and ellegant. You can create a file or folder and make it hidden all in one swoop - no need to fiddle with file attributes. Brilliant. :-) >> By creating the .gitattributes file in the root of the project and >> adding it to your project. > > ... and when I forget to add a file to .gitattributes, nothing helps me. > Our svn server is configured to prevent adding of files without proper > mime property settings. So you had to fiddle with the SubVersion server settings BEFORE things get handled correctly. What if you forgot? ;-) With Git's '.gitattributes' and '.gitignore' files you can let those "server settings" go with the repository when it's cloned. Just like SubVersion, you ideal "tweak" settings need to be done before hand and also only once. And if there is any more doubts about line ending conversion. Git can do sanity checks for you and warn about potential conversion issues. Welcome to the "core.safecrlf" setting If core.safecrlf is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of core.autocrlf. For "true", git rejects irreversible conversions; for "warn", git only prints a warning but accepts an irreversible conversion. == But I do think you have a point. Using standard mime types built into git (and extendible by repository maintainers via config file) would be a valuable addition to git. Simply to please that last few folk that can't decide if they like or hate git. :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] A web site that teaches how to use FPC
Do you mean FPC as in compiler specific features or as in Object Pascal, the language features? If it's a tutorial on the Object Pascal language, then most Delphi books or website could be used. - Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] A web site that teaches how to use FPC
On Wed, May 13, 2009 at 1:15 PM, ik wrote: > Both. > > I'm trying to help someone learn Object Pascal on Linux and he uses FPC. So > he asked me if I know any such web sites. A simple Google search using "delphi tutorials" revealed a lot of links. This one is apparently very good: http://delphi.wikia.com/wiki/Delphi_Wiki http://www.freeprogrammingresources.com/delphi.html http://delphi.about.com/od/beginners/a/delphicourse.htm http://www.techtutorials.info/delphi.html http://www.delphi-central.com/tutorials/ ... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Pascal librarys
On Fri, May 15, 2009 at 9:49 PM, ik wrote: > I think that if Pascal will have a lot of libraries in one area, that will > make it easier then anything else existed, it might gain more usage and > popularity. I thought FCL is exactly that. It contains lots of libraries and header translations etc.. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Pascal librarys
On Sat, May 16, 2009 at 10:27 AM, ik wrote: > But it is not unique. For example Boost and QT for C++ provide a lot more > general support then FCL. Lets see what FCL gives us (the very short list): * built-in XML handling * built-in full DOM support * built-in database support (SqlDB and many RDBMS to choose from) * built-in graphic file loading/saving support (png, jpg, gif, tiff, etc...) * built-in unit testing framework * built-in JSON support * built-in web development support (cgi and more) * Apache module support * built-in netDB support * built-in CHM support * built-in code generation support (as used by Lazarus Data Desktop app) ...etc. These and many more are all in pure object pascal and included with the compiler. Something C/C++ and other compilers don't. You have to pay a fortune for Qt, just to get some of these features (like database support). Free Pascal gives this as standard for free. AND I haven't even mentioned the features included in the RTL (various collection class, string handling, thread management, etc...) or the Lazarus LCL or fpGUI or MSEgui or AggPAS. All pure object pascal goodies. Object Pascal developers sometimes forget how good (easy) we have things! :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Pascal librarys
On Sat, May 16, 2009 at 10:58 AM, ik wrote: > > But if you can show me that by taking this units I can work less and do a > lot more, then we have something to talk about, and I don't think you can. Then take a look at the result output formats in FPCUnit. I would show you other XML units, but unfortunately it is closed source. Other built-in classes that come to mind. TIniFile (and Lazarus TXMLPropStorage class). They make saving settings etc a no-brainer. Even the TStringList class is a blessing for reading files and running through each line (compared to C/C++). I can't commend on Ruby, PHP etc. as I don't use them. Free Pascal does everything I need, even for web applications. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Pascal librarys
On Sat, May 16, 2009 at 1:10 PM, ik wrote: > > The difference of what we talk about is, that you present a lot of tools > that using them I can make a framework. > What I'm talking about is an existed framework to make it more usable, and > make things easier. OK, now I see what you mean... > lets take Rails (or even Django in Python) they take a lot of tools and > combine them into a one big tool that is a framework that allow you to I haven't looked at fpWeb for over a year, but I believe good improvements have been made to it, allowing XML, JSON and template based web development. Other than that, there is also Morfik (http://www.morfik.com) which is a big tool for web development (using FPC) - apparently very good - but I haven't used it yet. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Hi, Michael Van Canneyt told me that we cannot include DUnit2 into the FPC source code tree, replacing FPCUnit (if we wanted to do that). The reason being that DUnit2 is developed under the MPL license which is incompatible with the GPL or LGPL license used by FPC. Well here is a question. FPCUnit is a port of JUnit DUnit is a port of JUnit DUnit2 is also a port of JUnit (it's a fork from DUnit with many parts totally rewritten) In all these projects it is clearly stated in the headers that they derived from JUnit. So what licenses is JUnit distributed with? From their website, it is the "Common Public License". http://junit.sourceforge.net/cpl-v10.html So how does CPL compare to GPL and MPL. Shouldn't FPCUnit, DUnit and DUnit2 also use CPL license then? They are derived work are they not? [...then again, I have no knowledge about the CPL license...] If so, is FPCUnit actually allowed in the FPC source tree? If it may, then maybe DUnit2's MPL license is actually invalid and should have been CPL instead, which ultimately means DUnit2 could also be bundled in the FPC source tree. Or maybe CPL is incompatible with (L)GPL and none of the 3 products may actually be bundled with FPC? I have no clue. Anybody got some thoughts on this? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Graeme Geldenhuys wrote: In all these projects it is clearly stated in the headers that they derived from JUnit. So what licenses is JUnit distributed with? From their website, it is the "Common Public License". http://junit.sourceforge.net/cpl-v10.html And here is IBM's FAQ on the CPL license. http://www.ibm.com/developerworks/library/os-cplfaq.html And Wikipedia's take on the CPL http://en.wikipedia.org/wiki/Common_Public_License Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Jonas Maebe wrote: Or maybe CPL is incompatible with (L)GPL and none of the 3 products may actually be bundled with FPC? The CPL is not compatible with the (L)GPL: http://www.gnu.org/philosophy/license-list.html#CommonPublicLicense10 Correct, the IBM FAQ on CPL also states that the CPL is incompatible with (L)GPL. So unless the authors of both JUnit and DUnit gave permission to also distribute their code under the modified LGPL, fpcunit cannot be distributed under that license. But was FPCUnit allowed to use a different license? I'm trying to track down information regarding "derived work" where the original code was CPL. I haven't found anything yet. made for a unit testing framework. After all, you seldom distribute unit tests, so the license is of minor importance. Good to know. (CC'ing Michael, since he's not subscribed to fpc-other; Michael, Graeme's original message can be found here: http://lists.freepascal.org/lists/fpc-other/2009-July/000300.html ) Thanks Jonas. I wasn't sure if this message thread should have been in FPC-devel or not. So I instead opted for fpc-other to be safe. But yeah, I don't know how many developers are subscribed to fpc-other. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Michael Van Canneyt wrote: FPCunit was implemented from scratch by Dean Zobec, and he gave it to So porting a project (even to point where it shows exact same behaviour or not) to a different language does not constitute as "derivative work"? I would have thought it is still derivative work. Considering that even the Money example from JUnit was ported to FPCUnit. If FPCUnit is deemed derivative work, that would mean it must still use the CPL license, not so? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Graeme Geldenhuys wrote: If FPCUnit is deemed derivative work, that would mean it must still use the CPL license, not so? Did I mentioned I HATE software licenses. :-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Jonas Maebe wrote: It does, but "implementation from scratch" <> "porting". And here follows the words from Dean Zobec himself. It was a discussion between him and myself on the fpc-pascal mailing list dated 2007-05-27. == ... FPCUnit has a different structure then DUnit, is a literal port of the JUnit test framework, with only some changes that were required to adapt the Java code (callbacks instead of inner classes in some places iirc). TTest is an abstract class, TTestSuite is a composite pattern. Just look at the JUnit documentation, here you can find a UML diagram: http://junit.sourceforge.net/doc/cookstour/cookstour.htm and there is a good chapter available as an MIT Lecture on OOP and patterns that takes the JUnit framework as a Case Study: http://courses.csail.mit.edu/6.170/old-www/2001-Fall/lectures/lecture-17.pdf I choose to adhere strictly to the JUnit framework as it was a standard when the FPCUnit port was created, and no additional documentation of the framework was needed (you could always refer to the JUnit documentation and practice, a lot of articles and books were written on the subject). Still, it's not a good excuse for lack of documentation :) Regards, Dean == Extract from the fpc-pascal archives... http://lists.freepascal.org/lists/fpc-pascal/2007-May/013811.html In that quoted piece he mentions twice that FPCUnit is a port of JUnit. Maybe we should silently delete that message from the mailing list archives. ;-) [...and once read, this message will self-destruct in 10 seconds...] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] FPCUnit, DUnit2 and JUnit licenses question
Graeme Geldenhuys wrote: Jonas Maebe wrote: It does, but "implementation from scratch" <> "porting". Extract from the fpc-pascal archives... http://lists.freepascal.org/lists/fpc-pascal/2007-May/013811.html We will have to delete this one as well, from the fpc-devel mailing list. ;-) http://lists.freepascal.org/lists/fpc-devel/2009-May/016835.html Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Borland /was/ planning a 32 bit TP for Dos
On 7 February 2010 02:50, Henry Vermaak wrote: >> >> Apparently they didn't see "and some people might simply start writing their >> own compiler" coming :) > > :) And they didn't think that all those other platforms will become > important, either. +1 A very narrow vision. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Borland /was/ planning a 32 bit TP for Dos
On 10 February 2010 22:51, Felipe Monteiro de Carvalho wrote: > > What impresses is that the same company with so much vision in 1993 > managed to have not such a great vision (or implementation) at 2001 > with Kylix and then having a totally wrong vision in 2003 with Delphi > .NET and basically managing in the end in the 6 years between 2003 and > 2009 to implement only 1 big feature: unicode support ... That amazes me too. They were pretty unbeatable in the 80's and early 90's, then it was downhill from there. Borland even built a huge office (the Borland Campus) which was home for over 1200 developers at the time. I believe Borland relocated but left some developers behind. Which became CodeGear, with a hand-full of employees. I read the other day that they are now also leaving the Borland Campus offices. One minute you're right up there and the next minute you are down in the dirt. :-( Lets hope it does take 6 years for FPC to get Unicode support - that means we will only see Unicode by 2016!! :-/ I better schedule some time at the office so I can work on the 'cpstrnew' branch. > I wouldn't care much, but their lack of vision severely harmed the > Pascal job market. Very true, but I think it's busy picking up again. Every little bit helps. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] fpGUI Toolkit v0.7-rc1 for FPC 2.4
fpGUI v0.7-rc1 is available --- An archived source download can be found at the following URL, or the source code could be pulled directly from the source code repository. http://sourceforge.net/projects/fpgui/files/ For more details, please visit the fpGUI home page: http://opensoft.homeip.net/fpgui/ The v0.7 release contains a lot of added features compared to the previous release. Below is just a small list of things that changed or was added. A more detailed change-log will be made available when I create the final v0.7 release. The final release will also include updated Class Documentation (in HTML and INF format) and application help for DocView and UI Designer. The FPC Language Reference document will also be made available in INF format. Some changes in v0.7-rc1 - * FPC 2.4.0 compatible. * Fully tested on 32-bit and 64-bit platforms. Tested on Linux, Windows and the *BSD family. * Mobile device support is back. Tested on ARM Linux and Windows Mobile devices. * fpGUI UI Designer has improved a lot and extended it's component palette and Object Inspector. * Various bug fixes, memory leaks and other enhancements have been applied. * Units have a more uniform naming style. * Classes have a more uniform structure/hierarchy with base classes. * Help support has been added to the core framework * fpGUI now has it's own help file viewer called DocView. Docview includes the following features: - document annotation - bookmarks - browse history - exporting articles to plain text or IPF format. - full text search (including weighting of results to see how relevant the results are) - Font and Color customization - Concatenation of help files at run-time so a library of help files can be viewed simultaneously. - Easy integration via the "external tools" feature of IDE's like Lazarus or MSEide. This allows for context sensitive help. - History of most recently viewed help files. - Help file format used is the INF format (IBM's format used it OS/2), which is very compact, incredibly fast and supports full text search. * A lot of new components have been added, including enhancements to existing components. * Various new dialogs have been added, which include Color Wheel, Character Map, Database Login etc. * Improved integration with tiOPF project via the Model-GUI-Mediator design pattern. * Graphical FPCUnit unit test runner. * Lots of new language translations for the core fpGUI library. * A lot of new example projects demoing various GUI components. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] fpGUI Toolkit v0.7-rc2 for FPC 2.4
fpGUI v0.7-rc2 is available --- An archived source download can be found at the following URL, or the source code could be pulled directly from the source code repository. http://sourceforge.net/projects/fpgui/files/ For more details, please visit the fpGUI home page: http://opensoft.homeip.net/fpgui/ The v0.7 release contains a lot of added features compared to the previous release. Below is just a small list of things that changed or was added. A more detailed change-log will be made available when I create the final v0.7 release. The final release will also include updated Class Documentation (in HTML and INF format) and application help for DocView and UI Designer. The FPC Language Reference document will also be made available in INF format. Some changes in v0.7.rc2 - Fixed some compiler errors for experimental FPC 2.5.1 - Localization of Character Map dialog. - Insert from Character Map added to TfpgEdit default popup menu. - ModalResults is now a enum type. Improved integration with UI Designer. - Memo: problems with deleting selected text is now fixed. - Improved WinCE support, including reading BMP files. - Fixed compilation of all example projects. - Extended available properties that can be edited via the Object Inspector of the UI Designer. - Fixed issues where dialogs are closed via the window border X button and not the available buttons in the dialog. Developer can define behaviour of X close button. - Improved TabSheet handling in UI Designer. - Various improvements to TfpgPageControl and TfpgTabSheet. This includes new tab positions: Bottom, Left, Right and None. - SelectDirectory dialog was not working under Windows. - Setting selected directory in SelectDirectory dialog now works. - New mouse cursor demo. - Improved the ability to customize the HintWindow. HintWindow demo was extended to show how this can be done. - Improved Visible property handling especially with child components. Now only the parent Visible property is changed. - tiOPF: correctly disable event handlers in edit mediators. - Added a script which generates a fpGUI version number based on Git repository information. Later this will be converted to a object pascal console application. Some changes in v0.7.rc1 - FPC 2.4.0 compatible. - Fully tested on 32-bit and 64-bit platforms. Tested on Linux, Windows and the *BSD family. - Mobile device support is back. Tested on ARM Linux and Windows Mobile devices. - fpGUI UI Designer has improved a lot and extended it's component palette and Object Inspector. - Various bug fixes, memory leaks and other enhancements have been applied. - Units have a more uniform naming style. - Classes have a more uniform structure/hierarchy with base classes. - Help support has been added to the core framework - fpGUI now has it's own help file viewer called DocView. Docview includes the following features: - document annotation - bookmarks - browse history - exporting articles to plain text or IPF format. - full text search (including weighting of results to see how relevant the results are) - Font and Color customization - Concatenation of help files at run-time so a library of help files can be viewed simultaneously. - Easy integration via the "external tools" feature of IDE's like Lazarus or MSEide. This allows for context sensitive help. - History of most recently viewed help files. - Help file format used is the INF format (IBM's format used it OS/2), which is very compact, incredibly fast and supports full text search. - A lot of new components have been added, including enhancements to existing components. - Various new dialogs have been added, which include Color Wheel, Character Map, Database Login etc. - Improved integration with tiOPF project via the Model-GUI-Mediator design pattern. - Graphical FPCUnit unit test runner. - Lots of new language translations for the core fpGUI library. - A lot of new example projects demoing various GUI components. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
Henry Vermaak het geskryf: > > The whole thing just seems so absurd. Absolutely! It shouldn't be about the language used, but rather the integration and usage of the running application itself. Apple is totally bonkers! With all their "forced usage requirements" (regarding Mac OS + hardware, iPhone etc) on end-users and developers, what is next? Code may only be typed on a Qwerty keyboard or only written by right-handed people??? Such crazy restrictions that Apple enforces on all it's products should simply not be allowed. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Awesome desktop layout for programming
Hi, I've read a article on 'Coding Horror' and thought I would try it out for a day. Rotate your desktop (and screen) by 90 degrees. That gives me 900x1440 resolution on my LCD display. This is pretty awesome for reading FPC documentation, websites or viewing source code! I now have almost 90 lines of code I can see all at once. Plus our projects have rather a lot of units, so having an enlarged Project Inspector windows is pretty great too. :-D Here is a screenshot of what I see: http://opensoft.homeip.net/~graemeg/vertical_desktop.png Alternatively, you can go the other way. 3 LCD monitors in a horizontal position. But I still like the extra vertical space I have, which a horizontal layout will not provide. http://www.codinghorror.com/blog/2007/09/lcd-monitor-arms.html -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On 9 April 2010 18:07, Jonas Maebe wrote: > > Hence, it would be useful if enough people send in their FPC-related > comments via http://developer.apple.com/contact/, so the reworded version > could maybe take into account our situation as well. Even though I don't program for the iPhone, I did email Apple with my concerns about their absurd decision. I also mentioned that developers worked hard on FPC to get iPhone support. Lets hope enough developers complain! -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Wanted: permanent or contract developers for a new project
Hi, The company I work for is called Master Maths. We are a franchise business and based in South Africa. We primarily produce computer based training for Maths and Science, and have been in business since 1976. Our Head Office has a staff complement of just over 30 people, and we are located in Somerset West, 40km outside Cape Town. We want to broaden our product range, and will be starting a new project soon (a few months time). We are looking for Object Pascal developers with good OOP (Object Oriented Programming) and Software Design skills. The developer(s) will start the project from scratch, and I will simply oversee the development progress. We are looking for permanent staff, but will accept contract programmers developing over the internet as well (no matter the country you are based in). If you are interested in working with Master Maths, please send me a private email (gra...@mastermaths.co.za), so that we can contact you closer to the time. Further enquiries are welcome, but only via private email. -- Regards, - Graeme - Master Maths Head Office web: www.mastermaths.co.za email: gra...@mastermaths.co.za ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Rumors regarding Apple apps in new OS
On 24/04/2010, ik wrote: > > Any new app require to be digitally signed by Apple (for $99) before it even > reviewed. With the sh*t Apple is trying to pull these days, I simply say: Dump that platform and move to something more open and developer friendly. In the end when Apple sale plummet, they might realize what they are doing wrong. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: Pascal dialect
On 4 June 2010 17:03, Jonas Maebe wrote: > is a hit, it's a good way to encourage customers to upgrade. In our case > it's primarily a good way to get complaints :) The big difference you are overlooking is that in a open-source environment you get to see what is happening before a release is out. You get a changes to prepare your code while the changes are being implemented. If you were early enough you could maybe even have contributed in the thought process for the code-breaking changes. I have been following this same path with fpGUI and our company projects. As soon as FPC announces a RC or Beta, then I start looking at what needs to change in our projects to stay compatible when the new release is finally out. Lately I have been following trunk too. In a closed source environment the end-user is left in the dark (not even a detailed roadmap from Embarcadero) and only see what changed after you purchased the new version. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On 4 June 2010 16:16, Michael Van Canneyt wrote: > > Converting 2 million lines because they broke compatibility is NOT funny, > and will - in all likelihood - cost us a lot of money. > Rightly so, but why? Because you got no prior warning of the scale of the change, no end-user input was sought, no time to prepare. So you were forced to follow the "wait and see what we get on release day" approach - this is terrible!. This is exactly why I think open-source software is so great. The community gets a chance to be involved, and you can see long before what is changing and get prepared as the changes progress. And with the community involvement (more eyes on the code), better designs could be discussed (like in the case of FPC's Unicode support compared to Delphi's). So even though there might be a code-breaking change - the effect should never be has harsh as what you get from Embarcadero. You would have much longer to prepare your code for the change. So in the end the code-breaking change (to currently maintained code) is not so bad. The FPC Unicode implementation is such an example. It's not 100% Delphi compatible, because FPC came up with a better design - the covers more platforms and solutions. So non-compatibility is justified. I just ask that other code changes be judged with the same open minded approach. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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 12
On 4 June 2010 18:57, Jonas Maebe wrote: > > 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. After all, our company switched to FPC 4-5 years ago without any regrets. We don't need Delphi to write our commercial software, hence we don't need Delphi compatibility as such. FPC is brilliant, and evolves faster that Delphi does. So there is NO real benefit in trying to keep our company software or fpGUI compatible with two compilers (essentially to products). FPC does everything we want in a commercial environment. Good database support, good web support, good internet protocol support, fantastic FCL, cross-platform RTL etc. So what's the benefit of Delphi compatibility? To keep those developers that can't make up there minds if they want to switch or not happy? They will probably will never contribute to FPC either, so what's the point in trying to please them the whole time. And it's more work for you guys. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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 12
On 4 June 2010 19:04, Felipe Monteiro de Carvalho
> So the original suggestion doesn't make sense. If you don't like
> {$mode Delphi}, don't use it, use another mode, or create your own.
That only affects language features doesn't it? What about classes in
the RTL, eg: the workings of TWriter, TComponent etc. Changing the
compiler mode will not change there interface of behaviour would it?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
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 12
On 4 June 2010 19:51, Jonas Maebe wrote: > > As I said in the mail you replied to (first paragraph I wrote): FPC and Delphi > are part of the same ecosystem. If you keep looking at it as if it is about > "us versus them", you will probably remain unhappy forever with how > FPC evolves, because it will always seem as if we are doing various things > out of servitude to Embarcadero and its horde of evil Delphi users. Maybe you haven't noticed, but neither Borland, CodeGear or now Embarcadero gives a toss about Free Pascal. They see it as a competitive compiler, hence the reason they are getting there act together now, and implementing missing feature. Also why they are implementing their own versions of a cross-platform compiler, instead of working with Free Pascal and reusing it for non-Windows platforms. There is *no* relationship between Embarcadero and Free Pascal. The FPC core team might think otherwise, but they are the only ones that think that. If there was any relationship between the two compilers, then Embarcadero (f**k I hate that long name) could very easily have implemented Generics in the syntax FPC came up with first, but no, they had to break the compatibility - for their gain, so FPC needs to play catch-up again or be told they are incompatible. Generics is just one such example. You are living a dream if you think they care about FPC, so why the hell care about them. FPC is a good product, you don't need Delphi (or delphi compatibility) when you have FPC. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On 4 June 2010 21:09, Jonas Maebe wrote: > > supporting the same language and run time environment has advantages both for > the > FPC developers (by lack of an official standard to aim for, a de fact > standard is a nice > alternative guideline) Why didn't you just say that from the start! ;-) I get the picture now. No official (think ISO) standards exist for Object Pascal, so go with the second best option. > Waarom spreken we Engels hoewel we elkaar ook verstaan in het > Nederlands/Afrikaans? Sodat almal anders ook kan verstaan. En seker omdat rekenaars en programmerings tale almal in Engels is. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12
On 4 June 2010 16:13, Michael Van Canneyt wrote: > So actually, currently it's you being dangerous, and we are protecting your > job safety. Just because we like our hobby. I don't think dangerous is the correct word to use here. My thoughts on open-source software (and this I have mentioned to a few here before) is that because it's open and free, others using that software have more time to review what is coming in the next release, and can prepare their own project to keep up with changes. Exactly what I do with fpGUI when a beta or RC release of FPC is announced. Now compare that to Borland/Embarcadero that tells you nothing, not even a clear roadmap (unless you pay them a fortune), and then suddenly release a new version of a product. I'm also a big believer of rather breaking a bit of code, to improve an underlying design. In the long run you reap a lot more rewards and have much better maintainable code. Compare that the Windows spaghetti mess of inconsistent API's, software riddled with bugs etc, all because they put "backward compatibility" on such a high pedestal that it affects their product line. Our company software was often broken due to changes made to tiOPF or fpGUI. But those changes were carefully thought out, designed and then implemented. And even though such changes broke our software, it was always relatively little effort to fix - and because the frameworks were open source, I knew what was coming so it gave me time to prepare. Your changes to MGM in tiOPF was one of those times. It broke our code, but now we are much better off than before. So the one day it took to fix our software was well worth the effort. And look at the positive knock-on effect that had. You got introduced to real-world usage of Observer etc, and that made you think of possible improvements in the Classes unit. I just think the same could be applied to any project, including FPC. So no, I am not suggesting "dangerous" changes, just well thought out improved design in some places. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
On 5 June 2010 08:02, Felipe Monteiro de Carvalho wrote: > > Having said that, think that Object Pascal as we know it should also > have a standard. I'm thinking the same thing, and am busy reading the beginnings of such a standard - which was unfortunately never completed or submitted. Maybe the Free Pascal project can continue work on this and make FPC the first Object Pascal compiler to adhere to this. http://www.pascal-central.com/OOE-stds.html How does ANSI or ISO standards work? Can anybody create a draft to be submitted, or do you have to be some company or organization first? I guess a Google search will answer some of this. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] [ANN] Beyond Compare 3.2 public beta is available
Hi, I just noticed that the Beyond Compare 3.2 public beta is available. BC is probably the best file/folder comparison tool out there. The v3.x version is available for Windows and Linux. It can compare data files, Linux packages (.rpm, deb, tar.gz, tar.bz), images, source code, binary .dfm files, version information inside .exe's etc.. This tool is unbelievable and can even be used in scripts and do things like sync folder, talk via SSH, SFTP. I've integrated BC with Midnight Commander (linux console file manager) allowing me to easily select files to compare via the F2 user menu. Nautilus (Gnome) and Window Shell integration comes standard. Public Beta http://www.scootersoftware.com/beta Beyond Compare homepage: http://www.scootersoftware.com/ PS: Best of all, it's written in Object Pascal! :-) I'm not affiliated with Scooter Software in any way, I just think Beyond Compare is an extremely handy tool for any developer. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] DocView and FPC documentation release
On 26 August 2010 18:47, Tomas Hajny wrote: > Any idea why is your Win32 binary 100 kB (12%) larger than the one I > compiled two days ago from your fpGui7.0 sources available in SourceForge? > I assume you haven't made any changes in the sources in between, have you? There has been 137 commits already since the fpGUI 0.7 release - many of them related to DocView improvements - which includes a new form and some extra components. Not sure why the 12% size change though - that seems a bit much. Maybe I didn't have the same compiler version or compiler settings as you. Could you let me know what compiler version and settings you used to compile DocView? > I tried opening some OS/2 INF files (in particular the "pascalized" > version of the IBM OS/2 Control Program Reference/CPREF distributed with A known problem. IBM is just about the only people I know that used *all* the features the INF file format supports. The major one being controlling multiple help windows inside VIEW. It's those multiple windows that bug me and many other OS/2 users)over the years. Not all INF help files managed window placement, size etc. very well. For this reason I decided to let DocView only have one view area - after all, the reason I created DocView is for newers applications - not really help files from 15 years ago. :-) Saying that, with IBM's IPFC20.INF and some other OS/2 help files I could manage to get to some of those hidden topics via the Index (set index to Full in "Settings - Options - General") or the Search tab. > Virtual Pascal v1.0) and DocView displayed empty pages for just any of the > Control Program APIs listed in the Contents pane. IBM's XVIEW (Win16 Could you maybe email me in private one of those INF files - I'll see if I can make DocView work with them a little better. My preferred email is: graemeg at gmail dot com Many thanks, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] DocView and FPC documentation release
Op 2010-08-27 10:30, Tomas Hajny het geskryf: > > Sure, will do (at latest during the weekend). I'll also check whether the Thanks. > Toolkit works any better (and also recheck whether NewView can cope with > the VP/2 version correctly). I've never used NewView, but I believe it also manages multiple windows (but apparently better than VIEW) - so those INF files should work with it. NewView is now the default help viewer in eComStation. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] DocView and FPC documentation release
On 27 August 2010 10:30, Tomas Hajny wrote: > Sure, will do (at latest during the weekend). I'll also check whether the > "standard" version of CPREF distributed with the latest OS/2 Developer > Toolkit works any better (and also recheck whether NewView can cope with > the VP/2 version correctly). I'll dig out my old OS/2 cd's and VisualAge cd's... they should give me many INF files to play with as well. But if you can, please email me the one of VP/2 which you say shows blank topics. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: [fpc-devel] Parallel processing in the compiler
On 6 September 2010 10:27, Henry Vermaak wrote: > The install is crazy, it basically installs a whole mingw/msys system > (when I last checked). I've already got an mingw/msys install and > having two is suicide. I've heard that people use the git install as > a base and then install other mingw/msys packages on top of it. No idea which Windows git version you are running. There is the old Cygwin version, and the newer (windows native) msysGit version. The latter is a mere 12MB download, and allows install customization on 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. Saying that, my Windows usage is limited these days. For the last few years, most of my time spent developing software is under Linux. But we do test our software and do bug fixing under Windows, in a VirtualBox session. In such cases I do use msysGit (last installed version is 1.6.2.1 from 2009-03), and found none of the issues Florian raised. I have a cloned copy of FPC & Lazarus git mirrors, and of our company software repositories all setup in the VM session. A stand-alone development VM environment. Maybe I'm just lucky, or Windows behaves better in a limited VM environment. Who knows? :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: inf files and textmode IDE (fwd)
On 6 September 2010 10:52, Marco van de Voort wrote: > > When the recent discussion about git moved to fpc-other, that reminded me > that the last to-fpc-other discussion had loose ends :-) Oh boy, this sounds serious. Doesn't not replying, also answer a question. ;-) Just kidding. > - Don't compare compressed sizes if you must depack to use. OR at least > clearly annotate such (or provide both statistics) Not 100% sure what you mean here. I thought I compared a INF file to a CHM file to the unpacked HTML help archive. 3 size comparisons. Lets use LCL. lcl.inf -> 3.8MB lcl.chm -> 10.9MB but apparently you need the lcl.xct file too for keyword support which is already included in the INF file, so lets add that file too. lcl.chm + lcl.xct -> 12.1MB lcl help in HTML format -> 65MB ( This is the /docs/lcl/html/ directory after generating the LCL help in HTML format. So as you can see, having the same content, but in different formats, there is a big difference in size. So why download a larger archive, when a smaller archive contains the same help content, plus index, keyword search plus TOC etc... At one stage (a couple months back), did a speed comparison between the help viewers for use with Lazarus IDE as well. I used EpikTimer, to wrap the code that loads a topic and displays that topic - ready for a end-user to start reading the content. I compared DocView against LHelp. In my tests, DocView was about 20+ times (on avg.) faster than LHelp, loading and displaying the same topics. I then disregarding the "displaying of topics", and only timed the loading of topics. Again, DocView was considerably faster that LHelp. I also did a speed comparison in loading of the help file itself, and simply populating the Table of Content and Index. Again DocView was some 20-25 times faster than LHelp. This I believe was after some binary tree addition to the CHM code which should have increased the CHM speed. Another test I did was scrolling of loaded content. Load a large topic, then drag the scrollbar button from the top to the bottom. After all, help is there to me read, and the end-user is bound to scroll the help. So my thinking was to test what the end-user would experience. If memory serves me well, I used the LCL TApplication topic (in INF help, that would be the TApplication Method Overview node). LHelp was simply unusable, but apparently the HTML Viewer component used by LHelp is to blame for that. Never the less, that is the experience the end-user would get. So if any of these tests and comparisons seem unfair in any way, please let me know, and suggest any alternative way I can do similar comparisons. My main point I was trying to get at was download size (myself and many others I have limited internet bandwidth per month), and end-user experience. > The main reason seems to be to make html usable without an index tab left to > it. This is useful for online use (though strictly, you could have an index Just like the HTML or CHM help needs additional information to have some form of navigation like a Table of Content, so do does the INF format have additional information for TOC and Index support. A TOC does not appear magically in INF, the fpdoc IPF writer needs to add information in the IPF output for that. The Index is a different matter. You can have built-in Index information in the INF file, but DocView has a special ability to build it's own Index or or even use a combined Index (one from the INF file, and one it generates itself). > Example: If I press F1 in the textmode IDE on TStringlist, I go to the > tstringlist overview page, and from there can go to all stringlist topics. > > If I do the same with .inf, I end up on tstringlist, but can go nowhere, and > have to look up tstringlist methods in the main index. I can count on my one hand how many times I have used the textmode FP IDE. I was under the impression that the textmode IDE is a dying project. Either way, I fired it up at tried it for the first time with the INF files I generated recently. Attached is a screenshot of how I setup textmode FP IDE for INF. I included two more screenshots (in separate emails) showing what I saw. I used separate emails because I don't know the attachment size limit in fpc-other mailing list. Do you know? Pressing F1 while the cursor was on TStringList, the help windows showed me an Index page. A rather large list. I took a guess and started typing TStringList, and it automatically jumped to TStringList in the Index. I pressed Enter and saw the TStringList overview page (image in part 1 email). The overview pages is what I would have expected to see if I searched any help for TStringList. So this is good so far. I then tried the Prev / Next links you mentioned. These are not part of the INF topics content by the way, they are inserted by textmode IDE help system. I selected next, and it showed me the TStringList Method Overview. As I expected too. It
[fpc-other] Re: inf files and textmode IDE (fwd)
In case those previous attachments don't go through (which it seems they didn't), here are some external links to those images. How I setup INF files with textmode IDE: http://opensoft.homeip.net/~graemeg/fp_ide_inf_setup.png TStringList overview topic as shown in textmode IDE: http://opensoft.homeip.net/~graemeg/fp_ide_stringlist-1.png After following the "next topic" link from the previous image http://opensoft.homeip.net/~graemeg/fp_ide_stringlist-2.png PS to mailing list admin: Could the attachment size be increased for this mailing list? My previous attachments where 22-25KB and they didn't seem to make it through to the mailing list. External links don't always last forever, so including images in messages is nice for archiving purposes. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: inf files and textmode IDE (fwd)
On 6 September 2010 15:36, Marco van de Voort wrote: > No, you compared a compressed INF to a CHM, on the basis that they had the > exact same context, while in fact the content generating routines are > different (html vs linear, with html repeating more code, e.g. for the > larger class overviews). I'm working on the premiss that they have the same content (originating from the fpdoc XML description files). Whatever is available in the XML files _are_ in the final help format. Of course you can't compare INF content to CHM content (not referring the help content here, but to file structure content), because they are different file formats with different file structures to ultimately produce the same result to the end user. So to be clear: same content = same xml description files. As for the "larger class overviews". I consider them the same, just presented differently to the end-user. CHM and HTML shows one LARGE page with Class summary, Method overview and Event overview and implemented Interface overview. One big ass page (which doesn't do LHelp any favours). In INF, that _exact_ same information is split across three/four tree nodes in the TOC. Again using the TStringList as an example. TStringList> Class summary page: used units, short & long description Interface Overview --> list implemented interfaces with descriptions if no interfaces are used, this node does not exist Method Overview -> list all methods of the class with descriptions Event Overview -> list all events of the class with descriptions So CHM "class overview" = INF's Class summary + Interface Overview + Method overview + Event overview And if we really want to nitpick, the only thing INF doesn't currently show (which I'll be adding before the next INF docs release) is the class declaration. But surely something as small as the class declaration can't contribute for a 3.8MB vs 11.9MB difference. And by class declaration, the only physical text strings that are missing in INF is the keywords 'type', 'class', 'destructor', 'constructor', 'procedure', 'function' and 'property'. The actual identifier for the class name, and its methods and properties, including descriptions for each of those _are_ in XXX Overview pages in INF. > I'm not interested in the unpacked .html, since I don't consider it a help > system. Good, we agree on something. :) > But _is_ it equal? Since the CHM files had the following (uncommitted) patch > to the build systems applied: I use the same build scripts included with Lazarus, and I call it as follows: ./build_lcl_docs --outfmt ipf --fpdoc /opt/fpc-2.5.1/src/utils/fpdoc/fpdoc And yes I know about the flaw in the Lazarus docs build script where they disregard order. I actually created a console docs build app for fpGUI to fix a similar issue. It doesn't use scripts (so runs on all platforms), and I specify the correct order of units inside the console app. > where you can insert your advocacy. .xct are related to fpdoc only, and > not part of the helpsystem. The fact that you don't know that doesn't bode > well for inter-inf links. OK, so that's probably where the confusion came in. I call those files .cnt where you call them .xct So if they are not part of the help system, why did you include them in the latest chm zip archive you published? It was part of your published zip archive, so I count them as part of the download size comparison. > A 100% difference in archive size is about true. A significant part of that > is due to a bigger class overview, and links from topic to topic outside the See above, I already explained that. The information IS in the INF file, just over 3 or 4 TOC nodes. It's simply a difference in presentation/layout, not in help content. > A small price to pay for a format that comes with multiple viewers default > on various operating systems and a portable compiler. Don't even go there... Multiple CHM viewers under Linux! Yeah right! Lets see... some don't display the CSS stylesheets, some don't support Indexes and Searching, some don't display the TOC, most don't support cross-chm links (unknown ms-its: protocol errors), and if they do support it, the Back button doesn't take you back to the original CHM file, most can't load multiple CHM files, and the list goes on. A pretty huge mess - and a good example of the failure of open-source software. Sh**ty levels of implemented features - or the lack thereof. Hence I compare something closer to home... something written in FPC's Object Pascal. Hence... LHelp and DocView. > The CHM support is not really optimized at all atm, but pitted for For your information, I haven't even started profiling or optimizing DocView. The only profiling I done (a few days ago after the docview release) was to see where the slow initial loading bug was under
Re: [fpc-other] Re: inf files and textmode IDE (fwd)
On 6 September 2010 17:58, Tomas Hajny wrote: > > Neither Lazarus IDE nor MSEide are available under OS/2 and I don't expect > that to change any time soon. So if I use an IDE (rather than a standalone > editor and command line tools - that is an option I occasionally use too > depending on the particular task), it's the textmode IDE. Ah, a valid point. I forgot about the OS/2 developers. This brings me to another question I have been meaning to ask you (seeing that you are the only FPC developer under OS/2 I know). Sybil (or WDSybil) still runs under OS/2, does it not? It is open-source, so is it not possible to allow Sybil to call FPC instead of the Sybil compiler? This should give you an instant "object pascal friendly" IDE to work with - hopefully with relatively little effort. Alternatively, and something that has been on my mind for a while. I was a big fan of OS/2 in the early 90's. I even did promotional work for IBM (not that it helped much). Does OS/2 support SDL? I'm seeing a gap in the market, and would like to kill two birds with one stone. I'm getting a renewed interest in OS/2, and I'm lately rather impressed with Haiku as well. I think Haiku supports SDL already. What I'm getting at, is writing a new fpGUI backend with SDL, so I can target all those "specialized" platforms with a single fpGUI backend - similar to what Pixel32 (photo editing software) project did. In my spare time (when I wasn't arguing with Marco or the Lazarus developers ), I starting writing a fpGUI based IDE. This was done two-fold: 1) to get the features I wanted in a IDE, 2) to create a more realistic "real world" application that can show off fpGUI a bit. Many developers still think fpGUI is pretty useless, but they are wrong. Hopefully DocView was a push in the right direction. As a side note, I would also like the efforts I put into the IDE, to help some platforms get more use out of FPC. Platforms like OS/2 and Haiku, by giving them a new GUI development framework and some tools to use it with. After all, they already have the excellent FPC compiler. > I'm not sure whether redesigning it is really necessary (especially if the > goals, advantages and collateral damages are not known beforehand ;-) ), > but I'd appreciate fixing whatever bugs are there. Exactly my point. I would rather fix the few bugs in the textmode IDE, and then spend the bulk of my spare time developing a more up-to-date IDE and GUI framework for those niche/specialized OS's. OS's which Lazarus and MSEide are not currently targeting. The benefits will be much greater I think. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf: > possibly a dedicated mailing list, chat room... Graeme, you seem to be > the git expert, what would you suggest for the repository topic? SourceForge has good project management tools, from bug reporting, mailing lists (though I prefer newsgroups), to project website, to repository. Git is clearly my choice due to the distributed development model, huge features set, and it simply fits my way of working better. As for what I think is a very good workflow and management of a project is the following (taken from the git project itself): http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html I think the graduation of features is the important part. Promoting the idea of pulling branch directly from somebody else should be common practice, but so too is the "development branch" where various features branches get merged together giving everybody a easy place to test something new. Anyway, the URL above describes all I have to say on this topic. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 03:41, Travis Siegel het geskryf: > personally, if I wanted to do something major with fpc, I'd not bother > trying to get it integrated to the main branch, I'd spawn my own > project, call it something else, and make it clear that it comes from It seems more and more people are thinking like that. This seems to be true in the Lazarus project as well. This should raise some alarm bells for the FPC and Lazarus project members, but they seem to be purposely oblivious to this fact. There seems to be something majorly wrong with how these projects are managed. I blame it on the "god complex" factor, but that's just me speculating. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 09:12, Florian Klaempfl het geskryf: > > Don't worry, we know this for years. > - "If the FPC team doesn't do what I want I use software XY" > - FPC team: "Fine, do so" > - "Then I fork FPC" > - FPC team: "Fine, do so" > - *silence* Then I must be the exception to the rule. I didn't like LCL, so I started fpGUI. I didn't like fpcunit, I forked DUnit (to circumvent issues in fpcunit, but did take some fpcunit ideas with me) and started my own testing framework. I'm starting to dislike Lazarus IDE (every release is more buggy that before), I already started work on my own IDE. I strongly believe in the saying: "put your money where you mouth is", and I'm not afraid in doing so either. I write software to solve problems, not make problems. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 09:04, Florian Klaempfl het geskryf: > Other people spent years of their life into getting something working > and now suddenly somebody pops up and thinks he can do better? It's called evolution. Every new generation is supposedly producing more clever people than the generation before. It's been proven to be true more often that we would like to admit. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 12:08, Aleksa Todorovic het geskryf: > > On the other hand, you can always make a fork, and have Graeme > criticize your code in several years ;-) Hey, that's a cheap shot. Be nice. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 12:43, Adem het geskryf: > This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I > have never seen it come up anywhere else. +1 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 13:02, Aleksa Todorovic het geskryf: >> First, how would you prove you're worthy of the task? > > Firstly, you need to understand how FPC development works, and to > accept that. Secondly, you need to show other FPC developers that you > are willing to work (continuous task) and work as part of team. This is where I think FPC and Lazarus teams get it all wrong. Not everybody wants to "join for life", hold hands and cuddle around the source code. Many times I use a tool, find a bug or annoyance, fix it and contribute back by supplying a patch and most importantly, MOVE ON. It's up to the FPC devels to review and commit those changes. But no, we must first fight about it for ages, prove ourselves to the ends of time before anything is accepted "outside the close family unit". There loss, not mine. God sakes man, this is ridiculous! Look at other successful open source projects - they don't work like that. If your patch works, that enough. No need to prove your loyalty shit. The FPC and Lazarus teams keep bitching about not having enough contributors. Well, you can start by NOT MAKE IT SO F**KEN HARD TO CONTRIBUTE. I've taken the following stance with the Lazarus team. I contribute, and forget about the patch. They can do with it as they please, I did my part. It works on my side, git makes it easy to ingrate that fix/feature after every update, that's what's important to me. That's not a very successful way from their side in running a open source project, but they left me no choice. I don't have time to quibble over every line of code I changed. FPC seems to follow closely behind the ways of the Lazarus team, and that makes we want to contribute even less. Martin Schreiber (author of MSEide&MSEgui) seems to have the write approach. Fork everything in FPC (one of his examples being sqldb code), and maintain that code yourself. No hassles, less stress, a happy life. If FPC team wants any of his changes, they can go fetch it themselves. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 13:40, Jonas Maebe het geskryf: > > That's fine for simple patches and such patches are normally directly > committed to FPC. If someone wants to rewrite/restructure half the > compiler however, then it's not fine, because such a patch can easily Valid point. But sometimes [in my case more relevant to Lazarus project than FPC project - to be fair] a relatively small patch is contributed, but then it is totally blown out of proportion - as if it was a total rewrite of something, which it wasn't. Such actions alienate contributors - ending up in the project receiving less and less contributions (big or small). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 13:30, Helmut Hartl het geskryf: > > That's the language spoken on other places. ...and I should forward you some of the private messages I received after discussions in FPC or Lazarus mailing lists. Yes they kept it in private, but the language used and personal insults will make Linus's message look like a saint. So here is no better than there. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Op 2010-10-22 12:47, Hans-Peter Diettrich het geskryf: > > Regardless of the reasons, a separate git repository would allow for any > number of additional contributions. My problem still is how to set up > such a repository, for public use, and how to sync it with the SVN > trunk. Can your fpc/Lazarus git repository be used for that purpose, or > can another repository refer to and stay in sync with it? I don't actually know how collaboration (write permissions for others) work with GitHub, that is why I suggested SourceForge. Just keep in mind, Git is a distributed VCS, you can pull and push from/to anywhere. The repository in GitHub is just a "public view" of one repository, mimicking the "single server repository" model of SubVersion, CVS etc. Yes you can clone the GitHub mirror as a starting point, then publish your branches to wherever you want. At the moment the github mirrors of FPC and Lazarus are a one-way street. I setup our server to only push Trunk commits from SubVersion to Git. None of my personal branches end up on GitHub's mirrors. Public collaboration can easily be accomplished via Pull Requests (the contributor notifying you of the server and branch you can pull from), or posting patches via email (newsgroups or mailing lists). Git has excellent email+patch support (official method used by git.git project itself), and can extract and apply patches directly from emails without hassle. If you do the latter, it would be wise to get organized early on. This is what Junio (from git.git project) does so well. Each contributor gets his own branch (usually by using initials) in Junio's local repository. Those contributor branches will exist until the features is dead (not going to be accepted), or until it made in into 'master' (what will become the next release). Keeping them in branches makes the job really easy for git. You can quickly query another branch to see what commits haven't been applied/merged yet, apply additional commits (improvements to the original patch) etc... I highly recommend you email Junio in person, or post to the git mailing list for some guidance. Junio does an excellent job, and taking into account that he is one man running most of the git repository tasks, cutting releases etc. Very impressive for such a busy project. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 22 October 2010 20:20, Marco van de Voort wrote: > > 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
2010/10/23 Adem : > work, use git to ingrate that fix/feature after every update. > This way, you will have micro-forked FPC (or Lazarus or whatever) but it is This works very well indeed. I have +- 15 such feature branches for Lazarus IDE alone, and it takes all of 1 minute to rebase and merge them into my own work branch - after a update. > Now, if only Graeme wrote up a comprehensive (and comprehensible) howto for > doing that :) I think I've done this a few times, but here goes again. $ git checkout master $ git pull github master The 'master' branch is the branch on github that tracks the SubVersion trunk branch. $ git checkout feature1 $ git rebase master $ git checkout feature2 $ git rebase master 'feature1' and 'feature2' are branches that implement the features I need, and that are not included in Lazarus or FPC svn repositories. The rebase command resets that branch to be identical to 'master', then replays the commits on top of that. This makes the repository history linear, and looks as if I implemented those features on top of the latest commit in 'master'. $ git checkout master $ git checkout -b work Start from the 'master' branch, then create a 'work' branch off of 'master'. I'll use the 'work' branch to apply/merge all my features I want. This will be the branch I use on a day to day usage. $ git merge feature1 feature2 This now merges the 'feature1' and 'feature2' branches with the current 'work' branch. Now simply recompile FPC or Lazarus using this 'work' branch. It will then contain the local features you want, without having to bother the FPC or Lazarus team members. When it's time to sync with subversion, by pulling new updates from github, simple redo the process above. You can even place all these commands in a script or batch file to speed things up even more. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:09, Florian Klämpfl wrote: > > Oh yes, the vcs is to blame for poor commit comment. Or maybe actually manager YOUR project better, by telling all the read/write users of your project to give better commit messages. Nobody can describe a patch very well, and the reason for the patch in a single line commit message. Just to 'svn log' or 'git log' and actually look at the history of the FPC project and the commit messages of each commit. 99% are one liners. So with such bad practices of yourself and of your team members, you are setting a terrible example. That clearly rubs off on the new contributors - they just follow the example that was set before them. Your are to blame, because you don't manage your project well, or set down some basic (logical) rules for all your team members. Having descend commit messages for a patch that explains what the patch does, and why the patch is needed, will making it so much easier for the person reviewing that patch. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:11, Marco van de Voort wrote: > > I don't understand what providing quick and dirty patches that How do you get to 'quick and dirty'? Not every small patch is a hack or quick or dirty. The same applies for bigger patches. If the author of the patch simply explains in the commit/patch message (git automatically includes those when you email a patch, subversion doesn't) what the patch does, and the reason for the patch, applying that patch should be easier for the person reviewing that patch. They have more detail regarding the patch and what it should do - no guessing required. But the FPC & Lazarus team set such bad examples (just review the repository history and lengths of each commit message, new contributors just follow suite. Sergei Gorelkin seems to be the exception in the FPC team - he is about the only one that seems to give (above agv) multi-line commit messages, explaining in more detail what that commit does. Jonas Maebe being second after Sergei. Learn from those two! -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:43, Florian Klämpfl wrote: > > Why shows git log only a one liners? I though using git fixes this? God, now you're being stupid too. 'git log' if you are using the FPC git mirror, or 'svn log' if you are using FPC's subversion repository directly. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 24 October 2010 19:50, Florian Klämpfl wrote: > > Everybody gets the replys he deserves :) That's correct. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Programming Language Index (tiobe index)
Top 20 languages for 2010 so far: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Hey, Delphi (aka Object Pascal) is 12th - that's not bad, though its ranking is falling. :-( But again, look at that spike back in 2005. Just shows what new management can do. http://www.tiobe.com/index.php/paperinfo/tpci/Delphi.html Good old Pascal (procedural non-Object Oriented one) is not doing bad either, sitting steady at 15th place. Wow, here are some interesting graphs for you. This one just goes to show what a populare product(s) like iPhone and iPad can do to the popularity of a programming language. http://www.tiobe.com/index.php/paperinfo/tpci/Objective-C.html And what's up with Ada? Moving up 12 places from last year. I thought that language was done and dusted, or maybe I got confused with another language. Visual Basic! Wow, is anybody still using that?? It's falling fast, but still up there in 5th place! http://www.tiobe.com/index.php/paperinfo/tpci/%28Visual%29_Basic.html Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Programming Language Index (tiobe index)
Op 2010-10-26 14:55, Florian Klaempfl het geskryf: > > What new management? CodeGear was announced by the beginning of 2006 and > Delphi was sold in 2008. However I admit, I cannot give any reason for > the spike in 2004/2005. Ok, then I must have gotten my dates wrong. It is weird though. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] News on Delphi x64
Op 2010-11-01 11:26, Sven Barth het geskryf: > > A little entry about some details of Delphi x64 I stumbled on today: And let me guess, they took no cues from FPC, and had to make sure there is as much "incompatibility" as humanly possible! This is why I say, FPC should cut any ties with Delphi and simply innovate on it's own. > > So, Extended = Double. > > // how is this in FPC? Extended is just not available on x86_64, or? > (well... I don't use Extended anyway ^^) FPC has Extended and it's rang is 19-20 significant digits with range: 1.9E-4932 – 1.1E4932 It's size is 10 bytes. > > Type sizes for 64: SizeOf(Integer)=4, > SizeOf(NativeInt)=SizeOf(Pointer)=8, Oh f**k, please don't tell me FPC is now going to downgrade Integer to a 32-bit type. This will break such a LOT of programs!! > // they needed to call it NativeInt, didn't they? They couldn't have > gone with PtrInt -.- Definitely not, because that would be FPC compatible. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [Lazarus] News on Delphi x64
Op 2010-11-01 12:21, Sven Barth het geskryf: > > E... In modes "objfpc" and "delphi" SizeOf(Integer) = 4 is already > the case no matter what bitness your system has. For that purpose Oh, when did that change? I looked up the information in FPC's Language Reference docs "Predefined integer types" table. My copy had Integer as 2,4 or 8 bytes. I just downloaded a new copy of FPC 2.4 Language Ref, and indeed that table has been update to show 2 or 4 bytes as the Integer size. Ummm... interesting. > "exit with argument". In a comment to that a Delphi developer said "We > never broke compatibility with FPC on purpose". It's a pity that I'm not > able to find that statement again :( I'm sure Embarcadero deleted it off the internet. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [Lazarus] News on Delphi x64
Op 2010-11-01 13:02, Sven Barth het geskryf: > > It was always the case in the implementation (as far as I'm aware of), > but it might be that the documentation didn't reflect that ^^ Yes, Michael just confirm that. The docs were wrong. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: [fpc-devel] Interface scope incompatibility with Delphi
Op 2010-11-11 13:05, Thaddy het geskryf: > Graeme should realize that the Delphi compilers (or MS compilers or > Watson, or Intel) can all drive you nuts with behaveour beyond the > documentation or beyond logic. Sorry, but I disagree. I had a lot lets gray hairs using Delphi 7 (maybe even Kylix 3) than I do with FPC. > At least with FPC, you can do something about it, like with the GNU > compiler set. That is not a certainty! Say I had the expertise, and I did manage to fix my current problem so that it behaves like Delphi, it will NOT be accepted in the offical FPC source tree. So what good is it that I got my hands dirty and fixed the problem? Yes it's fixed on my system, but not any anybody elses, so it's useless for the tools and frameworks I develop. Unfortunately I seem to have bad luck, all my problems are normally something that will not be fixed in FPC (for whatever reasons). Op 2010-11-11 14:58, Henry Vermaak het geskryf: > someone else to pick up and continue. At least with fpc you can jump > in and fix it yourself, or even hire a compiler developer on contract > to do the work inside an agreed time scale. Still wouldn't work in my case, see above. So hiring a skilled compiler developer or putting out a bounty will not solve my problems. So there goes my ideas of using FPC to develop two commercial developer tools: a cross platform installer and an alternative debugger toolset. Unlike Delphi, I can't ship FPC compiled .ppu units that other developers can simply use. So I need to supply source code, which in turn needs to be compiled by the official FPC compiler (not my personal hacked version). Now you might understand my frustrations with FPC, it's killing my business ventures. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-devel] Interface scope incompatibility with Delphi
Op 2010-11-11 15:32, Henry Vermaak het geskryf: > obviously, or do you think that relying on undocumented behaviour is a > good idea? Look what happened with flashplayer in fedora with the > current memcpy fiasco. Sorry, I don't know about that problem. I've never used Fedora. > From over here it looks like you are killing your business ventures by > basing the implementation on dangerous assumptions. Well, in the case of Delphi, and the fact that it (this interface behaviour I discussed) has been working for use for just over a decade is not bad going, and good enough for me (and clearly for other ISV's too). Having to tweak your code once every decade is not a considered a problem. > Btw, why this cross platform installer? Simply because what is out there is rather crap. To big 3rd party dependencies (a Java VM, large Qt libraries, large GTK libraries etc), way too expensive, doesn't always support console and GUI etc. My solution works on any system with or without a GUI. And if the latter, just a bare mininum GUI (in the case of Linux/Unix - just minimal X11 setup) is needed. It's XML driven, scriptable, customizable and comes with a graphical Install Builder too - designed for the Free Pascal developer, but not limited to them. My installer favours the GUI (but doesn't shun console needs), so Linux desktop users can finally have single file setups and simply the "next, next, finish" experience Windows users have had for so long. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-devel] Interface scope incompatibility with Delphi
Op 2010-11-11 16:42, Henry Vermaak het geskryf: > much deeper than just tweaking. They've based their implementation on > undocumented features. And many others have done similar things: in Delphi language, Delphi IDE, Microsoft OS, in Unix OS etc... It might not be "ideal", but it is a practise that's been around since the dawn of computers, and seems an acceptable risk. > Will you integrate with existing package managers? It is planned yes, but might not be in the first release. > If not, how will you deal with dependencies, upgrades, config files? I'm targeting the "desktop developer" market, not the OS, Library or Desktop Development Environment (Gnome, KDE libs themselves) market. The latter already have solutions via the many variations in package managers. In cases like Delphi, Lazarus, Kylix, fpGUI, MSEgui based projects projects, it is normally just copying files around, registering a service or DLL, and creating icons. But that is not the extend of the installer. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] fpGUI Toolkit v0.8 release for FPC 2.4.4 & 2.6.0-rc
Hi, I'm glad to announce the next release of fpGUI Toolkit. fpGUI v0.8 -- An archived source download and pre-built binaries for DocView (fpGUI's Documentation Viewer) can be found at the following URL: http://sourceforge.net/projects/fpgui/files/fpGUI/0.8/ ...or clone the source code repository by using any of the following commands: from SourceForge: git clone git://fpgui.git.sourceforge.net/gitroot/fpgui/fpgui from GitHub: git clone git://github.com/graemeg/fpGUI.git or git clone https://github.com/graemeg/fpGUI.git Pre-built documentation in the highly optimized INF file format (for use with DocView) is also available for download in a single archive, just 1.7MB in side. The archive contains the fpGUI Toolkit API documentation, and for your convenience, I also included the Free Pascal Language Reference, FPC Runtime Library and the FPC Free Component Library. http://sourceforge.net/projects/fpgui/files/fpGUI/Documentation/ For more details, please visit the fpGUI home page: http://fpgui.sourceforge.net The v0.8 release contains a lot of added features and enhancements. Below is just a small list of things that added or changed. v0.8 (2011-11-02) - New widget demos and many improvements to existing demos. - New application examples * Spinning Globe, show some graphics support with zooming. * An experimental IDE called Maximus, which supports project management, compiler settings management, macro management, multi-threading enabled, fast procedure list searching, syntax-highlighting enabled text editor, OS independent file monitor support etc. - PDF reporting engine and preview support. Thanks to Jean-Marc Levecque for this awesome contribution. - Huge improvements and enhancements to the Treeview widget. * massive speed improvement * improved painting support * extended treeview and node method calls * state image support (eg: having checkboxes next to nodes) widget. - Many Docview (fpGUI documentation viewer) improvements * Bookmark support * Improved annotation support * Improved the text rendering and text wrapping * Rewrote the font handling which gave a massive 200+% speed increase in startup times (depending on the amount of fonts you have installed on your system), and reduced memory usage by 50%. - Added image support to RichView, the text viewer used by Docview. - Two new supported platforms: OpenSolaris and MacOSX (with X11 support). - Global keyboard shortcut support for menu items and actions. - fpGUI API documentation has been extended and improved. - OS independent DND (drag-n-drop) support has been implemented. This supports external application-to-application and internal widget-to-widget drag-n-drop. - Improved the workings of implementing context sensitive help inside your applications. - Improved fpGUI project templates for use with Lazarus IDE or MSEide. - Included the WIPFC (OpenWatcom IPF Compiler) binaries to allow you to compile your own IPF help files into binary INF help files. - UI Designer (the visual forms designer for fpGUI) has seen many improvements: * new components on the component palette. * new properties accessible in the Object Inspector * improved dialogs for "tab order" and "widget order" changes. * code generated can now use spaces or tab characters for indentation. * improved File menu layout and new options. - Improved themes support - Experimental MDI (multi-document interface) support - Extended the Unicode wrapper functions for the FPC's RTL file handing functions. - New built-in code page conversion functions have been added. - Grid widgets have improved scrolling support options. - Improved fpGUI language translations. - Many, many more bug fixes and improvements. For a full list run: git log v0.8...v0.7 -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: [fpc-pascal] I found FPC v0.2 source code :-)
On 30 January 2012 12:05, Mark Morgan Lloyd wrote: > mainframe switchmode PSUs, so with apologies to the list owner I'm probably > in a position where I have to comment on this for safety reasons. > > My advice: don't. Thanks for the warning. :) > any number of stories about people who've done something that they thought > was safe which has gone on to cause damage or injury. Same could be said for ridding a motorcycle (which I do often) or even crossing the road, but I get what you are saying. > Things like the output wire on low voltage PSUs are fair game for repair. > You can get spare concentric connectors from RS or Maplin in the UK (Graeme- > I thought you were abroad?) I lived in the UK for 4 years, and moving back there in 2 months time. > unopenable by hand i.e. you /had/ to use screwdrivers etc.) then I'd suggest > looking around for something like a C&G-accredited electronic technician > course- which full-time would take years. When I finished high school (many many years ago), it was a coin flip between studying pure programming or electrical engineering (light current) and hardware programming. I opted for the pure software programming, which has been my career path ever since. But I have always had the urge to start some part time studies to get an Electrical Engineering degree - those little colorful bits of electronics just fascinate the hell out of me (even 20+ years later). :-) Thanks for the URL, I'll keep that handy in case I ever need some electronics repaired. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Re: [fpc-pascal] I found FPC v0.2 source code :-)
On 30 January 2012 12:17, Henry Vermaak wrote: > > I'd advise against fiddling with switch mode PSUs. See my other message to fpc-other mailing list. I have had a very long interest in electronics, I just never pursued it. Maybe it's time I scratch my itch. :) I have two pieces of electronics that recently failed, and no easy way to replace them. One is a small AC power supply to a wireless access point. It uses a 5V power supply, which I just can't find anywhere here in South Africa - other that buying a whole new Wireless Access Point. :-( The other is a SATA-to-USB/Firewire400 adapter. I used it purely for the firewire port. I can see some bits turned dark/black on the pc board, and it smells like burn. I just have no clue how to repair it. Nobody in our area wants to touch it either. :-( > they turn out to be pretty crap (due to the cheapness). Repair cables and > connectors, perhaps even replace bulging capacitors, but apart from that, > this is not hobby material! I beg to differ. Case in point. My wife's uncle is a rep of some sorts for a large chemical supplier. His hobby is acoustics - those old valve amps and very weird looking speakers etc. Nothing related to his day-time job. Clearly valve amps are not as easy to come by these days, and neither is getting somebody to repair them. He started looking into that many many years back. He is now the local go-to guy in Gauteng, South Africa, to have your valve amps or speakers repaired or modified. :) He is on the verge of retiring, and guess what? He wants to officially make his hobby into a post-retirement career. :) Programming is fun, but there are so many other things that are fun too. I'll probably enroll into some electronics course, because as I stated earlier - I have a huge interest in light current electronics, I just know nothing about it (but would love too). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] I found FPC v0.2 source code :-)
On 30 January 2012 13:44, Henry Vermaak wrote: > > Can't speak for RSA, but this is the reason people don't fix these things > here: Just one more reason to add to my list of why I am moving back to the UK. ;-) We get those "multi adaptors" that give 1.5, 3, 6, 9 or 12 volts, but just not 5v. :-( -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] I found FPC v0.2 source code :-)
On 30 January 2012 14:44, Mark Morgan Lloyd wrote: > > A multi adapter set to 3V will give you about 5V lightly loaded, and set to > 6V will give you about 5V on moderate load. The point about the ones that > Henry cited is that they're mini switchmodes, they've got stable output and > run cooler than "wall warts". Using the 3V setting doesn't power up my Wireless AP. Using the 6V setting does, but it ran very hot, so I opted to stop using it until I could find a 5V adapter. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-pascal] I found FPC v0.2 source code :-)
2012/1/30 Adem : > > Make sure you get the same of greater wattage as that of your old adapter. Thanks for the tip and the URLs. Seeing that I'm moving back to the UK, I'll rather order one after I relocated. Postage and Important duties in RSA normally more than double the price of any overseas order. :-( > One more thing: Don't know what kind of connector you will use/need, in the > worst case, you will have to nip off the connector from the old adapter and Yeah, that shouldn't be a problem. I have some soldering skills. ;) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Firemonkey progress so far
Hi I've been following the Embarcadero Firemonkey newsgroup for a while now. For those that don't know, Firemonkey is the cross-platform replacement for VCL, and currently targets the Windows, Mac OSX and iOS platforms. Well, so far it seems Firemonkey is worse off that CLX was. The most basic functionality is still missing, and no good documentation. Simple things like loading a text file's content, getting the parameters passed to a program, ActionLists etc are all major issues with Firemonkey. Also the application code I have seen posted on the newsgroup is littered with IFDEF statements too - not a good sign for a cross-platform library. And then the worst thing that can happen in a cross platform framework - the same code/functionality behaves differently under the "supported" platforms! It seems Embarcadero rushed it and released an "alpha" version of Firemonkey to the public, instead of a 1.0 version. This is surely going to hurt their reputation a bit. The "no updates" after 11 months policy is also not helping them much either. I guess frameworks like LCL, MSEgui and fpGUI are still safe for a while - and the better choice for true cross-platform development. :) Way to go Open Source Software!! -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Firemonkey progress so far
Hi, On 9 August 2012 10:35, Mark Morgan Lloyd wrote: > > Perhaps this would be a good time and place to summarise where MSEgui and > fpGUI are with respect to a form designer and IDE such as Lazarus? fpGUI is 100% IDE independent - you can use any IDE or programmer editor. The help viewer and form designer are stand-alone tools, so work anywhere, but they can also be integrated (called via an External Tools menu item for example) from existing IDE's or Programmer Editors. I personally use both Lazarus IDE and MSEide to develop commercial fpGUI based software. No IDE is perfect, and that is why I use both. Each have their own strengths (eg: Lazarus IDE has better code navigation, but MSEide's code template design rocks). At this point I have no intention in developing a full blown IDE - I see no need for that in fpGUI. The "Maximus IDE" sample project included with fpGUI is just that - a sample project to maybe show of some more advanced features of fpGUI, or simply a more complex sample app (seeing that all my commercial projects are closed source). As for MSEide's form designer I don't develop MSEgui based apps, so I don't use the integrated form designer in MSEide, but from what I have seen, it seems very capable. The IDE has a whole is very fast, light on resources and very configurable. The flexibility in Project Settings is also fantastic. Overall I find MSEide much more stable than Lazarus IDE. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Firemonkey progress so far
Hi, On 9 August 2012 11:49, Mark Morgan Lloyd wrote: > > And how about the second part of the question? I do not understand? > I notice that Lazarus now provides the option of using fpGUI as the widget > set for generated projects: to what extent is this complete? Lazarus has had the LCL-fpGUI widgetset for years. I do not head up that development, but do submit patches from time to time. As far as I remember all the widgets from the 'Standard' component palette works, and a few other features. For more details on its progress have a look at the following wiki page. http://wiki.freepascal.org/Roadmap#Status_of_features_on_each_widgetset -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Easygit and Git discussions (moved from fpc-devel)
Hi, On 2012-09-25 19:15, Bernd wrote: > default it is doing its best to be as cryptic, strange behaving and > unaccessible as possible. I almost believe Linus did this on purpose. That was maybe the case in the early days of git versions leading up to v1.0. Since then Git commands have been radically simplified. Maybe you should try a git v1.6.x or v1.7.x branch again. > It needed easygit to finally make me comfortable with git and see its > advantages. I had a look at easygit, and I really don't see the "advantage" compared to git v1.6.x or git v1.7.x - because all the easygit commands are near identical to the real git commands. Easygit seems outdated too, because they "introduce new features", but those "features" already exist in git. http://people.gnome.org/~newren/eg/documentation/list-of-changes.html for example: --- Changes to branch: 'eg branch' is identical to 'git branch' other than adding a new -s option for switching to a branch immediately after creating it. --- ...well in git you simply do 'git checkout -b ' and it will create the branch mentioned, and check it out for you. Going through that list of changes, lots of the functionality mentioned in easygit has already existed in git for some time. So it seems easygit was a good idea in the early days of git, but definitely lost it relevance in git v1.6.x and git v1.7.x releases. > git commit -a This command is only great for the initial commit (importing new source code) of a Git repository. Using the -a parameter every time, and you loose so much of the benefits of git, and staged commits. For example: I do development work for a hour or two, then start committing. Even though I might have made lots of code changes, I believe in small atomic commits (something the -a parameter is not, and neither is 'svn commit'). So I launch 'git gui' select the hunks I want to commit, or even select only certain lines inside a hunk to be committed. I repeat this until all the code changes I want is committed. At the same time I can discard (revert) debug changes I don't want to commit, like debug writeln() statements etc. Small atomic commits is key to an easy to manage repository, plus it makes 'git bisect' and 'git log' infinitely more useful. Speaking of 'git log'. Here is a comparison of 'eg log' vs 'git log' output. I find the latter color coded output much easier to read. See attached image. Then doing commands like 'eg show' in actual fact simple executes 'git show' with no extra modifications. So you get the full benefit of git with color highlighting, showing diffs in red/green/cyan. > pull from and push to by default, git has some totally unintuitive > defaults and surprising behavior for many things I have no idea what you mean. > and btw the git help you mentioned is the worst help I have seen so > far in the last 30 years. Try eg help to see how helpful help needs to > look like. "eg help uses its own help system, ignoring the one from git help...except that eg help will call git help if asked for help on a subcommand it does not recognize. The git man pages are really nice for people who are experts with git; they are comprehensive and detailed." --- from the 'eg help help' output So other than the very basic 15 lines of help output for the odd 10 commands 'eg' knows, it actually uses the real git help. :-) The 'eg help' is a help summary at best. Just an overview of what a command does. It gives no real help with various git usage examples etc. that the actual git help does. Then, did you actually bother to read the official Git online help, Pro Git book, Git User Manual etc? http://git-scm.com/docs Detailed help with images and graphs to help explain and visualise things. Tutorial videos (thanks to the GitHub guys) etc. For an open source project, Git has pretty impressive official help with lots of very valuable real usage command examples. No to mention the thousands of unofficial git help sites out there too. Anyway, like I said. I think there was a time when easygit could have been useful. But with the latest versions of git, it is already so easy to use, it makes easygit obsolete. And if the command line is too much for a git newbie simply create some desktop icons for 'gitk --all' or 'git gui' or 'git gui blame ' Lets just be glad you are using git and not svn any more. ;-) Cheers, - Graeme - <>___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-26 14:22, Henry Vermaak wrote: I haven't found a project that uses NNTP for a long time. fpGUI - GUI Toolkit since 2005/6) tiOPF - Object Persistence Framework since 1999) OpenWatcom - C/C++ Compiler,IDE,Debugger,etc. Indy - Internet components used by Delphi and FPC. NexusDB - Database server split from TurboPower FlashFiler since years ago. Embarcadero - all products, announcements and developer areas Usenet - Over a 100,000 newsgroups already. Yes, alt.binary is probably the biggest contributor to the 9 TerraBytes of storage requirements, but areas like comp.lang.* is still being used by programmers and IT admins today. Use Google Groups to see recent posts. ...the lists can go on. You just haven't been paying attention. ;-) How do you know it's the most used? Considering Usenet was launched in 1980 already, has over 100,000 newsgroups, plus the thousands of private hosted NNTP servers around. And yes (as somebody else also asked), I did actually read recently some web page about NNTP usage statics. NNTP is still very much used. My main problem with it was that you can't keep track of read messages across different computers. Mobile users tend to use laptops, so no problem there. Alternatively, use you smart phone and install a NNTP client there (iOS and Android has NNTP clients). If the project you are monitoring doesn't get 1000's of new messages a day (I even consider Lazarus discussions small) it is still not so much of a problem marking a bunch of message as read. Simple "mark as read by date" functionality exists in most NNTP clients (I know Mozilla Thunderbird does). Even temporary changing to unthreaded view and order-by-date is a quick solution. There are lots of benefits to NNTP though: - easier to navigate than web forums - hierarchy of conversations are standard - you can choose your favourite NNTP client - new users can follow existing discussions by seeing past messages easily. Mailing lists fail miserably here. - It's a pull medium, not a push medium. So I only see message when I really want to. - a clear separation between my email and project discussions - simpler to prevent spam - messages can be cancelled if posted in error - offline reading - offline searching - way faster than web forums ...etc Regards, - Graeme - ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 10:29, Henry Vermaak wrote: None of the FOSS projects I've worked with have used NNTP. That hardly makes NNTP obsolete. It just means we move in different "software" circles. Do you have a list of _actual_ benefits of NNTP? Right back at you for Mailing Lists and Web Forums. Graeme. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 10:11, Sven Barth wrote: I think Henry meant that differently. I understood Henry perfectly. I worked like that too. Desktop and work, and laptop at home. Maybe our tolerances to what is "brain energy" is quite different. Maybe Henry just hasn't bother to learn the shortcuts or features of the News client he uses. Take Mozilla Thunderbird as an example...here are some shortcuts: R - mark whole thread as read. If the topic doesn't grab my attention this option gets used often. N - Jump to next unread message. This jumps across message topics too. I also have Thunderbird setup to mark a message as read as soon as the message has been opened - no delays. C - short for "catch-up". Mark message as read between dates. Great for if you have been away on holiday, and don't care about old topics. \ - collapse all expanded message threads. Quickly giving you an overview of what is going on. There are lots more like these. Then I haven't even touched on message filters. eg: I have standard filters in email and news clients that mark topics in green if they replied to one of my messages, or it has my name mentioned. With all these, it literally too me <10 seconds to sync my home laptop to the same message state I left my work PC. Considering how long it takes to actually read and reply to messages, than <10 is hardly any effort or "brain energy". Now these things simply can't be done with Web Forums. 99% of them have linear views (think Gmail layout here) or hierarchies (of whole messages), and not just a hierarchy of titles. So you scroll and scroll and scroll and scroll and scroll.z... Oh, and then each new topic needs to be clicked and whole web pages need to be reloaded, with MB's of images and JavaScript etc, and that is so damn slow compared to NNTP clients which just pulls the actual message when you need it. I have a 60Mb fibre optic internet connection, and I still think web forums are slow! I don't care how old the NNTP protocol is. The reality, even after 30+ years, is than Newsgroups are still miles ahead of the current 'web forums' idea. Graeme. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 11:13, Mark Morgan Lloyd wrote: > best to organise a backend, particularly in view of typical > discussion-group (innd etc.) servers' very poor resilience to e.g. > abrupt shutdown. I use 'sn' NNTP Server. It runs on just about any *nix type operating system. It is ideal for small to medium size newsgroups and has pull support. I must say that it holds up very well to abrupt shutdowns, like power failures etc which South Africa is very prone to having (many power failures per year). Touch wood, I have been running sn for 7 years, and haven't had a single corrupt newsgroup, but maybe the secret is in how sn stores its messages. One directory for each newsgroup and lots of numbered files (they look like text with a small 2 line binary header). Each numbered file stores something like 10-15 messages. I'm using sn v0.3.8 Graeme. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] How can i make FPC's mantis to notify my by email ?
On 2012-09-27 21:45, ik wrote: > How can I make it notify me by email on changes only of things I > opened, or took part of ? +1 Even my home-grown (in-house) bug tracking software I wrote has this ability. I know in Mantis the notifications are totally disabled for the FPC project, and as you noted, everybody get flooded with emails in the Lazarus project. Graeme. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 08:34, Sven Barth wrote: > > Btw: Do you know where this "S" with accent comes from? I have noticed > this in nearly every mail of you already. I see those too. It seems his email client (Outlook for Mac v14) is not setup very well. Some of his posts are encoded ISO-8859-1, which is when I see those Š symbols. And sometimes his posts are encoded as UTF-8, which then appear normal. Graeme. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-28 10:38, Henry Vermaak wrote:
> already explained why I prefer email, but I'm not trying to convert
> anyone.
Neither am I. I just pointed out my opinion and experiences. Some seem
to read more into that than I.
> It's interesting to note that both fpgui and mse{ide|gui} are using
> NNTP;
Actually you are wrong. MSEide+MSEgui uses a mailing list. Some of those
developers (just like in Lazarus and FPC mailing lists) use GMANE to
read/write via a NNTP client.
Graeme.
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Last message about changes (guaranteed!)
On 2012-09-29 13:36, Cephas Atheos wrote: > How many of you reading this message could, say, at 6:30 tonight, fix a > configuration problem on the mailing list server, if whoever usually looks > after it got called away and was uncontactable? From where you sit right > now? What about if a hacker logs in to the list and starts spamming the Ah yes, another benefit of NNTP. No spamming of every inbox out there. Remember, NNTP is a pull service. Any admin can delete the spam message before it ever reaches everybody's nntp client (like the case with mailing lists). > list? How long would it take to shut them down? Speaking as a person has already been moderated, and that constantly get harassed by mailing list admins because my tone is a bit offensive to their ears.. They seem to act quickly. Personally I think the mailing list is not the worse part of the Free Pascal Project. If I was you, I would rather concentrate on the website design, and improving how easily one can get to information one seeks. > Every new user would know instantly how to log in, how to search, and how to > ask questions and how to find answers, with no change that anyone has to Ah yes, another big annoyance of web forums. You have to log in first before you can post. Newsgroups that require authentication (like Embarcadero's), my NNTP client does the authentication for me automatically. As for your usability statement. Posting a newsgroup message is exactly like posting an email. Click "new message", type, click "send". I think my 4 year old can do that already. > Hey, if you like pain, go for it! But please don't expect new users to want > to go through the same arcane process. Because I can tell you, right now, > that they don't. And they aren't going to in the future, either. I appreciate what you are trying to do - making it easier for new users to the Free Pascal project. But lets also not belittle the intelligence of a programmer. I think it is safe to assume programmers have a little bit of intelligence - after all, programming requires reasoning and problem solving skills. So dumbing down everything to a level that actually insults programmers-by-trade is also a bit ridiculous. For example.. you mentioned earlier about the "oh so scary subversion, we should hide that from newbies". Well, what damn programmer - in this day and age - doesn't use version control. Everybody should be using it, it should be a standard tool in there programming toolbox. If they have never heard of it before, they should maybe think of moving into a different field of work. Disclaimer: Yes, this is my personal opinion, not the opinion of the Free Pascal project. I admit, I have zero patiences, and I hate people that think they must be spoon fed everything. Programmers should be able to think, problem solve and do research (reading documentation). Graeme. ___ 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
On 2012-10-06 00:08, Cephas Atheos wrote: > > You're not seriously comparing nntp clients with > browser clients and claiming that news servers are just as popular and > useable as forums, and more reliable to boot? Seriously? Seriously? Well, I think so. > One of the critical points I tried to make when suggesting a forum as an > option, was moving ALL the historical data to the forum DB, to make it Well, maybe try and do that first, because telling everybody to try the forum. Currently there is NO historical data in that forum you setup. I also couldn't find a way to show a treeview style list of discussions. I rely on a treeview style overview of conversations... who replied to what message. This is why I hate Gmail, as it simply lumps the last response to the bottom of a long list. That doesn't give me any indication to what message that person replied to, and I can't follow the various branches (discussions) in the same thread. > professionalism or my discipline, simply because I recommended an > improvement to the current state of the FPC site. Maybe you are tackling something that isn't actually a problem. The mailing list (even though I don't like them much) are working. Maybe concentrate your efforts on the website improvements instead. Get more usable information easily available on the FPC home page. Add a more detailed menu on the FPC site so we can pick what we want to view, without navigating through many static pages, etc. Regards, - Graeme - ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Job offer for software developer
On 2012-11-05 15:27, Sven Barth wrote: > > as we plan to redesign our main software we are looking for > Pascal/Delphi developers to extend our team in Munich, Germany. Is it a on-site job (location Munich), or can you work remotely via the internet? Regards, - Graeme - ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
