Python on guile v1.2.3.7

Python on guile v1.2.3.7

[Stefan Israelsson Tampe]

Hi,

I released a new tag of my python code that basically is a snapshot of a
work in progress.

This release includes
* pythons new match statement
* dataclasses
* Faster python regexps through caching and improved datastructures
* Numerous bug fixes found while executing the python unit tests.

Re: Python on guile v1.2.3.7

[Maxim Cournoyer]

Hi Stefan,

Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> Hi,
>
> I released a new tag of my python code that basically is a snapshot of a
> work in progress.
>
> This release includes
> * pythons new match statement
> * dataclasses
> * Faster python regexps through caching and improved datastructures
> * Numerous bug fixes found while executing the python unit tests.

This sounds promising!

Thank you for working on it.

Maxim

Re: Python on guile v1.2.3.7

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Hi Stefan,

Could it be that you have not committed the file:

language/python/module/re/flag-parser.scm

?

Best regards,
Mikael

On Sun, Apr 11, 2021 at 11:23 AM Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> Hi,
>
> I released a new tag of my python code that basically is a snapshot of a
> work in progress.
>
> This release includes
> * pythons new match statement
> * dataclasses
> * Faster python regexps through caching and improved datastructures
> * Numerous bug fixes found while executing the python unit tests.
>

[-- Attachment #2: Type: text/html, Size: 973 bytes --]

Re: Python on guile v1.2.3.7

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 12813 bytes --]

I have continued to debug python for guile 3.1 and I am now getting much
less warnings and also I can run test cases and it looks good. Tip, To run
unit tests one can do from the module directory in the dist

python language/python/module/unittest/tests/test_case.py

to see what's working and what's not working.

I am also working on getting it to behave better and especially take
advantage
of guile's new reader to introduce python source code numbering instead of
the generated scheme code's numbering. Note that in python on guile I only
modified the reader so that it reads python code and spit's out scheme
code. So I then use some macros to modify line and columns to the python
code. This way I can take advantage of the python scheme interface as the
design goal is to be able to write pythonistic constructs in scheme code
via a big chunk of macrology. Thanks to wingos work on the reader and
making sure that the syntax objects contains the source location info, much
of the dangerous clucky stuff that was added to get some kind of line
numbering is now removed for version 3.1 of guile, we still support
2.0,2.1,2.2,3.0 as well. But the older version is less tested.

I will not release a new version of python immediately as I continue to
work on making the new version more robust against the 3.1 target and will
try to continue to reduce the test cases that fail.

