Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-20 Thread David Lyon

Marco van de Voort wrote:
What I think we should devise or adapt is something a bit similar to the 
python/perl library model.



What exactly is that model? Triple the average linux packaging system size
by sticking every unit into a separate installable package and provide of a
web of dependancies that pulls half of them in in an average install?
  
The model is that you download the source you need and compile it into 
your own system.

- use/extend the existing fpc tools to load the package. They get
  installed into a predefined directory like the /perl/site/lib directory
  in perl.



Define load. Also keep in mind that Perl installs interpreter sourcecode,
what exactly do you imagine for FPC? compiled libs, source? How do you deal
with versioning?
  
Right. That's what perl does. We should do the same thing. Then compile 
it into a library that we can use.
 
  

- the compilable source files get compiled at package load time
  and integrated into the system for use in the uses clause.



I don't think it is wise to bother the compiler with the packaging system.
  
It has no feelings :-) no pain will be caused by say 3 seconds of 
compiling.

Keep in mind we are not a scripting system, but a compiler. The whole idea
is that the end-users of a binary don't need the whole shebang.
  
I agree. It is a compiler. So we shouldn't be afraid to ask it to 
compile an extra file for us.


The issue is more about platform independance and download size. By 
distributing packages in source code and compiling them after download, 
it means quicker downloads and less time recompiling the whole of 
lazararus just to add in a new package.

- fpc/lazarus uses these library files just as it would
  internal functions...



That is impossible. (or you use internal functions entirely the wrong
way).
  

Why impossible ?

At compile time, the compiler could decide whether the function is 
internal ie within the lazarus library files, or external within the 
users library directory.


It makes no difference to the linker (ld), where the code is. The linker 
just needs the names of the additional libraries to link against.



Maybe we already have some of the parts of this already. It would be good
to have something that works as simply as this. Yes, I might be able to
help with making it work if people want to go this way.



This is what fppkg and friends are achieving. However it has not much to do
with dynlinking. There are tough technicaly nuts to be crached there first.
Read the wiki articles.
  
Well I don't have an enormous amount of working experience with fpc to 
comment too deeply on what it is or isn't doing.


But I have noticed that we are using the GNU ld linker and I have been 
exposed to that a bit in the past. I know what that thing can do and 
what it can't.


When I use GLScene in Lazarus, ld takes an enourmous amount of time to 
link. It is unbearable. ld is being asked  to write in all the glscene 
code into the .exe and seems to take forever (15+ seconds).


I would prefer to have the option to link against the runtime libraries 
dynamically. This would save so much time.


As far as I am aware, it is only a matter of changing the command line 
parameters when ld is being called, and ensuring that all the libraries 
that are being linked against are in the correct directories.


David









Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-20 Thread David Lyon

Michael Van Canneyt wrote:

- fpc/lazarus uses these library files just as it would
  internal functions...



That is impossible. (or you use internal functions entirely the wrong
way).
  
  

Why impossible ?

At compile time, the compiler could decide whether the function is internal
ie within the lazarus library files, or external within the users library
directory.



This is not something the compiler should decide. It should compile code,
period. 

Right. That is technically correct.

The linker, ld actually decides where it needs to pull in the 
appropriate library code from.

All the rest should be outside the compiler, in an installer system.
  

That may well be.

But what calls the linker ld ?

This is the kind of stuff that fppkg is meant to solve.
  

Maybe that is the right place for it.

David



Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-20 Thread Marco van de Voort
On Mon, Aug 20, 2007 at 05:42:26PM +1000, David Lyon wrote:
 The model is that you download the source you need and compile it into your 
 own system.

That's no problem, and already the case.

 Define load. Also keep in mind that Perl installs interpreter
 sourcecode, what exactly do you imagine for FPC? compiled libs, source?
 How do you deal with versioning?
   
 Right. That's what perl does. We should do the same thing. Then compile it 
 into a library that we can use.

I don't understand what you really want to add. The perl reference is next
to useless. Please be more descriptive.
 
 - the compilable source files get compiled at package load time
   and integrated into the system for use in the uses clause.
 
 
 I don't think it is wise to bother the compiler with the packaging system.
   
 It has no feelings :-) no pain will be caused by say 3 seconds of 
 compiling.

