Hello,

Issue ID: #29483. [1]

This patch implements the HTTP support in the TurboPower IPro component.

Thank you!

[1] http://bugs.freepascal.org/view.php?id=29483

Hello Silvio,

Are you considering to use TurboPower HTTP components to implements HPACK and HTTP/2 ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160123/752a7a0a/attachment.html>

Hello Jy,

Yes, it can be easily implemented in TP comps. ASA nghttp2 get a pascal header, BTW with a ng header in hands, you can use this one with any pascal code. :-)

I took a look at the IpHtmlPanel comp. on Windows, it's a nice component... it prints some basic HTML/CSS, but it needs patches to fix some bugs (eg: I can't see a HTML form on it), so I'm going to send that ASAP.

Instead of relying on external libraries such as nghttp2, is there anyone on this list willing to implement HPACK in pure pascal code in a single unit from the explicit source code available here: https://github.com/twitter/hpack/tree/master/hpack/src/main/java/com/twitter/hpack of course this "translation" from java to pascal would qualify for a bounty,

I hope this would help as a starting point to move forward to a pure pascal implementation of HTTP2,

anyone feel free to comment directly on the list if some programmers are ready to help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160125/c83e0a0f/attachment.html>

[...]

Hm... I don't understand why many Pascal users hates external libraries, even when it's written in C, one of the best languages to create fast and stable libraries, with a lot of users around the world provinding support for that. :-/

Many units in Free Pascal and Delphi uses C libraries... when aren't using a C library (an API system call, an third party library call, etc.), are using assembly, ie, mostly time Pascal is used as a high-level language to consume some low-level code written in C or assembly.

Just an example, the Embarcadero Delphi provides support for BJSON and MongoDB, so you can find libraries like `libbson-1.0.dll` and `libmongoc-1.0.dll` in the Delphi directory, and it was a very nice choice, because these libraries implements a lot of features and they are maintained for many programmers. I saw some Pascal libraries for MongoDB, but they seem have been abandoned by their maintainers before being concluded.

I use Pascal for high-level logic and sometimes for low-level logic using pointers, but when I need a feature that Pascal hasn't implemented yet, I search a C library to solve it, so I don't see a problem in using external libraries. :-)

Oops,

On Mon, Jan 25, 2016 at 11:56 AM, silvioprog wrote: [...]

Just an example, the Embarcadero Delphi provides support for BJSON

I meant:

"... provides support for BSON ..."

.. so I don't see a problem

"... I don't have problem ..."

Sorry. ^^'

There is a simple reason:
Debugging and bugfixing is a lot easier if all the code is in pascal.

Most libraries are a black box.
I don't think I've purchased a library/package that didn't contain bugs, which I had to debug manually and fix.

Old timers as X, libc, pthreads and more such oldtimers will generally be bug-free, but there is lots of code out there with a less good track record.

Michael.

On Mon, Jan 25, 2016 at 5:08 PM, Michael Van Canneyt <

I agree. Using external libraries has pros and cons.

Most libraries are a black box. I don't think I've purchased a

library/package that didn't contain bugs, which I had to debug manually and fix.

Sad but true. :-/

The best advantage is that mostly C libraries have a lot of users and active maintainers. I'm using three of them, and I got bugs on them, but I fixed some of them by myself, and others I got help on theirs bugtracker.

Old timers as X, libc, pthreads and more such oldtimers will generally be

bug-free, but there is lots of code out there with a less good track record.

Yes.

I'm using (and indicating) third party GNU C libraries, but before adopt them, I check theirs ecosystem, how many programmers are involved on theirs development, the commit history, how long an issue remains open, and if the libraries are still active. :-)

On Mon, Jan 25, 2016 at 3:08 PM, Michael Van Canneyt <

Here's another reason - cross-platform availability. FPC is cross platform. To some extent (Java?) is more cross-platform that C is.

When using an external library, there might be a risk that the library is not *easily* available for another platform that is targeted. It's common for open-source projects, not to provide any binary builds, requiring a library user to build the library themselves. Luckily, the most common projects do have some satellite projects that actually provide binaries.

Building C (C++) library could be a real pain for some Pascal users. (Pascal spoils!)
Building C/C++ library for a desired target platform, could be even more painful, specifically if some sort of cross-tools required or when building configuration needs to be changed.

Thus a pure pascal library would be a number one choice for most users. With though it might be outdated and/or slower than its C-counterpart (i.e. paszlib vs zlib)

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160125/a6e06c0e/attachment.html>

On Mon, Jan 25, 2016 at 5:02 PM, Dmitry Boyarintsev <

wrote: With though it might be outdated ...

correction:
* Even though it might be outdated ...

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160125/4902b079/attachment.html>

On Mon, Jan 25, 2016 at 7:02 PM, Dmitry Boyarintsev <

Indeed. But the one of the basic steps before chosing a library (from any language) is read its specification, and know if it provides the needed features, works in the expected SOs, and provides a good documentation with a stable support. I need to make a device and it need a microcontroller, so I found that the best choice is a PIC16F64A because its datasheet shows all the features and the basic hardware that I need.
Well, the mostly C libraries work fine in many OSs. One that I use works in the popular systems (currently I need it just for Windows and Linux) like GNU/Linux, FreeBSD, OpenBSD, NetBSD, Android, OS X, Win32/64 and special systems like Symbian and z/OS, and it's already available in some tools like apt, yum, npm, maven, pacman... :-) ... (and if I have a chance from FPC team, I can make it also installable via fppkg tool too! :-D )

That was the main problem that I also had, unfortunatelly. :-(

For example:

https://github.com/libharu/libharu/issues/118

Mostly Pascal programmers don't like C libraries they get boring because of the bugs like this, and can't fix the problem (lack time; doesn't have a C environment, or doesn't know C etc.). But, why not try to understand the problem? Is C so hard that a Pascal programmer can't understand that? I don't think so, if you already use pointers and played with low-level programming in standard Pascal, you can learn C too.

Building C (C++) library could be a real pain for some Pascal users.

(Pascal spoils!)

Sad but true. :-(

But they should try to get support from the library list. Some days ago I fixed a lot a problems in a C library (that's already a FPC/Delphi header) and now it works like a charm on Windows, Linux and OS X. But first time, I thought: "oh ktulu, why it doesn't compile plz..." ... but after trying to fix it by myself, finally I can fix common bugs in any C library, because complex bugs usually are already fixed by its maintainers.

Building C/C++ library for a desired target platform, could be even more

painful, specifically if some sort of cross-tools required or when building configuration needs to be changed.

Well, in mostly cases I just use the ./configure && make && make install-strip hehehe... On Windows I use MinGW, so I can compile C libraries easily, and when I got any problem to compiled that, I solve it easily too, by myself or getting support in the Pascal or C communities. :-)

Thus a pure pascal library would be a number one choice for most users. With though it might be outdated and/or slower than its C-counterpart (i.e. paszlib vs zlib)

I agree, but I can't find a hard problem that makes a Pascal programmer (beginner or veteran) not to use a C library even if it has already a solution that's not implemented in Pascal yet. :-)

These days I took a look at FPC/Laz examples finding some solution to control keyboard/mouse remotely, something like a VNC, but just the control, without the server, and I found that, the components/MouseAndKeyInput package, that uses external libraries. On Windows and OS X it uses theirs APIs (they are external libraries), on Linux it uses the libxTst library, and I don't have problem to use this component just because it's using a third party external GNU library. After installing it via apt, the only problem that I got was create the library link on the /lib folder.

But, unfortunatelly, even with this pros, Pascal programmers avoid to use external libraries, that's a real fact. :-/

2016-01-25 23:09 GMT-02:00 silvioprog :

But, unfortunatelly, even with this pros, Pascal programmers avoid to use external libraries, that's a real fact. :-/

This issue is not restricted to Pascal programmers, this problem is inherent in any development platform.

The root problem of using an external library is: when you add an external dependency on your code, your code becomes constrained by the limitations of that external dependency. For example, let's suppose you are writing a code that handles an exotic file format. Your code are supposed to run on windows. Then you find an external library which solves your problem. Three months after, your project's requirements changes. The new requirement is that your code shall run on Linux. However, that external library runs only on windows. So, your code are constrained by this limitation. Now, you need to find an alternative solution. Sometimes, none of them are feasible and this fact can lead your project to fail.

By other side, if you find a solution in pascal, your code are constrained only by the limitations of the compiler.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160126/e5f3a4df/attachment.html>

True, although this is an argument for using only cross platform open source libs. Not specially for using only Pascal libs. Not all Pascal libs run on all platforms.

Mattias

Well, I disagree. I'm working with other languagens (C - libs, Java - 3rdparty things, and NodeJS - compiled modules), I joined on their communities, and I find many programmers adopting C libraries there.

The root problem of using an external library is: when you add an external

As I said: "... But the one of the basic steps before chosing a library (from any language) is read its specification, and know if it provides the needed features, works in the expected SOs, and provides a good documentation with a stable support. I need to make a device and it need a microcontroller, so I found that the best choice is a PIC16F64A because its datasheet shows all the features and the basic hardware that I need".

...

"... Well, the mostly C libraries work fine in many OSs. One that I use works in the popular systems (currently I need it just for Windows and Linux) like GNU/Linux, FreeBSD, OpenBSD, NetBSD, Android, OS X, Win32/64 and special systems like Symbian and z/OS, and it's already available in some tools like apt, yum, npm, maven, pacman...".

By other side, if you find a solution in pascal, your code are constrained only by the limitations of the compiler.

IMHO this isn't a reason, I also can find Pascal code that works only on a specific SO, and hard to be implemented in other systems, so I prefer to get some C library that already do it instead of spending a long time trying to implement it just because "oh, I can't work with libraries". :-)

The main a real reason that I find is: mostly Pascal programmers can't debug a C libraries. And many Pascal programmers can't use or don't know how to use shared/static libraries by themselves and can't find time to know it, but anyway they use external libraries implicitly, when they declare Pascal units that uses them.

Imagine if Lazarus developers think this same way, they probably would not have created Lazarus for GTK and Qt. :-)

"silvioprog" wrote

As I said: "... But the one of the basic steps before chosing a library

(from any language) is read its specification, and know if it provides the needed features, works in the expected SOs, and provides a good documentation with a stable support. I need to make a device and it need a microcontroller, so I found that the best choice is a PIC16F64A because its datasheet shows all the features and the basic hardware that I need".

... "... Well, the mostly C libraries work fine in many OSs. One that I use

works in the popular systems (currently I need it just for Windows and Linux) like GNU/Linux, FreeBSD, OpenBSD, NetBSD, Android, OS X, Win32/64 and special systems like Symbian and z/OS, and it's already available in some tools like apt, yum, npm, maven, pacman...".

You are right. However, often we can't prevent when the requirements of our project will change and what will change. As i have said, you can find a library that address your problem today, but after some time, your project's requirements changes and that external dependency becomes a problem. The problem of cross-platform availability was just an example. A particular library may have many other kinds of limitations. Very often, you can't just figure out which of that limitations may become a problem in the future.

IMHO this isn't a reason, I also can find Pascal code that works only on

a specific SO, and hard to be implemented in other systems, so I prefer to get some C library that already do it instead of spending a long time trying to implement it just because "oh, I can't work with libraries". :-)

I am not against the use of libraries. What i am trying to say is, when you add an external dependency to your code, your code becomes constrained by the limitations of that external dependency so, would be better if you can solve the problem without add a new level constraints to your code.

The main a real reason that I find is: mostly Pascal programmers can't

debug a C libraries. And many Pascal programmers can't use or don't know how to use shared/static libraries by themselves and can't find time to know it, but anyway they use external libraries implicitly, when they declare Pascal units that uses them.

Imagine if Lazarus developers think this same way, they probably would

not have created Lazarus for GTK and Qt

Why i can't make an Android app using Lazarus, as the free pascal compiler provides support to it? Is it because there is no GTK to android? And if the lazarus GUI framework did not depends on external libraries?

The lazarus team did the right thing. They did not stopped to develop the Lazarus for Unix because "they couldn't use libraries". However, how would be the actual scenario if the GUI framework of the Lazarus was developed using just Pascal? Perhaps, I would not currently facing the problem of not being able to develop an android app using Lazarus provided frameworks. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160126/df8df176/attachment-0001.html>

silvioprog wrote

But, unfortunatelly, even with this pros, Pascal programmers avoid to use external libraries, that's a real fact. :-/

Speaking of the core team, you may be right. And speaking about people writing cross plattform programm it presumably is a wise decision to translate things to pascal. Once done it reduces efforts of updating external libs to newer versions, oddities when compiling for multiple platforms, etc.

But besides that I'm not hesitating to use external libraries to get things done. I had some USB access code from a third party and no time to translate before the release, so it was a bliss to compile some cut out C functions into objects and link them to the pascal program. Works, still in use.

There is no a language/compiler/library that can prevent all possible future problems or customers needs. :-)

Any choice must be done carefully for everything, language, compiler, library, Pascal component etc.

Sometimes is better to reuse codes that already exit, instead of spending a long time trying to solve the problem alone. For example, I still can't find a pure Pascal package to build a HTTP 2.0 server, but I can create a Pascal header to reuse some C library that already does it properly.

I couldn't understand what you meant.

"silvioprog" wrote

On Tue, Jan 26, 2016 at 1:01 PM, Fabr?cio Srdic

> > Em 26/01/2016 11:30, "silvioprog" escreveu > Why i can't make an Android app using Lazarus, as the free pascal

compiler provides support to it? Is it because there is no GTK to android? And if the lazarus GUI framework did not depends on external libraries?

> > The lazarus team did the right thing. They did not stopped to develop

the Lazarus for Unix because "they couldn't use libraries". However, how would be the actual scenario if the GUI framework of the Lazarus was developed using just Pascal? Perhaps, I would not currently facing the problem of not being able to develop an android app using Lazarus provided frameworks.

To summarize my opinion: if I am java programmer, would be better if I can solve my problem via Java classes than using C library binds. If i am a Pascal programmer, i prefer to solve my problem via Pascal classes instead of C binds. Add an external dependency to the code may be a good option in short term, however may become a big problem in long term. Perhaps, if the Lazarus GUI framework was developed using pure pascal ( like fpGUI) instead of using external libraries and frameworks, we could develop mobile apps using Lazarus today.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160126/1b0bff3d/attachment-0001.html>

I agree. And using lib I can use the modularization concept with Free Pascal.

Awesome!

Me too, but Java programmers mostly time use external C libraries when it hasn't already implemented some feature yet, it is a good choice, and you can use that Java classes without knowing that it make calls to an external C library. The Free Pascal and Delphi do it too, for example, when you access a database using SQLdb, it uses an external C library (the database client), that is made in C, and many Pascal programmers uses SQLdb with pure Pascal interfaces (headers) without knowing that the main implementation is in the external C library.

Fabr?cio Srdic wrote

To summarize my opinion: if I am java programmer, would be better if I can solve my problem via Java classes than using C library binds.

I think it is safe to say we would all love such a solution for Object Pascal too. But unfortunately C is an overwhelmingly popular language, and most core functionality of an OS or library is implemented in it.

Java is more popular than C (depends which stats you look at obviously), and thus it too has a lot of pure Java implementations of many things. eg: parsers, database libraries, database engines, graphics engines, etc

Bottom line is, these two language show that you need to have a massive market share for something like that to happen [at such a scale].

Lazarus GUI framework was developed using pure pascal ( like fpGUI) instead of using external libraries and frameworks,

Personally I agree that LCL was implemented the wrong way (not custom drawn), but I also need to correct you, or at least point out that even though fpGUI Toolkit implements ALL widgets in pure Object Pascal, and even has its own Object Pascal 2D graphics library for sub-pixel anti-aliased drawing, it too relies on external libraries. How else is fpGUI going to talk to X11, Win32, OS/2 etc. At some point it needs to talk to the windowing system of the OS (which is most likely implement in C, as some library). fpGUI's dependencies are magnitudes smaller than LCL, but there are still dependencies - you simply can't avoid that, other than implement a whole OS, windowing system, window manager etc in Object Pascal too.

we could develop mobile apps using Lazarus today.

As far as I know there is work being done to allow Lazarus to develop Android applications. I guess this work simply hasn't been made public yet, as it likely is still incomplete and under development.

ps:
I welcome you to implement a Android backend for fpGUI. ;-) Somebody is apparently working on this already, though I don't know the status or progress.

Regards,
- Graeme -

From: Graeme Geldenhuys

<snip)

I think it is safe to say we would all love such a solution for Object Pascal too. But unfortunately C is an overwhelmingly popular language, and most core functionality of an OS or library is implemented in it.

<snip>

Personally, I am very interested in developing a 3D Window Manager for Linux using Object Pascal. I am still not sure if I would need to work at the level of OpenGL (and if there are Object Pascal wrappers for all OpenGL functions) or if there are higher-level tools in Lazarus that could be used to write a true 3D Window Manager / Desktop Environment for Linux? Any ideas?

Unfortunately I also do not currently have time to look at this in more detail, so probably only in 2017. Just saying that I am seriously interested in using Lazarus/Object Pascal at such a lower level if possible (and it might even be ported to be cross-platform later, depending on which underlying API it would use).

And now I am totally off-topic. But if anybody else would be interested in something like this, please contact me... at least we can start looking at what options are available. The other option I am considering instead of Object Pascal is C++, which will probably have a good interface to OpenGL. Any 3D game programmers that used Object Pascal looking for a new challenge?

Cheers,
Chavoux

2016-01-27 7:47 GMT-02:00 Graeme Geldenhuys :

Guys, i am talking about "levels" of external dependency. Ok, FpGUI obviously depends on OS's API's exposed through external libs. However, there is a big difference: if my app uses FpGUI, my apps depends on OS API's. By other side, if my app uses GTK, my apps depends on OS's API's AND GTK. Do you see?

Yes, and as far as i know they are doing this through LCLCustomDraw, and not through binds to any C lib GUI framework for Android.

Do you see the drawback of the external dependency? Lazarus users are limited by the constraints of GTK and etc.

ps: again, i am not against the use of external libs. I use many C libs in my projects.

This is on my to-do list :-).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160127/973ba181/attachment.html>

Fabr?cio Srdic wrote

Do you see the drawback of the external dependency? Lazarus users are limited by the constraints of GTK and etc.

You are preaching to the choir. :-) I fully agree with you.

Regards,
- Graeme -

2016-01-27 0:19 GMT-02:00 silvioprog

I undertand this. I know it is virtually impossible to drop all the dependency on external C libs on all platforms and programming languages. It is not feasible and such goal is all about waste of time and reinventing the wheel. I wouldn't do this even in my projects.

Let me explain in another way: nowadays, Lazarus doesn't provide a GUI framework for Android. Perharps, there is a C framework that can solve the problem now. However, although implementing C binds requires relative little time and efforts, join efforts in projects like LCL Custom Draw and FpGUI may result in many benefits on long-term so, that may be the best choice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160127/f73f5348/attachment-0001.html>

Let me explain in another way: nowadays, Lazarus doesn't provide a GUI framework for Android. Perharps, there is a C framework that can solve the problem now.

You mean like Qt 5?

R.

Yes (you need OpenGL or Vulkan (if its out then ^^) using a full blown (game) engine for such a task looks like a bad choice IMHO) and yes (there are headers for OpenGL and if they are missing some stuff it's very easy to add).

The other option I am considering instead of Object Pascal is C++, which will probably have a good interface to OpenGL.

Having used both languages to do OpenGL projects I can say there isn't much of a difference.

Any 3D game programmers that used Object Pascal looking for a new challenge?

No, thanks. I never got what these 3D DEs would improve when we are interacting with 2D devices like mouse and touchpads. But if you would like to take a look at 3D programming in Pascal you may be interested in my little graphics engine (http://asmoday.sourceforge.net/pmwiki/pmwiki.php). It's quite old and not under active development but it is usable for simple stuff and shows how to use OpenGL in FreePascal.

R:

Reimar Grabowski wrote

I never got what these 3D DEs would improve when we are interacting with 2D devices like mouse and touchpads.

+1

Especially now that all "modern design" [yeah right] is going back to wire-frame like designs, like in the days of Windows v1.0 and v2.0. Everything being mono colors and ugly flat looking. Windows, Linux, OSX and mobile devices all following this stupid trend. You can't distinguish a button from a label. No thanks!

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

I understood. :-)

I love coding with pure Pascal code too, however as Greame said, there is a lot of users that already made something in C and exported it as a library, and Pascal programmers can *enjoy it responsibly*. :-)

Compared with 'Oh it's Unix, I know that system...' 3d file manager out of Jurassic (Era|Park) they are a breeze of fresh air ;)

Also all these modern HD 1280x800 displays are getting better at, is beautifully anti-aliased fonts and wire-frames. (thanks to having much better contrast & colour space coverage figures, to be honest)

(I still have a working machine from around 10years ago that sported a 1440x1050 display on 14" diagonal LCD)

Regards, - Graeme -

-L.

Lukasz Sokol wrote

Compared with 'Oh it's Unix, I know that system...' 3d file manager out of Jurassic (Era|Park) they are a breeze of fresh air ;)

Sorry, don't fully understand your statement.

Also all these modern HD 1280x800 displays...

I have no idea how or why consumers allowed LCD manufacturers to rip them off like that. My old Dell Inspiron 9100 (circa 2004) laptop was a 15.4" display with a 1920x1200 resolution. I would expect consumers to appreciate and expect improvements, yet the standard laptop display is now 1366x768. G*d, my monitors from the early 90's had better resolution than that!!

Screen Resolution Statistics (W3Schools site only):

http://www.w3schools.com/browsers/browsers_display.asp

And don't get me going on aspect ratio!

My last [overpriced] laptop purchase was a Macbook Pro with Retina, simply because of the better display, compared to anything PC manufacturers could offer.

Sadly I think most smartphones have a higher resolution than 1366x768.

Anyway, way off topic now. So lets move this elsewhere or email directly for further conversion on this.

Regards,
- Graeme -