Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-02

the libc unit (again)

8 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

ik

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/
Peter Vreman
Show quoted text 7 lines
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

Marco van de Voort
to Peter Vreman
Show quoted text 11 lines
> 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.

Giuliano Colla
to Marco van de Voort

Marco van de Voort ha scritto:

Show quoted text 13 lines
>> 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)
ik
to Giuliano Colla
Giuliano Colla wrote 28 lines
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 ...

Show quoted text 9 lines
Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde)

Ido

http://ik.homelinux.org/
Giuliano Colla
to ik

ik ha scritto:

Show quoted text 42 lines
On Sat, Feb 23, 2008 at 2:26 PM, Giuliano Colla 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)
Mattias Gaertner
to Giuliano Colla
[...] 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

Giuliano Colla
to Mattias Gaertner

Mattias Gaertner ha scritto:

Show quoted text 22 lines
On Sat, 23 Feb 2008 15:45:22 +0100 Giuliano Colla 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." :-)

Show quoted text 10 lines
> 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