On Sat, Apr 17, 2021 at 2:30 PM Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> Om man har ett filnamn kan jag lägga in den i syntax-object och meta
> information finns i filen som python antar
> existerar. Så på något sätt behöver jag det infot. Man kan ha en fluid som
> när man kompilerar en fil, så får den nuvarande compilations identitet och
> annars #f. Användaren är ansvarig att kolla ifall fluiden är #f och använde
> något default värde, t.ex. när man evaluerar python kod i shell miljön.
>
> On Sat, Apr 17, 2021 at 1:40 PM Mikael Djurfeldt <mikael@djurfeldt.com>
> wrote:
>
>> ...och vad händer om man pipe:ar in kod i kompilatorn så att ingen giltig
>> fil finns? Hur går det då?
>>
>> Den lör 17 apr. 2021 13:38Mikael Djurfeldt <mikael@djurfeldt.com> skrev:
>>
>>> OK, det verkar ju vara en rimlig begäran.
>>>
>>> Kan vi hitta ett giltigt "use case" där detta är motiverat? Jag är ute
>>> efter att stärka argumentationen här.
>>>
>>> Varför behöver pythonkompilatorn veta detta?
>>>
>>> Mvh
>>> Mikael
>>>
>>> Den lör 17 apr. 2021 13:28Stefan Israelsson Tampe <
>>> stefan.itampe@gmail.com> skrev:
>>>
>>>> Hmm, jag har fixat detta på ett annat sätt nu. Du kan göra en update av
>>>> guile-persist och python-on-guile för att få något som ska fungera bättre
>>>> med bättre rad hänvisningar till python kod och få varningar.
>>>>
>>>> Nu över till nästa grej. Om vi kompilerar en fil so vill jag i min
>>>> python compilator veta vilket filnamn vi compilerar. Hur får jag tag på det
>>>> standardmässigt?
>>>>
>>>> mvh
>>>> Stefan
>>>>
>>>> On Fri, Apr 16, 2021 at 11:57 PM Mikael Djurfeldt <mikael@djurfeldt.com>
>>>> wrote:
>>>>
>>>>> Tyvärr är det nog så med mig att jag ändå inte förstår varför den här
>>>>> funktionaliteten behövs.
>>>>>
>>>>> Rimligtvis borde varningar (och fel, för den delen) vara undantagsfall
>>>>> så att den här situationen som du beskriver---att det blir en uppsjö av
>>>>> varningar---aldrig borde inträffa.
>>>>>
>>>>> Nu är det istället så att vi har en mekanism som leder till denna
>>>>> uppsjö av varningar. Och frågan, tycker jag, är om man på något vis kan
>>>>> fixa problemet redan på den nivån snarare än att dämpa varningarna---jag
>>>>> menar se till att varningarna aldrig uppstår.
>>>>>
>>>>> Dessvärre förstår jag fortfarande inte exakt hur de här varningarna
>>>>> uppstår. Visst kunde jag dyka ned i koden, men det skulle nog ta ganska
>>>>> lång tid så jag ber fortfarande om hjälp att förstå.
>>>>>
>>>>> Kan du ge ett enkelt exempel med en enkel klass där du konkret kan
>>>>> visa vilken bindning till vilket objekt som skapas och varför det ger en
>>>>> varning?
>>>>>
>>>>> Ledsen att jag är så petig...
>>>>>
>>>>> On Fri, Apr 16, 2021 at 10:54 PM Stefan Israelsson Tampe <
>>>>> stefan.itampe@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> I huvudsak, när jag skapar python classer så sparas en bindning till
>>>>>> en del object i classen i modulen
>>>>>> programatiskt som t.ex. medlemsfunktionerna. Detta används närman
>>>>>> serialiserar classer och speciellt
>>>>>> do de medlemmar, så när man kan göra x=[A.fkn1,B.fkn2], och göra en
>>>>>> deepcopy på x, serialisera och deserialisera utan att gå in på
>>>>>> funktionerne i sig som e bökit och kan ta mycket kraft. Har en ganska
>>>>>> komplett serialiserings funktion i guile persist som används av guile
>>>>>> python för copy,deepcopy och pickle. Där kan man serialisera t.ex.
>>>>>> Generatorer och iteratorer (om de inte använder o boxade variabler i
>>>>>> stacken) vilket för python kod e fallet då set! används för att boxa alla
>>>>>> variabler. (Detta kan man inte göra i python :-)) en tycker det e en farlig
>>>>>> men mycket cool feature då det vill till en massa C magi för att fixa till
>>>>>> detta (guile-persist) men som sagt var tack vare att vi skapar en länk
>>>>>> ifrån modul till medlemsvariabler så minskas behovet av C-kod ganska
>>>>>> dramatiskt.
>>>>>>
>>>>>> De är också praktiskt när man länkar in C-kod, va för mig att min
>>>>>> gamla version av guile wranade när man använder dessa inlänkade funktioner.
>>>>>> Så det vore bra där med att hindra varningar att uppstå. Änne senare
>>>>>> versioner kunde man göra (define f #f) innan f sattes ab c-koden och hindra
>>>>>> varningar. Men nu verkar denna
>>>>>> metod slutat fungera. Så i de fall när man får typ sådana problem kan
>>>>>> den föreslagna metodiken fungera bra.
>>>>>>
>>>>>> Över till var with ... ska länkas in.
>>>>>>
>>>>>> jag moddade compile-file (system base compile) för att knö till
>>>>>> detta, funkat bra med detta men det kan finnas
>>>>>> bättre ställen att sätta in den, och när jag tittade på koden så e
>>>>>> nog det bästa stället funktionen 'compile' i samma module.
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 16, 2021 at 9:22 PM Mikael Djurfeldt <
>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>
>>>>>>> Så det rör sig om top level bindings i moduler?
>>>>>>>
>>>>>>> Dum fråga: Varför är den inte bunden när den används?
>>>>>>>
>>>>>>> Är det kompilatorn som är övernitisk och i själva verket hinner
>>>>>>> variabeln bli bunden dynamiskt innan den verkliga användningen?
>>>>>>>
>>>>>>> Finns någon särskild anledning till att det blir mer sådant när man
>>>>>>> kompilerar Python?
>>>>>>>
>>>>>>> Och, vet du var, mer precist, som anropet till
>>>>>>> with-no-warnings-for-symbol ska placeras?
>>>>>>>
>>>>>>> Den fre 16 apr. 2021 11:02Stefan Israelsson Tampe <
>>>>>>> stefan.itampe@gmail.com> skrev:
>>>>>>>
>>>>>>>> Vi tar den patch som är viktigast och enklast först,
>>>>>>>>
>>>>>>>> Vi behöver ett system för att kunna undertrycka varningar för att
>>>>>>>> en modules symbol inte är bunden när den används. Att skriva ut sådana
>>>>>>>> varningar när den är viktig är ett av guiles starka sidor jämfört med t.ex.
>>>>>>>> python. Men med python kompilering så får vi ett ton av symboler som
>>>>>>>> varnas för och vi förlorar guldklimparna i allt skräp som skrivs ut. Med
>>>>>>>> min patch har jag fångat otaliga buggar i python libbet faktiskt som jag
>>>>>>>> skulle
>>>>>>>> ha missat om jag inte patchat warnings systemet eller använt cpython
>>>>>>>>
>>>>>>>> Föreslagen API:
>>>>>>>>
>>>>>>>> (define *no-warning-for-symbol-map* (make-fluid #f))
>>>>>>>>
>>>>>>>> (define (no-warn-printout-for-symbol? symbol)
>>>>>>>>   (let ((symmap (fluid-ref *no-warning-for-symbol-map*)))
>>>>>>>>     (if symmap
>>>>>>>>         (hash-ref symmap symbol)
>>>>>>>>         #f)))
>>>>>>>>
>>>>>>>> (define (with-no-warnings-for-symbol thunk)
>>>>>>>>   (with-fluids ((*no-warning-for-symbol-map* (make-hash-table)))
>>>>>>>>     (thunk)))
>>>>>>>>
>>>>>>>> (define (add-no-warning-for-symbol symbol)
>>>>>>>>    (when (not (symbol? symbol))
>>>>>>>>        (error "add-no-warning-for-symbol symbol takes a symbol as
>>>>>>>> argument"))
>>>>>>>>
>>>>>>>>   (let ((m (fluid-ref *no-warning-for-symbol-map*)))
>>>>>>>>     (if m
>>>>>>>>         (hash-set! m symbol #t)
>>>>>>>>         (error "adding symbol to inhibit warning outside of
>>>>>>>> compilation"))))
>>>>>>>>
>>>>>>>>
>>>>>>>> ;; API=======================
>>>>>>>>
>>>>>>>> ;; 'add-no-warning-for-symbol'
>>>>>>>> ;;    ska vara synlig för guile användaren
>>>>>>>> ;;    Man kan här under kompilering lägga till en symbol som inte
>>>>>>>> ska warnas
>>>>>>>> ;;    för att den e odefinierad
>>>>>>>>
>>>>>>>> ;; 'no-warn-printout-for-symbol?'
>>>>>>>> ;;    varingsystemet ska kolla med denna om den ska skriva ut en
>>>>>>>> varning för
>>>>>>>> ;;    användandet av en obunden variable
>>>>>>>>
>>>>>>>> ;; 'with-no-warnings-for-symbol'
>>>>>>>> ;;    scheme kompilerings systemet ska använda denna för att alla
>>>>>>>> kompilerings
>>>>>>>> ;;    moduler ska få en egen no-warn hashmap
>>>>>>>>
>>>>>>>> Mvh
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> On Fri, Apr 16, 2021 at 10:16 AM Mikael Djurfeldt <
>>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>>
>>>>>>>>> Jag vet inte om du känner till det, men jag har varit en av
>>>>>>>>> Guile's maintainers och känner åtminstone Ludovic hyfsat väl. Jag har
>>>>>>>>> dessutom skrivrättigheter i repositoryt. Därför borde jag kunna hjälpa dig
>>>>>>>>> att få in saker.
>>>>>>>>>
>>>>>>>>> Ska vi kanske börja med något enkelt, dvs inte en hel bunt patchar
>>>>>>>>> utan *en* funktion som du behöver?
>>>>>>>>>
>>>>>>>>> Du skulle tex kunna visa mig den och förklara syftet för mig.
>>>>>>>>>
>>>>>>>>> Mvh
>>>>>>>>> Mikael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 16, 2021 at 10:11 AM Stefan Israelsson Tampe <
>>>>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Jag har försökt få in den i guile flera ggr men får ingen
>>>>>>>>>> repsons. Jag behöver bra debuginformation för att kunna komma framåt i
>>>>>>>>>> felsökningen, vilket är anledningen att denna funktionalitet finns där. Jag
>>>>>>>>>> kan stänga dessa moddar för trunk om du vill. Radnummer i syntax objecten e
>>>>>>>>>> ju perfekt. Då ska man modda dessa i stället (och få bättre funktion) och
>>>>>>>>>> man slipper den moddningen. Jag ska ta ner trunk och studera detta.
>>>>>>>>>>
>>>>>>>>>> Stefan
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 16, 2021 at 10:00 AM Mikael Djurfeldt <
>>>>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Min åsikt är att det du gör i detta avseende inte är en effektiv
>>>>>>>>>>> strategi.
>>>>>>>>>>>
>>>>>>>>>>> Obs att du, som utvecklare av ett alternativt språk i Guile, har
>>>>>>>>>>> giltiga skäl att få den funktionalitet du behöver tillgodosedd av Guile.
>>>>>>>>>>> Därför bör du begära att den kommer in i Guile, och då kommer den
>>>>>>>>>>> funktionaliteten att underhållas där.
>>>>>>>>>>>
>>>>>>>>>>> Att patcha Guile, samt att underhålla sådana patchar, är dömt
>>>>>>>>>>> att kontinuerligt skapa en massa onödigt jobb.
>>>>>>>>>>>
>>>>>>>>>>> Mvh
>>>>>>>>>>> Mikael
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 16, 2021 at 9:51 AM Stefan Israelsson Tampe <
>>>>>>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hmm, jag kör 3.0.4 själv. Jag moddar guile genom att patcha
>>>>>>>>>>>> funktioner i efterhand för att få lite bättre radnummer för pyton
>>>>>>>>>>>> funktioner i tracebacks, kunna kompilera till python automagiskt genom att
>>>>>>>>>>>> titta på extension ändelsen på filen samt att undertrycka warningar som
>>>>>>>>>>>> inte e sanna för att undvika att dränkas
>>>>>>>>>>>> av varningar vilket e en godsend då de varningar som dyker upp
>>>>>>>>>>>> vanligtvis pekar på en bugg. Jag skulle tro
>>>>>>>>>>>> att wingo mekat med warningssystemet så jag måste modifiera
>>>>>>>>>>>> dessa patchar.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Apr 16, 2021 at 9:36 AM Mikael Djurfeldt <
>>>>>>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Apr 16, 2021 at 9:28 AM Stefan Israelsson Tampe <
>>>>>>>>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> vilken version av guile kör du?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> HEAD av master
>>>>>>>>>>>>>
>>>>>>>>>>>>

[-- Attachment #2: Type: text/html, Size: 16548 bytes --]

Re: Python on guile v1.2.3.7

[Stefan Israelsson Tampe]

Om du vill kan du göra en update på guile and guile-persists, börjar bli
bra nu.

On Sun, Apr 18, 2021 at 12:12 AM Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> I have continued to debug python for guile 3.1 and I am now getting much
> less warnings and also I can run test cases and it looks good. Tip, To run
> unit tests one can do from the module directory in the dist
>
> python language/python/module/unittest/tests/test_case.py
>
> to see what's working and what's not working.
>
> I am also working on getting it to behave better and especially take
> advantage
> of guile's new reader to introduce python source code numbering instead of
> the generated scheme code's numbering. Note that in python on guile I only
> modified the reader so that it reads python code and spit's out scheme
> code. So I then use some macros to modify line and columns to the python
> code. This way I can take advantage of the python scheme interface as the
> design goal is to be able to write pythonistic constructs in scheme code
> via a big chunk of macrology. Thanks to wingos work on the reader and
> making sure that the syntax objects contains the source location info, much
> of the dangerous clucky stuff that was added to get some kind of line
> numbering is now removed for version 3.1 of guile, we still support
> 2.0,2.1,2.2,3.0 as well. But the older version is less tested.
>
> I will not release a new version of python immediately as I continue to
> work on making the new version more robust against the 3.1 target and will
> try to continue to reduce the test cases that fail.
>
> On Sat, Apr 17, 2021 at 2:30 PM Stefan Israelsson Tampe <
> stefan.itampe@gmail.com> wrote:
>
>> Om man har ett filnamn kan jag lägga in den i syntax-object och meta
>> information finns i filen som python antar
>> existerar. Så på något sätt behöver jag det infot. Man kan ha en fluid
>> som när man kompilerar en fil, så får den nuvarande compilations identitet
>> och annars #f. Användaren är ansvarig att kolla ifall fluiden är #f och
>> använde något default värde, t.ex. när man evaluerar python kod i shell
>> miljön.
>>
>> On Sat, Apr 17, 2021 at 1:40 PM Mikael Djurfeldt <mikael@djurfeldt.com>
>> wrote:
>>
>>> ...och vad händer om man pipe:ar in kod i kompilatorn så att ingen
>>> giltig fil finns? Hur går det då?
>>>
>>> Den lör 17 apr. 2021 13:38Mikael Djurfeldt <mikael@djurfeldt.com> skrev:
>>>
>>>> OK, det verkar ju vara en rimlig begäran.
>>>>
>>>> Kan vi hitta ett giltigt "use case" där detta är motiverat? Jag är ute
>>>> efter att stärka argumentationen här.
>>>>
>>>> Varför behöver pythonkompilatorn veta detta?
>>>>
>>>> Mvh
>>>> Mikael
>>>>
>>>> Den lör 17 apr. 2021 13:28Stefan Israelsson Tampe <
>>>> stefan.itampe@gmail.com> skrev:
>>>>
>>>>> Hmm, jag har fixat detta på ett annat sätt nu. Du kan göra en update
>>>>> av guile-persist och python-on-guile för att få något som ska fungera
>>>>> bättre med bättre rad hänvisningar till python kod och få varningar.
>>>>>
>>>>> Nu över till nästa grej. Om vi kompilerar en fil so vill jag i min
>>>>> python compilator veta vilket filnamn vi compilerar. Hur får jag tag på det
>>>>> standardmässigt?
>>>>>
>>>>> mvh
>>>>> Stefan
>>>>>
>>>>> On Fri, Apr 16, 2021 at 11:57 PM Mikael Djurfeldt <
>>>>> mikael@djurfeldt.com> wrote:
>>>>>
>>>>>> Tyvärr är det nog så med mig att jag ändå inte förstår varför den här
>>>>>> funktionaliteten behövs.
>>>>>>
>>>>>> Rimligtvis borde varningar (och fel, för den delen) vara
>>>>>> undantagsfall så att den här situationen som du beskriver---att det blir en
>>>>>> uppsjö av varningar---aldrig borde inträffa.
>>>>>>
>>>>>> Nu är det istället så att vi har en mekanism som leder till denna
>>>>>> uppsjö av varningar. Och frågan, tycker jag, är om man på något vis kan
>>>>>> fixa problemet redan på den nivån snarare än att dämpa varningarna---jag
>>>>>> menar se till att varningarna aldrig uppstår.
>>>>>>
>>>>>> Dessvärre förstår jag fortfarande inte exakt hur de här varningarna
>>>>>> uppstår. Visst kunde jag dyka ned i koden, men det skulle nog ta ganska
>>>>>> lång tid så jag ber fortfarande om hjälp att förstå.
>>>>>>
>>>>>> Kan du ge ett enkelt exempel med en enkel klass där du konkret kan
>>>>>> visa vilken bindning till vilket objekt som skapas och varför det ger en
>>>>>> varning?
>>>>>>
>>>>>> Ledsen att jag är så petig...
>>>>>>
>>>>>> On Fri, Apr 16, 2021 at 10:54 PM Stefan Israelsson Tampe <
>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> I huvudsak, när jag skapar python classer så sparas en bindning till
>>>>>>> en del object i classen i modulen
>>>>>>> programatiskt som t.ex. medlemsfunktionerna. Detta används närman
>>>>>>> serialiserar classer och speciellt
>>>>>>> do de medlemmar, så när man kan göra x=[A.fkn1,B.fkn2], och göra en
>>>>>>> deepcopy på x, serialisera och deserialisera utan att gå in på
>>>>>>> funktionerne i sig som e bökit och kan ta mycket kraft. Har en ganska
>>>>>>> komplett serialiserings funktion i guile persist som används av guile
>>>>>>> python för copy,deepcopy och pickle. Där kan man serialisera t.ex.
>>>>>>> Generatorer och iteratorer (om de inte använder o boxade variabler i
>>>>>>> stacken) vilket för python kod e fallet då set! används för att boxa alla
>>>>>>> variabler. (Detta kan man inte göra i python :-)) en tycker det e en farlig
>>>>>>> men mycket cool feature då det vill till en massa C magi för att fixa till
>>>>>>> detta (guile-persist) men som sagt var tack vare att vi skapar en länk
>>>>>>> ifrån modul till medlemsvariabler så minskas behovet av C-kod ganska
>>>>>>> dramatiskt.
>>>>>>>
>>>>>>> De är också praktiskt när man länkar in C-kod, va för mig att min
>>>>>>> gamla version av guile wranade när man använder dessa inlänkade funktioner.
>>>>>>> Så det vore bra där med att hindra varningar att uppstå. Änne senare
>>>>>>> versioner kunde man göra (define f #f) innan f sattes ab c-koden och hindra
>>>>>>> varningar. Men nu verkar denna
>>>>>>> metod slutat fungera. Så i de fall när man får typ sådana problem
>>>>>>> kan den föreslagna metodiken fungera bra.
>>>>>>>
>>>>>>> Över till var with ... ska länkas in.
>>>>>>>
>>>>>>> jag moddade compile-file (system base compile) för att knö till
>>>>>>> detta, funkat bra med detta men det kan finnas
>>>>>>> bättre ställen att sätta in den, och när jag tittade på koden så e
>>>>>>> nog det bästa stället funktionen 'compile' i samma module.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 16, 2021 at 9:22 PM Mikael Djurfeldt <
>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>
>>>>>>>> Så det rör sig om top level bindings i moduler?
>>>>>>>>
>>>>>>>> Dum fråga: Varför är den inte bunden när den används?
>>>>>>>>
>>>>>>>> Är det kompilatorn som är övernitisk och i själva verket hinner
>>>>>>>> variabeln bli bunden dynamiskt innan den verkliga användningen?
>>>>>>>>
>>>>>>>> Finns någon särskild anledning till att det blir mer sådant när man
>>>>>>>> kompilerar Python?
>>>>>>>>
>>>>>>>> Och, vet du var, mer precist, som anropet till
>>>>>>>> with-no-warnings-for-symbol ska placeras?
>>>>>>>>
>>>>>>>> Den fre 16 apr. 2021 11:02Stefan Israelsson Tampe <
>>>>>>>> stefan.itampe@gmail.com> skrev:
>>>>>>>>
>>>>>>>>> Vi tar den patch som är viktigast och enklast först,
>>>>>>>>>
>>>>>>>>> Vi behöver ett system för att kunna undertrycka varningar för att
>>>>>>>>> en modules symbol inte är bunden när den används. Att skriva ut sådana
>>>>>>>>> varningar när den är viktig är ett av guiles starka sidor jämfört med t.ex.
>>>>>>>>> python. Men med python kompilering så får vi ett ton av symboler som
>>>>>>>>> varnas för och vi förlorar guldklimparna i allt skräp som skrivs ut. Med
>>>>>>>>> min patch har jag fångat otaliga buggar i python libbet faktiskt som jag
>>>>>>>>> skulle
>>>>>>>>> ha missat om jag inte patchat warnings systemet eller använt
>>>>>>>>> cpython
>>>>>>>>>
>>>>>>>>> Föreslagen API:
>>>>>>>>>
>>>>>>>>> (define *no-warning-for-symbol-map* (make-fluid #f))
>>>>>>>>>
>>>>>>>>> (define (no-warn-printout-for-symbol? symbol)
>>>>>>>>>   (let ((symmap (fluid-ref *no-warning-for-symbol-map*)))
>>>>>>>>>     (if symmap
>>>>>>>>>         (hash-ref symmap symbol)
>>>>>>>>>         #f)))
>>>>>>>>>
>>>>>>>>> (define (with-no-warnings-for-symbol thunk)
>>>>>>>>>   (with-fluids ((*no-warning-for-symbol-map* (make-hash-table)))
>>>>>>>>>     (thunk)))
>>>>>>>>>
>>>>>>>>> (define (add-no-warning-for-symbol symbol)
>>>>>>>>>    (when (not (symbol? symbol))
>>>>>>>>>        (error "add-no-warning-for-symbol symbol takes a symbol as
>>>>>>>>> argument"))
>>>>>>>>>
>>>>>>>>>   (let ((m (fluid-ref *no-warning-for-symbol-map*)))
>>>>>>>>>     (if m
>>>>>>>>>         (hash-set! m symbol #t)
>>>>>>>>>         (error "adding symbol to inhibit warning outside of
>>>>>>>>> compilation"))))
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ;; API=======================
>>>>>>>>>
>>>>>>>>> ;; 'add-no-warning-for-symbol'
>>>>>>>>> ;;    ska vara synlig för guile användaren
>>>>>>>>> ;;    Man kan här under kompilering lägga till en symbol som inte
>>>>>>>>> ska warnas
>>>>>>>>> ;;    för att den e odefinierad
>>>>>>>>>
>>>>>>>>> ;; 'no-warn-printout-for-symbol?'
>>>>>>>>> ;;    varingsystemet ska kolla med denna om den ska skriva ut en
>>>>>>>>> varning för
>>>>>>>>> ;;    användandet av en obunden variable
>>>>>>>>>
>>>>>>>>> ;; 'with-no-warnings-for-symbol'
>>>>>>>>> ;;    scheme kompilerings systemet ska använda denna för att alla
>>>>>>>>> kompilerings
>>>>>>>>> ;;    moduler ska få en egen no-warn hashmap
>>>>>>>>>
>>>>>>>>> Mvh
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>> On Fri, Apr 16, 2021 at 10:16 AM Mikael Djurfeldt <
>>>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>>>
>>>>>>>>>> Jag vet inte om du känner till det, men jag har varit en av
>>>>>>>>>> Guile's maintainers och känner åtminstone Ludovic hyfsat väl. Jag har
>>>>>>>>>> dessutom skrivrättigheter i repositoryt. Därför borde jag kunna hjälpa dig
>>>>>>>>>> att få in saker.
>>>>>>>>>>
>>>>>>>>>> Ska vi kanske börja med något enkelt, dvs inte en hel bunt
>>>>>>>>>> patchar utan *en* funktion som du behöver?
>>>>>>>>>>
>>>>>>>>>> Du skulle tex kunna visa mig den och förklara syftet för mig.
>>>>>>>>>>
>>>>>>>>>> Mvh
>>>>>>>>>> Mikael
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 16, 2021 at 10:11 AM Stefan Israelsson Tampe <
>>>>>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Jag har försökt få in den i guile flera ggr men får ingen
>>>>>>>>>>> repsons. Jag behöver bra debuginformation för att kunna komma framåt i
>>>>>>>>>>> felsökningen, vilket är anledningen att denna funktionalitet finns där. Jag
>>>>>>>>>>> kan stänga dessa moddar för trunk om du vill. Radnummer i syntax objecten e
>>>>>>>>>>> ju perfekt. Då ska man modda dessa i stället (och få bättre funktion) och
>>>>>>>>>>> man slipper den moddningen. Jag ska ta ner trunk och studera detta.
>>>>>>>>>>>
>>>>>>>>>>> Stefan
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 16, 2021 at 10:00 AM Mikael Djurfeldt <
>>>>>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Min åsikt är att det du gör i detta avseende inte är en
>>>>>>>>>>>> effektiv strategi.
>>>>>>>>>>>>
>>>>>>>>>>>> Obs att du, som utvecklare av ett alternativt språk i Guile,
>>>>>>>>>>>> har giltiga skäl att få den funktionalitet du behöver tillgodosedd av
>>>>>>>>>>>> Guile. Därför bör du begära att den kommer in i Guile, och då kommer den
>>>>>>>>>>>> funktionaliteten att underhållas där.
>>>>>>>>>>>>
>>>>>>>>>>>> Att patcha Guile, samt att underhålla sådana patchar, är dömt
>>>>>>>>>>>> att kontinuerligt skapa en massa onödigt jobb.
>>>>>>>>>>>>
>>>>>>>>>>>> Mvh
>>>>>>>>>>>> Mikael
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Apr 16, 2021 at 9:51 AM Stefan Israelsson Tampe <
>>>>>>>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hmm, jag kör 3.0.4 själv. Jag moddar guile genom att patcha
>>>>>>>>>>>>> funktioner i efterhand för att få lite bättre radnummer för pyton
>>>>>>>>>>>>> funktioner i tracebacks, kunna kompilera till python automagiskt genom att
>>>>>>>>>>>>> titta på extension ändelsen på filen samt att undertrycka warningar som
>>>>>>>>>>>>> inte e sanna för att undvika att dränkas
>>>>>>>>>>>>> av varningar vilket e en godsend då de varningar som dyker upp
>>>>>>>>>>>>> vanligtvis pekar på en bugg. Jag skulle tro
>>>>>>>>>>>>> att wingo mekat med warningssystemet så jag måste modifiera
>>>>>>>>>>>>> dessa patchar.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Apr 16, 2021 at 9:36 AM Mikael Djurfeldt <
>>>>>>>>>>>>> mikael@djurfeldt.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Apr 16, 2021 at 9:28 AM Stefan Israelsson Tampe <
>>>>>>>>>>>>>> stefan.itampe@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> vilken version av guile kör du?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HEAD av master
>>>>>>>>>>>>>>
>>>>>>>>>>>>>

Re: Python on guile v1.2.3.7

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]


Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> I have continued to debug python for guile 3.1 and I am now getting much
> less warnings and also I can run test cases and it looks good. Tip, To run
> unit tests one can do from the module directory in the dist
>
> python language/python/module/unittest/tests/test_case.py
>
> to see what's working and what's not working.
>
> I am also working on getting it to behave better and especially take
> advantage
> of guile's new reader to introduce python source code numbering instead of

Thank you for your work! It’s pretty awesome to see Python on Guile!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]