It has no knowledge of lazarus, all it knows are stuff like directories to
search for source.

 Keep in mind we are not a scripting system, but a compiler. The whole idea
 is that the end-users of a binary don't need the whole shebang.
   
 I agree. It is a compiler. So we shouldn't be afraid to ask it to compile 
 an extra file for us.
 
 The issue is more about platform independance and download size. By 
 distributing packages in source code and compiling them after download, it 
 means quicker downloads and less time recompiling the whole of lazararus 
 just to add in a new package.

How is this different than e.g. fppkg ?

 - fpc/lazarus uses these library files just as it would
   internal functions...
 
 
 That is impossible. (or you use internal functions entirely the wrong
 way).
   
 Why impossible ?
 
 At compile time, the compiler could decide whether the function is 
 internal ie within the lazarus library files, or external within the 
 users library directory.

Well, the compiler knows nothing about lazarus.
 
 But I have noticed that we are using the GNU ld linker and I have been 
 exposed to that a bit in the past. I know what that thing can do and what 
 it can't.

(actually starting with 2.1.x/2.2 not on windows anymore)

 When I use GLScene in Lazarus, ld takes an enourmous amount of time to 
 link. It is unbearable. ld is being asked  to write in all the glscene code 
 into the .exe and seems to take forever (15+ seconds).
 
 I would prefer to have the option to link against the runtime libraries 
 dynamically. This would save so much time.

Well, I actually don't know that, but it could be yes. But that would
require library packages like Delphi has and is far off. Further, it is
pretty unrelated to the source packaging system.
 
 As far as I am aware, it is only a matter of changing the command line 
 parameters when ld is being called, and ensuring that all the libraries 
 that are being linked against are in the correct directories.

_IF_ you have a valid librarypackaging system (shared lib generation on
pascal level) system. But this is maybe as big as a change as e.g. adding a
ELF internal linker.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-20 Thread Michael Van Canneyt


On Mon, 20 Aug 2007, David Lyon wrote:

 Michael Van Canneyt wrote:
 - fpc/lazarus uses these library files just as it would
   internal functions...
 
 
That is impossible. (or you use internal functions entirely the wrong
way).
  
  
   Why impossible ?
  
   At compile time, the compiler could decide whether the function is
   internal
   ie within the lazarus library files, or external within the users
   library
   directory.
   
 
  This is not something the compiler should decide. It should compile code,
  period. 
 Right. That is technically correct.
 
 The linker, ld actually decides where it needs to pull in the appropriate
 library code from.

Not really, the source code tells you where it is ? 

  All the rest should be outside the compiler, in an installer system.

 That may well be.
 
 But what calls the linker ld ?

The compiler.

  This is the kind of stuff that fppkg is meant to solve.

 Maybe that is the right place for it.

I think we're talking about different things, so never mind my remark :-)

Michael.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-20 Thread David Lyon

Marco van de Voort wrote:

Define load. Also keep in mind that Perl installs interpreter
sourcecode, what exactly do you imagine for FPC? compiled libs, source?
How do you deal with versioning?
  
  
Right. That's what perl does. We should do the same thing. Then compile it 
into a library that we can use.



I don't understand what you really want to add. The perl reference is next
to useless. Please be more descriptive.
  
The typical scenario is this... need a library for say ... blowfish 
encryption...


Run the package-manager fppkg ... search for blowfish... find the 
package... download it... compile it... and have it available.


we end up with the following files in our directories...

/packages
   /source - blowfish.pas
  readme.txt
  moduleinfo.xml
   /library
  blowfish.dll
  (or)  blowfish.so


The issue is more about platform independance and download size. By 
distributing packages in source code and compiling them after download, it 
means quicker downloads and less time recompiling the whole of lazararus 
just to add in a new package.



How is this different than e.g. fppkg ?
  

Things we need to look at :

- a central code/libary repository ie like cpan


Well, I actually don't know that, but it could be yes. But that would
require library packages like Delphi has and is far off. Further, it is
pretty unrelated to the source packaging system.
  

Not sure why...but I accept what you say... everything takes time...
 
  
As far as I am aware, it is only a matter of changing the command line 
parameters when ld is being called, and ensuring that all the libraries 
that are being linked against are in the correct directories.



_IF_ you have a valid librarypackaging system (shared lib generation on
pascal level) system. But this is maybe as big as a change as e.g. adding a
ELF internal linker.
  

I wish I had more time to look into this.

Maybe I might have to see how it works for myself.

David




Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-20 Thread Michael Van Canneyt


On Mon, 20 Aug 2007, David Lyon wrote:

 Marco van de Voort wrote:
Define load. Also keep in mind that Perl installs interpreter
sourcecode, what exactly do you imagine for FPC? compiled libs, source?
How do you deal with versioning?
  
  
   Right. That's what perl does. We should do the same thing. Then compile it
   into a library that we can use.
   
 
  I don't understand what you really want to add. The perl reference is next
  to useless. Please be more descriptive.

 The typical scenario is this... need a library for say ... blowfish
 encryption...
 
 Run the package-manager fppkg ... search for blowfish... find the package...
 download it... compile it... and have it available.
 
 we end up with the following files in our directories...
 
 /packages
/source - blowfish.pas
   readme.txt
   moduleinfo.xml
/library
   blowfish.dll
   (or)  blowfish.so

or
/units/blowfish.ppu

That is what is implemented now. There is no need for the library.
If you start with libraries, then they must be deployed as well, and that
will start nameclashes, version clashes etc. This is avoided with the units.

 
 
   The issue is more about platform independance and download size. By
   distributing packages in source code and compiling them after download, it
   means quicker downloads and less time recompiling the whole of lazararus
   just to add in a new package.
   
 
  How is this different than e.g. fppkg ?

 Things we need to look at :
 
 - a central code/libary repository ie like cpan

That is already implemented in fppkg.

Michael.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-19 Thread Marco van de Voort
On Sun, Aug 19, 2007 at 10:08:57AM +1000, David Lyon wrote:
 
 When the ToDos are solved the IDE can be extended.
 
 
 I added a few links to FPC wiki sites there.
 Well, I have had a think about this library issue a bit further.
 
 What I think we should devise or adapt is something a bit similar to the 
 python/perl library model.

What exactly is that model? Triple the average linux packaging system size
by sticking every unit into a separate installable package and provide of a
web of dependancies that pulls half of them in in an average install?
 
It does buy exposure though :-)

 This is what imho we should provide. The ideas are not so new I know:

 - use/extend the existing fpc tools to load the package. They get
   installed into a predefined directory like the /perl/site/lib directory
   in perl.

Define load. Also keep in mind that Perl installs interpreter sourcecode,
what exactly do you imagine for FPC? compiled libs, source? How do you deal
with versioning?
 
 - the compilable source files get compiled at package load time
   and integrated into the system for use in the uses clause.

I don't think it is wise to bother the compiler with the packaging system.
Keep in mind we are not a scripting system, but a compiler. The whole idea
is that the end-users of a binary don't need the whole shebang.
 
 - fpc/lazarus uses these library files just as it would
   internal functions...

That is impossible. (or you use internal functions entirely the wrong
way).

 Summary...
 
 Maybe we already have some of the parts of this already. It would be good
 to have something that works as simply as this. Yes, I might be able to
 help with making it work if people want to go this way.

This is what fppkg and friends are achieving. However it has not much to do
with dynlinking. There are tough technicaly nuts to be crached there first.
Read the wiki articles.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-18 Thread Marco van de Voort
On Thu, Aug 16, 2007 at 09:10:46AM +0200, Mattias Gaertner wrote:
 On Thu, 16 Aug 2007 09:46:46 +1000
 David Lyon [EMAIL PROTECTED] wrote:
 
  Hi Darius,
  
  Darius Blaszijk wrote:
 [...]
   2) Lazarus only supports static packages. So installing a package 
   would always require to recompile Lazarus. I have no idea what the 
   progress on this topic is. Perhaps the wiki has something on it, or 
   someone from core can comment.
 
 See
 http://wiki.lazarus.freepascal.org/Lazarus/FPC_Libraries
 
 When the ToDos are solved the IDE can be extended.

I added a few links to FPC wiki sites there.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit??? release 0.5

2007-08-18 Thread David Lyon

Marco van de Voort wrote:

Darius Blaszijk wrote:
[...]
  
2) Lazarus only supports static packages. So installing a package 
would always require to recompile Lazarus. I have no idea what the 
progress on this topic is. Perhaps the wiki has something on it, or 
someone from core can comment.


See
http://wiki.lazarus.freepascal.org/Lazarus/FPC_Libraries

When the ToDos are solved the IDE can be extended.



I added a few links to FPC wiki sites there.

Well, I have had a think about this library issue a bit further.

What I think we should devise or adapt is something a bit similar to the 
python/perl library model.


This is what imho we should provide. The ideas are not so new I know:

- provide the ability to package up a directory containing all the
  necessary files, source, docs, tests, examples data etc (ie akin to
  the .deb or .rpm or .zip

- use/extend the existing fpc tools to load the package. They get
  installed into a predefined directory like the /perl/site/lib directory
  in perl.

- within fpc/lazarus, keep either an xml file or a database
  holding names of all the installed packages.

- the tricky bit, is that within the package registration information
  , there is a platform string and a version number somewhere.

- the package name, version and platform, go into the database.

- the compilable source files get compiled at package load time
  and integrated into the system for use in the uses clause.

- it doesn't matter if the platform is different. The packages
  can be compiled and installed on any platform. (Providing
  they are marked as platform independant in their config
  file)

- at run time, the libraries are kept within a specific directory
  (/site/lib ?) as .dll or .so whatever files. All together with
  all the other libraries. But away from the source files.

- fpc/lazarus uses these library files just as it would
  internal functions...

Summary...

Maybe we already have some of the parts of this already.

It would be good to have something that works as simply as this.

Yes, I might be able to help with making it work if people want to go 
this way.


David








Re: [lazarus] Web Service Toolkit” release 0.5

2007-08-16 Thread Mattias Gaertner
On Thu, 16 Aug 2007 09:46:46 +1000
David Lyon [EMAIL PROTECTED] wrote:

 Hi Darius,
 
 Darius Blaszijk wrote:
[...]
  2) Lazarus only supports static packages. So installing a package 
  would always require to recompile Lazarus. I have no idea what the 
  progress on this topic is. Perhaps the wiki has something on it, or 
  someone from core can comment.

See
http://wiki.lazarus.freepascal.org/Lazarus/FPC_Libraries

When the ToDos are solved the IDE can be extended.

Mattias

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit” release 0.5

2007-08-16 Thread Michael Van Canneyt


On Thu, 16 Aug 2007, David Lyon wrote:

 Michael Van Canneyt wrote:
  As far as I'm concerned, this is an absolute must for inclusion in Lazarus
  by default. It would ensure that lazarus covers all areas of modern
  development. (if such a thing exists...)

 When I made my modern comment, I actually meant it with students in mind.
 Who sometimes hear that pascal is an old language.
 
 So saying modern implies that it is like Python or C# or Java etc..
 
 Having XML/RPC/Webservices inbuilt would be a good step.

None of the languages you mention have XML/RPC/Webservices inbuilt.
They do provide libraries for these techniques. It would be good to 
point this out if people comment on features of a 'language'.

Most people seem to confuse the language with the libraries that provide
functionality.

With WST, FPC/lazarus now offers libraries for all areas of modern development.

 
 The other big issue, something that delphi suffers from bigtime, is
 package-management.
 
 Having worked with Perl, they really do a wonderful job of package management.
 
 That is, if you want say, a ups library, type in ppm search ups. It gives
 you a list of modules. To install one, you say install 2 (install the second
 module on the list). Bingo, it now works

This is exactly what fppkg (see the packaging thread in fpc-devel) is meant to 
do.

It is in it's early stages, but all building blocks are there to make
something equal to or better than CPAN.

Any help with it's development is appreciated.

Michael.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit” release 0.5

2007-08-15 Thread Michael Van Canneyt


On Wed, 15 Aug 2007, Inoussa OUEDRAOGO wrote:

 Dear Lazarus users,
 
 Web Service Toolkit is a web services package for FPC, Lazarus and
 Delphi; Web Service Toolkit is meant to ease web services
 consumption and creation by FPC, Lazarus and Delphi users.

I updated from SVN and compiled everything. What can I say ?

My congratulations. It looks excellent; 
Much better than I had ever dreamed of :-)

As far as I'm concerned, this is an absolute must for inclusion in Lazarus
by default. It would ensure that lazarus covers all areas of modern
development. (if such a thing exists...)

And a definite must for showing off on Systems... :-)

Michael.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


RE: [lazarus] Web Service Toolkit release 0.5

2007-08-15 Thread Hess, Philip J
I second this. I've been using WST extensively on Windows with Delphi
and FPC and on OS X with FPC: WST works great. If you're not exploring
the use of Web services you're potentially missing out on a really
useful new technology.

Thanks.

-Phil


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Van Canneyt
Sent: Wednesday, August 15, 2007 3:34 AM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Web Service Toolkit release 0.5



