Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread silvioprog 
On Wed, Jan 27, 2016 at 9:30 AM, Fabrício Srdic 
wrote:

> 2016-01-27 0:19 GMT-02:00 silvioprog 
>
>> 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.
>>>
>> 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.
>>
> 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.
>

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*. :-)

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Graeme Geldenhuys 
On 2016-01-27 13:12, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Chavoux Luyt 
> From: Graeme Geldenhuys 
 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.

> 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.
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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Fabrício Srdic 
2016-01-27 7:47 GMT-02:00 Graeme Geldenhuys :

> On 2016-01-27 01:51, 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.
>
>
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?


>
> > 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.
>
>
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.


> 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.
>
>
This is on my to-do list :-).
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Graeme Geldenhuys 
On 2016-01-27 11:28, 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 -


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Graeme Geldenhuys 
On 2016-01-27 01:51, 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 -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Reimar Grabowski 
On Wed, 27 Jan 2016 13:16:14 +0200
Chavoux Luyt  wrote:

> 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?
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:

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Fabrício Srdic 
2016-01-27 0:19 GMT-02:00 silvioprog 

> 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.
>>
> 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.
>
> --
> Silvio Clécio
>
>
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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-27 Thread Reimar Grabowski 
On Wed, 27 Jan 2016 10:30:17 -0200
Fabrício Srdic  wrote:

> 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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread Fabrício Srdic 
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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread silvioprog 
On Tue, Jan 26, 2016 at 9:17 AM, Fabrício Srdic 
wrote:

> 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.
>

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
> 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.
>

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. :-)

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread Fabrício Srdic 
Em 26/01/2016 11:30, "silvioprog"  escreveu:
>
> 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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread Marc Santhoff 
On Mo, 2016-01-25 at 22:09 -0300, 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.

-- 
Marc Santhoff 


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread silvioprog 
On Tue, Jan 26, 2016 at 1:01 PM, Fabrício Srdic 
wrote:

> Em 26/01/2016 11:30, "silvioprog"  escreveu:
> >
> > 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.
>
There is no a language/compiler/library that can prevent all
possible future problems or customers needs. :-)

> > 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.
>
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.

> > 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.
>
I couldn't understand what you meant.

--
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread Fabrício Srdic 
Em 26/01/2016 23:23, "silvioprog"  escreveu:
>
> On Tue, Jan 26, 2016 at 1:01 PM, Fabrício Srdic 
wrote:
>>
>> 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.
>
> I couldn't understand what you meant.
>
> --
> Silvio Clécio

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread silvioprog 
On Tue, Jan 26, 2016 at 9:54 PM, Marc Santhoff  wrote:

> On Mo, 2016-01-25 at 22:09 -0300, 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.
>

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


> 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.


Awesome!

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread silvioprog 
On Tue, Jan 26, 2016 at 10:51 PM, Fabrício Srdic 
wrote:

> Em 26/01/2016 23:23, "silvioprog"  escreveu:
> >
> > On Tue, Jan 26, 2016 at 1:01 PM, Fabrício Srdic <
> fabricio.sr...@gmail.com> wrote:
> >>
> >> 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.
> >
> > I couldn't understand what you meant.
> >
> > --
> > Silvio Clécio
>
> 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.
>
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.

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-26 Thread Mattias Gaertner 
On Tue, 26 Jan 2016 10:17:36 -0200
Fabrício Srdic  wrote:

>[...]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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread silvioprog 
On Mon, Jan 25, 2016 at 8:54 AM, Jy V  wrote:

> On Mon, Jan 25, 2016 at 4:59 AM, silvioprog  wrote:
>
>>
>> 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. :-)
>>
>
> Instead of relying on external libraries such as nghttp2,
>
[...]
>

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. :-)

--
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread silvioprog 
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. ^^'

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread Michael Van Canneyt 



On Mon, 25 Jan 2016, silvioprog wrote:



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.


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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread Dmitry Boyarintsev 
On Mon, Jan 25, 2016 at 3:08 PM, Michael Van Canneyt  wrote:

> On Mon, 25 Jan 2016, silvioprog wrote:
>
>>
>> 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.
>>
>
> There is a simple reason: Debugging and bugfixing is a lot easier if all
> the code is in pascal.
>

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread silvioprog 
On Mon, Jan 25, 2016 at 5:08 PM, Michael Van Canneyt  wrote:

> On Mon, 25 Jan 2016, silvioprog wrote:
>>
>> 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.
>>
>
> There is a simple reason: Debugging and bugfixing is a lot easier if all
> the code is in pascal.
>

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. :-)

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread Dmitry Boyarintsev 
On Mon, Jan 25, 2016 at 5:02 PM, Dmitry Boyarintsev <
skalogryz.li...@gmail.com> wrote:

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

thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread silvioprog 
On Mon, Jan 25, 2016 at 7:02 PM, Dmitry Boyarintsev <
skalogryz.li...@gmail.com> wrote:

> On Mon, Jan 25, 2016 at 3:08 PM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
>
>> On Mon, 25 Jan 2016, silvioprog wrote:
>>
>>>
>>> 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.
>>>
>>
>> There is a simple reason: Debugging and bugfixing is a lot easier if all
>> the code is in pascal.
>>
>
> Here's another reason - cross-platform availability.
> FPC is cross platform. To some extent (Java?) is more cross-platform that
> C is.
>

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 )


> 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.
>

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. :-/

--
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-25 Thread Jy V 
On Mon, Jan 25, 2016 at 4:59 AM, silvioprog  wrote:

>
> 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. :-)
>

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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-24 Thread silvioprog 
On Sat, Jan 23, 2016 at 8:37 AM, Jy V  wrote:

> Hello Silvio,
>
> Are you considering to use TurboPower HTTP components to implements HPACK
> and HTTP/2 ?
>

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.

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-23 Thread Jy V 
Hello Silvio,

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

On Sat, Jan 23, 2016 at 5:39 AM, silvioprog  wrote:

> 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
>
> --
> Silvio Clécio
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] [PATCH] components/turbopower_ipro: added the Iphttpbroker and its example

2016-01-22 Thread silvioprog 
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

-- 
Silvio Clécio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus