Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.folklore.computer > #47866 > unrolled thread

Alte Programmiersprachen in neuen Compilern

Back to article view | Back to de.alt.folklore.computer

Contents

  Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-16 16:54 +0000
    Re: Alte Programmiersprachen in neuen Compilern "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-16 19:58 +0100
    Re: Alte Programmiersprachen in neuen Compilern "F. W." <me@home.invalid> - 2025-03-17 09:18 +0100
      Re: Alte Programmiersprachen in neuen Compilern "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-18 22:36 +0100
        Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-19 05:22 +0100
        Re: Alte Programmiersprachen in neuen Compilern Andreas Bockelmann <xotzil@gmx.de> - 2025-03-19 11:55 +0100
          Re: Alte Programmiersprachen in neuen Compilern Ignatios Souvatzis <u502sou@bnhb484.de> - 2025-03-19 11:12 +0000
            Re: Alte Programmiersprachen in neuen Compilern Christian Weisgerber <naddy@mips.inka.de> - 2025-03-19 21:43 +0000
            Re: Alte Programmiersprachen in neuen Compilern "F. W." <me@home.invalid> - 2025-03-20 16:37 +0100
              Re: Alte Programmiersprachen in neuen Compilern Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-20 17:12 +0100
                Re: Alte Programmiersprachen in neuen Compilern "F. W." <me@home.invalid> - 2025-03-20 17:15 +0100
                  Re: Alte Programmiersprachen in neuen Compilern Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-20 22:00 +0100
                    Re: Alte Programmiersprachen in neuen Compilern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-22 11:09 +0000
                      Re: Alte Programmiersprachen in neuen Compilern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-03-22 14:31 +0100
                        Re: Alte Programmiersprachen in neuen Compilern "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-22 14:55 +0100
                          Re: Alte Programmiersprachen in neuen Compilern Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-22 17:35 +0100
                            Re: Alte Programmiersprachen in neuen Compilern Stefan Reuther <stefan.news@arcor.de> - 2025-03-23 12:18 +0100
                          Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-22 18:57 +0100
                          Re: Alte Programmiersprachen in neuen Compilern "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-22 19:30 +0100
                          Re: Alte Programmiersprachen in neuen Compilern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-03-22 22:29 +0100
                            Re: Alte Programmiersprachen in neuen Compilern "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-22 23:49 +0100
                              Re: Alte Programmiersprachen in neuen Compilern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-23 16:47 +0000
                          Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-22 21:48 +0000
                        Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-22 14:59 +0100
                          Re: Alte Programmiersprachen in neuen Compilern Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-22 17:36 +0100
                            Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-23 12:56 +0100
                              Re: Alte Programmiersprachen in neuen Compilern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-03-23 14:38 +0100
                              Re: Alte Programmiersprachen in neuen Compilern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-23 16:53 +0000
                          Re: Alte Programmiersprachen in neuen Compilern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-03-22 22:33 +0100
          Re: Alte Programmiersprachen in neuen Compilern "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-03-19 16:46 +0000
          Re: Alte Programmiersprachen in neuen Compilern "F. W." <me@home.invalid> - 2025-03-20 16:36 +0100
            Re: Alte Programmiersprachen in neuen Compilern Guido Grohmann <guido.grohmann@gmx.de> - 2025-03-20 18:41 +0100
      Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-20 09:34 +0000
      Re: Alte Programmiersprachen in neuen Compilern wolfgang s <see@sig.nature> - 2025-03-20 14:37 +0000
        Re: Alte Programmiersprachen in neuen Compilern "F. W." <me@home.invalid> - 2025-03-20 16:42 +0100
          Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-20 17:08 +0100
            Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-20 16:58 +0000
            Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-20 18:01 +0100
              Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-20 17:47 +0000
              Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-20 19:57 +0100
                Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-21 06:38 +0100
                  Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-22 13:58 +0100
                    Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-22 17:20 +0000
              Re: Alte Programmiersprachen in neuen Compilern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-22 11:13 +0000
                Re: Alte Programmiersprachen in neuen Compilern "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-22 14:46 +0100
                  Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-22 15:05 +0100
            Re: Alte Programmiersprachen in neuen Compilern Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-20 22:01 +0100
              Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-21 06:44 +0100
                Re: Alte Programmiersprachen in neuen Compilern mlelstv@serpens.de (Michael van Elst) - 2025-03-21 07:50 +0000
                  Re: Alte Programmiersprachen in neuen Compilern "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-03-21 09:12 +0000
                    Re: Alte Programmiersprachen in neuen Compilern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-03-22 08:04 +0100
                Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-21 09:45 +0000
                  Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-21 12:12 +0100
                  Re: Alte Programmiersprachen in neuen Compilern Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2025-03-21 19:22 +0100
          Re: Alte Programmiersprachen in neuen Compilern Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-20 17:13 +0100
            Re: Alte Programmiersprachen in neuen Compilern "F. W." <me@home.invalid> - 2025-03-20 17:16 +0100
            Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-20 16:29 +0000
          Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-20 16:28 +0000
          Re: Alte Programmiersprachen in neuen Compilern Ignatios Souvatzis <u502sou@bnhb484.de> - 2025-03-21 10:21 +0000
            Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-21 10:41 +0000
              Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-21 12:21 +0100
                Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-21 12:40 +0000
                  Re: Alte Programmiersprachen in neuen Compilern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-21 16:37 +0100
                    Re: Alte Programmiersprachen in neuen Compilern Thomas Koenig <tkoenig@netcologne.de> - 2025-03-21 17:51 +0000
        Re: Alte Programmiersprachen in neuen Compilern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-03-21 06:42 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#47866 — Alte Programmiersprachen in neuen Compilern

Vielleicht mal was anderes, möglicherweise weniger kontroverses.

Mit einem der gegenwärtigen Entwicklerversion von gcc
gcc (GCC) 15.0.1 20250316 (experimental) kann man sich
Cobol konfigurieren:

$ cat doors.cob
       IDENTIFICATION DIVISION.
       PROGRAM-ID. 100Doors.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 Current-n      PIC 9(3).
       01 StepSize       PIC 9(3).
       01 DoorTable.
          02 Doors       PIC 9(1)   OCCURS 100 TIMES.
             88 ClosedDoor          VALUE ZERO.
       01 Idx            PIC 9(3).

       PROCEDURE DIVISION.
       Begin.
           INITIALIZE DoorTable
           PERFORM VARYING StepSize FROM 1 BY 1 UNTIL StepSize > 100
             PERFORM VARYING Current-n FROM StepSize BY StepSize
                     UNTIL Current-n > 100
               SUBTRACT Doors (Current-n) FROM 1 GIVING Doors (Current-n)
             END-PERFORM
           END-PERFORM

           PERFORM VARYING Idx FROM 1 BY 1
                   UNTIL Idx > 100
             IF NOT ClosedDoor (Idx)
               DISPLAY Idx " is open."
             END-IF
           END-PERFORM

           STOP RUN
           .
$ gcobol doors.cob
$ ./a.out
001 is open.
004 is open.
009 is open.
016 is open.
025 is open.
036 is open.
049 is open.
064 is open.
081 is open.

Und Algol 68 ist auch schon in der Diskussion.

[toc] | [next] | [standalone]

#47876

On 2025-03-16 16:54, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Vielleicht mal was anderes, möglicherweise weniger kontroverses.
>
> Mit einem der gegenwärtigen Entwicklerversion von gcc
> gcc (GCC) 15.0.1 20250316 (experimental) kann man sich
> Cobol konfigurieren:

Wenn ich mich recht erinnere, hat der sogar voriges Jahr die komplette
offizielle Test-Suite bestanden.

Wenn ich jetzt die Floppy mit meinen alten COBOL-Sourcen noch lesen
könnte ...

        hp

[toc] | [prev] | [next] | [standalone]

#47900

Am 16.03.2025 um 17:54 schrieb Thomas Koenig:

> Mit einem der gegenwärtigen Entwicklerversion von gcc gcc (GCC) 
> 15.0.1 20250316 (experimental) kann man sich Cobol konfigurieren:

Verstehe ich nicht so ganz. gcobol ist in C/C++ programmiert? Wie ist
die Verbindung von COBOL und C/C++? Übersetzt gcobol den Quellcode in C/
C++? Das hatte FreePascal in seinen frühen Versionen mal gemacht.

FW

[toc] | [prev] | [next] | [standalone]

#47926

On 2025-03-17 08:18, F. W. <me@home.invalid> wrote:
> Am 16.03.2025 um 17:54 schrieb Thomas Koenig:
>
>> Mit einem der gegenwärtigen Entwicklerversion von gcc gcc (GCC) 
>> 15.0.1 20250316 (experimental) kann man sich Cobol konfigurieren:
>
> Verstehe ich nicht so ganz. gcobol ist in C/C++ programmiert?

Da die GNU Compiler Suite generell in C (und C++?) geschrieben ist, ist
anzunehmen, dass das auch für den Cobol-Compiler gilt.

> Wie ist die Verbindung von COBOL und C/C++?

Gar nicht. Man kann in jeder Programmiersprache einen Compiler für jede
Programmiersprache schreiben (aber um einen Compiler in Cobol zu
schreiben, braucht man schon eine gehörige Portion Masochismus).

Man braucht natürlich eine Support-Library. Die wird vermutlich in C
geschrieben sein, weil C die Default-Sprache auf Unix-Systemen für alles
systemnahe ist, aber das muss nicht sein.

> Übersetzt gcobol den Quellcode in C/ C++?

Unwahrscheinlich. Wozu sollte man das tun, wenn man einen Compiler hat,
der Assembler erzeugen kann?

> Das hatte FreePascal in seinen frühen Versionen mal gemacht.

Die wollten sich offensichtlich den schwierigeren Teil des Compilers
sparen.

        hp

[toc] | [prev] | [next] | [standalone]

#47930

Am 18.03.25 um 22:36 schrieb Peter J. Holzer:

>> Übersetzt gcobol den Quellcode in C/ C++?

> Unwahrscheinlich. Wozu sollte man das tun, wenn man einen Compiler hat,
> der Assembler erzeugen kann?

Compiler sind so aufgebaut, dass sie ihre Quellsprache
in eine passende Zwischensprache übersetzen.
Die Zwischensprache kann unabhängig vom Maschinencode
des jeweiligen computers sein.

Für jede verwendete Sprache wird ein passendes Anfangsteil programmiert,
für jeden verwendeten Maschinentyp ein passendes Endteil.

>> Das hatte FreePascal in seinen frühen Versionen mal gemacht.

> Die wollten sich offensichtlich den schwierigeren Teil des Compilers
> sparen.

Der bytecode eigent sich schlecht zum optimieren,
weil für Optimierung einiges umsortiert wird.
Aus bytecode lässt sich allerdings mit Verkettungen
eine Art Baum herstellen.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#47932

Peter J. Holzer schrieb:

> Gar nicht. Man kann in jeder Programmiersprache einen Compiler für jede
> Programmiersprache schreiben (aber um einen Compiler in Cobol zu
> schreiben, braucht man schon eine gehörige Portion Masochismus).

Gibt es irgendwo eine Sourcecode für einen Fotran-Compiler in Brainfuck?

An"heutemaltrollig"dreas

[toc] | [prev] | [next] | [standalone]

#47937

Andreas Bockelmann wrote: 
> Peter J. Holzer schrieb:
>
>> Gar nicht. Man kann in jeder Programmiersprache einen Compiler für jede
>> Programmiersprache schreiben (aber um einen Compiler in Cobol zu
>> schreiben, braucht man schon eine gehörige Portion Masochismus).
>
> Gibt es irgendwo eine Sourcecode für einen Fotran-Compiler in Brainfuck?
>
> An"heutemaltrollig"dreas

Ich erhöhe auf Concurrent Intercal.

	-is

[toc] | [prev] | [next] | [standalone]

#47947

On 2025-03-19, Stefan Ram <ram@zedat.fu-berlin.de> wrote:

>   Und Donald Knuth hat TeX (ein Programm, des heute immer noch
>   verbreitet ist, in absoluten Zahlen vielleicht mehr denn je) 
>   in Pascal geschrieben. In Pascal!!

In WEB.

Ich habe mir nicht angeschaut, wie TeXLive heutzutage gebaut wird,
bin mir aber sicher, dass dazu kein Pascal-Compiler vorhanden sein
muss.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#47955

Am 19.03.2025 um 18:33 schrieb Stefan Ram:
> ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>> Es gibt |dc.sed - an arbitrary precision RPN calculator - eine
>> Implementation von dc in sed.
> 
> Und Donald Knuth hat TeX (ein Programm, des heute immer noch 
> verbreitet ist, in absoluten Zahlen vielleicht mehr denn je) in
> Pascal geschrieben. In Pascal!!
> 
> 

Pascal ist doch eine geile Sprache und immer noch (seit 1981) mein
Standard-Werkzeug.

Okay, okay.

FW

[toc] | [prev] | [next] | [standalone]

#47958

"F. W." <me@home.invalid> wrote:
>Pascal ist doch eine geile Sprache und immer noch (seit 1981) mein
>Standard-Werkzeug.

Weil Du sowieso alles selbst schreibst und sowieso niemalsnie eine
fremde Library verwenden würdest?

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#47960

Am 20.03.2025 um 17:12 schrieb Marc Haber:

> "F. W." <me@home.invalid> wrote:
>> Pascal ist doch eine geile Sprache und immer noch (seit 1981)
>> mein Standard-Werkzeug.
> 
> Weil Du sowieso alles selbst schreibst und sowieso niemalsnie eine 
> fremde Library verwenden würdest?
> 
> Grüße Marc

Nee, weil Du mich nachts um drei wecken kannst und ich sofort im
Halbschlaf Pascal schreiben kann.

FreePascal und Lazarus haben doch Tonnen von Librarys...

FW

[toc] | [prev] | [next] | [standalone]

#47980

"F. W." <me@home.invalid> wrote:
>FreePascal und Lazarus haben doch Tonnen von Librarys...

Vermutlich ein Tausendstel von Python.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#48032

On Thu, 20 Mar 2025 22:00:01 Marc Haber wrote:
> "F. W." <me@home.invalid> wrote:
>>FreePascal und Lazarus haben doch Tonnen von Librarys...

> Vermutlich ein Tausendstel von Python.

Ab einer gewissen Größe von Libraries finde ich das mehr hinderlich
als nützlich, weil ich nicht mehr ansatzweise den Überblick behalten
kann. Python kenne ich nicht, aber wenn ich mir ansehe, dass man in
nodejs z.B. ein eigenes Modul is-true laden und verwenden kann, dann
halte ich das eher für einen Bug als für ein Feature.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Bunt und gesund!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#48049

On 3/22/25 12:09, Stefan Froehlich wrote:
> On Thu, 20 Mar 2025 22:00:01 Marc Haber wrote:
>> "F. W." <me@home.invalid> wrote:
>>> FreePascal und Lazarus haben doch Tonnen von Librarys...
> 
>> Vermutlich ein Tausendstel von Python.
> 
> Ab einer gewissen Größe von Libraries finde ich das mehr hinderlich
> als nützlich, weil ich nicht mehr ansatzweise den Überblick behalten
> kann.

By python muss man schon für Grundfunktionen Libraries laden. 'os' 
und/oder 'sys' hast eigentlich immer in einem Script importiert.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#48054

On 2025-03-22 13:31, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 3/22/25 12:09, Stefan Froehlich wrote:
>> On Thu, 20 Mar 2025 22:00:01 Marc Haber wrote:
>>> "F. W." <me@home.invalid> wrote:
>>>> FreePascal und Lazarus haben doch Tonnen von Librarys...
>> 
>>> Vermutlich ein Tausendstel von Python.
>> 
>> Ab einer gewissen Größe von Libraries finde ich das mehr hinderlich
>> als nützlich, weil ich nicht mehr ansatzweise den Überblick behalten
>> kann.
>
> By python muss man schon für Grundfunktionen Libraries laden. 'os' 
> und/oder 'sys' hast eigentlich immer in einem Script importiert.

Ja, aber die sind Teil des Grundpakets und gemeinsam mit der Sprache
dokumentiert. Das unterscheidet sich nicht wesentlich von den
C-Standard-Funktionen (es gibt nur mehr davon).

Stefan geht es vermutlich eher um den Wildwuchs auf den Repositorys wie
PyPI, npm, CPAN, etc. Da kann halt jeder Pakete hochladen, was dazu
führt, dass manche Pakete absolut trivial sind, und es für viele
Anwendungszwecke zig Pakete gibt und man nicht weiß, welches man nehmen
soll.

        hjp

[toc] | [prev] | [next] | [standalone]

#48070

"Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>Stefan geht es vermutlich eher um den Wildwuchs auf den Repositorys wie
>PyPI, npm, CPAN, etc. Da kann halt jeder Pakete hochladen, was dazu
>führt, dass manche Pakete absolut trivial sind, und es für viele
>Anwendungszwecke zig Pakete gibt und man nicht weiß, welches man nehmen
>soll.

Ich nehm einfach die die für Debian paketiert sind und schwupps kann
ich simpelst mit der seriellen Schnittstelle sprechen, JSON und YAML
lesen und scheiben, Excels erzeugen und wieder zurücklesen, Webseiten
scrapen, Modbus oder MQTT sprechen etc bla. Alleine argparse spart
jedes Mal einen halben Tag.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#48091

Am 22.03.2025 um 17:35 schrieb Marc Haber:
> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>> Stefan geht es vermutlich eher um den Wildwuchs auf den Repositorys wie
>> PyPI, npm, CPAN, etc. Da kann halt jeder Pakete hochladen, was dazu
>> führt, dass manche Pakete absolut trivial sind, und es für viele
>> Anwendungszwecke zig Pakete gibt und man nicht weiß, welches man nehmen
>> soll.
> 
> Ich nehm einfach die die für Debian paketiert sind und schwupps kann
> ich simpelst mit der seriellen Schnittstelle sprechen, JSON und YAML
> lesen und scheiben, Excels erzeugen und wieder zurücklesen, Webseiten
> scrapen, Modbus oder MQTT sprechen etc bla. Alleine argparse spart
> jedes Mal einen halben Tag.

Wenn's funktioniert, ist das super. Wenn nicht: nur bei wenigen
Programmiersprachen hab ich so geflucht wie bei Python. Heißt das nun
python-crypto? python-cryptodome? python3-crypto? Oder installier ich
mir das Paket lieber in manuell in ein virtualenv? Wie navigiere ich um
die Tretminen von deprecated Funktionen herum? Wie stelle ich sicher,
dass nachdem ich alle deprecated-Funktionen ersetzt habe, so dass es bei
mir unter Debian 12 läuft, es immer noch unter Ubuntu 18.4 läuft, was
aufgrund der Forderung nach reproduzierbaren Builds auch für die erste
Projektversion noch in der CI existiert?


  Stefan

[toc] | [prev] | [next] | [standalone]

#48075

Am 22.03.25 um 14:55 schrieb Peter J. Holzer:
> On 2025-03-22 13:31, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 3/22/25 12:09, Stefan Froehlich wrote:
>>> On Thu, 20 Mar 2025 22:00:01 Marc Haber wrote:
>>>> "F. W." <me@home.invalid> wrote:
>>>>> FreePascal und Lazarus haben doch Tonnen von Librarys...
>>>
>>>> Vermutlich ein Tausendstel von Python.
>>>
>>> Ab einer gewissen Größe von Libraries finde ich das mehr hinderlich
>>> als nützlich, weil ich nicht mehr ansatzweise den Überblick behalten
>>> kann.
>>
>> By python muss man schon für Grundfunktionen Libraries laden. 'os'
>> und/oder 'sys' hast eigentlich immer in einem Script importiert.
> 
> Ja, aber die sind Teil des Grundpakets und gemeinsam mit der Sprache
> dokumentiert. Das unterscheidet sich nicht wesentlich von den
> C-Standard-Funktionen (es gibt nur mehr davon).
> 
> Stefan geht es vermutlich eher um den Wildwuchs auf den Repositorys wie
> PyPI, npm, CPAN, etc. Da kann halt jeder Pakete hochladen, was dazu
> führt, dass manche Pakete absolut trivial sind, und es für viele
> Anwendungszwecke zig Pakete gibt und man nicht weiß, welches man nehmen
> soll.

Die, bei der für die nächste Version "to be deprecated", steht. ;-) ??

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#48079

On 2025-03-22 17:41, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>   Und wenn ich dieses Modul [1] unter CPython ausführe, erscheint
>   unter anderem:
>
> os
> sys
>
>   . Was zeigt, daß "os" und "sys" bereits geladen sind. Durch die
>   import-Anweisungen werden in diesem Fall also wohl nur noch die
>   Namen global bereitgestellt, ohne daß dabei noch wirklich etwas
>   geladen wird.

Das scheint korrekt zu sein, wenn ich mir den Output von strace ansehe,
aber aus Deinem Test geht das nicht hervor:

>
>   [1]
>
> import sys

Hier lädtst Du explizit »sys«, also ist es kein Wunder, dass es danach in
der Liste der geladenen Module aufscheint.

>
> loaded_modules = sys.modules
>
> print( "Loaded Modules:" )
> for module_name in sorted( loaded_modules.keys() ):
>     print( module_name )

Das lässt die Frage offen, wo »os« herkommt. Aber da »sys« und »os« eng
verwandt sind, wäre es nicht überraschend, wenn »sys« seinerseits »os«
lädt.

        hjp

[toc] | [prev] | [next] | [standalone]

#48083

On 3/22/25 14:55, Peter J. Holzer wrote:
> On 2025-03-22 13:31, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 3/22/25 12:09, Stefan Froehlich wrote:
>>> On Thu, 20 Mar 2025 22:00:01 Marc Haber wrote:
>>>> "F. W." <me@home.invalid> wrote:
>>>>> FreePascal und Lazarus haben doch Tonnen von Librarys...
>>>
>>>> Vermutlich ein Tausendstel von Python.
>>>
>>> Ab einer gewissen Größe von Libraries finde ich das mehr hinderlich
>>> als nützlich, weil ich nicht mehr ansatzweise den Überblick behalten
>>> kann.
>>
>> By python muss man schon für Grundfunktionen Libraries laden. 'os'
>> und/oder 'sys' hast eigentlich immer in einem Script importiert.
> 
> Ja, aber die sind Teil des Grundpakets und gemeinsam mit der Sprache
> dokumentiert. 

Die Funktionen davon hätte man einfach direkt integrieren können.


  Gerrit

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | de.alt.folklore.computer

csiph-web