I think packages could be used to use Free Pascal object-oriented
libraries in other languages.
With packages it's possible to build LCL, for example, into a DLL,
create a procedural wrapper around it, and then use in any language,
like is done for the Qt bindings.
I'm not saying I would do it, b
L schrieb:
> Freepascal, C, etc. 'Compile using packages' does not make the plugin system
> language independent and portable too. I'm not sure if for example delphi
> packages would ever dynamically load into an fpc executable.
You can't even use packages across different versions of the same co
> Hi Lars,
>
> > The key point is exporting the api from the executable rather than the dll.
> > Many
> > people don't understand this basic concept nor know it is possible, nor
> > understand why it works and how it works.
> >
> I, too, in fact don't understand this. care to give a short explanat
Hi Lars,
The key point is exporting the api from the executable rather than the dll. Many
people don't understand this basic concept nor know it is possible, nor
understand why it works and how it works.
I, too, in fact don't understand this. care to give a short explanation
? I do know abou
Hi
The key point is exporting the api from the executable rather than the dll. Many
people don't understand this basic concept nor know it is possible, nor
understand why it works and how it works.
LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is
no longer in active
Daniël Mantione wrote:
Op Sat, 3 Nov 2007, schreef Marco van de Voort:
Florian Klaempfl schrieb:
Ok, I'll ask next time this person to spent the weekend to fix windows
installer scripts and assign to it the still open web download page,
installer and install package bugs.
I was never for the
>
> > If you really want to write C plugin, then I can add a unit to the
> > IDEIntf with some common functions without OOP.
> >
> I don't intend to doing that right now.
>
> But one of the most commonly used and supposedly complex and well
> defined plugin systems open to 3rd party providers is St
If you really want to write C plugin, then I can add a unit to the
IDEIntf with some common functions without OOP.
I don't intend to doing that right now.
But one of the most commonly used and supposedly complex and well
defined plugin systems open to 3rd party providers is Steinberg (Cuba
On Mon, 05 Nov 2007 12:08:31 +0100
Michael Schnell <[EMAIL PROTECTED]> wrote:
>
> > Look, I don't try to convince you that Lazarus or FPC should make
> > extensive use of packages - we worked years without it and we worked
> > very well,
> If using packages is the way to go to make installing vi
Look, I don't try to convince you that Lazarus or FPC should make
extensive use of packages - we worked years without it and we worked
very well,
If using packages is the way to go to make installing visual components
in Lazarus, IMHO it's essential to use them there ASAP.
It would be really
Op Sat, 3 Nov 2007, schreef Marco van de Voort:
> > Florian Klaempfl schrieb:
> > >>> Ok, I'll ask next time this person to spent the weekend to fix windows
> > >>> installer scripts and assign to it the still open web download page,
> > >>> installer and install package bugs.
> > >> I was never
Marco van de Voort schrieb:
>> Florian Klaempfl schrieb:
> Ok, I'll ask next time this person to spent the weekend to fix windows
> installer scripts and assign to it the still open web download page,
> installer and install package bugs.
I was never for the download system in the
> Florian Klaempfl schrieb:
> >>> Ok, I'll ask next time this person to spent the weekend to fix windows
> >>> installer scripts and assign to it the still open web download page,
> >>> installer and install package bugs.
> >> I was never for the download system in the first place remember? In my
>
Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael
Van Canneyt:
>
> Packages and the missing TClientDataset are the only 2 remaining
> things
> stopping me from using FPC/Lazarus for my daytime job. All else is
> covered or can be covered with a minimal amount of work.
You'l
Florian Klaempfl schrieb:
> Marco van de Voort schrieb:
>> [ Charset ISO-8859-1 unsupported, converting... ]
>>> Because we've to deliever also the fpl's?
>> If it really is that of a problem, you only deliver them using a optional
>> package.
> Who will maintain this?
The pers
Marco van de Voort schrieb:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> Because we've to deliever also the fpl's?
> If it really is that of a problem, you only deliver them using a optional
> package.
Who will maintain this?
>>> The person that will otherwise have to exp
[ Charset ISO-8859-1 unsupported, converting... ]
> Because we've to deliever also the fpl's?
> >>> If it really is that of a problem, you only deliver them using a optional
> >>> package.
> >> Who will maintain this?
> >
> > The person that will otherwise have to explain to newbies how to pa
> Op Sat, 3 Nov 2007, schreef Marco van de Voort:
>
> > > Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
> > > Even then, there will only be savings if the amount of code that can be
> > > smartlinked is small.
> > >
> > > Example: Let's say an LCL package is 10MB. 2 applications are 2MB when
> Michael Van Canneyt schreef:
> >
> > On Sat, 3 Nov 2007, Marco van de Voort wrote:
> >
> >> Don't get too worked up about plugin architectures in the AutoCAD sense. In
> >> practice it is way simpler, like only shipping one BPL to a custom if he
> >> @([EMAIL PROTECTED] paid for it. This means
Op Sat, 3 Nov 2007, schreef Marco van de Voort:
> > Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
> > Even then, there will only be savings if the amount of code that can be
> > smartlinked is small.
> >
> > Example: Let's say an LCL package is 10MB. 2 applications are 2MB when
> > smartli
Michael Van Canneyt schreef:
On Sat, 3 Nov 2007, Marco van de Voort wrote:
Don't get too worked up about plugin architectures in the AutoCAD sense. In
practice it is way simpler, like only shipping one BPL to a custom if he
@([EMAIL PROTECTED] paid for it. This means you can have one main bina
Marco van de Voort schrieb:
>> Marco van de Voort schrieb:
>> - major blow up of installer size
> I fail to see this ?
Because we've to deliever also the fpl's?
>>> If it really is that of a problem, you only deliver them using a optional
>>> package.
>> Who will maintain this?
>
> Th
> Marco van de Voort schrieb:
> - major blow up of installer size
> >>> I fail to see this ?
> >> Because we've to deliever also the fpl's?
> >
> > If it really is that of a problem, you only deliver them using a optional
> > package.
>
> Who will maintain this?
The person that will otherwi
On Sat, 3 Nov 2007, Marco van de Voort wrote:
>
> To be honest, all this diskspace/memory stuff is totally uninteresting.
> Packages are about dividing the Pascal program up in blocks, with parts
> being compilable AFTER the main program, without a lot of additional demands
> (or need for contr
Michael Van Canneyt schrieb:
>
> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>
>> Michael Van Canneyt schrieb:
>>> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>>>
Michael Van Canneyt schrieb:
> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>
>> Leonardo M. Ramé schrieb:
>>> Rea
Marco van de Voort schrieb:
- major blow up of installer size
>>> I fail to see this ?
>> Because we've to deliever also the fpl's?
>
> If it really is that of a problem, you only deliver them using a optional
> package.
Who will maintain this?
___
> Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
> Even then, there will only be savings if the amount of code that can be
> smartlinked is small.
>
> Example: Let's say an LCL package is 10MB. 2 applications are 2MB when
> smartlinked, and 100kb when linked against the package. (The heap can
On Sat, 3 Nov 2007, Daniël Mantione wrote:
>
>
> Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
>
> >
> > > - memory footprint of programs increase significantly since no
> > > smartlinking is possible, I created once a pure shared linked lazarus:
> > > it depended on 50 MB of shared libs.
> Michael Van Canneyt schrieb:
> >>> Hm. I don't see what OSS or not OSS has to do with it ?
> >> Packages have major drawbacks
> >> - DLL/shared lib hell; remember each fpc build gets/needs it's own set
> >> of packages
> >
> > I don't see this as a problem. We release only once a year.
>
> Well
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> Michael Van Canneyt schrieb:
> >
> > On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> >
> >> Michael Van Canneyt schrieb:
> >>> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> >>>
> Leonardo M. Ramé schrieb:
> > Reading a post in "public.mseide
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
>
> > - memory footprint of programs increase significantly since no
> > smartlinking is possible, I created once a pure shared linked lazarus:
> > it depended on 50 MB of shared libs.
>
> Disk footprint may be higher, but memory footprint is de
Michael Van Canneyt schrieb:
>
> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>
>> Michael Van Canneyt schrieb:
>>> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>>>
Leonardo M. Ramé schrieb:
> Reading a post in "public.mseide-msegui.talk", the mseide discussion
> list, I found this:
> On Sat, 3 Nov 2007, Dani?l Mantione wrote:
> ...
> In my opinion, Packages are the second best thing Borland did for RAD.
> If I remember the shit we had with VB and its OCXes, DLLs and whatnot.
> ...
I agree. I also want to remind that it is not just about the use for us. The
devels will crea
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> Michael Van Canneyt schrieb:
> >
> > On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> >
> >> Leonardo M. Ramé schrieb:
> >>> Reading a post in "public.mseide-msegui.talk", the mseide discussion
> >>> list, I found this:
> >>>
> >>> "Florian has comm
On Sat, 3 Nov 2007, Daniël Mantione wrote:
>
>
> Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
>
> >
> >
> > On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> >
> > > Leonardo M. Ramé schrieb:
> > > > Reading a post in "public.mseide-msegui.talk", the mseide discussion
> > > > list, I fo
Daniël Mantione schrieb:
>
> Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
>
>>
>> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>>
>>> Leonardo M. Ramé schrieb:
Reading a post in "public.mseide-msegui.talk", the mseide discussion
list, I found this:
"Florian has committed
> Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
> > > played only with it.
> >
> > Hm. I don't see what OSS or not OSS has to do with it ?
> >
> > Packages are IMHO a pre-requisite for any good plugin system.
>
> The reason is that the "library" construction requires you to write down
> your
Michael Van Canneyt schrieb:
>
> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>
>> Leonardo M. Ramé schrieb:
>>> Reading a post in "public.mseide-msegui.talk", the mseide discussion
>>> list, I found this:
>>>
>>> "Florian has committed the beginning of dynamic packages support".
>>>
>>> With "D
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
>
>
> On Sat, 3 Nov 2007, Florian Klaempfl wrote:
>
> > Leonardo M. Ramé schrieb:
> > > Reading a post in "public.mseide-msegui.talk", the mseide discussion
> > > list, I found this:
> > >
> > > "Florian has committed the beginning of dynami
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> Leonardo M. Ramé schrieb:
> > Reading a post in "public.mseide-msegui.talk", the mseide discussion
> > list, I found this:
> >
> > "Florian has committed the beginning of dynamic packages support".
> >
> > With "Dynamic Packages" you mean a platf
Leonardo M. Ramé schrieb:
> Reading a post in "public.mseide-msegui.talk", the mseide discussion
> list, I found this:
>
> "Florian has committed the beginning of dynamic packages support".
>
> With "Dynamic Packages" you mean a platform independent way of
> implementing something similar to
>
Reading a post in "public.mseide-msegui.talk", the mseide discussion
list, I found this:
"Florian has committed the beginning of dynamic packages support".
With "Dynamic Packages" you mean a platform independent way of
implementing something similar to
.Dlls (or .bpl)? without creating each lib
42 matches
Mail list logo
