Re: [fpc-devel] no logo
On Wed, Mar 20, 2013 at 1:23 PM, Marco van de Voort wrote: > In our previous episode, Vittorio Giovara said: > > is it possible to disable printing the fpc logo without editing fpc.cfg > or > > redirecting the output? > > Yes, disable loading of fpc.cfg with -n > That indeed works too, abeit a little more complex. What about the ppas.* script? Is it possible to have it not print anything? Thanks, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] no logo
On Wed, Mar 20, 2013 at 10:24 AM, Mattias Gaertner < nc-gaert...@netcologne.de> wrote: > On Wed, 20 Mar 2013 10:17:48 +0100 > Vittorio Giovara wrote: > > > Hi, > > is it possible to disable printing the fpc logo without editing fpc.cfg > or > > redirecting the output? > > You can disable any option by appending a minus. > > fpc -l- > > Mattias > Thanks, that did the trick! Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] no logo
Hi, is it possible to disable printing the fpc logo without editing fpc.cfg or redirecting the output? Thanks, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of code collaboration
Hi all, So some time has passed, do you think we could reach an agreement on the GSoC collaboration? We have to submit our application by the end of this month but I would like to set up a tentative schedule beforehand. Can we work on this together? Vittorio Sent from my iPad Mini On 21/feb/2013, at 10:37, Vittorio Giovara wrote: On Mon, Feb 11, 2013 at 9:59 AM, Jonas Maebe wrote: > > On 10 Feb 2013, at 22:32, Vittorio Giovara wrote: > > What about (d) is this project feasible? If not, is it can you split in > > (parallel) sub projects so that more people can tackle it? > > I really don't know whether it is feasible. There is definitely a lot of > work that needs to be done to get a clean result, some of it fairly tedious > (such as creating complete type definitions for types that are currently > opaque in the compiler, like VMT layouts and RTTI). I'm now leaving on > holidays for 3 weeks, maybe I'll have a better idea when I come back :) > > I'd say we have plenty of time to evaluate, we have until 18th of March before we have to submit papers. Let's seen if we can work this out when you get back! Cheers, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04/mar/2013, at 16:57, luiz americo pereira camara wrote: > Personally, i don't care much about compilation speed since is faster > enough (at least for me). I'm more interested in better generated > code. This is were i'd like to see the efforts going. > > Luiz > Sorry for the +1 style mail but I just wanted to say that completely agree with your statement! Compilation speed is nice, but better code (size/speed) is... better! Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04/mar/2013, at 15:02, Michael Van Canneyt wrote: On Mon, 4 Mar 2013, Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber wrote: Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux. Slightly off topic: http://www.utf8everywhere.org/ Seriously, drop UTF16 support NOW. Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, Mar 4, 2013 at 10:25 AM, Kostas Michalopoulos < badsectorac...@gmail.com> wrote: > On Mon, Mar 4, 2013 at 9:26 AM, Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > >> Don't use fpc if you don't like it, or send patches to improve it ;) >> > > > http://programmers.stackexchange.com/questions/68740/whats-the-canonical-retort-to-its-open-source-submit-a-patch > Nice link, but I find this more appropriate: http://lmgtfy.com/?q=how+to+benchmark+compilers Related, abeit exploited http://tvtropes.org/pmwiki/pmwiki.php/Main/Troll ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, Mar 4, 2013 at 12:35 AM, Marcos Douglas wrote: > On Sun, Mar 3, 2013 at 8:29 PM, Vittorio Giovara > wrote: > > On 04/mar/2013, at 00:21, Marcos Douglas wrote: > > > > [cut] > > > >> FPC Team: > >> Try to hear Martin otherwise, because he is a great developer with > great ideas. > > > > I am no fpc dev here, but patches are welcome I guess. > > That's what I meant when I spoke "he is making a mistake in their > approach of how to present FPC's "defects". > What "defects" exactly? I just see random data dumped on the mailing list, data produced from a random project using random compiler switches... Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;) jm2c Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04/mar/2013, at 00:21, Marcos Douglas wrote: > On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys > wrote: >> >> On 2013-03-03 19:47, Florian Klämpfl wrote: >>> >>> First 10 m of a marathon done. >> >> >> Is that 'miles' or 'meters'? ;-) > > Sad. Instead of "fight", why not walking together? > > IMHO Martin Schreiber is doing a great job using these comparisons and > some improvements could be made in FPC... but he is making a mistake > in their approach of how to present FPC's "defects". I am not so sure about this... I know nothing of dcc switches but he is comparing the compiler speed with a different set of features, it is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all optimization flags and it is expected that optimizing code takes time. Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time! > FPC Team: > Try to hear Martin otherwise, because he is a great developer with great > ideas. I am no fpc dev here, but patches are welcome I guess. Jm2c Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
> Am 01.03.2013 18:33, schrieb Martin Schreiber: >> Hi, >> >> In order to have a good benchmark for FPC Afaik Delphi 7 is closed source, so inherently worse than any version of FPC. Cheers, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] link search order
I've opened a bug regarding this http://bugs.freepascal.org/view.php?id=23948 for better tracking this issue. Thanks for all the feedback received here. Vittorio On Sat, Feb 23, 2013 at 5:50 PM, Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > On 22/feb/2013, at 16:59, Tomas Hajny wrote: > > > On Fri, February 22, 2013 16:33, Vittorio Giovara wrote: > > > > > > Hi, > > > >> yes I was talking about linux. I didn't include much information > because I > >> didn't want to confuse people with details. > >> > >> In this branch of Hedgewars > >> https://code.google.com/p/hedgewars/source/list?name=physfslayer we are > >> using physfs library version 2.1.0. > >> However many people out there have version 2.0.3 installed and (of > course) > >> it doesn't contain many of the APIs present in 2.1.0. > >> So when libphysfs is not found (or an old one is detected) we provide a > >> copy of the right physfs and have CMake (our build system) compile and > >> install it. However even if I hardcode the right path of the right > library > >> of the right version, the installed system library takes precedence, and > >> thus if another version of physfs is installed, hedgewars doesn't link > any > >> more. > >> > >> I would refrain from using a different library name; looking at the > >> generated link.res file it seems that the first lib search path is > >> /urs/lib > >> and /lib and the custom one (where the right libphysfs resides) is found > >> only later on. Is there a way to prevent this? I tried to play with the > >> -Xd > >> flag but the result didn't change. > > > > I don't know enough about the library path setting (I leave commenting on > > this to others). However, if you require a specific version number of a > > library (and even distribute that version with your code), explicitly > > linking to that library version seems to be the appropriate solution from > > my point of view. Another option may be linking the respective library > > > > As mentioned, I've been doing only static builds so far. Plus I passed > the linker (with -k) the full path of the library it should link, but > the system one is somehow always dragged in and linked before my > command takes effect. > > Vittorio > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] link search order
On 22/feb/2013, at 16:59, Tomas Hajny wrote: > On Fri, February 22, 2013 16:33, Vittorio Giovara wrote: > > > Hi, > >> yes I was talking about linux. I didn't include much information because I >> didn't want to confuse people with details. >> >> In this branch of Hedgewars >> https://code.google.com/p/hedgewars/source/list?name=physfslayer we are >> using physfs library version 2.1.0. >> However many people out there have version 2.0.3 installed and (of course) >> it doesn't contain many of the APIs present in 2.1.0. >> So when libphysfs is not found (or an old one is detected) we provide a >> copy of the right physfs and have CMake (our build system) compile and >> install it. However even if I hardcode the right path of the right library >> of the right version, the installed system library takes precedence, and >> thus if another version of physfs is installed, hedgewars doesn't link any >> more. >> >> I would refrain from using a different library name; looking at the >> generated link.res file it seems that the first lib search path is >> /urs/lib >> and /lib and the custom one (where the right libphysfs resides) is found >> only later on. Is there a way to prevent this? I tried to play with the >> -Xd >> flag but the result didn't change. > > I don't know enough about the library path setting (I leave commenting on > this to others). However, if you require a specific version number of a > library (and even distribute that version with your code), explicitly > linking to that library version seems to be the appropriate solution from > my point of view. Another option may be linking the respective library > As mentioned, I've been doing only static builds so far. Plus I passed the linker (with -k) the full path of the library it should link, but the system one is somehow always dragged in and linked before my command takes effect. Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] link search order
On 22/feb/2013, at 21:49, Marco van de Voort wrote: > In our previous episode, Vittorio Giovara said: >> I'm using fpc and trying to link it with a library, let's call it libfoo >> version 2. >> >> The problem I'm facing is that many people have libfoo 1.0 installed and >> that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of >> course this causes a link failure as I need many libfoo version 2 functions. >> >> I set the right library search path but the system search path gets always >> picked first (confirmed by looking at link.res). >> Is there a way to force the order of search path (possibly without >> modifying fpc.cfg or playing with linker flags)? > > Pass -Xd and then your own list of libraries with various -Fl? > > Without -Xd some defaults are emitted I've tried setting -Xd and then -Fl/path/to/right/lib but the system library is picked first nevertheless. Plus I need to have the system path in the search path, just in a different order, otherwise I'd have to hardcore different paths for every possible arch out there... Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] link search order
Hi, yes I was talking about linux. I didn't include much information because I didn't want to confuse people with details. In this branch of Hedgewars https://code.google.com/p/hedgewars/source/list?name=physfslayer we are using physfs library version 2.1.0. However many people out there have version 2.0.3 installed and (of course) it doesn't contain many of the APIs present in 2.1.0. So when libphysfs is not found (or an old one is detected) we provide a copy of the right physfs and have CMake (our build system) compile and install it. However even if I hardcode the right path of the right library of the right version, the installed system library takes precedence, and thus if another version of physfs is installed, hedgewars doesn't link any more. I would refrain from using a different library name; looking at the generated link.res file it seems that the first lib search path is /urs/lib and /lib and the custom one (where the right libphysfs resides) is found only later on. Is there a way to prevent this? I tried to play with the -Xd flag but the result didn't change. Any help is appreciated. Vittorio On Fri, Feb 22, 2013 at 3:35 PM, Tomas Hajny wrote: > On Fri, February 22, 2013 10:59, Vittorio Giovara wrote: > > > Hi, > > > I'm using fpc and trying to link it with a library, let's call it libfoo > > version 2. > > > > The problem I'm facing is that many people have libfoo 1.0 installed and > > that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of > > course this causes a link failure as I need many libfoo version 2 > > functions. > > > > I set the right library search path but the system search path gets > always > > picked first (confirmed by looking at link.res). > > Is there a way to force the order of search path (possibly without > > modifying fpc.cfg or playing with linker flags)? > > You don't provide much information about your situation, but I assume that > you talk about Linux here. If you need version 2, you may need to link > explicitly to libfoo.2.so rather just libfoo.so. If you link to libfoo.so > and this is expected to be a symbolic link to the latest installed > version, you may also want to check why people having both libfoo 1.0 and > libfoo 2.0 installed do not have the symbolic link pointing to the later > version. One such reason may be not having the development version of the > respective library installed (at least this may be the case on some Linux > distributions as far as I know). > > Tomas > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] link search order
Hi, I'm using fpc and trying to link it with a library, let's call it libfoo version 2. The problem I'm facing is that many people have libfoo 1.0 installed and that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of course this causes a link failure as I need many libfoo version 2 functions. I set the right library search path but the system search path gets always picked first (confirmed by looking at link.res). Is there a way to force the order of search path (possibly without modifying fpc.cfg or playing with linker flags)? Thanks, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of code collaboration
On Mon, Feb 11, 2013 at 9:59 AM, Jonas Maebe wrote: > > On 10 Feb 2013, at 22:32, Vittorio Giovara wrote: > > What about (d) is this project feasible? If not, is it can you split in > > (parallel) sub projects so that more people can tackle it? > > I really don't know whether it is feasible. There is definitely a lot of > work that needs to be done to get a clean result, some of it fairly tedious > (such as creating complete type definitions for types that are currently > opaque in the compiler, like VMT layouts and RTTI). I'm now leaving on > holidays for 3 weeks, maybe I'll have a better idea when I come back :) > > I'd say we have plenty of time to evaluate, we have until 18th of March before we have to submit papers. Let's seen if we can work this out when you get back! Cheers, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of code collaboration
On Sun, Feb 10, 2013 at 8:39 PM, Jonas Maebe wrote: > > On 10 Feb 2013, at 20:12, Vittorio Giovara wrote: > > The iOS experience could be improved in many ways, for example in > Xcode you cannot set a breakpoint and when you do so with gdb all you > get is an assembly viewer > > > I don't remember ever hearing about this or seeing a bug report about > this. It's unlikely that this is related to FPC vs LLVM code or debug info > generation though. And adding support for LLVM is something different than > adding support for LLVM + LLVM debug information. The two are completely > decoupled, and one will not automatically get you the other. > > I wasn't fully aware of that, thanks for the explanation. Yeah as first project, a LLVM backend support is more than enough, isn't it? I'll try to reproduce the bug I mentioned with a more recent build of fpc and open a ticket if it's still present. > That said, regarding some other things that have been mentioned in this > thread: > a) the fpc llvm branch is completely out of date, predates the high level > code generator that now should be used to add LLVM support, and at best can > be used to get some ideas or code snippets from. I'm not sure how much is > really usable though. > b) I do think that adding an LLVM backend to FPC is useful. As I've > mentioned before, it's however extremely unlikely that it will ever replace > existing code generators (for any platform), it would simply become an > additional option > c) from the GSoC mentors list, I've understood that the best students are > generally people who were already involved with the project (on the mailing > lists, by submitting patches, ...). They are familiar with the project, the > way contributions are handled, expectations of the existing developers > regarding new code, and there is more chance that they are interested in > working on the project in the long term (contributed code that is not > maintained afterwards is much less valuable, because we already have a lot > of code to maintain; if you have to maintain code, it's generally easier to > do so if you wrote it yourself) > > For (b) it fully makes sense. For (c) there is a long period between student selection and start of the project, where student can approach organizations and contribute to them; generally the students who are already capable of providing patches have higher chances of being accepted (although that's not always the case). If you think having a student is something useful we can highlight the "collaboration" on each organisation website in order to get maximum visibility, but it's the mentor who has to pick the right student in the end. What about (d) is this project feasible? If not, is it can you split in (parallel) sub projects so that more people can tackle it? > > Jonas > > To everyone, it was not my intention to rant/start a flamewar on bundled tools, sorry if I touched a nerve there. Please let's focus on building something together, foss-style. Cheers, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of code collaboration
On 10/feb/2013, at 15:58, Florian Klaempfl wrote: > Am 10.02.2013 15:23, schrieb Vittorio Giovara: >> Indeed, a fpc->js code generator would have a rather limited use. A >> LLVM backend instead could be use on many more levels, and for example >> could improve (or replace) the compilation process on iOS. > > Improve in which regard? Experience showed that the more tools involved the > less comfortable the use of FPC is. Within a few minutes you can build on any > platform a win32 cross compiler (if the CPU is fast enough) because no > external tools are involved. Compare this with cross compiling to linux (no > to talk about darwin): takes usually 1-2 hours to setup: first, download, > configure and build binutils, then sort out the libraries and copy them to > host system, and then with some luck (if binutils are not broken), building > fpc might work. Well the existence of external tools is what has allowed technology to foster and advance, eg have some common grounds and entry points... Your (limited) example is not exactly perfect, the tools that fpc bundle on windows are often outdated and conflict which the other tools (off the top of my head mingw or ld). And I successfully crosscompiled Darwin from Linux, it was a much less painful process than setting up a build environment under Windows. But I digress. The iOS experience could be improved in many ways, for example in Xcode you cannot set a breakpoint and when you do so with gdb all you get is an assembly viewer; having a LLVM backend could actually allow a better debugging and other tricks such as those provided by www.piecable.com > Not to mention that I estimate that full llvm support with debugging and > extending llvm to support everything required by fpc might be more something > like 1-2 years of full time work than a few summer months of work of a > student. I know that this is not going to be an easy project but please as I said don't underestimate students, GSoC people have carried out tasks that revolutionized more than one organization. Moreover I think that trying to offer help to achieve this long term goal is better than pestering on IRC with "is the LLVM-fpc branch ready yet??" Cheers, Vittorio > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of code collaboration
Indeed, a fpc->js code generator would have a rather limited use. A LLVM backend instead could be use on many more levels, and for example could improve (or replace) the compilation process on iOS. Plus I would like that this collaboration would be about something that could be useful for many projects, not something hedgewars-only. Vittorio Inviato da iPhone Il giorno 10/feb/2013, alle ore 11:09, Sven Barth ha scritto: > On 09.02.2013 14:40, Florian Klämpfl wrote: >> Am 09.02.2013 03:13, schrieb Vittorio Giovara: >>> To do that we are using a tool >>> named 'emscripten' which takes LLVM bytecode and generates Javascript, >>> without affecting performance too much. Yes, we had to write a horribly >>> hacked converter that took the small subset of Pascal used by Hedgewars >>> and convert it to C (on a side node, the converter is written in >>> Haskell) and reimplement the RTL. >> >> I still don't understand what's the use of generating LLVM code in >> between instead of generating directly Javascript ... The process >> pascal->llvm->js looks as well very fragile to me. > > Having a LLVM backend would not only benefit HedgeWar's JavaScript case, > but also all others that would like to use the LLVM backend for one > purpose or the other. And in my opinion a pure JS backend would be much > harder to implement than a LLVM backend as one also needs to think about > how certain things should be implemented in JS (which the emscripten > developers already thought of). > > Regards, > Sven > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Summer of code collaboration
Hi all, I'm one of the developer of Hedgewars, an open source video game all written with FreePascal. Please see the full site at http://www.hedgewars.org/ One of the Hedgewars project is to make a WebGL/Javascript version of the game so that it can run in a browser. To do that we are using a tool named 'emscripten' which takes LLVM bytecode and generates Javascript, without affecting performance too much. Yes, we had to write a horribly hacked converter that took the small subset of Pascal used by Hedgewars and convert it to C (on a side node, the converter is written in Haskell) and reimplement the RTL. So, this got the job done (if you are using an old browser the demo might still work http://hedgewars.org/hwjs/hwjs.html ) but all this process is *highly* unmaintainable and very prone to breakage. So the right way (tm) to achieve this result would be to directly integrate LLVM bytecode generation inside Freepascal. I think we could make this work thanks to the Google Summer of Code! This program (*if* they announce it) basically introduces students to the world of FOSS development by having them work on projects for an open source organization during the summer. I don't know if Freepascal wants to participate on its own, but if not, if there is one or more developer willing to act as mentor for the students, Hedgewars (*if* selected) would happily allocate some of its students to work on this task and act as a "umbrella" for this project targeting Freepascal sources. Of course the students would still have to write a sensible project proposal for being accepted. What do you think of this idea? Unfortunately I do not know Freepascal sources much and cannot fully evaluate the load of work, but I still think that we could collaborate on this level. Also do not underestimate the skills of GSoC students, the demo I posted above was compiled by one of them. Cheers, Vittorio (koda on #hedgewars) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
