unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>


  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).