I've begun working. Haven't much time so it may be not a very short story.
But I will try to do my best in such conditions.
--
Best regards
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-
On Mon, 12 Mar 2007 19:42:36 +0300, Micha Nelissen <[EMAIL PROTECTED]>
wrote:
Evgeniy Ivanov wrote:
library released under the LGPL, e.g., to extend the functionality of
that
This is why we have the exception.
Sorry, I don't understand what you mean.
For example, look at the RTL licens
Evgeniy Ivanov wrote:
library released under the LGPL, e.g., to extend the functionality of
that
This is why we have the exception.
Sorry, I don't understand what you mean.
For example, look at the RTL license:
http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/rtl/COPYING.FPC?rev=1&view=
On Mon, 12 Mar 2007 11:04:00 +0300, Micha Nelissen <[EMAIL PROTECTED]>
wrote:
Evgeniy Ivanov wrote:
released under the LGPL. However the relevant LGPL provisions do not
address all possible ways in which code released under the MPL and code
released under the LGPL could be combined to form
Evgeniy Ivanov wrote:
released under the LGPL. However the relevant LGPL provisions do not
address all possible ways in which code released under the MPL and code
released under the LGPL could be combined to form a larger work. In
particular, when linking Mozilla source files directly into a li
On Mon, 12 Mar 2007 00:11:06 +0300, Marco van de Voort <[EMAIL PROTECTED]>
wrote:
> Are the licensing issues sorted out for it? If not, there may be a
> problem since standard MPL is incompatible with GPL (so people can't
> release GPL programs using those bindings). I don't know about the
L
> > Are the licensing issues sorted out for it? If not, there may be a
> > problem since standard MPL is incompatible with GPL (so people can't
> > release GPL programs using those bindings). I don't know about the LGPL
> > (and how our static linking exception affects this).
> >
>
> As far
On Sat, 10 Mar 2007 23:12:32 +0300, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
Are the licensing issues sorted out for it? If not, there may be a
problem since standard MPL is incompatible with GPL (so people can't
release GPL programs using those bindings). I don't know about the LGPL
(an
On 10 Mar 2007, at 11:40, Aleš Katona wrote:
Just so you know, I just added modified SDL units from JEDI-SDL into
packages/extra but only to trunk (2.3.1). I think it's best you use
those and not copy your own, but we might need to merge into 2.2 later
then (there's a freeze in effect now I thi
On Sat, 10 Mar 2007 13:40:31 +0300, Aleš Katona <[EMAIL PROTECTED]> wrote:
Just so you know, I just added modified SDL units from JEDI-SDL into
packages/extra but only to trunk (2.3.1). I think it's best you use
those and not copy your own, but we might need to merge into 2.2 later
then (there'
>
> OK, the conclusion is to implement sdlgraph in pascal on top of JEDI-SDL.
> So, I will work with it. I will finish my study activities (I was ill 2
> weeks so this week (after Sunday) I will clear my debts) and then will
> implement it.
> Daniël was talking about 2.2 FPC release, what
On Sat, 10 Mar 2007 00:09:32 +0300, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
Daniel was talking about staticallu linking the interface, not the
libraries themselves. Since we do not distribute the libraries, what
license they are distributed under is irrelevant. The interface can be
used
On 9 mrt 2007, at 20:33, Evgeniy Ivanov wrote:
Sorry, but you are wrong. JEDI-SDL is Mozilla Public License 1.1
(MPL 1.1). I don't know all refinements of licences, but JEDI-SDL
is based on SDL libraries and they are LGPL version 2, so if we
want to use JEDI-SDL headers they will bring us
On Fri, 09 Mar 2007 21:07:55 +0300, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
This might make
sense if we don't have somebody who'd maintain the full headers, whereas
maintaining just a highly limited set needed for sdlgraph purposes might
be still acceptable (possibly just copied from the e
Op Fri, 9 Mar 2007, schreef Tomas Hajny:
> Evgeniy Ivanov wrote:
> > On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe
> > <[EMAIL PROTECTED]> wrote:
> > On Fri, 09 Mar 2007 18:39:10 +0300, Dani??l Mantione
> > <[EMAIL PROTECTED]> wrote:
> .
> .
> >> Many people @ Pascal Game Development. Domiqu
Evgeniy Ivanov wrote:
> On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe
> <[EMAIL PROTECTED]> wrote:
> On Fri, 09 Mar 2007 18:39:10 +0300, DaniĂŤl Mantione
> <[EMAIL PROTECTED]> wrote:
.
.
>> Many people @ Pascal Game Development. Domique Louis (Savage) is also
>> still maintaining it. Writing al
On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
See e.g. the graph.pp and ggigraph.pp files at
http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/unix/
The include files are in
http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/inc/
Thanks, I wa
> > The graph unit is pretty generic in this respect. You indeed only need
> > to implement putpixel, getpixel, graphics mode detection, setting a
> > graphic mode, setting and getting colour palette entries for indexed
> > modes, and closing down the graphic system again. But it's perfectly
On 9 mrt 2007, at 16:26, Evgeniy Ivanov wrote:
On Fri, 09 Mar 2007 18:08:35 +0300, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
The graph unit is pretty generic in this respect. You indeed only
need to implement putpixel, getpixel, graphics mode detection,
setting a graphic mode, setting and g
Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov:
> As far as I've understood Daniel is working only on driver system, isn't it?
It already exists.
> He doesn't touch such things like line and circle for example (It should be
> based on PutPixel as I thing) but he is implementing only the things tha
> > That's true, and it's the case for most libraries out there. Converting
> > all libraries from C to Pascal rather than the headers would be a huge
> > and never-ending duplication of effort. There's nothing wrong with using
> > Pascal interfaces for libraries which are written in another
On Fri, 09 Mar 2007 18:08:35 +0300, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
The graph unit is pretty generic in this respect. You indeed only need
to implement putpixel, getpixel, graphics mode detection, setting a
graphic mode, setting and getting colour palette entries for indexed
mod
On 9 mrt 2007, at 15:59, Evgeniy Ivanov wrote:
I personally wouldn't necessarily wait for PTCPas based
implementation -
if Daniel wants to use the driver system, it should be enough to
agree on
the driver interface, anything else can be done completely
independently.
As far as I've under
On Fri, 09 Mar 2007 15:46:34 +0300, Tomas Hajny <[EMAIL PROTECTED]>
wrote:
Hi Tomas,
Hi Evgeniy,
I'd say that having Graph built on top of SDL would be quite useful. I
agree with Daniel that implementation in Pascal would be much better
choice - among others, one could use it on various p
Daniël Mantione wrote:
> Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov:
Hi Evgeniy,
>> I tried to use freepascal' graph module based on svgalib but from my
>> point of
>> view it's not comfortable: I need root prevelege or to remember what to
>> do
>> with *ids (uid and so on). Also I have a proble
Daniël Mantione schrieb:
> It is in the planning to rewrite Graph on top of PTCPas. I hope to do this
> before 2.2 it released. In the meantime ggigraph might suit your needs.
Then you've to hurry ;)
___
fpc-devel maillist - fpc-devel@lists.freepascal
Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov:
> Hello!
>
> I tried to use freepascal' graph module based on svgalib but from my point of
> view it's not comfortable: I need root prevelege or to remember what to do
> with *ids (uid and so on). Also I have a problems with konsole after starting
> p
Hello!
I tried to use freepascal' graph module based on svgalib but from my point
of view it's not comfortable: I need root prevelege or to remember what to
do with *ids (uid and so on). Also I have a problems with konsole after
starting programm with graph module: there is an error with in
28 matches
Mail list logo
