the libc unit (again)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

the libc unit (again)

ik-6
Hello,

I find more and more units and components (for Lazarus) that are using
the libc unit. I find it really problematic, because it doesn't exists
for all platforms and architectures, so why not markring the unit as
obsolete for the next FPC release so other developers will have to
work with more flexible units ?

Thanks,

Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

Peter Vreman
> Hello,
>
> I find more and more units and components (for Lazarus) that are using
> the libc unit. I find it really problematic, because it doesn't exists
> for all platforms and architectures, so why not markring the unit as
> obsolete for the next FPC release so other developers will have to
> work with more flexible units ?

Other users will start to submit bug reports that there is no Libc unit.
We clearly state that libc is only for compatibility and not for portability. The same is with the
old TP7 units.

Peter

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

Marco van de Voort
> > Hello,
> >
> > I find more and more units and components (for Lazarus) that are using
> > the libc unit. I find it really problematic, because it doesn't exists
> > for all platforms and architectures, so why not markring the unit as
> > obsolete for the next FPC release so other developers will have to
> > work with more flexible units ?
>
> Other users will start to submit bug reports that there is no Libc unit.
> We clearly state that libc is only for compatibility and not for portability. The same is with the
> old TP7 units.

We could mark all functions in libc with deprecated. The questions keep
coming back. Harsh, but IMHO the only sane way.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

Giuliano Colla
Marco van de Voort ha scritto:

>>> Hello,
>>>
>>> I find more and more units and components (for Lazarus) that are using
>>> the libc unit. I find it really problematic, because it doesn't exists
>>> for all platforms and architectures, so why not markring the unit as
>>> obsolete for the next FPC release so other developers will have to
>>> work with more flexible units ?
>> Other users will start to submit bug reports that there is no Libc unit.
>> We clearly state that libc is only for compatibility and not for portability. The same is with the
>> old TP7 units.
>
> We could mark all functions in libc with deprecated. The questions keep
> coming back. Harsh, but IMHO the only sane way.

What would be of great help is concise guide on how migrate of the libc
functionalities (a wiki page?). I'm porting to fpc Kylix projects which
used libc. Reading this mailing list I realized that libc wasn't the way
to go, but I had a hell of a time to discover the equivalents, scattered
in SysUtils, Unix, UnixUtils,BaseUnix, sometimes with different names,
different parameters, etc.

Sort of:
libc.getenv -> SysUtils.GetEnvironmentVariable

Someone with a good knowledge of fpc should be able to do it in a short
time.

Giuliano

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

ik-6
On Sat, Feb 23, 2008 at 2:26 PM, Giuliano Colla
<[hidden email]> wrote:

> Marco van de Voort ha scritto:
>
> >>> Hello,
>  >>>
>  >>> I find more and more units and components (for Lazarus) that are using
>  >>> the libc unit. I find it really problematic, because it doesn't exists
>  >>> for all platforms and architectures, so why not markring the unit as
>  >>> obsolete for the next FPC release so other developers will have to
>  >>> work with more flexible units ?
>  >> Other users will start to submit bug reports that there is no Libc unit.
>  >> We clearly state that libc is only for compatibility and not for portability. The same is with the
>  >> old TP7 units.
>  >
>  > We could mark all functions in libc with deprecated. The questions keep
>  > coming back. Harsh, but IMHO the only sane way.
>
>  What would be of great help is concise guide on how migrate of the libc
>  functionalities (a wiki page?). I'm porting to fpc Kylix projects which
>  used libc. Reading this mailing list I realized that libc wasn't the way
>  to go, but I had a hell of a time to discover the equivalents, scattered
>  in SysUtils, Unix, UnixUtils,BaseUnix, sometimes with different names,
>  different parameters, etc.
>
>  Sort of:
>  libc.getenv -> SysUtils.GetEnvironmentVariable
>
>  Someone with a good knowledge of fpc should be able to do it in a short
>  time.

I usually use grep when I require to find things. I personally do not
understand why the unix units contain function names with the prefix
of Fp, but it does not matter, because the name remains, so I do
something like

grep -in functionname ./location/* -R | grep -v "something I do not
wish to be included"

And I find what/where what I wish to have is located... It's good btw
for anything you do not remember/know where/how it is located ...

>
>  Giuliano
>
>  --
>  Giuliano Colla
>
>  Whenever people agree with me, I always feel I must be wrong (O. Wilde)
>
>

Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

Giuliano Colla
ik ha scritto:

> On Sat, Feb 23, 2008 at 2:26 PM, Giuliano Colla
> <[hidden email]> wrote:
>> Marco van de Voort ha scritto:
>>
>>>>> Hello,
>>  >>>
>>  >>> I find more and more units and components (for Lazarus) that are using
>>  >>> the libc unit. I find it really problematic, because it doesn't exists
>>  >>> for all platforms and architectures, so why not markring the unit as
>>  >>> obsolete for the next FPC release so other developers will have to
>>  >>> work with more flexible units ?
>>  >> Other users will start to submit bug reports that there is no Libc unit.
>>  >> We clearly state that libc is only for compatibility and not for portability. The same is with the
>>  >> old TP7 units.
>>  >
>>  > We could mark all functions in libc with deprecated. The questions keep
>>  > coming back. Harsh, but IMHO the only sane way.
>>
>>  What would be of great help is concise guide on how migrate of the libc
>>  functionalities (a wiki page?). I'm porting to fpc Kylix projects which
>>  used libc. Reading this mailing list I realized that libc wasn't the way
>>  to go, but I had a hell of a time to discover the equivalents, scattered
>>  in SysUtils, Unix, UnixUtils,BaseUnix, sometimes with different names,
>>  different parameters, etc.
>>
>>  Sort of:
>>  libc.getenv -> SysUtils.GetEnvironmentVariable
>>
>>  Someone with a good knowledge of fpc should be able to do it in a short
>>  time.
>
> I usually use grep when I require to find things. I personally do not
> understand why the unix units contain function names with the prefix
> of Fp, but it does not matter, because the name remains, so I do
> something like
>
> grep -in functionname ./location/* -R | grep -v "something I do not
> wish to be included"
>
> And I find what/where what I wish to have is located... It's good btw
> for anything you do not remember/know where/how it is located ...
>

Tanks for the hint, but grep (or Find in Files from IDE) has the big
disadvantage that you don't find only the declaration, but also all the
references. You search "FindFirst" and you find 200 entries...
Moreover if you search e.g. execvp, you'll never find TProcess, which is
the recommended way to start an external application.
That's why some help from developers, or experienced users, would be
more than welcome.

Giuliano


--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

Mattias Gaertner
On Sat, 23 Feb 2008 15:45:22 +0100
Giuliano Colla <[hidden email]> wrote:

>[...]
> Tanks for the hint, but grep (or Find in Files from IDE) has the big
> disadvantage that you don't find only the declaration, but also all
> the references. You search "FindFirst" and you find 200 entries...

Lazarus / View / Code Browser / Levels / Show identifiers: execvp
Disable 'show packages' and 'show units'
It will show:

Procedure Execvp(ProgName:String;Args:TStrings)
function execvp(__file:Pchar;__argv:PPchar):longint

Move the mouse over the entries to see a hint about its location and/or
double click to jump to the source.


> Moreover if you search e.g. execvp, you'll never find TProcess, which
> is the recommended way to start an external application.
> That's why some help from developers, or experienced users, would be
> more than welcome.

Maybe you can start a wiki page.


Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: the libc unit (again)

Giuliano Colla
Mattias Gaertner ha scritto:

> On Sat, 23 Feb 2008 15:45:22 +0100
> Giuliano Colla <[hidden email]> wrote:
>
>  
>> [...]
>> Tanks for the hint, but grep (or Find in Files from IDE) has the big
>> disadvantage that you don't find only the declaration, but also all
>> the references. You search "FindFirst" and you find 200 entries...
>>    
>
> Lazarus / View / Code Browser / Levels / Show identifiers: execvp
> Disable 'show packages' and 'show units'
> It will show:
>
> Procedure Execvp(ProgName:String;Args:TStrings)
> function execvp(__file:Pchar;__argv:PPchar):longint
>
> Move the mouse over the entries to see a hint about its location and/or
> double click to jump to the source.
>
>
>  
Thanks a lot for the hint.
Shakespeare would have said:
"There are more things in Lazarus IDE, Horatio,
Than are dreamt of in your philosophy." :-)

>> Moreover if you search e.g. execvp, you'll never find TProcess, which
>> is the recommended way to start an external application.
>> That's why some help from developers, or experienced users, would be
>> more than welcome.
>>    
>
> Maybe you can start a wiki page.
>
>
>  
I'll do it, but I can only put there my limited knowledge. I hope that
someone else will  fill up the holes.

Thanks,

Giuliano
 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal