python on guile

python on guile

[Federico Beffa]

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

Hi, I'm a user of python which would very much prefer to use Scheme :-)

I just wanted to say that the reason for which a lot of
engineers/scientists are using python, is because it now provides a
pretty large set of scientific/engineering and plotting functions with
the 3 main libraries numpy, scipy and matplotlib. It would be
fantastic if somehow this functionality could be made available in
guile :-)

Regards,
Federico

Re: python on guile

[Nala Ginrut]

On Sat, 2014-08-09 at 14:58 +0200, Federico Beffa wrote:
> > 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.
> 
> Hi, I'm a user of python which would very much prefer to use Scheme :-)
> 
> I just wanted to say that the reason for which a lot of
> engineers/scientists are using python, is because it now provides a
> pretty large set of scientific/engineering and plotting functions with
> the 3 main libraries numpy, scipy and matplotlib. It would be
> fantastic if somehow this functionality could be made available in
> guile :-)
> 

I agree with you, the popular of Python is largely because of some
popular libs.


I'm one of the guys who is interested in hacking multi-lang front-end on
Guile. And I think there're at least two approaches to cut this Gordian
Knot.

1. Make great effort to be compatible with the original Python, even the
C interfaces(maybe a wrapper or refactor the C part with Guile CAPIs).
And recompile the whole numpy/scipy/matplotlib with guile-python. This
would be the fantastic and idealism way. But challenging.
One of the reasons is whether our brand new CPS-based backend (in master
branch) is suitable for Python language would be suspended. In
principle, it's suitable for FP languages especially continuation-based
one. But it's worth to try anyway.
The difficulty contains both workload and indeterminacy.

2. Write Guile own libs for the same purpose of numpy/scipy/matplotlib,
and users may call the related modules from Python code. I have to
emphasize that any language implemented on Guile could call the modules
written with other languages, if it's on Guile too.
This is also challenging. But IMO, the difficulty of this way contains
workload only.


These are my ideas. And I'd like to try the first way because of my
hacking habit.
But the most significant thing is to make the latest Guile-2.2(in master
branch) better than before. I'm trying to rewrite guile-lua on
Guile-2.2, but it's in a slow progress since there're lot of new stuffs
need to learn.

Any ideas?
 

Best regards.

Re: python on guile

[Jan Wedekind]

Hi,
In the past I have looked at how Python's NumPy and Ruby's NArray are implemented. I then implemented Ruby multiarray (one of the HornetsEye libraries). The point is that ultimately you want a flexible library for umiform arrays with a JIT compiler to match the exressiveness of Guile/Scheme. I am working on something like that at the moment [1]. Any comments and suggestions are welcome.

Jan

[1] https://github.com/wedesoft/aiscm

On August 13, 2014 6:43:09 AM GMT+01:00, Nala Ginrut <nalaginrut@gmail.com> wrote:
>On Sat, 2014-08-09 at 14:58 +0200, Federico Beffa wrote:
>> > 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.
>> 
>> Hi, I'm a user of python which would very much prefer to use Scheme
>:-)
>> 
>> I just wanted to say that the reason for which a lot of
>> engineers/scientists are using python, is because it now provides a
>> pretty large set of scientific/engineering and plotting functions
>with
>> the 3 main libraries numpy, scipy and matplotlib. It would be
>> fantastic if somehow this functionality could be made available in
>> guile :-)
>> 
>
>I agree with you, the popular of Python is largely because of some
>popular libs.
>
>
>I'm one of the guys who is interested in hacking multi-lang front-end
>on
>Guile. And I think there're at least two approaches to cut this Gordian
>Knot.
>
>1. Make great effort to be compatible with the original Python, even
>the
>C interfaces(maybe a wrapper or refactor the C part with Guile CAPIs).
>And recompile the whole numpy/scipy/matplotlib with guile-python. This
>would be the fantastic and idealism way. But challenging.
>One of the reasons is whether our brand new CPS-based backend (in
>master
>branch) is suitable for Python language would be suspended. In
>principle, it's suitable for FP languages especially continuation-based
>one. But it's worth to try anyway.
>The difficulty contains both workload and indeterminacy.
>
>2. Write Guile own libs for the same purpose of numpy/scipy/matplotlib,
>and users may call the related modules from Python code. I have to
>emphasize that any language implemented on Guile could call the modules
>written with other languages, if it's on Guile too.
>This is also challenging. But IMO, the difficulty of this way contains
>workload only.
>
>
>These are my ideas. And I'd like to try the first way because of my
>hacking habit.
>But the most significant thing is to make the latest Guile-2.2(in
>master
>branch) better than before. I'm trying to rewrite guile-lua on
>Guile-2.2, but it's in a slow progress since there're lot of new stuffs
>need to learn.
>
>Any ideas?
> 
>
>Best regards.

-- 
Jan Wedekind
http://www.wedesoft.de/

Python on guile

[Stefan Israelsson Tampe]

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

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

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

Re: Python on guile

[Arne Babenhauserheide]

Stefan Israelsson Tampe <stefan.itampe@gmail.com> 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

[Stefan Israelsson Tampe]

Hi all, there is an ever stream of tickets to fix in the python clone made
in guile. Usually I spend time testing some python submodule and in the
process realizes issues with the current code base. I'm certain that there
is quite a lot of bus still remaining.

My latest addition was the subprocess module, which exersisced the select
code, the os module and a popen like implementation. In the process
glitches in the name spacing was found and fixed for classes. (the name
bounding in clasdefs are a let construct but the decorators can refer to
the variable bindings (methods and assignments). I fixed the try exception
mechanism when one issues a simple (raise). If in a contexts of a error
handler, then the catched exception is resent. previously a simple
Exception with no data was resent. Now most warnings that was spamming the
python session have been quited. quite a lot of bugs have been found in the
os module and fixed.

With this I'm happy with the python on guile repo and just released a
version 1.1

Repo:
https://gitlab.com/python-on-guile/python-on-guile/tree/master

Happy hacking

Re: Python on guile

[Maxim Cournoyer]

Hello Stefan!

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

> Hi all, there is an ever stream of tickets to fix in the python clone made
> in guile. Usually I spend time testing some python submodule and in the
> process realizes issues with the current code base. I'm certain that there
> is quite a lot of bus still remaining.
>
> My latest addition was the subprocess module, which exersisced the select
> code, the os module and a popen like implementation. In the process
> glitches in the name spacing was found and fixed for classes. (the name
> bounding in clasdefs are a let construct but the decorators can refer to
> the variable bindings (methods and assignments). I fixed the try exception
> mechanism when one issues a simple (raise). If in a contexts of a error
> handler, then the catched exception is resent. previously a simple
> Exception with no data was resent. Now most warnings that was spamming the
> python session have been quited. quite a lot of bugs have been found in the
> os module and fixed.
>
> With this I'm happy with the python on guile repo and just released a
> version 1.1
>
> Repo:
> https://gitlab.com/python-on-guile/python-on-guile/tree/master
>
> Happy hacking

Sounds good!  I've yet to try it, but the idea of running Python things
using Guile is really cool to me :-).  I'll try to give it a spin soon.

Cheers,

Maxim

python on guile

[Stefan Israelsson Tampe]

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

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

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

Re: python on guile

[Nala Ginrut]

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