On Mon, 10 Jan 2011, Jeppe Johansen wrote:
Den 10-01-2011 02:36, leledumbo skrev:
Compile the attached project (really difficult to trim it down) using two
different options. First, using -glh, then using -g. The first one raises
nothing (program runs fine), while the second raises
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
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
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 platforms
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
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
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
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
2011/1/10 alexv...@mail.ru 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 -
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.
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru 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
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 alexv...@mail.ru:
But I want packages to be binary portable between OS (on target
processor
architecture)
I don't
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.rualexv...@mail.ru:
But I want packages to be binary portable between OS (on
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 alexv...@mail.ru:
But I want packages to be binary portable between OS (on target processor
architecture)
I don't
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 alexv...@mail.ru:
But I want packages to be binary portable
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 alexv...@mail.ru:
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
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
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?
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, 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
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 the
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, 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 meansperformance
On Mon, January 10, 2011 13:46, alexv...@mail.ru wrote:
10.01.2011 15:31, Marco van de Voort пиŃ#65533;ĐľŃ#65533;:
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
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
In the program I could narrow the problem down to line 117 in parser.pp.
If that one was removed it ran fine
Of course, because removing that line causes nothing to be parsed (it's the
first top level production that deals with something from the input) ;)
--
View this message in context:
Sorry, I was referring to the new code. Yes, that line adds class instance to
TFPGObjectList.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Segmentation-fault-gone-if-compiled-with-glh-tp3334353p3334791.html
Sent from the Free Pascal - General mailing list
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 assume you
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
On 10 Jan 2011, at 06:54, Jeppe Johansen wrote:
Doesn't the problem lie in that TFPGObjectList uses @ on the
incoming parameters?
function TFPGObjectList.Add(const Item: T): Integer;
begin
Result := inherited Add(@Item);
end;
Unless there's some magic going on, won't it then point to the
Den 10-01-2011 16:10, Jonas Maebe skrev:
On 10 Jan 2011, at 06:54, Jeppe Johansen wrote:
Doesn't the problem lie in that TFPGObjectList uses @ on the incoming
parameters?
function TFPGObjectList.Add(const Item: T): Integer;
begin
Result := inherited Add(@Item);
end;
Unless there's some
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
I've tried changing const to constref and recompile fgl unit, no effect :(
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Segmentation-fault-gone-if-compiled-with-glh-tp3334353p3335091.html
Sent from the Free Pascal - General mailing list archive at
W dniu 02.01.2011 23:21, Michael Van Canneyt pisze:
On Sun, 2 Jan 2011, dib...@wp.pl wrote:
Hi,
Month ago I posted a bug (http://bugs.freepascal.org/view.php?id=18117)
Admin give me solution and feedback, but this solution doesn't work
well and i think he don't read my last comment.
So,
On Mon, 10 Jan 2011, dib...@wp.pl wrote:
Sorry for refreshing, but the problem is still present :( . It works perfect
on my mashine (ubuntu 10.10 64 bit) but doesn't work on my friends computer.
For example, one of my friend have this same laptop as me and exactly this
same version of
- michael vancanneyt michael.vancann...@wisa.be 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
W dniu 10.01.2011 20:41, Michael Van Canneyt pisze:
On Mon, 10 Jan 2011, dib...@wp.pl wrote:
Sorry for refreshing, but the problem is still present :( . It works
perfect on my mashine (ubuntu 10.10 64 bit) but doesn't work on my
friends computer. For example, one of my friend have this same
Update: this is something really really weird, if AStream.Free (last
statement) in linguc.lpr is removed, then the error's totally GONE!
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Segmentation-fault-gone-if-compiled-with-glh-tp3334353p3335939.html
Sent
39 matches
Mail list logo
