On 01/10/2011 12:09 PM, michael.vancann...@wisa.be wrote:
>
>
> On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
>
>> 10.01.2011 13:50, michael.vancann...@wisa.be пишет:
>>>
>>>
>>> On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
>>>
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
>
To split some hairs ;)
Level the OS's with an addition (or some additions) and program the
universal application on top of that.
This makes the application lighter AND portable.
Regards / Cees (who has no practical experience with
fpc-pascal/Lazarus/Freepascal i.e. a lurker)
On 01/10/2011 11:05
- "michael vancanneyt" schreef:
> > My solution, in short, is that packages should have OS independent
> interface
> > to RTL built into executable visible to packages as RTL built as c
> package
> > (with is a bridge to real RTL).
>
> I understood that. Assuming you can make this interfa
10.01.2011 17:40, Jonas Maebe пишет:
On 10 Jan 2011, at 14:46, Alex Shishkin wrote:
By the way despite the fact that static linking to external libraries
will be impossible, but dynamic linking could be implemented. Anyway
I understand that platform independence of code imposes certain
restr
On 10 Jan 2011, at 14:46, Alex Shishkin wrote:
By the way despite the fact that static linking to external
libraries will be impossible, but dynamic linking could be
implemented. Anyway I understand that platform independence of code
imposes certain restrictions and that restrictions impac
As an example, your
proposal would imply that no external calls whatsoever would be possible
(including calls to external libraries due to them using different calling
conventions, etc.).
Tomas
By the way despite the fact that static linking to external libraries
will be impossible, but dynam
In our previous episode, michael.vancann...@wisa.be said:
> >> work as packages are intended to work.
> >
> > Could you explain this?
>
> A Delphi DLL on windows is roughly equivalent to a exe.
> A fully contained binary, no dependencies.
DLL's can perfectly fine depend on other binaries.
I assu
On Mon, 10 Jan 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
The main problem is the Windows target where a library is more like a
self-contained exe. On Linux (and probably Mac OS), libraries already
work as packages are intended to work.
Could y
On Mon, January 10, 2011 13:46, alexv...@mail.ru wrote:
> 10.01.2011 15:31, Marco van de Voort пи�о�:
>> In our previous episode, alexv...@mail.ru said:
>>> But I want packages to be binary portable between OS (on target
>>> processor architecture)
>> That's effectively not possible with all O
In our previous episode, alexv...@mail.ru said:
> >> But I want packages to be binary portable between OS (on target
> >> processor architecture)
> > That's effectively not possible with all OSes providing such emulation
> > ABI.
> >
> > Esperanto for OSes so to speak.
> >
> Does "inefficiently" m
10.01.2011 15:31, Marco van de Voort пишет:
In our previous episode, alexv...@mail.ru said:
But I want packages to be binary portable between OS (on target
processor architecture)
That's effectively not possible with all OSes providing such emulation ABI.
Esperanto for OSes so to speak.
__
In our previous episode, Matt Emson said:
> > Like I said, your proposal requires that we emulate all OSes on all
> > other OSes.
>
> Or create a VM layer that levels the OS level differences - but again,
> why do this? Creating such a VM is probably a magnitude of complexity
> over just using
In our previous episode, Sven Barth said:
>
> The main point with packages is that a package is a libary that can be
> loaded at runtime with some compiler magic.
IMHO that is only secondary.
The primary point is that a set of units (+mainprogram) can be divided over
multiple binaries transpar
In our previous episode, alexv...@mail.ru said:
> But I want packages to be binary portable between OS (on target
> processor architecture)
That's effectively not possible with all OSes providing such emulation ABI.
Esperanto for OSes so to speak.
___
In our previous episode, michael.vancann...@wisa.be said:
> The main problem is the Windows target where a library is more like a
> self-contained exe. On Linux (and probably Mac OS), libraries already
> work as packages are intended to work.
Could you explain this?
_
10.01.2011 14:09, michael.vancann...@wisa.be пишет:
I understood that. Assuming you can make this interface (which I don't
believe), your solution is still not realistic:
And how will you make a package that uses a os-specific function OS
independent ? (for instance, a package with a control
On 10/01/2011 11:09, michael.vancann...@wisa.be wrote:
Like I said, your proposal requires that we emulate all OSes on all
other OSes.
Or create a VM layer that levels the OS level differences - but again,
why do this? Creating such a VM is probably a magnitude of complexity
over just using
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:50, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want pac
10.01.2011 13:50, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target processor
architecture)
I don't think that is fe
10.01.2011 13:19, Florian Klaempfl пишет:
Am 10.01.2011 11:16, schrieb alexv...@mail.ru:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru:
But I want packages to be binary portable between OS (on target
processor
arc
Am 10.01.2011 11:16, schrieb alexv...@mail.ru:
> 10.01.2011 13:05, michael.vancann...@wisa.be пишет:
>>
>>
>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>
>>> 2011/1/10 alexv...@mail.ru :
>
But I want packages to be binary portable between OS (on target
processor
architecture)
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target
processor
architecture)
I don't think that is feasible, unless you don't use any OS features.
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target processor
architecture)
I don't think that is feasible, unless you don't use any OS features.
Exactly.
Even just because FPC supports multiple CPUs
Am 10.01.2011 11:00, schrieb alexv...@mail.ru:
10.01.2011 12:50, michael.vancann...@wisa.be пишет:
Why ? There is no need for that; You can perfectly use the OS
functionality.
All you need to do is add a layer on top which hides the OS specifics.
Borland could do it, so we can do it too.
The
2011/1/10 alexv...@mail.ru :
>>
> But I want packages to be binary portable between OS (on target processor
> architecture)
I don't think that is feasible, unless you don't use any OS features.
Vincent
___
fpc-pascal maillist - fpc-pascal@lists.freep
10.01.2011 12:58, Matt Emson пишет:
On 10/01/2011 09:26, alexv...@mail.ru wrote:
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to
duplicate some OS functions to make things crossplatform.
I don't think that is
Am 10.01.2011 10:58, schrieb Matt Emson:
On 10/01/2011 09:26, alexv...@mail.ru wrote:
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to duplicate
some OS functions to make things crossplatform.
I don't think that
10.01.2011 12:50, michael.vancann...@wisa.be пишет:
Why ? There is no need for that; You can perfectly use the OS
functionality.
All you need to do is add a layer on top which hides the OS specifics.
Borland could do it, so we can do it too.
The main problem is the Windows target where a li
On 10/01/2011 09:26, alexv...@mail.ru wrote:
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to duplicate
some OS functions to make things crossplatform.
I don't think that is what Sven meant. I think the executa
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 12:05, Sven Barth пишет:
No, FPC should rely on the operating system for dynamic linking. There is
no use in duplicating a functionality that is already there. One "just"
needs to spot all problems that might arise on different platform
10.01.2011 12:05, Sven Barth пишет:
No, FPC should rely on the operating system for dynamic linking. There
is no use in duplicating a functionality that is already there. One
"just" needs to spot all problems that might arise on different
platforms when using dynamic libraries (e.g. symbol reso
Am 09.01.2011 22:03, schrieb alexv...@mail.ru:
24.12.2010 17:31, Sven Barth пишет:
Yeah... and only works on i386- and x86_64-linux.
Runtime packages will come sooner or later, maybe not this year (ok...
that's hard to beat ^^) and maybe not next year. But when they come
they'll be implemented
24.12.2010 17:31, Sven Barth пишет:
Yeah... and only works on i386- and x86_64-linux.
Runtime packages will come sooner or later, maybe not this year (ok...
that's hard to beat ^^) and maybe not next year. But when they come
they'll be implemented in a good cross platform way without such
ha
Am 23.12.2010 16:20, schrieb alexv...@mail.ru:
23.12.2010 17:52, Marco van de Voort пишет:
In our previous episode, alexv...@mail.ru said:
Therefore, until the time someone finds a cross-platform way to
implement packages, I see no reason not to start on RTTI. They can
perfectly be implented in
On Thu, 23 Dec 2010, alexv...@mail.ru wrote:
23.12.2010 17:52, Marco van de Voort пишет:
In our previous episode, alexv...@mail.ru said:
Therefore, until the time someone finds a cross-platform way to
implement packages, I see no reason not to start on RTTI. They can
perfectly be implented i
23.12.2010 17:52, Marco van de Voort пишет:
In our previous episode, alexv...@mail.ru said:
Therefore, until the time someone finds a cross-platform way to
implement packages, I see no reason not to start on RTTI. They can
perfectly be implented independently
or even in parallel.
Wine has abil
In our previous episode, alexv...@mail.ru said:
> > Therefore, until the time someone finds a cross-platform way to
> > implement packages, I see no reason not to start on RTTI. They can
> > perfectly be implented independently
> > or even in parallel.
> >
> Wine has ability to load windows libra
22.12.2010 21:52, Michael Van Canneyt пишет:
Therefore, until the time someone finds a cross-platform way to
implement packages, I see no reason not to start on RTTI. They can
perfectly be implented independently
or even in parallel.
Wine has ability to load windows libraries on linux. This
On Wed, 22 Dec 2010, Dimitri Smits wrote:
Sure, but I was talking about the RTTI unit and API compatibility.
(hierarchical starting point is program, then package, then unit, then type)
more pressing would be:
- list of units in program (only once, hence the packages or monolythic
executabl
On 22.12.2010 17:46, Dimitri Smits wrote:
a TClass should be able to get its unitname as well.
FPC already supports TClass.UnitName.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listin
Sure, but I was talking about the RTTI unit and API compatibility.
(hierarchical starting point is program, then package, then unit, then type)
more pressing would be:
- list of units in program (only once, hence the packages or monolythic
executable)
- list of types/vars/methods in that unit
a
On Wed, 22 Dec 2010, Dimitri Smits wrote:
Hi,
what is so different on this mail than the one I sent a few months ago to the
fpc-devel list?
anyway, it would require some packages (bpl) language/RTE additions as well.
Would you care to explain why you think so ?
The 2 features have nothin
Hi,
what is so different on this mail than the one I sent a few months ago to the
fpc-devel list?
anyway, it would require some packages (bpl) language/RTE additions as well.
That was where I was hanging when spare time slipped away a few months back. I
started on rtti unit with help in embar
22.12.2010 22:13, Anthony Walter wrote:
Thanks for working on adding methods and visibility to record types.
Could you also look into fixing generics? That is, to allow for
generic constraints and remove the redundant generic and specialize
keywords.
I hope someone else will do this. At least
Paul,
Thanks for working on adding methods and visibility to record types. Could
you also look into fixing generics? That is, to allow for generic
constraints and remove the redundant generic and specialize keywords. For
example:
{code}
type
TList = class { ... interface code ... } end;
TIn
22.12.2010 21:22, Thierry Coq wrote:
Hello,
I've started looking into Delphi 2010 RTTI scheme. For example,
superobject uses it. Delphi 2010 declares a whole new API for RTTI.
Would it be possible to reproduce the interface of this API and
implement it using the existing RTTI system in FPC?
Y
On 22 Dec 2010, at 15:22, Thierry Coq wrote:
I've started looking into Delphi 2010 RTTI scheme. For example,
superobject uses it. Delphi 2010 declares a whole new API for RTTI.
Would it be possible to reproduce the interface of this API and
implement it using the existing RTTI system in FP
Hello,
I've started looking into Delphi 2010 RTTI scheme. For example,
superobject uses it. Delphi 2010 declares a whole new API for RTTI.
Would it be possible to reproduce the interface of this API and
implement it using the existing RTTI system in FPC? Would it be legal?
I'm investigating f
On 11/12/2010 11:53, Michael Van Canneyt wrote:
...
If you want to look into it, I think Paul can help on the compiler
end, and I'm willing to help with the extra RTL functionality.
How can I help?
I know a lot how the Delphi RTTI works, but I don't have a Delphi 2010
version (too expensive)!
I
On Sat, 11 Dec 2010, Paul Ishenin wrote:
11.12.2010 13:13, Thierry Coq wrote:
Delphi 2010 has changed the RTTI mechanism, and it is said to be much more
usable than the previous one.
(see here for example: http://www.malcolmgroves.com/blog/?p=476)
I would said extended what they had before.
11.12.2010 13:13, Thierry Coq wrote:
Delphi 2010 has changed the RTTI mechanism, and it is said to be much
more usable than the previous one.
(see here for example: http://www.malcolmgroves.com/blog/?p=476)
I would said extended what they had before.
Currently, the FPC doesn't implement this ne
Hello,
Delphi 2010 has changed the RTTI mechanism, and it is said to be much
more usable than the previous one.
(see here for example: http://www.malcolmgroves.com/blog/?p=476)
Some interesting tools are using this new approach, like DelphiOnRails:
http://code.google.com/p/delphionrails/
Curr
53 matches
Mail list logo
