From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: Mikael Djurfeldt <mikael@djurfeldt.com>,
guile-devel <guile-devel@gnu.org>,
Guile User <guile-user@gnu.org>
Subject: Re: Python on guile v1.2.3.7
Date: Sun, 18 Apr 2021 00:14:10 +0200 [thread overview]
Message-ID: <CAGua6m3UKdhN+B4p_D-3SEXPTc30JRCL+D0_UcEjwjtB5x8gTQ@mail.gmail.com> (raw)
In-Reply-To: <CAGua6m0Ve-_xtLy3aK0pr5KedXNNn9cdqW2xeDO92KGmEmgDdw@mail.gmail.com>
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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
next prev parent reply other threads:[~2021-04-17 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-11 9:22 Python on guile v1.2.3.7 Stefan Israelsson Tampe
2021-04-11 18:39 ` Maxim Cournoyer
2021-04-11 19:53 ` Dr. Arne Babenhauserheide
2021-04-14 11:59 ` Mikael Djurfeldt
[not found] ` <CAGua6m2H9NDepyN9wPHXmv0NO=XZnCu685gvGiVQsPUQmzMU-g@mail.gmail.com>
[not found] ` <CAA2XvwJnsqVBC48oFi=DdE3zOhZKuL8qRjj6ZSejFqv_HvFJNQ@mail.gmail.com>
[not found] ` <CAA2XvwLpu+mmAkggePNHBbt3uqNtU6wkSwx=8TTAtsfmbcAeaw@mail.gmail.com>
[not found] ` <CAGua6m1Sp7TTmo_Bq5ooeegBmdNM184dUCpDj3SB_-B31vbxYA@mail.gmail.com>
[not found] ` <CAGua6m3oHmMAYTv-S199ZDieYuaJM7Y5qDSM0u9Se0-zhxDmZQ@mail.gmail.com>
[not found] ` <CAGua6m1sr+1tVZpYiOctLpEmXb2_kLiEppKtzBhOokjTB7Wj1Q@mail.gmail.com>
[not found] ` <CAA2XvwJryKUbsx_zup8_OhtKRJEHuO1PnJu0v7S+Zxx0oiYPHw@mail.gmail.com>
[not found] ` <CAGua6m0xpxG4ETgcuPw2xZQ3QevG+_wHP4CeZXAri1ywih8KKA@mail.gmail.com>
[not found] ` <CAA2XvwK_K=0Q9DJ-ZxJfwqaZuLEQs6fVoHaDPJ7V6aD=osiYgg@mail.gmail.com>
[not found] ` <CAGua6m2_zPtgg4JBPZ-DebqqOhiPzXGR2Jyc-bMwKtVA_5MzkQ@mail.gmail.com>
[not found] ` <CAA2Xvw+2HWkkEaUhwcWfm+XpDWEoP5J0UPMS7+QyURvzd+dvOg@mail.gmail.com>
[not found] ` <CAGua6m1wmTcZUTsB3e+gLwuF-bG3nOnkQwtkY+kS7PAuZb5+MA@mail.gmail.com>
[not found] ` <CAA2Xvw+YLPkYe1eiF4-2JsUCn2hVMRowcXBrLMynwNT-DT6mBw@mail.gmail.com>
[not found] ` <CAGua6m3QhkJ+vXax7OEm2xX01rpkA=mrm-M1Mz5_DTQVMV2_UQ@mail.gmail.com>
[not found] ` <CAA2XvwLLzrb62zLVwLJKmEZq9b-5xRpbbpsGQuJ3W1JntX7g4A@mail.gmail.com>
[not found] ` <CAGua6m0w9bu0wJ4n=bKoTFvL2gC2YJ2h3=X+0p_v4czG7rQdMg@mail.gmail.com>
[not found] ` <CAA2XvwKvzjcJ2czpx2YmwZsSi03P0+ZY7XDXKwv+m=FmHXGBxw@mail.gmail.com>
[not found] ` <CAGua6m3btzAq4Md-FyeeL7zurvOMXXzU5mJLAn6Y-Unhd-sajA@mail.gmail.com>
[not found] ` <CAA2XvwKHeNJR+FXPROt25yLrS9dcTSd51LZNC-ZoUv3W4nSM_Q@mail.gmail.com>
[not found] ` <CAA2XvwJyiH1SLwetdfA2Q48vipecADw=xSYH2YCJ3Amoj2PPdw@mail.gmail.com>
[not found] ` <CAGua6m3pvkc1fjq+XDrdLSCW7yB+Z9+jxQtKRQZaZ8hbn1kyNw@mail.gmail.com>
2021-04-17 22:12 ` Stefan Israelsson Tampe
2021-04-17 22:14 ` Stefan Israelsson Tampe [this message]
2021-04-17 23:10 ` Dr. Arne Babenhauserheide
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGua6m3UKdhN+B4p_D-3SEXPTc30JRCL+D0_UcEjwjtB5x8gTQ@mail.gmail.com \
--to=stefan.itampe@gmail.com \
--cc=guile-devel@gnu.org \
--cc=guile-user@gnu.org \
--cc=mikael@djurfeldt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).