On Wed, 15 Aug 2007, Inoussa OUEDRAOGO wrote:

 Dear Lazarus users,
 
 Web Service Toolkit is a web services package for FPC, Lazarus and
 Delphi; Web Service Toolkit is meant to ease web services
 consumption and creation by FPC, Lazarus and Delphi users.

I updated from SVN and compiled everything. What can I say ?

My congratulations. It looks excellent; 
Much better than I had ever dreamed of :-)

As far as I'm concerned, this is an absolute must for inclusion in
Lazarus
by default. It would ensure that lazarus covers all areas of modern
development. (if such a thing exists...)

And a definite must for showing off on Systems... :-)

Michael.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit” release 0.5

2007-08-15 Thread David Lyon

Michael Van Canneyt wrote:

As far as I'm concerned, this is an absolute must for inclusion in Lazarus
by default. It would ensure that lazarus covers all areas of modern
development. (if such a thing exists...)
  
When I made my modern comment, I actually meant it with students in 
mind. Who sometimes hear that pascal is an old language.


So saying modern implies that it is like Python or C# or Java etc..

Having XML/RPC/Webservices inbuilt would be a good step.

The other big issue, something that delphi suffers from bigtime, is 
package-management.


Having worked with Perl, they really do a wonderful job of package 
management.


That is, if you want say, a ups library, type in ppm search ups. It 
gives you a list of modules. To install one, you say install 2 
(install the second module on the list). Bingo, it now works


Being open source, Lazarus really lends itself to doing the same thing. 
That's an example of a really modern feature.


This one just takes time to implement, but perl does it really nicely. 
In delphi, it can take so long to find code to do something. They are 
way behind perl in that respect. So it is an opportunity I believe...


Regards

David




_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit” release 0.5

2007-08-15 Thread Darius Blaszijk

David Lyon wrote:

Michael Van Canneyt wrote:
As far as I'm concerned, this is an absolute must for inclusion in 
Lazarus

by default. It would ensure that lazarus covers all areas of modern
development. (if such a thing exists...)
  
When I made my modern comment, I actually meant it with students in 
mind. Who sometimes hear that pascal is an old language.


So saying modern implies that it is like Python or C# or Java etc..

Having XML/RPC/Webservices inbuilt would be a good step.

The other big issue, something that delphi suffers from bigtime, is 
package-management.


Having worked with Perl, they really do a wonderful job of package 
management.


That is, if you want say, a ups library, type in ppm search ups. It 
gives you a list of modules. To install one, you say install 2 
(install the second module on the list). Bingo, it now works


Being open source, Lazarus really lends itself to doing the same 
thing. That's an example of a really modern feature.


This one just takes time to implement, but perl does it really nicely. 
In delphi, it can take so long to find code to do something. They are 
way behind perl in that respect. So it is an opportunity I believe...



AFAICT there are two issues here;

1) package management is currently being developed under FPC (see fppkg 
and fpmkunit and http://wiki.freepascal.org/FPMake). It will consist of 
a repository with downloadable packages for FPC. This could be 
extended easily in the near future for Lazarus. But it will be a long 
way still.
2) Lazarus only supports static packages. So installing a package would 
always require to recompile Lazarus. I have no idea what the progress on 
this topic is. Perhaps the wiki has something on it, or someone from 
core can comment.


Darius

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives


Re: [lazarus] Web Service Toolkit” release 0.5

2007-08-15 Thread David Lyon

Hi Darius,

Darius Blaszijk wrote:
1) package management is currently being developed under FPC (see 
fppkg and fpmkunit and http://wiki.freepascal.org/FPMake). It will 
consist of a repository with downloadable packages for FPC. This 
could be extended easily in the near future for Lazarus. But it will 
be a long way still.
I understand. Perl's package management system wasn't built overnight 
either.


2) Lazarus only supports static packages. So installing a package 
would always require to recompile Lazarus. I have no idea what the 
progress on this topic is. Perhaps the wiki has something on it, or 
someone from core can comment.

If that is the way that it is written so far then I accept what you say.

When I was at an OpenSource conference recently everybody was bragging 
how they got their perl module into cpan (the perl library 
repository). Now cpan is really huge - and some of the code quality on 
it is really high.


I've only mentioned this, because I've seen it elsewhere and know how 
powerful it can be. Kindof blows Torry out of the water so to speak. 
There is enough to get on with at the moment so it doesn't really 
present any problem. It's more of a wish-list thing.


Actually, package-management can be implemented via XML-RPC.. :-)

That is what made me think of it I guess...

Regards

David




_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives