Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2002-09

Contributing to FPC.

8 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

Hello.

According to the freepascal website, you are the maintainer of the Linux port, hence this mail.

I have been programming in Pascal for around 13 years now (I started with BP5 as a nine year old kid :-) )
I started using Linux around 4 years ago (back when slackware was reccommend for it's easy instalation) and had the shock of my life. NO proper pascal compiler, the only thing there was available was then alpha version of p2c which couldn't do anything more than Wirt level pascal (and not even all of that mind you - I still had to manually fix file-pointers in the C code after having used Assign/Rewrite )

I started using FreePascal sometime around version 0.8, I still remember my first post to the mailinglist being about a crash caused by the then experimental ansi-strings support and being told to get myself a copy of the snapshots :-)

Anyway, the point is I am still using FPC today and in my opinion it is the best pascal compiler around, and the only better one for delphi is borlands own (for the record I detest delphi - all the best things about pascal is hard to do - the only reason I call it better is because to my knowledge Delphi/Kylix are unique in fully supporting the Delphi GFX stuff)

I have done some truly amazing things with it, you may have noticed my contributed PTK unit - orriginally designed just for the sake of creating TK based GUI's now able to embed almost ANY scripted language into FPC code (With some limitations) and the code for that is less than 600 lines. Unfortunately it uses Linux specific functions (and it really does depend on them) so it's non-portable.

I believe very strongly in open-source and whenever possible I open-source my code, and now I would like to help develop FPC.

My programming experience is very varied, I have developed hundreds of different things (including once a very simple programming language back in dos days for my little brother to play with) and almost always in Pascal.

I think I am really good at it, I kn
e C/C++ and did a JAVA course at
university but there is no other language out there that ever appealed to my like Pascal. I always end up looking up syntax and commands, I cannot remember the last time I needed to look something up in Pascal.

I would love to contribute to FreePascal's developement. I am writing you directly because I couldn't find anything on the topic after an exhaustive search on freepascal.org .

My first idea for improvement is this:
A recreation of the Graph unit using SDL. The current Linux version requires SVGAlib which is no-longer included with most distributions and requires root privelages. I have worked quite a bit with Daniel Moisette's SDL headers and I am convinced it is do-able though it will certainly not be a hundred percent compatible. Once that is finished I would create CRT'ish mouse and keyboard access using SDL's event manager behind it -the result will be a graph unit that is portable to more platforms and OS's than FPC and depends only on a highly available, stable and open-source library.
Please let me know your feelings on this one.

As for more relevant and immediate actions I would like to help with the following:
Enhancing h2pas - the current version has severe problems with just about every header file on my system - I am sure it can be improved.

Documentation - There is a great deal of room for improvement with the documentation - for one thing the packages have been part of the FPC distribution for a long time now, but they are not documented, I think I am allready capable of writing chapters similiar to those in Units.pdf for several of them (including mysql and ncrt).

Please let me know if the FPC developers would be willing to let me work on any of the above as an official member of the team. In the fullness of time I will also be willing to work on improving the compiler itself, but I need to understand it better first (I am currently studying the sources for fun)

I hopefully await your answer.
A.J. Venter
Pretor

-------------------------------------------------------------------- mail2web - Check your email from the web at
http://mail2web.com/ .

Reply by email

Jonas Maebe
to Unknown author
According to the freepascal website, you are the maintainer of the Linux port, hence this mail.

It seems you wrote to the wrong address :)

Show quoted text 5 lines
I would love to contribute to FreePascal's developement. I am writing you directly because I couldn't find anything on the topic after an exhaustive search on freepascal.org .

fpc-devel would be a slightly better place than this list.

Show quoted text 8 lines
My first idea for improvement is this: A recreation of the Graph unit using SDL. The current Linux version requires SVGAlib which is no-longer included with most distributions and requires root privelages. I have worked quite a bit with Daniel Moisette's SDL headers and I am convinced it is do-able though it will certainly not be a hundred percent compatible.

No? The current graph unit is quite flexible. It's almost completely independent of the underlying system, it can even work if you only implement putpixel(), getpixel() and mode detection/setting (though quite slowly, as demonstrated by the current win32 graph unit). You can override almost all procedures (they're all procvars) though and in general, the more you override, the fast things become (most banked VESA routines are quite fast). A graph unit based on SDL would be really nice though, since it's available on many platforms.

Show quoted text 7 lines
Once that is finished I would create CRT'ish mouse and keyboard access using SDL's event manager behind it -the result will be a graph unit that is portable to more platforms and OS's than FPC and depends only on a highly available, stable and open-source library. Please let me know your feelings on this one.

This sounds really nice, but it would be even better if you could keep the mouse/keyboard stuff separate so that we can have the cake and eat it too: a (hopefully) BP compatible graph unit and all the advantages of using SDL in some other units. We already have keyboard/mouse units in the RTL though, maybe it would be best to implement those on top of sdl as well instead of creating completely new ones?

Show quoted text 5 lines
As for more relevant and immediate actions I would like to help with the following: Enhancing h2pas - the current version has severe problems with just about every header file on my system - I am sure it can be improved.

I agree :)

Show quoted text 6 lines
Documentation - There is a great deal of room for improvement with the documentation - for one thing the packages have been part of the FPC distribution for a long time now, but they are not documented, I think I am allready capable of writing chapters similiar to those in Units.pdf for several of them (including mysql and ncrt).

You're more than welcome to help, though you should coordinate this part with Michael, since he is the docs maintainer and may have already written some parts of this.

Show quoted text 8 lines
Please let me know if the FPC developers would be willing to let me work on any of the above as an official member of the team. In the fullness of time I will also be willing to work on improving the compiler itself, but I need to understand it better first (I am currently studying the sources for fun)

In general, it doesn't work like this with a solicitation and all :) All the source is available for you to work on, either by download or using cvs. You work on it, submit patches/new stuff, we test it/check it in and once we become bored with committing all the stuff for you because you submit so many good things, you get a cvs account so you can do it yourself ;) If you want to work on PFC, please do it on the main branch (1.1), since there may still be a 1.0.8 bugfix release, but after that all work will be done on 1.1 (which will probably become 2.0 when released).

Jonas

Reply by email

Jonas Maebe
to Aitor Santamaría: Under Linux, how does GRAPH unit do? Does it open XFree or the like? If the answer is NO,…
Aitor Santamaría wrote
Under Linux, how does GRAPH unit do? Does it open XFree or the like?

No, it uses (s)vgalib.

If the answer is NO, what happens if I start with a FrameBuffer device loaded, can I still draw things in such case?

Yes, but I'm not sure whether it works from within xfree, you may have to start it on another console. Also, for svgalib programs you need root access in most cases (the latest versions may have circumvented this in some way).

Jonas

Reply by email

Aitor Santamaría
to Jonas Maebe: It seems you wrote to the wrong address :) fpc-devel would be a slightly better place…
Show quoted text 20 lines
> My first idea for improvement is this: > A recreation of the Graph unit using SDL. The current Linux version > requires SVGAlib which is no-longer included with most distributions and > requires root privelages. I have worked quite a bit with Daniel > Moisette's > SDL headers and I am convinced it is do-able though it will certainly > not > be a hundred percent compatible. No? The current graph unit is quite flexible. It's almost completely independent of the underlying system, it can even work if you only implement putpixel(), getpixel() and mode detection/setting (though quite slowly, as demonstrated by the current win32 graph unit). You can override almost all procedures (they're all procvars) though and in general, the more you override, the fast things become (most banked VESA routines are quite fast). A graph unit based on SDL would be really nice though, since it's available on many platforms.

Under Linux, how does GRAPH unit do? Does it open XFree or the like? If the answer is NO, what happens if I start with a FrameBuffer device loaded, can I still draw things in such case?

Aitor

Reply by email

Michael Van Canneyt
to Aitor Santamaría
Show quoted text 25 lines
> > >> My first idea for improvement is this: >> A recreation of the Graph unit using SDL. The current Linux version >> requires SVGAlib which is no-longer included with most distributions and >> requires root privelages. I have worked quite a bit with Daniel >> Moisette's >> SDL headers and I am convinced it is do-able though it will certainly >> not >> be a hundred percent compatible. > > > No? The current graph unit is quite flexible. It's almost completely > independent of the underlying system, it can even work if you only > implement putpixel(), getpixel() and mode detection/setting (though > quite slowly, as demonstrated by the current win32 graph unit). You > can override almost all procedures (they're all procvars) though and > in general, the more you override, the fast things become (most banked > VESA routines are quite fast). A graph unit based on SDL would be > really nice though, since it's available on many platforms. Under Linux, how does GRAPH unit do? Does it open XFree or the like? If the answer is NO, what happens if I start with a FrameBuffer device loaded, can I still draw things in such case?

The current Linux implementation uses libvga; It will not cooperate with X as far as I know.
There is a ggigraph unit which uses GGI to decide whether it's running under X or not, and uses libvga or an X-window accordingly.

Michael.

Reply by email

Jonas Maebe
to Aitor Santamaría: The latest versions of svgalib? or of GRAPH unit? (I haven't used svgalib, at least…
Aitor Santamaría wrote 7 lines
> Yes, but I'm not sure whether it works from within xfree, you may have > to start it on another console. Also, for svgalib programs you need > root access in most cases (the latest versions may have circumvented > this in some way). The latest versions of svgalib? or of GRAPH unit? (I haven't used svgalib, at least conciously).

svgalib. It has something to do with creating a /dev entry for the video memory with permissions so that anyone can write to it.

Jonas

Reply by email

Aitor Santamaría
to Jonas Maebe: No, it uses (s)vgalib. Yes, but I'm not sure whether it works from within xfree, you may…
Show quoted text 15 lines
> Under Linux, how does GRAPH unit do? Does it open XFree or the like? No, it uses (s)vgalib. > If the answer is NO, what happens if I start with a FrameBuffer > device loaded, can I still draw things in such case? Yes, but I'm not sure whether it works from within xfree, you may have to start it on another console. Also, for svgalib programs you need root access in most cases (the latest versions may have circumvented this in some way).

The latest versions of svgalib? or of GRAPH unit? (I haven't used svgalib, at least conciously).

Aitor

Reply by email