python-on-guile
i am now experimenting with the new generator infrastructure to see how much actual python on guile code is sped up. In the process I am optimizing a lot of stuff regarding python for loops. But some irritating things remain. My number 1 anger is that a iterator can throw an exception as a way to end a loop. And then at a final step all loop data has to be available so in a functional style you now need to have the catch frame that is internal. Currently we have the cludge of wither use known safe iterations, like over a list of values or a range or a known safe generator. More general code needs to play with a pletoria of set! actions in order to transfer data out of scope. Horrible!!! But what about this solution just make a generator that returns all values so that you can keep track of em and just issue the finishing command with it. (define internalGenerator (lambda () (pause) (catch 'StopIteration (lambda () (let lp ((s s0) ...) (return x ... s ...) (let ((xx (next I)) ...) (let ((x xx) ...) code ... (lp snew ... (return 'finished) (lambda xxx (return 'finished)) We know that the generator over head in the loop is quite small just 3-4x the speediest loop guile perform. with this we get non set! operations that are very performant. But not only this we might get continue to work speedily as well
Re: Python-on-guile
Nice to know it! I still don't have time to polish my guile-lua-rebirth. Anyway, it's really good news to see the transpiler has a good performance on Guile.! Best regards. On Fri, Apr 23, 2021 at 11:01 PM Mikael Djurfeldt wrote: > Hi, > > Yesterday, Andy committed new code to the compiler, some of which > concerned skipping some arity checking. > > Also, Stefan meanwhile committed something called "reworked object system" > to his python-on-guile. > > Sorry for coming with unspecific information (don't have time to track > down the details) but I noticed that my benchmark script written in Python, > and which computes the 20:th Ramanujan number, now runs 60% faster than > before these changes. > > This means that python-on-guile running on guile3 master executes python > code only 2.6 times slower than the CPython python3 interpreter itself. :-) > > Have a nice weekend all, > Mikael > >
Re: Python-on-guile
Hello, Le dimanche 25 avril 2021 à 12:54 +0200, Dr. Arne Babenhauserheide a écrit : > (next frontier: compete with math that’s implemented via numpy — you > can find RPython implementations of the basics of numpy in the > pypy-sources: > https://foss.heptapod.net/pypy/pypy/-/tree/branch/default/pypy/module/micronumpy > ) I think it would be wiser to use guile arrays to implement the same things as numpy.
Re: Python-on-guile
Stefan Israelsson Tampe writes: > (define-syntax-rule (letec f) > (let/ec x (f x > > Actually lead to similar speeds as python3. Please keep in mind that this is math. There are parts of Python that are heavily optimized, for example reading strings from disk. Guile will likely have a hard time to compete with that. But for math Guile is quite a bit faster than Python :-) (next frontier: compete with math that’s implemented via numpy — you can find RPython implementations of the basics of numpy in the pypy-sources: https://foss.heptapod.net/pypy/pypy/-/tree/branch/default/pypy/module/micronumpy ) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Python-on-guile
It is not the break let/ex that slows it down. But for wha it's worth we do not do a let/ec if no break is used. Now. On Sun, 25 Apr 2021, 10:20 Mikael Djurfeldt wrote: > Nice! > > I guess it would be nice if "continue" *could* be compiled efficiently. > And, as you indicate, perhaps that would amount to efficiently compiling > let/ec. > > Best regards, > Mikael > > On Sat, Apr 24, 2021 at 5:19 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> Guile is 3x faster then fastest python-on-guile which is 2x faster then >> python3 Cpython >> >> attached is a guile corresponding program. >> >> On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> To note is that 'continue' is killing performance for python-on-guile >>> programs, so by changing the >>> code to not use continue lead to python-on-guile running twice the speed >>> of python3. The reason is that >>> the while loop is used as >>> (while (...) >>>(let/ec continue >>> ...)) >>> >>> And the let/ec is probably not optimally compiled. Python-on-guile will >>> check the loop for continue usage and if not then it will skip the let/ec. >>> >>> I attached the code not using continue >>> >>> On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < >>> stefan.ita...@gmail.com> wrote: >>> >>>> Actually changing in (language python compile), >>>> >>>> (define (letec f) >>>> (let/ec x (f x >>>> >>>> To >>>> >>>> (define-syntax-rule (letec f) >>>> (let/ec x (f x >>>> >>>> Actually lead to similar speeds as python3. >>>> >>>> >>>> >>>> On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < >>>> stefan.ita...@gmail.com> wrote: >>>> >>>>> Pro tip, when running this on guile the scheme code that it compilse >>>>> to is located in log.txt. >>>>> If you ,opt the resulting code in a guile session you might be able to >>>>> pinpoint issues that >>>>> delays the code execution. >>>>> >>>>> On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt < >>>>> mik...@djurfeldt.com> wrote: >>>>> >>>>>> (I should perhaps add that my script doesn't benchmark the object >>>>>> system but rather loops, conditionals and integer arithmetic.) >>>>>> >>>>>> Den fre 23 apr. 2021 17:00Mikael Djurfeldt >>>>>> skrev: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yesterday, Andy committed new code to the compiler, some of which >>>>>>> concerned skipping some arity checking. >>>>>>> >>>>>>> Also, Stefan meanwhile committed something called "reworked object >>>>>>> system" to his python-on-guile. >>>>>>> >>>>>>> Sorry for coming with unspecific information (don't have time to >>>>>>> track down the details) but I noticed that my benchmark script written >>>>>>> in >>>>>>> Python, and which computes the 20:th Ramanujan number, now runs 60% >>>>>>> faster >>>>>>> than before these changes. >>>>>>> >>>>>>> This means that python-on-guile running on guile3 master executes >>>>>>> python code only 2.6 times slower than the CPython python3 interpreter >>>>>>> itself. :-) >>>>>>> >>>>>>> Have a nice weekend all, >>>>>>> Mikael >>>>>>> >>>>>>>
Re: Python-on-guile
Python List lookup is 2x slower now than cpython. Tuple lookup is slightly faster. On Fri, 23 Apr 2021, 17:01 Mikael Djurfeldt wrote: > Hi, > > Yesterday, Andy committed new code to the compiler, some of which > concerned skipping some arity checking. > > Also, Stefan meanwhile committed something called "reworked object system" > to his python-on-guile. > > Sorry for coming with unspecific information (don't have time to track > down the details) but I noticed that my benchmark script written in Python, > and which computes the 20:th Ramanujan number, now runs 60% faster than > before these changes. > > This means that python-on-guile running on guile3 master executes python > code only 2.6 times slower than the CPython python3 interpreter itself. :-) > > Have a nice weekend all, > Mikael > >
Re: Python-on-guile
The remaining 3x between guile and python can be to either the extensive usage of set! in python or if the number of runs in the inner loop is small because there is a let/ec for the break and according to the standard a catch to support the raising of StopIteration. Set! probably cannot account for 3x speedwise, but it may hinder optimisations that may yield a speedup of that factor. On Sat, Apr 24, 2021 at 5:19 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > Guile is 3x faster then fastest python-on-guile which is 2x faster then > python3 Cpython > > attached is a guile corresponding program. > > On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> To note is that 'continue' is killing performance for python-on-guile >> programs, so by changing the >> code to not use continue lead to python-on-guile running twice the speed >> of python3. The reason is that >> the while loop is used as >> (while (...) >>(let/ec continue >> ...)) >> >> And the let/ec is probably not optimally compiled. Python-on-guile will >> check the loop for continue usage and if not then it will skip the let/ec. >> >> I attached the code not using continue >> >> On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> Actually changing in (language python compile), >>> >>> (define (letec f) >>> (let/ec x (f x >>> >>> To >>> >>> (define-syntax-rule (letec f) >>> (let/ec x (f x >>> >>> Actually lead to similar speeds as python3. >>> >>> >>> >>> On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < >>> stefan.ita...@gmail.com> wrote: >>> >>>> Pro tip, when running this on guile the scheme code that it compilse to >>>> is located in log.txt. >>>> If you ,opt the resulting code in a guile session you might be able to >>>> pinpoint issues that >>>> delays the code execution. >>>> >>>> On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt >>>> wrote: >>>> >>>>> (I should perhaps add that my script doesn't benchmark the object >>>>> system but rather loops, conditionals and integer arithmetic.) >>>>> >>>>> Den fre 23 apr. 2021 17:00Mikael Djurfeldt >>>>> skrev: >>>>> >>>>>> Hi, >>>>>> >>>>>> Yesterday, Andy committed new code to the compiler, some of which >>>>>> concerned skipping some arity checking. >>>>>> >>>>>> Also, Stefan meanwhile committed something called "reworked object >>>>>> system" to his python-on-guile. >>>>>> >>>>>> Sorry for coming with unspecific information (don't have time to >>>>>> track down the details) but I noticed that my benchmark script written in >>>>>> Python, and which computes the 20:th Ramanujan number, now runs 60% >>>>>> faster >>>>>> than before these changes. >>>>>> >>>>>> This means that python-on-guile running on guile3 master executes >>>>>> python code only 2.6 times slower than the CPython python3 interpreter >>>>>> itself. :-) >>>>>> >>>>>> Have a nice weekend all, >>>>>> Mikael >>>>>> >>>>>>
Re: Python-on-guile
Nice! I guess it would be nice if "continue" *could* be compiled efficiently. And, as you indicate, perhaps that would amount to efficiently compiling let/ec. Best regards, Mikael On Sat, Apr 24, 2021 at 5:19 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > Guile is 3x faster then fastest python-on-guile which is 2x faster then > python3 Cpython > > attached is a guile corresponding program. > > On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> To note is that 'continue' is killing performance for python-on-guile >> programs, so by changing the >> code to not use continue lead to python-on-guile running twice the speed >> of python3. The reason is that >> the while loop is used as >> (while (...) >>(let/ec continue >> ...)) >> >> And the let/ec is probably not optimally compiled. Python-on-guile will >> check the loop for continue usage and if not then it will skip the let/ec. >> >> I attached the code not using continue >> >> On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> Actually changing in (language python compile), >>> >>> (define (letec f) >>> (let/ec x (f x >>> >>> To >>> >>> (define-syntax-rule (letec f) >>> (let/ec x (f x >>> >>> Actually lead to similar speeds as python3. >>> >>> >>> >>> On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < >>> stefan.ita...@gmail.com> wrote: >>> >>>> Pro tip, when running this on guile the scheme code that it compilse to >>>> is located in log.txt. >>>> If you ,opt the resulting code in a guile session you might be able to >>>> pinpoint issues that >>>> delays the code execution. >>>> >>>> On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt >>>> wrote: >>>> >>>>> (I should perhaps add that my script doesn't benchmark the object >>>>> system but rather loops, conditionals and integer arithmetic.) >>>>> >>>>> Den fre 23 apr. 2021 17:00Mikael Djurfeldt >>>>> skrev: >>>>> >>>>>> Hi, >>>>>> >>>>>> Yesterday, Andy committed new code to the compiler, some of which >>>>>> concerned skipping some arity checking. >>>>>> >>>>>> Also, Stefan meanwhile committed something called "reworked object >>>>>> system" to his python-on-guile. >>>>>> >>>>>> Sorry for coming with unspecific information (don't have time to >>>>>> track down the details) but I noticed that my benchmark script written in >>>>>> Python, and which computes the 20:th Ramanujan number, now runs 60% >>>>>> faster >>>>>> than before these changes. >>>>>> >>>>>> This means that python-on-guile running on guile3 master executes >>>>>> python code only 2.6 times slower than the CPython python3 interpreter >>>>>> itself. :-) >>>>>> >>>>>> Have a nice weekend all, >>>>>> Mikael >>>>>> >>>>>>
Re: Python-on-guile
Guile is 3x faster then fastest python-on-guile which is 2x faster then python3 Cpython attached is a guile corresponding program. On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > To note is that 'continue' is killing performance for python-on-guile > programs, so by changing the > code to not use continue lead to python-on-guile running twice the speed > of python3. The reason is that > the while loop is used as > (while (...) >(let/ec continue > ...)) > > And the let/ec is probably not optimally compiled. Python-on-guile will > check the loop for continue usage and if not then it will skip the let/ec. > > I attached the code not using continue > > On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> Actually changing in (language python compile), >> >> (define (letec f) >> (let/ec x (f x >> >> To >> >> (define-syntax-rule (letec f) >> (let/ec x (f x >> >> Actually lead to similar speeds as python3. >> >> >> >> On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> Pro tip, when running this on guile the scheme code that it compilse to >>> is located in log.txt. >>> If you ,opt the resulting code in a guile session you might be able to >>> pinpoint issues that >>> delays the code execution. >>> >>> On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt >>> wrote: >>> >>>> (I should perhaps add that my script doesn't benchmark the object >>>> system but rather loops, conditionals and integer arithmetic.) >>>> >>>> Den fre 23 apr. 2021 17:00Mikael Djurfeldt >>>> skrev: >>>> >>>>> Hi, >>>>> >>>>> Yesterday, Andy committed new code to the compiler, some of which >>>>> concerned skipping some arity checking. >>>>> >>>>> Also, Stefan meanwhile committed something called "reworked object >>>>> system" to his python-on-guile. >>>>> >>>>> Sorry for coming with unspecific information (don't have time to track >>>>> down the details) but I noticed that my benchmark script written in >>>>> Python, >>>>> and which computes the 20:th Ramanujan number, now runs 60% faster than >>>>> before these changes. >>>>> >>>>> This means that python-on-guile running on guile3 master executes >>>>> python code only 2.6 times slower than the CPython python3 interpreter >>>>> itself. :-) >>>>> >>>>> Have a nice weekend all, >>>>> Mikael >>>>> >>>>> (define (ramanujan n) (let lp ((w 0) (b0 1) (n n)) (if (> n 0) (let ((w (+ w 1))) (let lp2 ((b0 b0)) (if (< (+ 1 (* b0 b0 b0)) w) (lp2 (+ b0 1)) (let lp3 ((a 1) (a3 1) (b b0) (b3 (* b0 b0 b0)) (count 0)) (if (<= a b) (let ((s (+ a3 b3))) (cond ((< s w) (let ((aa (+ a 1))) (lp3 aa (* aa aa aa) b b3 count))) ((= s w) (let ((count (+ count 1))) (if (> count 1) (lp w b0 (- n 1)) (let* ((b (- b 1)) (b3 (* b b b))) (lp3 a a3 b b3 count) (else (let* ((b (- b 1)) (b3 (* b b b))) (lp3 a a3 b b3 count) (lp w b0 n)) w))) (pk (ramanujan 20))
Re: Python-on-guile
To note is that 'continue' is killing performance for python-on-guile programs, so by changing the code to not use continue lead to python-on-guile running twice the speed of python3. The reason is that the while loop is used as (while (...) (let/ec continue ...)) And the let/ec is probably not optimally compiled. Python-on-guile will check the loop for continue usage and if not then it will skip the let/ec. I attached the code not using continue On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > Actually changing in (language python compile), > > (define (letec f) > (let/ec x (f x > > To > > (define-syntax-rule (letec f) > (let/ec x (f x > > Actually lead to similar speeds as python3. > > > > On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> Pro tip, when running this on guile the scheme code that it compilse to >> is located in log.txt. >> If you ,opt the resulting code in a guile session you might be able to >> pinpoint issues that >> delays the code execution. >> >> On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt >> wrote: >> >>> (I should perhaps add that my script doesn't benchmark the object system >>> but rather loops, conditionals and integer arithmetic.) >>> >>> Den fre 23 apr. 2021 17:00Mikael Djurfeldt skrev: >>> >>>> Hi, >>>> >>>> Yesterday, Andy committed new code to the compiler, some of which >>>> concerned skipping some arity checking. >>>> >>>> Also, Stefan meanwhile committed something called "reworked object >>>> system" to his python-on-guile. >>>> >>>> Sorry for coming with unspecific information (don't have time to track >>>> down the details) but I noticed that my benchmark script written in Python, >>>> and which computes the 20:th Ramanujan number, now runs 60% faster than >>>> before these changes. >>>> >>>> This means that python-on-guile running on guile3 master executes >>>> python code only 2.6 times slower than the CPython python3 interpreter >>>> itself. :-) >>>> >>>> Have a nice weekend all, >>>> Mikael >>>> >>>> # ramanujan.py -- Compute the N:th Ramanujan number # # Copyright (C) 2018-2021 Mikael Djurfeldt # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. # # Version 2 # return the N:th Ramanujan number (sum of two cubes in more than one way) # def ramanujan (n): w = 0 # Ramanujan number candidate b0 = 1 # first second term to try while n > 0: w += 1 # try next candidate # increase initial b0 until 1 + b0^3 >=w while 1 + b0 * b0 * b0 < w: b0 += 1 a = 1 a3 = 1 b = b0 b3 = b0 * b0 * b0 count = 0 # number of ways to write w while a <= b: s = a3 + b3 if s < w: a += 1 # if sum is too small, increase a a3 = a * a * a elif s == w: count += 1 # found a sum! if count > 1: n -= 1 break b -= 1 # increase b both if sum too large and to find next way to write w b3 = b * b * b else: b -= 1 b3 = b * b * b return w print (ramanujan (21))
Re: Python-on-guile
Actually changing in (language python compile), (define (letec f) (let/ec x (f x To (define-syntax-rule (letec f) (let/ec x (f x Actually lead to similar speeds as python3. On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > Pro tip, when running this on guile the scheme code that it compilse to is > located in log.txt. > If you ,opt the resulting code in a guile session you might be able to > pinpoint issues that > delays the code execution. > > On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt > wrote: > >> (I should perhaps add that my script doesn't benchmark the object system >> but rather loops, conditionals and integer arithmetic.) >> >> Den fre 23 apr. 2021 17:00Mikael Djurfeldt skrev: >> >>> Hi, >>> >>> Yesterday, Andy committed new code to the compiler, some of which >>> concerned skipping some arity checking. >>> >>> Also, Stefan meanwhile committed something called "reworked object >>> system" to his python-on-guile. >>> >>> Sorry for coming with unspecific information (don't have time to track >>> down the details) but I noticed that my benchmark script written in Python, >>> and which computes the 20:th Ramanujan number, now runs 60% faster than >>> before these changes. >>> >>> This means that python-on-guile running on guile3 master executes python >>> code only 2.6 times slower than the CPython python3 interpreter itself. :-) >>> >>> Have a nice weekend all, >>> Mikael >>> >>>
Re: Python-on-guile
Pro tip, when running this on guile the scheme code that it compilse to is located in log.txt. If you ,opt the resulting code in a guile session you might be able to pinpoint issues that delays the code execution. On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt wrote: > (I should perhaps add that my script doesn't benchmark the object system > but rather loops, conditionals and integer arithmetic.) > > Den fre 23 apr. 2021 17:00Mikael Djurfeldt skrev: > >> Hi, >> >> Yesterday, Andy committed new code to the compiler, some of which >> concerned skipping some arity checking. >> >> Also, Stefan meanwhile committed something called "reworked object >> system" to his python-on-guile. >> >> Sorry for coming with unspecific information (don't have time to track >> down the details) but I noticed that my benchmark script written in Python, >> and which computes the 20:th Ramanujan number, now runs 60% faster than >> before these changes. >> >> This means that python-on-guile running on guile3 master executes python >> code only 2.6 times slower than the CPython python3 interpreter itself. :-) >> >> Have a nice weekend all, >> Mikael >> >>
Re: Python-on-guile
(I should perhaps add that my script doesn't benchmark the object system but rather loops, conditionals and integer arithmetic.) Den fre 23 apr. 2021 17:00Mikael Djurfeldt skrev: > Hi, > > Yesterday, Andy committed new code to the compiler, some of which > concerned skipping some arity checking. > > Also, Stefan meanwhile committed something called "reworked object system" > to his python-on-guile. > > Sorry for coming with unspecific information (don't have time to track > down the details) but I noticed that my benchmark script written in Python, > and which computes the 20:th Ramanujan number, now runs 60% faster than > before these changes. > > This means that python-on-guile running on guile3 master executes python > code only 2.6 times slower than the CPython python3 interpreter itself. :-) > > Have a nice weekend all, > Mikael > >
Re: Python-on-guile
Hurra! I noticed a couple.of weeks ago that declarative modules made it possible for me to stop using define-syntax-rule to force stupid inlining of code. The cross module inlining branch will make that even nicer. I can write cleaner code and get better error messages :) Guile has been going in a very nice direction for some time! -- Linus Björnstam On Fri, 23 Apr 2021, at 17:00, Mikael Djurfeldt wrote: > Hi, > > Yesterday, Andy committed new code to the compiler, some of which > concerned skipping some arity checking. > > Also, Stefan meanwhile committed something called "reworked object > system" to his python-on-guile. > > Sorry for coming with unspecific information (don't have time to track > down the details) but I noticed that my benchmark script written in > Python, and which computes the 20:th Ramanujan number, now runs 60% > faster than before these changes. > > This means that python-on-guile running on guile3 master executes > python code only 2.6 times slower than the CPython python3 interpreter > itself. :-) > > Have a nice weekend all, > Mikael >
Python-on-guile
Hi, Yesterday, Andy committed new code to the compiler, some of which concerned skipping some arity checking. Also, Stefan meanwhile committed something called "reworked object system" to his python-on-guile. Sorry for coming with unspecific information (don't have time to track down the details) but I noticed that my benchmark script written in Python, and which computes the 20:th Ramanujan number, now runs 60% faster than before these changes. This means that python-on-guile running on guile3 master executes python code only 2.6 times slower than the CPython python3 interpreter itself. :-) Have a nice weekend all, Mikael
Re: Python on guile v1.2.3.7
Stefan Israelsson Tampe 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 signature.asc Description: PGP signature
Re: Python on guile v1.2.3.7
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.ita...@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.ita...@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 >> 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 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.ita...@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 < >>>>> mik...@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
Re: Python on guile v1.2.3.7
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.ita...@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 > 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 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.ita...@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 >>>> 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.ita...@gmail.com> wrote: >>>>> >>>>>> >>>>>> I huvudsak, när jag skapar python classer så sparas en bindning till >>&g
Re: Python on guile v1.2.3.7
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.ita...@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. >
Re: Python on guile v1.2.3.7
Hi Stefan, Stefan Israelsson Tampe 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
Python on guile v1.2.3.7
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.
Python on guile v1.2.3.6
Hi, This is an interesting release as I'm starting to get the cpython's unit tests to work. Still remains a lot of work but much more is now working according to the CPython standard. Next up is getting all unit tests for the test framework to pass. Then to get as much as possible of the CPython unit tests working for generally. Thanks Stefan
Re: Python on guile v1.2.3
Stefan Israelsson Tampe writes: > done, all now have tags 1.2.3 Incredible response time, thanks! :-) I have not been able to build stis-parser, because slask.scm is missing: https://gitlab.com/tampe/stis-parser/-/issues/2 Is it a bug, or am I doing something wrong? Thanks, Marius
Re: Python on guile v1.2.3
done, all now have tags 1.2.3 On Tue, Jun 23, 2020 at 2:54 PM Marius Bakke wrote: > Stefan Israelsson Tampe writes: > > > Hi, > > > > I just tagged a minor release python on guile v1.2.3 that mainly is > > bugfixes an implementation of pythons ctypes ontop of guiles ffi layer. > > Hi, thanks for this work! > > I don't see any tags in this repository: > > https://gitlab.com/python-on-guile/python-on-guile/ > > Perhaps you forgot to 'git push --tags'? > > Can you also tag compatible versions of stis-parser and guile-persist? >
Python on guile v1.2.3
Hi, I just tagged a minor release python on guile v1.2.3 that mainly is bugfixes an implementation of pythons ctypes ontop of guiles ffi layer. Happy Hacking!
python-on-guile 1.2.1
I just released a version of python on guile that I think i much more fast in execution of the attribute lookup than before and also I think that this is one of the more correct versions and decided to freeze it into a release. Not much more feature wise than just speedier and slots implemented. Please use the latest depednecies. Works on guile 2.0,2.2,3.0
Re: Python on guile version 1.2
yes we can compile to module ast
python-on-guile compiles to macros in scheme that can be used without
compiling python from scheme. It targets
good or excellent interoperability between scheme and python
Yes works on guile 3.0. Also you need the most current dependencies see
readme
On Sat, Apr 25, 2020 at 6:27 PM zimoun wrote:
> Dear,
>
> Thank you for this interesting work.
>
>
> On Fri, 10 Apr 2020 at 15:41, Stefan Israelsson Tampe
> wrote:
>
> > I'm pleased to announce python on guile 1.2. This version increases the
> > correctness of the parser as well as adding quite a number of system py
> > files that compiles as an example the we can now generate python ast from
> > the compiler. Also some work to improve speed have been done.
>
> What do you mean by "now generate python AST from the compiler"?
> Do you mean that now python-on-guile can compile the python module
> named ast ('import ast')?
>
>
> > Python on guile is both a python clone and a macro framework where python
> > objects and methods can be used in pure scheme code. There is some
> > significant speed penalty due to this and a perfect match between python
> > modules and guile modules has not been achieved.
>
> Nice!
> If I understand correctly, python-on-guile is a first step similar to
> Hy [1] but using the Guile compiler tower instead of one of the Python
> interpreters, right?
>
> [1] https://docs.hylang.org/en/stable/
>
>
> > Sources (make sure to use the latest dependencies):
> > https://gitlab.com/python-on-guile/python-on-guile
>
> The current version in Guix is 0.1.0-3.00a51a2 using Guile 2.2.
> Does it work on Guile 3?
>
> And are the latest dependencies?
>
>
> All the best,
> simon
>
Re: Python on guile version 1.2
Dear,
Thank you for this interesting work.
On Fri, 10 Apr 2020 at 15:41, Stefan Israelsson Tampe
wrote:
> I'm pleased to announce python on guile 1.2. This version increases the
> correctness of the parser as well as adding quite a number of system py
> files that compiles as an example the we can now generate python ast from
> the compiler. Also some work to improve speed have been done.
What do you mean by "now generate python AST from the compiler"?
Do you mean that now python-on-guile can compile the python module
named ast ('import ast')?
> Python on guile is both a python clone and a macro framework where python
> objects and methods can be used in pure scheme code. There is some
> significant speed penalty due to this and a perfect match between python
> modules and guile modules has not been achieved.
Nice!
If I understand correctly, python-on-guile is a first step similar to
Hy [1] but using the Guile compiler tower instead of one of the Python
interpreters, right?
[1] https://docs.hylang.org/en/stable/
> Sources (make sure to use the latest dependencies):
> https://gitlab.com/python-on-guile/python-on-guile
The current version in Guix is 0.1.0-3.00a51a2 using Guile 2.2.
Does it work on Guile 3?
And are the latest dependencies?
All the best,
simon
Python on guile version 1.2
Hi I'm pleased to announce python on guile 1.2. This version increases the correctness of the parser as well as adding quite a number of system py files that compiles as an example the we can now generate python ast from the compiler. Also some work to improve speed have been done. Python on guile is both a python clone and a macro framework where python objects and methods can be used in pure scheme code. There is some significant speed penalty due to this and a perfect match between python modules and guile modules has not been achieved. On the todo is to test the python modules as much as I can and with time add more modules. The next modules to add is see if we can get the cpythons ffi framework to be ported to guile as well as porting the zip modules. Sources (make sure to use the latest dependencies): https://gitlab.com/python-on-guile/python-on-guile Happy hacking!
Re: Python on guile
Stefan Israelsson Tampe writes: > Now in corona times I'm working quite a lot with python-on-guile fixing > bugs in the parser and compiler. Trying to add and test more python > modules. My test case is to get IPython running on python on guile. You’re awesome! Thank you! It sounds like the time could be coming to actually test the speed. Maybe you can look into the pypy benchmarks for that: https://speed.python.org/ https://speed.python.org/about/ — with link to the code Those would give the first truly comparable test of the speed of Guile vs. a non-Scheme — and a practical path into improving performance based on higher level usage patterns. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
Python on guile
Hi all, Now in corona times I'm working quite a lot with python-on-guile fixing bugs in the parser and compiler. Trying to add and test more python modules. My test case is to get IPython running on python on guile. Some of the python library code is very advanced python so getting it working is a great test case. My latest addition is to generate AST from python code. I have an AST of my own but the translation is quite transparent. I also managed to get the python typing.py module compiling and running. That was quite a challenge as it is quite a lot af meta programming that was hard to get working. I also have been working hard to get autocompilation of python code working for guile 3.0.0 and are quite happy now with it. I also sielenced a lot of variable warnings that was wrong. So no usually those warnings are spot on and very helpful. I will continue to work on getting better feedback in the compiler to detect errors. I also want to see if I can do anything with the ctypes package as well. I think the gule ffi is comparable to ctypes. Else I will continue to see what I can do with the ipython package. Happy Hacking
Re: python-on-guile
Thanks for the work! I appreciate it! On Sat, Jun 15, 2019 at 3:05 AM Stefan Israelsson Tampe wrote: > > python on guile has reached quite far and now compiles a lot of the standard > python code base. The speed has not been of importance. Rather to get good > coopertion between guile scheme and python programs. > > But it also define a scheme interface to the python functionalites and i'm > now trying to compile some documentation of this inteface. You can find docs > at http://www.c-lambda.se/python-on-guile. > > source code is at, > https://gitlab.com/python-on-guile/python-on-guile/ > > This is a work in progress. > > Happy hacking!!
Re: python-on-guile
Stefan Israelsson Tampe writes: > python on guile has reached quite far and now compiles a lot of the > standard python code base. The speed has not been of importance. Rather to > get good coopertion between guile scheme and python programs. That sounds awesome! Thank you for sharing! > https://gitlab.com/python-on-guile/python-on-guile/ > Happy hacking!! Happy Hacking! Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
python-on-guile
python on guile has reached quite far and now compiles a lot of the standard python code base. The speed has not been of importance. Rather to get good coopertion between guile scheme and python programs. But it also define a scheme interface to the python functionalites and i'm now trying to compile some documentation of this inteface. You can find docs at http://www.c-lambda.se/python-on-guile. source code is at, https://gitlab.com/python-on-guile/python-on-guile/ This is a work in progress. Happy hacking!!
Re: python on guile
On Fri, 2014-05-30 at 23:33 +0200, Stefan Israelsson Tampe wrote: I would like to hijack the python2/3 community over to guile. Oh~I could be your accomplice~ ;-P A first step is a parser, it is ontop of guile-log so you might disslike it, but that can be changed later. I've rewritten guile-lua with LALR based on Guile-2.2 backend, and passed several tests. There're few ambiguous conflicts now, but the work is still continuing: https://github.com/NalaGinrut/guile-lua-rebirth/blob/master/language/lua/parser.scm Frankly, I wish I can write it with PEG. The conflicts in LALR drove me mad, PEG would be better, in principle. But I didn't have the chance when I started guile-lua-rebirth. Now we have it in master! Anyway it doesn't matter, I'll use PEG for next language front-end, maybe Ruby, or maybe fix Ecmascript with ES6... I do need to develop the guile-log parser framework further so it is logical to use it because of that. This means that currently none but me probably can use it atm but that will change. I'm very pleased with how the functional parser framework works. Currently it is in hefty development and I can't parse much python code, but that will change soon. https://gitorious.org/python-on-guile I confess I'm not a fan of Python, but I do appreciate that you can take it up. Maybe we can share something in frontend, in close future. ;-) Happy hacking! Stay tuned! /Stefan
python on guile
I would like to hijack the python2/3 community over to guile. A first step is a parser, it is ontop of guile-log so you might disslike it, but that can be changed later. I do need to develop the guile-log parser framework further so it is logical to use it because of that. This means that currently none but me probably can use it atm but that will change. I'm very pleased with how the functional parser framework works. Currently it is in hefty development and I can't parse much python code, but that will change soon. https://gitorious.org/python-on-guile Stay tuned! /Stefan
