From niko at alum.mit.edu Sun Apr 1 07:48:39 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Sun, 1 Apr 2007 07:48:39 +0200 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: <460D916E.8070008@gmail.com> References: <460D61A7.2060908@gmail.com> <460D916E.8070008@gmail.com> Message-ID: > The last time I checked what java's Hasttable offers and I saw you > can't pass to it custom hashing and equality functions, but maybe > there is a simple way to do it that I don't know. No, there isn't, but it shouldn't be too hard to cook up some kind of Hashtable substitute that uses small wrapper classes to handle that. I think that's what you did for C#, right? Niko From anto.cuni at gmail.com Sun Apr 1 13:46:19 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sun, 01 Apr 2007 13:46:19 +0200 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: References: <460D61A7.2060908@gmail.com> <460D916E.8070008@gmail.com> Message-ID: <460F9B8B.7010106@gmail.com> Niko Matsakis wrote: >> The last time I checked what java's Hasttable offers and I saw you >> can't pass to it custom hashing and equality functions, but maybe >> there is a simple way to do it that I don't know. > > No, there isn't, but it shouldn't be too hard to cook up some kind of > Hashtable substitute that uses small wrapper classes to handle that. I > think that's what you did for C#, right? No, for .NET it was simpler because the standard Dictionary type also accepts an optional class that implements the custom functions, so all I need to do is to create a class for each unique pair of equality and hashing functions (see cli/comparer.py). ciao Anto From lkcl at lkcl.net Mon Apr 2 13:58:09 2007 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 2 Apr 2007 11:58:09 +0000 (UTC) Subject: [pypy-dev] Paul Fernhout wants edit-and-continue in python Message-ID: <7379457735lkcl@lkcl.net> integration with leo - http://leo.sf.net - would be a good start. that would give you the GUI part, and context-sensitive execution. you _might_ have to do something similar to what gcc currently do, which is to hook in to eevvvveerryyything via __blahblah__ functions, for memory access eevveryyyything, in the "profiling". but that shouldn't be too hard (but would result in a performance hit - oh well, can't have everything). execution itself (from leo) could be performed via "yield". ok. you can obtain a list of all variables (global etc.) that a particular function modifies, right? so, before you go into any function, right, you record the previous "state". in fact, you might be able to record "state" on a per-line basis (bit extreme i know) and basically have an "undo" stack yeh. it's very simple. look up how "undo" is implemented, in editors, and then treat all variables like that. then, you can keep a record (using Leo) of which lines were modified, and use that to calculate which bits need JIT recompilation and how far back the "undo" stack you need to roll. in _fact_, and this is going to _really_ blow you away, Leo probably already _has_ an "Undo" capability - and so if you mentally turn things round, by treating "execute 1 function" as an "edit" operation under Leo, then you get what you want, for free!!! ooooo :) of course, if any variables are "volatile" - e.g. in an OS, like cleese, then you're shafted - but that's another story. and, of course, if anything calls out to _non_ python code, then you're equally shafted. in both cases, you can simply throw an exception saying "sorry, you need to run this program from scratch, dude". you stand a better chance of doing this in pypy than the python developers do. they consider it "impossible", because it's too radical a rethink, because they have been trapped, by design, in c-code. l. p.s. leo is in python, in case you hadn't guessed. From paul.degrandis at gmail.com Tue Apr 3 18:45:22 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Tue, 3 Apr 2007 12:45:22 -0400 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: <460F9B8B.7010106@gmail.com> References: <460D61A7.2060908@gmail.com> <460D916E.8070008@gmail.com> <460F9B8B.7010106@gmail.com> Message-ID: <9c0bb8a00704030945u16636af9k700172fa3379c831@mail.gmail.com> Hey guys, (and everyone else) I was working on an autonomic computing project using JDK6, and in the middle decided to switch up to hacking on PyPy and seeing if I could get a semi-functioning JSR-223 bindings by the end of the week. I svn uped, and wanted know if this release has any of the work the at you guys did? If not, let me know, and i'll get working so we can get a JVM translated PyPy Paul On 4/1/07, Antonio Cuni wrote: > > Niko Matsakis wrote: > >> The last time I checked what java's Hasttable offers and I saw you > >> can't pass to it custom hashing and equality functions, but maybe > >> there is a simple way to do it that I don't know. > > > > No, there isn't, but it shouldn't be too hard to cook up some kind of > > Hashtable substitute that uses small wrapper classes to handle that. I > > think that's what you did for C#, right? > > No, for .NET it was simpler because the standard Dictionary type also > accepts an optional class that implements the custom functions, so all I > need to do is to create a class for each unique pair of equality and > hashing functions (see cli/comparer.py). > > ciao Anto > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Tue Apr 3 20:06:21 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 3 Apr 2007 20:06:21 +0200 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: <460F9B8B.7010106@gmail.com> References: <460D61A7.2060908@gmail.com> <460D916E.8070008@gmail.com> <460F9B8B.7010106@gmail.com> Message-ID: <1157E100-0D8F-4AF4-B03A-AF117756E6AA@alum.mit.edu> > No, for .NET it was simpler because the standard Dictionary type > also accepts an optional class that implements the custom > functions, so all I need to do is to create a class for each unique > pair of equality and hashing functions (see cli/comparer.py). So, on a whim I implemented a "RDict" class for the JVM that does the necessary adaptation. (It consists almost entirely of generic type declarations and no actual code ;) I haven't integrated it into the Python code yet, looking to see where best to do that. Are most of the tests for custom dicts in test_objectmodel? Also, why are they called "rdicts" in some places, and "custom dicts" in others? Or is there a distinction I am missing? Niko From niko at alum.mit.edu Wed Apr 4 09:54:21 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 4 Apr 2007 09:54:21 +0200 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: <460D61A7.2060908@gmail.com> References: <460D61A7.2060908@gmail.com> Message-ID: <6E4AD99C-F907-43AC-9DB7-81FFD68BCB81@alum.mit.edu> > Some weeks ago I also tried to translate pypy-jvm; it seems that > the two most important missing features are r_dict and weakrefs. Ok, I implemented r_dicts now and checked it in. Not too much work, actually, ended up fitting fairly naturally into the existing code. I guess I'll look at weakrefs next, though no promises as to when that will be. :) Niko From anto.cuni at gmail.com Wed Apr 4 14:39:21 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 04 Apr 2007 14:39:21 +0200 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: <6E4AD99C-F907-43AC-9DB7-81FFD68BCB81@alum.mit.edu> References: <460D61A7.2060908@gmail.com> <6E4AD99C-F907-43AC-9DB7-81FFD68BCB81@alum.mit.edu> Message-ID: <46139C79.4070403@gmail.com> Niko Matsakis wrote: >> Some weeks ago I also tried to translate pypy-jvm; it seems that the >> two most important missing features are r_dict and weakrefs. > > Ok, I implemented r_dicts now and checked it in. Not too much work, > actually, ended up fitting fairly naturally into the existing code. I Hi Niko! This is very cool! :-) Most of r_dict tests are in test_objectmodel, though you may want to have also a look at rpython/test/test_rconstantdict. About the distinction between r_dict and "custom dict": do you find any place where they are used interchangeably? I would say that r_dict referes so the rpython-level type (objectmodel.r_dict), while "custom dict" should refer to the low level type used by the rtyper (ootype.CustomDict). Also, probably CustomDict would be a better name than RDict for your java class, I guess. > guess I'll look at weakrefs next, though no promises as to when that > will be. :) Adding weakrefs to gencli was very simple: I just needed to map lltypesystem.llmemory.WeakGcAddress to 'System.WeakReference', add the straightforward support for constants to cli/constant.py and add the also straightforward 'cast_ptr_to_weakadr' and 'cast_weakadr_to_ptr' operations in opcodes.py. I don't know for jvm, but I guess it would not be much more complicate. ciao Anto From niko at alum.mit.edu Wed Apr 4 15:05:05 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 4 Apr 2007 15:05:05 +0200 Subject: [pypy-dev] Towards pypy-jvm In-Reply-To: <46139C79.4070403@gmail.com> References: <460D61A7.2060908@gmail.com> <6E4AD99C-F907-43AC-9DB7-81FFD68BCB81@alum.mit.edu> <46139C79.4070403@gmail.com> Message-ID: <2B86C471-9C18-4C9B-A247-9C086590ED06@alum.mit.edu> > Most of r_dict tests are in test_objectmodel, though you may want > to have also a look at rpython/test/test_rconstantdict. Ah, ok. > About the distinction between r_dict and "custom dict": do you find > any place where they are used interchangeably? I guess not. I just wasn't clear if they should be usable interchangeably or not. As it happens, I renamed my Java class to CustomDict anyhow, because it was an implementation of the ootype.CustomDict, so it seemed right. > Adding weakrefs to gencli was very simple: I just needed to map > lltypesystem.llmemory.WeakGcAddress to 'System.WeakReference', add > the straightforward support for constants to cli/constant.py and > add the also straightforward 'cast_ptr_to_weakadr' and > 'cast_weakadr_to_ptr' operations in opcodes.py. > I don't know for jvm, but I guess it would not be much more > complicate. Cool, I'll check it out. Niko From grobinson at goombah.com Thu Apr 5 22:03:25 2007 From: grobinson at goombah.com (Gary Robinson) Date: Thu, 5 Apr 2007 16:03:25 -0400 Subject: [pypy-dev] Releasing the GIL in CPython extensions? Message-ID: <20070405160325173009.ceb4f62f@goombah.com> Hello, In PyPy's facilities for writing a CPython extension, would it be conceivable to have an option to release the CPython GIL when the extension is entered and grab it back upon exit? That would enable multiprocessing and could be extremely useful when the programmer knows he's not going to modifying shared items during the execution of the extension. Thanks, Gary -- Gary Robinson CTO Emergent Music, LLC grobinson at goombah.com 207-942-3463 Company: http://www.goombah.com Blog: http://www.garyrobinson.net From simon at arrowtheory.com Thu Apr 5 22:16:22 2007 From: simon at arrowtheory.com (Simon Burton) Date: Thu, 5 Apr 2007 13:16:22 -0700 Subject: [pypy-dev] Releasing the GIL in CPython extensions? In-Reply-To: <20070405160325173009.ceb4f62f@goombah.com> References: <20070405160325173009.ceb4f62f@goombah.com> Message-ID: <20070405131622.90c68e4f.simon@arrowtheory.com> On Thu, 5 Apr 2007 16:03:25 -0400 Gary Robinson wrote: > > Hello, > > In PyPy's facilities for writing a CPython extension, would it be conceivable to have an option to release the CPython GIL when the extension is entered and grab it back upon exit? It's easy enough to call the PyGIL_ functions manually from rpython.. Simon. From cfbolz at gmx.de Thu Apr 5 22:24:21 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 05 Apr 2007 22:24:21 +0200 Subject: [pypy-dev] Releasing the GIL in CPython extensions? In-Reply-To: <20070405131622.90c68e4f.simon@arrowtheory.com> References: <20070405160325173009.ceb4f62f@goombah.com> <20070405131622.90c68e4f.simon@arrowtheory.com> Message-ID: <46155AF5.6010406@gmx.de> Simon Burton wrote: > On Thu, 5 Apr 2007 16:03:25 -0400 > Gary Robinson wrote: > >> Hello, >> >> In PyPy's facilities for writing a CPython extension, would it be conceivable to have an option to release the CPython GIL when the extension is entered and grab it back upon exit? > > It's easy enough to call the PyGIL_ functions manually from rpython.. That might well be, but that does not release PyPy's GIL when the module is used together with PyPy. Cheers, Carl Friedrich From scott+pypy-dev at scottdial.com Sat Apr 7 00:47:25 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Fri, 06 Apr 2007 18:47:25 -0400 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <4603B1E0.1080200@scottdial.com> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> Message-ID: <4616CDFD.2090005@scottdial.com> Scott Dial wrote: > Maciek Fijalkowski wrote: >>> There is a bug somewhere in the translator.js.test suite >>> >> All places should not do this. Hmm... Could you provide more detailed >> info? Thanks for spotting. > > http://scottdial.com/pypy-dev/translator.js.diff > I'm pinging this because it's still messed up and I even provided the fix :-p Thanks, -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From simon at arrowtheory.com Sat Apr 7 20:56:59 2007 From: simon at arrowtheory.com (Simon Burton) Date: Sat, 7 Apr 2007 11:56:59 -0700 Subject: [pypy-dev] translate.py --jit targetpypystandalone: broken? Message-ID: <20070407115659.6354d8d5.simon@arrowtheory.com> this is not working for me: [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "./translate.py", line 287, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/driver.py", line 711, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/home/simon/site-packages/pypy/translator/tool/taskengine.py", line 112, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/driver.py", line 260, in _do [translation:ERROR] res = func() [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/driver.py", line 365, in task_hintannotate_lltype [translation:ERROR] {OriginFlags(): True}) [translation:ERROR] File "/home/simon/local/pypy/pypy/jit/hintannotator/annotator.py", line 62, in build_types [translation:ERROR] return self.build_graph_types(flowgraph, input_args_hs) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 192, in build_graph_types [translation:ERROR] self.complete() [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 248, in complete [translation:ERROR] self.processblock(graph, block) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 477, in processblock [translation:ERROR] self.flowin(graph, block) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 537, in flowin [translation:ERROR] self.consider_op(block.operations[i]) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 724, in consider_op [translation:ERROR] raise Exception,"unknown op: %r" % op [translation:ERROR] Exception: unknown op: v6855 = cast_ptr_to_int(i_25) [translation:ERROR] Processing block: [translation:ERROR] block at -1 is a Block at some unknown location [translation:ERROR] containing the following operations: [translation:ERROR] v6856 = cast_pointer(i_25) [translation:ERROR] v6855 = cast_ptr_to_int(i_25) [translation:ERROR] v6857 = cast_int_to_uint(v6855) [translation:ERROR] v6858 = getfield(v6856, ('typeptr')) [translation:ERROR] v6859 = getfield(v6858, ('name')) [translation:ERROR] v6860 = getarraysize(v6859) [translation:ERROR] v6861 = int_sub(v6860, (1)) [translation:ERROR] v6862 = direct_call((<* fn mallocstr__Signed>), v6861) [translation:ERROR] v6863 = getfield((<* struct ExcData { exc_type=..., exc_value=... }>), ('exc_type')) [translation:ERROR] v6864 = ptr_iszero(v6863) [translation:ERROR] --end-- [translation] start debugger... > /home/simon/site-packages/pypy/annotation/annrpython.py(724)consider_op() -> raise Exception,"unknown op: %r" % op $ svn info Path: . URL: https://codespeak.net/svn/pypy/dist/pypy Repository Root: https://codespeak.net/svn Repository UUID: fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada Revision: 41953 Node Kind: directory Schedule: normal Last Changed Author: hpk Last Changed Rev: 41916 Last Changed Date: 2007-04-05 09:29:13 -0700 (Thu, 05 Apr 2007) Properties Last Updated: 2006-10-08 12:39:47 -0700 (Sun, 08 Oct 2006) Simon. From simon at arrowtheory.com Mon Apr 9 19:24:23 2007 From: simon at arrowtheory.com (Simon Burton) Date: Mon, 9 Apr 2007 10:24:23 -0700 Subject: [pypy-dev] translate.py --jit targetpypystandalone: broken? In-Reply-To: <20070407115659.6354d8d5.simon@arrowtheory.com> References: <20070407115659.6354d8d5.simon@arrowtheory.com> Message-ID: <20070409102423.908417ec.simon@arrowtheory.com> On another machine: [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "./translate.py", line 287, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/home/simon/site-packages/pypy/translator/driver.py", line 711, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/home/simon/site-packages/pypy/translator/tool/taskengine.py", line 112, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/home/simon/site-packages/pypy/translator/driver.py", line 260, in _do [translation:ERROR] res = func() [translation:ERROR] File "/home/simon/site-packages/pypy/translator/driver.py", line 279, in task_annotate [translation:ERROR] s = annotator.build_types(self.entry_point, self.inputtypes) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 101, in build_types [translation:ERROR] return self.build_graph_types(flowgraph, inputcells, complete_now=complete_now) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 192, in build_graph_types [translation:ERROR] self.complete() [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 248, in complete [translation:ERROR] self.processblock(graph, block) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 477, in processblock [translation:ERROR] self.flowin(graph, block) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 537, in flowin [translation:ERROR] self.consider_op(block.operations[i]) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 744, in consider_op [translation:ERROR] raise_nicer_exception(op, str(graph)) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/annrpython.py", line 741, in consider_op [translation:ERROR] resultcell = consider_meth(*argcells) [translation:ERROR] File "", line 3, in consider_op_getattr [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/unaryop.py", line 519, in getattr [translation:ERROR] attrdef = ins.classdef.find_attribute(attr) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 218, in find_attribute [translation:ERROR] return self.locate_attribute(attr).attrs[attr] [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 213, in locate_attribute [translation:ERROR] self.generalize_attr(attr) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 322, in generalize_attr [translation:ERROR] self._generalize_attr(attr, s_value) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 303, in _generalize_attr [translation:ERROR] newattr.add_constant_source(origin_classdef, source) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 79, in add_constant_source[translation:ERROR] s_value = source.s_get_value(classdef, self.name) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 435, in s_get_value [translation:ERROR] s_value = self.bookkeeper.immutablevalue(v) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 440, in immutablevalue [translation:ERROR] self.see_mutable(x) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 543, in see_mutable [translation:ERROR] clsdef.add_source_for_attribute(attr, source) # can trigger reflowing [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 183, in add_source_for_attribute [translation:ERROR] attrdef.add_constant_source(self, source) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 79, in add_constant_source[translation:ERROR] s_value = source.s_get_value(classdef, self.name) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 435, in s_get_value [translation:ERROR] s_value = self.bookkeeper.immutablevalue(v) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 368, in immutablevalue [translation:ERROR] result.dictdef.generalize_value(self.immutablevalue(ev)) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 440, in immutablevalue [translation:ERROR] self.see_mutable(x) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 543, in see_mutable [translation:ERROR] clsdef.add_source_for_attribute(attr, source) # can trigger reflowing [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 183, in add_source_for_attribute [translation:ERROR] attrdef.add_constant_source(self, source) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 79, in add_constant_source[translation:ERROR] s_value = source.s_get_value(classdef, self.name) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/classdef.py", line 435, in s_get_value [translation:ERROR] s_value = self.bookkeeper.immutablevalue(v) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 368, in immutablevalue [translation:ERROR] result.dictdef.generalize_value(self.immutablevalue(ev)) [translation:ERROR] File "/home/simon/site-packages/pypy/annotation/bookkeeper.py", line 432, in immutablevalue [translation:ERROR] elif hasattr(x, '_freeze_') and x._freeze_(): [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/mixedmodule.py", line 80, in _freeze_ [translation:ERROR] self.getdict() [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/mixedmodule.py", line 74, in getdict [translation:ERROR] w_value = self.get(name) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/mixedmodule.py", line 34, in get [translation:ERROR] w_value = self.getdictvalue_w(space, name) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/baseobjspace.py", line 24, in getdictvalue_w[translation:ERROR] return self.getdictvalue(space, space.wrap(attr)) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/mixedmodule.py", line 54, in getdictvalue [translation:ERROR] w_value = loader(space) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/mixedmodule.py", line 203, in afileloader [translation:ERROR] return app.wget(space, attrname) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/gateway.py", line 769, in wget [translation:ERROR] w_globals = self.getwdict(space) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/gateway.py", line 760, in getwdict [translation:ERROR] return space.fromcache(ApplevelCache).getorbuild(self) [translation:ERROR] File "/home/simon/site-packages/pypy/tool/cache.py", line 43, in getorbuild [translation:ERROR] result = self._build(key) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/baseobjspace.py", line 145, in _build [translation:ERROR] return self.build(key) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/gateway.py", line 820, in build [translation:ERROR] return PyPyCacheDir.build_applevelinterp_dict(app, self.space) [translation:ERROR] File "/home/simon/site-packages/pypy/interpreter/gateway.py", line 874, in build_applevelinterp_dict [translation:ERROR] self.code, self.filename, self.modname) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 1525, in translate_as_module [translation:ERROR] gen.gen_source(tmpname, file=_file) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 1010, in gen_source [translation:ERROR] self.gen_source_temp() [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 1091, in gen_source_temp [translation:ERROR] self.gen_rpyfunction(func) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 1173, in gen_rpyfunction [translation:ERROR] body = list(self.rpyfunction_body(graph, localscope)) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 1391, in rpyfunction_body [translation:ERROR] for line in render_block(block): [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 1313, in render_block [translation:ERROR] for line in self.oper(op, localscope).split("\n"): [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 249, in oper [translation:ERROR] exv = self.expr(v, localscope) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 216, in expr [translation:ERROR] debug=('Constant in the graph of', self.currentfunc)) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 407, in nameof [translation:ERROR] name = meth(obj) [translation:ERROR] File "/home/simon/local/pypy/pypy/translator/geninterplevel.py", line 914, in nameof_type [translation:ERROR] self.currentfunc.__name__ or "*no function at all*")) [translation:ERROR] AssertionError': built-in class not found in typename_mapping while compiling _compile [translation:ERROR] .. v4273 = getattr(self_312, ('w_dict')) [translation:ERROR] .. '(pypy.interpreter.mixedmodule:43)MixedModule.getdictvalue' [translation:ERROR] Processing block: [translation:ERROR] block at 3 is a [translation:ERROR] in (pypy.interpreter.mixedmodule:43)MixedModule.getdictvalue [translation:ERROR] containing the following operations: [translation:ERROR] v4274 = getattr(space_0, ('finditem')) [translation:ERROR] v4273 = getattr(self_312, ('w_dict')) [translation:ERROR] v4275 = simple_call(v4274, v4273, w_name_0) [translation:ERROR] v4276 = getattr(self_312, ('lazy')) [translation:ERROR] v4277 = is_true(v4276) [translation:ERROR] --end-- From micahel at gmail.com Mon Apr 9 19:44:45 2007 From: micahel at gmail.com (Michael Hudson) Date: Mon, 9 Apr 2007 18:44:45 +0100 Subject: [pypy-dev] translate.py --jit targetpypystandalone: broken? In-Reply-To: <20070409102423.908417ec.simon@arrowtheory.com> References: <20070407115659.6354d8d5.simon@arrowtheory.com> <20070409102423.908417ec.simon@arrowtheory.com> Message-ID: On 09/04/07, Simon Burton wrote: > > On another machine: > I think the first problem was caused by Armin's change to add the id of objects to their repr, and it should be shallow enough to fix if you know your way around the hintannotator and the backends and so on to add support for cast_ptr_to_int (should be easy, it's basically a no-op at this level after all). The second one looks like one of those random annotation problems we all love so much :( Cheers, mwh From arigo at tunes.org Tue Apr 10 18:18:34 2007 From: arigo at tunes.org (Armin Rigo) Date: Tue, 10 Apr 2007 18:18:34 +0200 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <4616CDFD.2090005@scottdial.com> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> Message-ID: <20070410161834.GA21559@code0.codespeak.net> Hi Scott, On Fri, Apr 06, 2007 at 06:47:25PM -0400, Scott Dial wrote: > I'm pinging this because it's still messed up and I even provided the > fix :-p Tentatively checked in, though it's not my area of expertise :-) Armin From arigo at tunes.org Tue Apr 10 18:46:05 2007 From: arigo at tunes.org (Armin Rigo) Date: Tue, 10 Apr 2007 18:46:05 +0200 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <20070410161834.GA21559@code0.codespeak.net> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> <20070410161834.GA21559@code0.codespeak.net> Message-ID: <20070410164605.GA22993@code0.codespeak.net> Hi Scott, On Tue, Apr 10, 2007 at 06:18:34PM +0200, Armin Rigo wrote: > On Fri, Apr 06, 2007 at 06:47:25PM -0400, Scott Dial wrote: > > I'm pinging this because it's still messed up and I even provided the > > fix :-p > > Tentatively checked in, though it's not my area of expertise :-) Uh, I just realized that many tests fail after the use_pdb argument is removed, because they try to pass one anyway. Could you provide a more complete patch? Thanks! A bientot, Armin From scott+pypy-dev at scottdial.com Tue Apr 10 21:22:27 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Tue, 10 Apr 2007 15:22:27 -0400 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <20070410164605.GA22993@code0.codespeak.net> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> <20070410161834.GA21559@code0.codespeak.net> <20070410164605.GA22993@code0.codespeak.net> Message-ID: <461BE3F3.3090203@scottdial.com> Armin Rigo wrote: >> Tentatively checked in, though it's not my area of expertise :-) > > Uh, I just realized that many tests fail after the use_pdb argument is > removed, because they try to pass one anyway. Could you provide a more > complete patch? Thanks! > Agh, sorry. I didn't do a thorough search for "use_pdb" before. I think I saw the problem in main and updated test_main to match and (poorly) thought that would be the end of that. This explains why Maciek probably has been sitting on it. After having looked at the other places where "use_pdb" is passsed, there are other instances of functions that take a "use_pdb" optional argument which would have to be dealt with as well. I'm not familiar enough with all the ways those functions are called to say how this should be dealt with. With that said, I'm not feeling like it is my place or that I am qualified to be making the kind of sweeping changes that it would require. And for the time being, I'm not being annoyed by this because the underlying bugs that brought up the pygame windows has been fixed. -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From fijal at genesilico.pl Wed Apr 11 11:26:34 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Wed, 11 Apr 2007 11:26:34 +0200 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <461BE3F3.3090203@scottdial.com> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> <20070410161834.GA21559@code0.codespeak.net> <20070410164605.GA22993@code0.codespeak.net> <461BE3F3.3090203@scottdial.com> Message-ID: <461CA9CA.4000800@genesilico.pl> Scott Dial wrote: > Armin Rigo wrote: > >>> Tentatively checked in, though it's not my area of expertise :-) >>> >> Uh, I just realized that many tests fail after the use_pdb argument is >> removed, because they try to pass one anyway. Could you provide a more >> complete patch? Thanks! >> >> > > Agh, sorry. I didn't do a thorough search for "use_pdb" before. I think > I saw the problem in main and updated test_main to match and (poorly) > thought that would be the end of that. This explains why Maciek probably > has been sitting on it. > > After having looked at the other places where "use_pdb" is passsed, > there are other instances of functions that take a "use_pdb" optional > argument which would have to be dealt with as well. I'm not familiar > enough with all the ways those functions are called to say how this > should be dealt with. > > With that said, I'm not feeling like it is my place or that I am > qualified to be making the kind of sweeping changes that it would > require. And for the time being, I'm not being annoyed by this because > the underlying bugs that brought up the pygame windows has been fixed. > > -Scott > > Sorry, I was a bit out. Will try to take a look at it in few days. I've tried applying your patch, but this didn't work out, so I've dropped the issue, my fault :-) From grobinson at goombah.com Wed Apr 11 14:07:47 2007 From: grobinson at goombah.com (Gary Robinson) Date: Wed, 11 Apr 2007 08:07:47 -0400 Subject: [pypy-dev] Releasing the GIL in CPython extensions? Message-ID: <20070411080747666981.df029092@goombah.com> >> It's easy enough to call the PyGIL_ functions manually from rpython.. > That might well be, but that does not release PyPy's GIL when the module > is used together with PyPy. OK, but overall it sounds like, if one were to write an CPython extension using RPython programming style so that the critical parts are translated to C, one CAN release the CPython GIL and thereby take advantage of multiprocessors for threading. My understanding from the second comment above is that this extension would not have the GIL-releasing ability when the module is used with PyPy. The docs say that the extension-writing ability is beta and that "bugs and rough edges are likely." Are there any estimates as to when it might be fairly stable? Thanks, Gary -- Gary Robinson CTO Emergent Music, LLC grobinson at goombah.com 207-942-3463 Company: http://www.goombah.com Blog: http://www.garyrobinson.net From paul.degrandis at gmail.com Thu Apr 12 13:59:42 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Thu, 12 Apr 2007 07:59:42 -0400 Subject: [pypy-dev] SoC Acceptance! Message-ID: <9c0bb8a00704120459s30b9b30fw33b02bf49696b96f@mail.gmail.com> Hello everyone! I'm on board for Google Summer of Code (and long after). To refresh everyone's memory I'll be pushing the JVM backend forward and creating JSR-223 bindings to allow you to script PyPy in Java applications. Niko polished off dictionaries, leaving weakrefs to be worked on. Antonio is my mentor, whom I'm very happy and honored to work under. I'm really excited to take this portion of PyPy on. I'll be using my work on the project to advance an autonomic computing project I'm working on and collecting empirical data on PyPy's affect on productivity in a research environment. Results from all my work will be published in research papers. I'll be on IRC and AIM all day tomorrow. Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Thu Apr 12 18:29:55 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 12 Apr 2007 12:29:55 -0400 Subject: [pypy-dev] Forward: Dyla 07 Message-ID: Posted on c.l.p., but possibly more relevant here: ------------- Dear colleges, You might want to consider Dyla'07 as a good venue to present your work and your favourite programming language. Regards, Alexandre ************************************************************************** Call for Papers Dyla 2007: 3rd Workshop on Dynamic Languages and Applications July 31, 2007, Berlin (Collocated with ECOOP 2007) http://dyla2007.unibe.ch ************************************************************************** Objective ========= The goal of this workshop is to act as a forum where we can discuss new advances in the conception, implementation and application of object-oriented languages that radically diverge from the statically typed class-based reflectionless doctrine. The goal of the workshop is to discuss new as well as older "forgotten" languages and features in this context. Topics of interest include, but are certainly not limited to: - agents, actors, active object, distribution, concurrency and mobility - delegation, prototypes, mixins - first-class closures, continuations, environments - reflection and meta-programming - (dynamic) aspects for dynamic languages - higher-order objects & messages - ... other exotic dynamic features which you would categorize as OO - multi-paradigm & static/dynamic-marriages - (concurrent/distributed/mobile/aspect) virtual machines - optimisation of dynamic languages - automated reasoning about dynamic languages - "regular" syntactic schemes (cf. S-expressions, Smalltalk, Self) - Smalltalk, Python, Ruby, Scheme, Lisp, Self, ABCL, Prolog, ... - ... any topic relevant in applying and/or supporting dynamic languages. We solicit high-quality submissions on research results and/or experience. Submitted papers must be unpublished and not submitted for publication elsewhere. Submissions should not exceed 10 pages, LNCS format (www.springer.com/lncs). Submission ========== Prospective attendees are requested to submit a position paper or an essay (max 10 pages, references included) on a topic relevant to the workshop to Alexandre Bergel (Alexandre.Bergel at cs.tcd.ie). Submissions are demanded to be in .pdf format and should arrive before May 13, 2007. A selection of the best papers will be made, which will require an extension for an inclusion in a special issue in Electronic Communications of the EASST (eceasst.cs.tu-berlin.de). For this purpose, a new deadline will be set after the workshop. Moreover, Springer publishes a Workshop-Reader (as in the case of previous ECOOPs) which appears after the Conference and which contains Workshop-Reports (written by the organizers) and not the position papers submitted by the participants. Important dates =============== Submission due: May 13, 2007 Notification of Authors: May 31, 2007 ECOOP'07 Early Registration Date: June 15th. Workshop: July 31, 2007 Organisers ========== Alexandre Bergel Wolfgang De Meuter St?phane Ducasse Oscar Nierstrasz Roel Wuyts Program committee ================= Alexandre Bergel (LERO & Trinity College Dublin, Ireland) Johan Brichau (Universit? catholique de Louvain, Belgium) Pascal Costanza (Vrije Universiteit Brussel, Belgium) Wolfgang De Meuter (Vrije Universiteit Brussel, Belgium) St?phane Ducasse (University of Annecy, France) Erik Ernst (University of Aarhus, Denmark) Robert Hirschfeld (Hasso-Plattner-Institut, University of Potsdam, Germany) Oscar Nierstrasz (University of Bern, Switzerland) Matthew Flatt (University of Utah, USA) Dave Thomas (Bedarra Research Labs, Canada) Laurence Tratt (King's College London, UK) Roel Wuyts (IMEC & Universit? Libre de Bruxelles, Belgium) From holger at merlinux.de Thu Apr 12 19:43:16 2007 From: holger at merlinux.de (holger krekel) Date: Thu, 12 Apr 2007 19:43:16 +0200 Subject: [pypy-dev] Forward: Dyla 07 In-Reply-To: References: Message-ID: <20070412174316.GE18225@solar.trillke> Hi Terry, thanks a lot for the pointer! it's indeed highly interesting and as it's also geographically close to my usual living place i'd like to co-work on submitting a PyPy paper - i think we have more than enough fitting material. holger On Thu, Apr 12, 2007 at 12:29 -0400, Terry Reedy wrote: > Posted on c.l.p., but possibly more relevant here: > ------------- > Dear colleges, > > You might want to consider Dyla'07 as a good venue to present your > work and your favourite programming language. > > Regards, > Alexandre > > > ************************************************************************** > Call for Papers > Dyla 2007: 3rd Workshop on Dynamic Languages and Applications > July 31, 2007, Berlin (Collocated with ECOOP 2007) > > http://dyla2007.unibe.ch > ************************************************************************** > > Objective > ========= > > The goal of this workshop is to act as a forum where we can discuss > new advances in the conception, implementation and application of > object-oriented languages that radically diverge from the statically > typed class-based reflectionless doctrine. The goal of the workshop is > to discuss new as well as older "forgotten" languages and features in > this context. Topics of interest include, but are certainly not > limited to: > > - agents, actors, active object, distribution, concurrency and > mobility > - delegation, prototypes, mixins > - first-class closures, continuations, environments > - reflection and meta-programming > - (dynamic) aspects for dynamic languages > - higher-order objects & messages > - ... other exotic dynamic features which you would categorize as > OO > - multi-paradigm & static/dynamic-marriages > - (concurrent/distributed/mobile/aspect) virtual machines > - optimisation of dynamic languages > - automated reasoning about dynamic languages > - "regular" syntactic schemes (cf. S-expressions, Smalltalk, Self) > - Smalltalk, Python, Ruby, Scheme, Lisp, Self, ABCL, Prolog, ... > - ... any topic relevant in applying and/or supporting dynamic > languages. > > We solicit high-quality submissions on research results > and/or experience. Submitted papers must be unpublished > and not submitted for publication elsewhere. Submissions > should not exceed 10 pages, LNCS format (www.springer.com/lncs). > > > Submission > ========== > > Prospective attendees are requested to submit a position paper or an > essay (max 10 pages, references included) on a topic relevant to the > workshop to Alexandre Bergel (Alexandre.Bergel at cs.tcd.ie). Submissions > are demanded to be in .pdf format and should arrive before May 13, > 2007. > > A selection of the best papers will be made, which will require an > extension for an inclusion in a special issue in Electronic > Communications of the EASST (eceasst.cs.tu-berlin.de). For this > purpose, a new deadline will be set after the workshop. > > Moreover, Springer publishes a Workshop-Reader (as in the case of > previous ECOOPs) which appears after the Conference and which contains > Workshop-Reports (written by the organizers) and not the position > papers submitted by the participants. > > > Important dates > =============== > > Submission due: May 13, 2007 > Notification of Authors: May 31, 2007 > ECOOP'07 Early Registration Date: June 15th. > Workshop: July 31, 2007 > > > Organisers > ========== > > Alexandre Bergel > Wolfgang De Meuter > St?phane Ducasse > Oscar Nierstrasz > Roel Wuyts > > > Program committee > ================= > > Alexandre Bergel (LERO & Trinity College Dublin, Ireland) > Johan Brichau (Universit? catholique de Louvain, Belgium) > Pascal Costanza (Vrije Universiteit Brussel, Belgium) > Wolfgang De Meuter (Vrije Universiteit Brussel, Belgium) > St?phane Ducasse (University of Annecy, France) > Erik Ernst (University of Aarhus, Denmark) > Robert Hirschfeld (Hasso-Plattner-Institut, University of > Potsdam, Germany) > Oscar Nierstrasz (University of Bern, Switzerland) > Matthew Flatt (University of Utah, USA) > Dave Thomas (Bedarra Research Labs, Canada) > Laurence Tratt (King's College London, UK) > Roel Wuyts (IMEC & Universit? Libre de Bruxelles, > Belgium) > > > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From anto.cuni at gmail.com Fri Apr 13 11:10:08 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 13 Apr 2007 11:10:08 +0200 Subject: [pypy-dev] SoC Acceptance! In-Reply-To: <9c0bb8a00704120459s30b9b30fw33b02bf49696b96f@mail.gmail.com> References: <9c0bb8a00704120459s30b9b30fw33b02bf49696b96f@mail.gmail.com> Message-ID: <461F48F0.9020105@gmail.com> Paul deGrandis wrote: > Hello everyone! hi Paul! > I'm on board for Google Summer of Code (and long after). To refresh > everyone's memory I'll be pushing the JVM backend forward and creating > JSR-223 bindings to allow you to script PyPy in Java applications. Congratulations! I'm very happy that your application has been accepted, I'm sure I'll be able to do a great job. > Niko polished off dictionaries, leaving weakrefs to be worked on. > Antonio is my mentor, whom I'm very happy and honored to work under. I think that before writing code it would be better to have a good understanding of pypy's architecture. How much do you know of PyPy? Next, you should get an account on codespeak to be able to check your code in; have you already got such an account? > I'm really excited to take this portion of PyPy on. I'll be using my > work on the project to advance an autonomic computing project I'm > working on and collecting empirical data on PyPy's affect on > productivity in a research environment. Results from all my work will > be published in research papers. > > I'll be on IRC and AIM all day tomorrow. Today I'll be on IRC until about 16:00 UTC+2. My nick is - surprisingly enough - antocuni :-). ciao Anto From cfbolz at gmx.de Fri Apr 13 13:22:59 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 13 Apr 2007 13:22:59 +0200 Subject: [pypy-dev] Forward: Dyla 07 In-Reply-To: <20070412174316.GE18225@solar.trillke> References: <20070412174316.GE18225@solar.trillke> Message-ID: <461F6813.1020001@gmx.de> holger krekel wrote: > thanks a lot for the pointer! it's indeed highly > interesting and as it's also geographically close > to my usual living place i'd like to co-work on > submitting a PyPy paper - i think we have more > than enough fitting material. fwiw, I was considering to submit my Prolog paper (or a variation of it) there - but we can do some common planning, not sure whether we should submit two PyPy papers. Cheers, Carl Friedrich From arigo at tunes.org Sat Apr 14 11:05:53 2007 From: arigo at tunes.org (Armin Rigo) Date: Sat, 14 Apr 2007 11:05:53 +0200 Subject: [pypy-dev] Forward: Dyla 07 In-Reply-To: <461F6813.1020001@gmx.de> References: <20070412174316.GE18225@solar.trillke> <461F6813.1020001@gmx.de> Message-ID: <20070414090553.GA20210@code0.codespeak.net> Hi Carl, On Fri, Apr 13, 2007 at 01:22:59PM +0200, Carl Friedrich Bolz wrote: > fwiw, I was considering to submit my Prolog paper (or a variation of it) > there - but we can do some common planning, not sure whether we should > submit two PyPy papers. I think that it's a good place to submit a "core" PyPy paper, and I also think that your Prolog paper is independent enough to not count as another PyPy paper. In fact I'd imagine that if we were "academic enough", at this point, several of us should try to publish several papers independently on several aspects of PyPy... A bientot, Armin. From tjreedy at udel.edu Sun Apr 15 01:21:56 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 14 Apr 2007 19:21:56 -0400 Subject: [pypy-dev] Forward: Dyla 07 References: <20070412174316.GE18225@solar.trillke><461F6813.1020001@gmx.de> <20070414090553.GA20210@code0.codespeak.net> Message-ID: "Armin Rigo" wrote in message news:20070414090553.GA20210 at code0.codespeak.net... | Hi Carl, | | On Fri, Apr 13, 2007 at 01:22:59PM +0200, Carl Friedrich Bolz wrote: | > fwiw, I was considering to submit my Prolog paper (or a variation of it) | > there - but we can do some common planning, not sure whether we should | > submit two PyPy papers. | | I think that it's a good place to submit a "core" PyPy paper, and I also | think that your Prolog paper is independent enough to not count as | another PyPy paper. In fact I'd imagine that if we were "academic | enough", at this point, several of us should try to publish several | papers independently on several aspects of PyPy... For instance, if there is anything innovative in the JIT work, then that might make a nice paper in itself. TJR From amauryfa at gmail.com Mon Apr 16 00:31:32 2007 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Mon, 16 Apr 2007 00:31:32 +0200 Subject: [pypy-dev] Socket module on windows Message-ID: Hello, I finally managed to port the socket module to windows. It is probably incomplete, but at least it translates, and I prove it: > pypy.exe debug: WARNING: library path not found, using compiled-in sys.path Python 2.4.1 (pypy 1.0.0 build 41908) on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import socket >>>> s = socket.socket() >>>> s.connect(('localhost', 80)) >>>> s.send('GET\n\n') 5 >>>> s.recv(100) '>>> I can send a (rough) patch file to anybody who wants to test it... Since my svn account is still active, I will carefully submit my changes step by step, hoping not to break anything: I do not have access to a Unix machine, so I will closely follow the results of the nightly tests. Of course your comments are most welcome... there were some rough parts and I am sure I took the wrong way sometimes. Cheers, -- Amaury Forgeot d'Arc From fijal at genesilico.pl Mon Apr 16 13:35:57 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 16 Apr 2007 13:35:57 +0200 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <4616CDFD.2090005@scottdial.com> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> Message-ID: <46235F9D.4050600@genesilico.pl> Scott Dial wrote: > Scott Dial wrote: >> Maciek Fijalkowski wrote: >>>> There is a bug somewhere in the translator.js.test suite >>>> >>> All places should not do this. Hmm... Could you provide more >>> detailed info? Thanks for spotting. >> >> http://scottdial.com/pypy-dev/translator.js.diff >> > > I'm pinging this because it's still messed up and I even provided the > fix :-p > > Thanks, > -Scott > Ok, I'm coming back to issue. I didn't find on windows status page any failures related to that :-( Could you point me to some? Also seems that examples doesn't work on windows. Bad. From scott+pypy-dev at scottdial.com Tue Apr 17 03:24:22 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Mon, 16 Apr 2007 21:24:22 -0400 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <46235F9D.4050600@genesilico.pl> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> <46235F9D.4050600@genesilico.pl> Message-ID: <462421C6.6010601@scottdial.com> Maciek Fijalkowski wrote: > Ok, I'm coming back to issue. I didn't find on windows status page any > failures related to that :-( > > Could you point me to some? > Also seems that examples doesn't work on windows. Bad. > I've not tried to actually run the examples myself, so I hadn't realized that. With respect to failures, the underlying failures that would cause the need for PDB to run have been corrected. I think it would be silly to introduce an intentionally erroring test case for this purpose, so you'll have to trust me on the logic being broken. The problem as I see it is that configuration parameters are not being passed around in a consistent way. And the logic of rpython2javascript() is to use whatever "use_pdb" says ignoring the "jsconfig" entirely. It would perhaps make enough sense to say that they both have to be True for the debugger to be run. However, I think there is a larger issue here with the reason "use_pdb" needs to exist at all. -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From fijal at genesilico.pl Tue Apr 17 09:54:44 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 17 Apr 2007 09:54:44 +0200 Subject: [pypy-dev] translator.js.test invokes pygame (AKA, yet more annoyances from Scott) In-Reply-To: <462421C6.6010601@scottdial.com> References: <4603A19C.9090908@scottdial.com> <4603A508.9010004@genesilico.pl> <4603B1E0.1080200@scottdial.com> <4616CDFD.2090005@scottdial.com> <46235F9D.4050600@genesilico.pl> <462421C6.6010601@scottdial.com> Message-ID: <46247D44.3020108@genesilico.pl> Scott Dial wrote: > Maciek Fijalkowski wrote: >> Ok, I'm coming back to issue. I didn't find on windows status page >> any failures related to that :-( >> >> Could you point me to some? >> Also seems that examples doesn't work on windows. Bad. >> > > I've not tried to actually run the examples myself, so I hadn't > realized that. With respect to failures, the underlying failures that > would cause the need for PDB to run have been corrected. I think it > would be silly to introduce an intentionally erroring test case for > this purpose, so you'll have to trust me on the logic being broken. > > The problem as I see it is that configuration parameters are not being > passed around in a consistent way. And the logic of > rpython2javascript() is to use whatever "use_pdb" says ignoring the > "jsconfig" entirely. It would perhaps make enough sense to say that > they both have to be True for the debugger to be run. However, I think > there is a larger issue here with the reason "use_pdb" needs to exist > at all. > > -Scott > Ah, I think I got it (finally!). Ok, the idea was to have use_pdb override value in config, to be sure that in some places this config is not used, even though it defines use_pdb=False. I'll try to fix the logic than to use jsconfig.use_pdb in first place and override it. Thanks, Fijal From cfbolz at gmx.de Wed Apr 18 09:57:09 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 18 Apr 2007 09:57:09 +0200 Subject: [pypy-dev] "A Prolog Interpreter in Python" -- bachelor thesis submitted Message-ID: <4625CF55.6000403@gmx.de> Hi all! Yesterday I (finally) submitted my bachelor thesis about the implementation of a Prolog interpreter in Python. If you are interested in looking at it, you can find it here: http://codespeak.net/pypy/extradoc/paper/prolog-in-python.pdf Cheers, Carl Friedrich From radix at twistedmatrix.com Wed Apr 18 10:37:01 2007 From: radix at twistedmatrix.com (Christopher Armstrong) Date: Wed, 18 Apr 2007 09:37:01 +0100 Subject: [pypy-dev] "A Prolog Interpreter in Python" -- bachelor thesis submitted In-Reply-To: <4625CF55.6000403@gmx.de> References: <4625CF55.6000403@gmx.de> Message-ID: <60ed19d40704180137j3f5fa0eu1aa77befa19d14bc@mail.gmail.com> On 4/18/07, Carl Friedrich Bolz wrote: > Yesterday I (finally) submitted my bachelor thesis about the > implementation of a Prolog interpreter in Python. Congratulations! I hope it's well-accepted. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ From jgustak at gmail.com Wed Apr 18 14:21:45 2007 From: jgustak at gmail.com (Jakub Gustak) Date: Wed, 18 Apr 2007 14:21:45 +0200 Subject: [pypy-dev] scheme interpreter Message-ID: I think, it's about time for me to say hello! I am in the game for Google Summer of Code. I will be working on Scheme interpreter/front-end during this summer. Armin Rigo is my mentor. Right now I am doing more research on the subject and getting familiar with PyPy code base. The main issue right now is: How to start with PyPy? In short time we will have discussion on some basic ideas about the interpreter itself. We will probably use #pypy-scheme on IRC, to not to disturb the regular discussions on PyPy development. It is really great opportunity for me to work with you. Best regards, Jakub Gustak From fijal at genesilico.pl Wed Apr 18 18:59:40 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Wed, 18 Apr 2007 18:59:40 +0200 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: Message-ID: <46264E7C.1010006@genesilico.pl> Jakub Gustak wrote: > I think, it's about time for me to say hello! > > I am in the game for Google Summer of Code. I will be working on > Scheme interpreter/front-end during this summer. Armin Rigo is my > mentor. > > Right now I am doing more research on the subject and getting familiar > with PyPy code base. > > The main issue right now is: How to start with PyPy? > http://codespeak.net/pypy/dist/pypy/doc/getting-started.html is a nice place to start. > In short time we will have discussion on some basic ideas about the > interpreter itself. > > We will probably use #pypy-scheme on IRC, to not to disturb the > regular discussions on PyPy development. > I think that using #pypy is a very good place also because there is not too much discussions there right now. I think it makes sense if you sit there and have some overview what's going on. Cheers, fijal From micahel at gmail.com Wed Apr 18 19:08:31 2007 From: micahel at gmail.com (Michael Hudson) Date: Wed, 18 Apr 2007 18:08:31 +0100 Subject: [pypy-dev] scheme interpreter In-Reply-To: <46264E7C.1010006@genesilico.pl> References: <46264E7C.1010006@genesilico.pl> Message-ID: On 18/04/07, Maciek Fijalkowski wrote: > Jakub Gustak wrote: > > We will probably use #pypy-scheme on IRC, to not to disturb the > > regular discussions on PyPy development. > > > I think that using #pypy is a very good place also because there is not > too much discussions there right now. I think it makes sense if you sit > there and have some overview what's going on. I agree. Don't be shy! Cheers, mwh From paul.degrandis at gmail.com Wed Apr 18 20:03:40 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Wed, 18 Apr 2007 14:03:40 -0400 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: <46264E7C.1010006@genesilico.pl> Message-ID: <9c0bb8a00704181103u1a3255d6k2d4218c9aab37de7@mail.gmail.com> As fellow SoCer, I'm going to suggest #pypy as well. Everyone is super helpful and real friendly. I've followed the project for over a year, and never used the IRC channel, I regret that now. Paul On 4/18/07, Michael Hudson wrote: > > On 18/04/07, Maciek Fijalkowski wrote: > > Jakub Gustak wrote: > > > We will probably use #pypy-scheme on IRC, to not to disturb the > > > regular discussions on PyPy development. > > > > > I think that using #pypy is a very good place also because there is not > > too much discussions there right now. I think it makes sense if you sit > > there and have some overview what's going on. > > I agree. Don't be shy! > > Cheers, > mwh > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lac at openend.se Wed Apr 18 20:41:19 2007 From: lac at openend.se (Laura Creighton) Date: Wed, 18 Apr 2007 20:41:19 +0200 Subject: [pypy-dev] scheme interpreter In-Reply-To: Message from "Paul deGrandis" of "Wed, 18 Apr 2007 14:03:40 EDT." <9c0bb8a00704181103u1a3255d6k2d4218c9aab37de7@mail.gmail.com> References: <46264E7C.1010006@genesilico.pl> <9c0bb8a00704181103u1a3255d6k2d4218c9aab37de7@mail.gmail.com> Message-ID: <200704181841.l3IIfJNS001582@theraft.openend.se> I regularly read the logs of #pypy for when I cannot be around. I learn a lot this way. If the interesting discussion starts happening someplace else, I won't learn as much, which I would consider a shame. Laura From lac at openend.se Fri Apr 20 13:10:10 2007 From: lac at openend.se (Laura Creighton) Date: Fri, 20 Apr 2007 13:10:10 +0200 Subject: [pypy-dev] SciPy conference August 14-18 at Caltech Message-ID: <200704201110.l3KBAAjR031705@theraft.openend.se> Anybody here going? Even if we don't make a pypy presentation, we should probably make a poster/hand out. This conference is a likely source of the kind of people who do the sort of algorithmic computing that we can expect to best optimise. It would bt nice to get some speedup figures from them. Laura From jgustak at gmail.com Fri Apr 20 13:10:29 2007 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 20 Apr 2007 13:10:29 +0200 Subject: [pypy-dev] scheme interpreter In-Reply-To: <46264E7C.1010006@genesilico.pl> References: <46264E7C.1010006@genesilico.pl> Message-ID: > > Right now I am doing more research on the subject and getting familiar > > with PyPy code base. > > > > The main issue right now is: How to start with PyPy? > > > http://codespeak.net/pypy/dist/pypy/doc/getting-started.html > is a nice place to start. I have already went through that, and many more documentation. Now I am looking for some guidance how to start writing the interpreter itself, which will fit into the PyPy, and won't repeat effort you have already made. I am studying javascript interpreter and some parts of pyrolog. I can see that a lot of work is done by the pypy.rlib.parsing.ebnfparse. I will focus on that right now. Any links, documentation or literature to help me understand this part? Best regards, Jakub Gustak From santagada at gmail.com Fri Apr 20 14:01:05 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Fri, 20 Apr 2007 09:01:05 -0300 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: <46264E7C.1010006@genesilico.pl> Message-ID: Em 20/04/2007, ?s 08:10, Jakub Gustak escreveu: > I have already went through that, and many more documentation. Now I > am looking for some guidance how to start writing the interpreter > itself, which will fit into the PyPy, and won't repeat effort you have > already made. Basically a pypy interpreter is a python program that can be translated using pypy (which means, it uses rpython and only rpython routines). You can start defining a vm for the language in python trying to remember the limitations of rpython and after a little people can help you to get it rpythonic enough to be translated. to do the translation you will need something like pypy/translator/goal/ targetjsstandalone.py which you can mostly copy (We copied someone elses goal). You can also think about the parser for scheme, as I am doing right now for javascript, and for that you can use rlib/parsing but that is up to you. > > I am studying javascript interpreter and some parts of pyrolog. > I can see that a lot of work is done by the > pypy.rlib.parsing.ebnfparse. > I will focus on that right now. Any links, documentation or literature > to help me understand this part? > pypy.rlib.parsing is the parser generator we are using... it is not that important for the beginning of your work now. Good luck, and you can catch me at irc (my nickname is santagada) > Best regards, > Jakub Gustak > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev -- Leonardo Santagada santagada at gmail.com From cfbolz at gmx.de Fri Apr 20 14:10:59 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 20 Apr 2007 12:10:59 +0000 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: <46264E7C.1010006@genesilico.pl> Message-ID: <348899050704200510s6ce9a925q85dfbc6a7ef4ba51@mail.gmail.com> Hi Jakub! Welcome on board! I will try to co-mentor you a bit during the summer. 2007/4/20, Jakub Gustak : > > > Right now I am doing more research on the subject and getting familiar > > > with PyPy code base. > > > > > > The main issue right now is: How to start with PyPy? > > > > > http://codespeak.net/pypy/dist/pypy/doc/getting-started.html > > is a nice place to start. > > I have already went through that, and many more documentation. Now I > am looking for some guidance how to start writing the interpreter > itself, which will fit into the PyPy, and won't repeat effort you have > already made. To get started with development, you should get a codespeak account. Send a mail to Michael Hudson ( micahel at gmail.com ) with your name, the user name you want and your public ssh key. You should agree on using the MIT license for your code, which is what the rest of PyPy uses. Also you should try to follow the coding guide: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html The Scheme interpreter should probably be put into the pypy/lang/scheme directory. In general you should write test before you start coding using the py.test testing framework: http://codespeak.net/py/dist/test.html You should check in fairly often so that we can see what you're working on and how you are doing and help you if you run into problems. > I am studying javascript interpreter and some parts of pyrolog. > I can see that a lot of work is done by the pypy.rlib.parsing.ebnfparse. > I will focus on that right now. Any links, documentation or literature > to help me understand this part? There are some docs about the parser generator here: http://codespeak.net/pypy/dist/pypy/doc/rlib.html If you have any questions about it you can ask me (on IRC or here), I wrote most of it. It is most certainly not finished, if you run into problems we can think about how to fix it. I guess by default Scheme is not that hard to parse (no clue what happens if macros and other evil things enter the picture). Cheers, Carl Friedrich From cfbolz at gmx.de Fri Apr 20 14:17:44 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 20 Apr 2007 12:17:44 +0000 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: <46264E7C.1010006@genesilico.pl> Message-ID: <348899050704200517t79ad7bcai63ab4a586367d3f1@mail.gmail.com> 2007/4/20, Leonardo Santagada : > > Em 20/04/2007, ?s 08:10, Jakub Gustak escreveu: > > I have already went through that, and many more documentation. Now I > > am looking for some guidance how to start writing the interpreter > > itself, which will fit into the PyPy, and won't repeat effort you have > > already made. > > Basically a pypy interpreter is a python program that can be > translated using pypy (which means, it uses rpython and only rpython > routines). You can start defining a vm for the language in python > trying to remember the limitations of rpython and after a little > people can help you to get it rpythonic enough to be translated. to > do the translation you will need something like pypy/translator/goal/ > targetjsstandalone.py which you can mostly copy (We copied someone > elses goal). You can also think about the parser for scheme, as I am > doing right now for javascript, and for that you can use rlib/parsing > but that is up to you. I think you should not try very hard to to get the interpreter to be RPython in the beginning. Just try to use not too many highly dynamic features and try to concentrate on getting the interpreter do the right thing. > > I am studying javascript interpreter and some parts of pyrolog. > > I can see that a lot of work is done by the > > pypy.rlib.parsing.ebnfparse. > > I will focus on that right now. Any links, documentation or literature > > to help me understand this part? > > > pypy.rlib.parsing is the parser generator we are using... it is not > that important for the beginning of your work now. For scheme it should be easy enough to get a simple but usable parser. Cheers, Carl Friedrich From fijal at genesilico.pl Fri Apr 20 15:47:32 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 20 Apr 2007 15:47:32 +0200 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: <46264E7C.1010006@genesilico.pl> Message-ID: <4628C474.4060403@genesilico.pl> Jakub Gustak wrote: >> > Right now I am doing more research on the subject and getting familiar >> > with PyPy code base. >> > >> > The main issue right now is: How to start with PyPy? >> > >> http://codespeak.net/pypy/dist/pypy/doc/getting-started.html >> is a nice place to start. > > I have already went through that, and many more documentation. Now I > am looking for some guidance how to start writing the interpreter > itself, which will fit into the PyPy, and won't repeat effort you have > already made. > > I am studying javascript interpreter and some parts of pyrolog. > I can see that a lot of work is done by the pypy.rlib.parsing.ebnfparse. > I will focus on that right now. Any links, documentation or literature > to help me understand this part? > > Best regards, > Jakub Gustak > > :ms We can try to organize some kind of mini-sprint in Poland if you like to introduce you. As far as I know you're living in Wroclaw, I'm passing through Wroclaw once in a while, so we can arrange one-two days long coding session if you find it suitable for you. Cheers, fijal From jgustak at gmail.com Fri Apr 20 17:47:29 2007 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 20 Apr 2007 17:47:29 +0200 Subject: [pypy-dev] scheme interpreter In-Reply-To: <4628C474.4060403@genesilico.pl> References: <46264E7C.1010006@genesilico.pl> <4628C474.4060403@genesilico.pl> Message-ID: > We can try to organize some kind of mini-sprint in Poland if you like to > introduce you. As far as I know you're living in Wroclaw, I'm passing > through Wroclaw once in a while, so we can arrange one-two days long > coding session if you find it suitable for you. Well that sounds fun! I (my association) can organize a place to work at my university with network and some desks. We definitively can do this. And by the way, my association is organizing "The 4th Linux Session". It is planned on 26th of May. It is, despite the name, generally about open software, etc. I am planning to give an introduction talk about PyPy. But maybe one of you would like to take over the talk, as long as I am a newbie. Cheers, Jakub Gustak From florian.schulze at gmx.net Fri Apr 20 16:46:06 2007 From: florian.schulze at gmx.net (Florian Schulze) Date: Fri, 20 Apr 2007 16:46:06 +0200 Subject: [pypy-dev] Javascript parser Message-ID: Hi! I read that some people here may work on a javascript parser. I'm also working on one, so I would be really interested in collaboration. Especially with people who have more experience with compiler and interpreter needs. I only have the need up to an AST and generating javascript from that again. I just need some transformations which may get more complicated though. Just contact me, Florian Schulze From lalo.martins at gmail.com Sun Apr 22 08:43:06 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 22 Apr 2007 06:43:06 +0000 (UTC) Subject: [pypy-dev] Embedding pypy Message-ID: Here's an interesting question... how hard would it be to write a C API for embedding the pypy VM in a C or C+ + application? I have an application for which I'm working on Python scripting, but for many reasons it would be interesting to use pypy instead. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lac at openend.se Sun Apr 22 10:07:02 2007 From: lac at openend.se (Laura Creighton) Date: Sun, 22 Apr 2007 10:07:02 +0200 Subject: [pypy-dev] Should we decide to have another seminar in Gbg ... Message-ID: <200704220807.l3M872SH006577@theraft.openend.se> we should remember to invite this person: http://www.cs.lth.se/home/Calle_Lejdfors/ posted here, so we don't lose it. (Plus you might want to read his papers.) Laura From micahel at gmail.com Sun Apr 22 11:57:40 2007 From: micahel at gmail.com (Michael Hudson) Date: Sun, 22 Apr 2007 10:57:40 +0100 Subject: [pypy-dev] Embedding pypy In-Reply-To: References: Message-ID: On 22/04/07, Lalo Martins wrote: > Here's an interesting question... > > how hard would it be to write a C API for embedding the pypy VM in a C or C+ > + application? I have an application for which I'm working on Python > scripting, but for many reasons it would be interesting to use pypy instead. Well, to do it at all would require attacking a small pile of details: teaching the tool chain to build a library rather than an application, supporting multiple entry points (though I guess this bit is somewhat solved by the extcompiler and the js backend, in different ways), ... nothing too impossible though. The fun part would be the integration between the application and the interpreter. If you're happy with just passing strings back and forth (equivalent to Py_RunSimpleString or whatever it's called) that's probably quite easy, but also not very interesting. To provide app-specific modules to Python, to allow Python to call your app which then calls Python again... I dunno, but this sort of thing would probably be quite a lot of work. Cheers, mwh From mauriceling at gmail.com Sun Apr 22 13:07:08 2007 From: mauriceling at gmail.com (Maurice Ling) Date: Sun, 22 Apr 2007 21:07:08 +1000 Subject: [pypy-dev] Who's developing language interpreters in PyPy Message-ID: <462B41DC.4090802@acm.org> Hi, I've been reading up on pypy and is really interested in the idea of implementing X language interpreters in pypy, where X can be any known programming language. Do we have a knowledge of who is developing or interested in which X-to-pypy interpreter so there's no competition nor duplication of work? Personally I have some interests in a few languages that I know, such as R and pascal. Cheers maurice From cfbolz at gmx.de Sun Apr 22 15:16:52 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 22 Apr 2007 15:16:52 +0200 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462B41DC.4090802@acm.org> References: <462B41DC.4090802@acm.org> Message-ID: <348899050704220616g36248a72ua7453479a68dc596@mail.gmail.com> Hi Maurice! 2007/4/22, Maurice Ling : > I've been reading up on pypy and is really interested in the idea of > implementing X language interpreters in pypy, where X can be any known > programming language. > > Do we have a knowledge of who is developing or interested in which > X-to-pypy interpreter so there's no competition nor duplication of work? Short overview: The following interpreters are in the PyPy repository currently (or will be, in the case of Scheme): - Python (various people) - Prolog (me) - JavaScript (Leonardo Santagada) - Scheme (Jakub Gustak, not yet started) In addition, Christopher Armstrong is working on "SafeLisp": https://code.launchpad.net/~subol-hackers/subol/safelisp-rpython > Personally I have some interests in a few languages that I know, such as > R and pascal. I don't really know either of them very well, but I imagine that the problem with R would be that you would have to implement all sorts of numerical functions (which is a lot of effort) or interface to existing C libraries (which is not much fun, since the rctypes are a mess, currently). Cheers, Carl Friedrich From santagada at gmail.com Sun Apr 22 16:04:56 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Sun, 22 Apr 2007 11:04:56 -0300 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462B41DC.4090802@acm.org> References: <462B41DC.4090802@acm.org> Message-ID: <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> Em 22/04/2007, ?s 08:07, Maurice Ling escreveu: > Hi, > > I've been reading up on pypy and is really interested in the idea of > implementing X language interpreters in pypy, where X can be any known > programming language. > Yep it is... but probably more interesting to interpreters... > Do we have a knowledge of who is developing or interested in which > X-to-pypy interpreter so there's no competition nor duplication of > work? > > Personally I have some interests in a few languages that I know, > such as > R and pascal. > Pascal should be easier to do, but you have to tell us exactly what you want. If you are planning to do a pascal compiler it would be the first compiler in pypy. If you are thinking on a pascal interpreter this could be quite easy to do but then you need to have some problem with current pascal compilers that you want to fix. I think this could be used on teaching compilers, as understanding a pascal compiler written in python would be much more comprehensible than a C or pascal one. -- Leonardo Santagada santagada at gmail.com From mauriceling at gmail.com Mon Apr 23 02:24:40 2007 From: mauriceling at gmail.com (Maurice Ling) Date: Mon, 23 Apr 2007 10:24:40 +1000 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> References: <462B41DC.4090802@acm.org> <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> Message-ID: <462BFCC8.60100@acm.org> Thanks Leonardo >> >> Personally I have some interests in a few languages that I know, >> such as >> R and pascal. >> > Pascal should be easier to do, but you have to tell us exactly what > you want. If you are planning to do a pascal compiler it would be the > first compiler in pypy. If you are thinking on a pascal interpreter > this could be quite easy to do but then you need to have some problem > with current pascal compilers that you want to fix. I think this > could be used on teaching compilers, as understanding a pascal > compiler written in python would be much more comprehensible than a C > or pascal one. > I don't actually use Pascal these days but it's just the first programming language I learnt. So it's more like a childhood dish kinda thing, just refuse to let it go completely although I do agree with you that a Pascal compiler written in Python will be more comprehensible than one written in C or Pascal. And it may just seems oxymoronic to think about implementing a C compiler in PyPy. My current langauge kit is Python/C/Java/R/SQL/UML. So I presume there's a bit more interest in R than in pascal and implementing a R interpreter in python will reduce the need for RPy in many cases (I think). Otherwise, I may go on a total tangent and try working on modeling/simulation languages like Modelica/SBML combination or even a UML simulator in RPython, which may be more useful to my future employment. So yes, I'm kinda polling interests here... Any suggestions? Thanks Cheers maurice From santagada at gmail.com Mon Apr 23 02:41:44 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Sun, 22 Apr 2007 21:41:44 -0300 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462BFCC8.60100@acm.org> References: <462B41DC.4090802@acm.org> <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> <462BFCC8.60100@acm.org> Message-ID: Em 22/04/2007, ?s 21:24, Maurice Ling escreveu: > Thanks Leonardo You're welcome > So yes, I'm kinda polling interests here... Any suggestions? If you make an R interpreter using pypy we would probably still need RPy to use R inside python. What you could do is implement Numeric (I don't know how it is called this days, maybe numpy or numarray) in pypy, that probably helps to make python able to do the same kind of work as R is used to today... and maybe even faster :) Just remember implementing Numeric on pypy is going to be kind of hard... in exchange you will probably get your hack skillz up to a demi god level :) Good luck, -- Leonardo Santagada santagada at gmail.com From faassen at startifact.com Mon Apr 23 11:04:26 2007 From: faassen at startifact.com (Martijn Faassen) Date: Mon, 23 Apr 2007 11:04:26 +0200 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: References: <462B41DC.4090802@acm.org> <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> <462BFCC8.60100@acm.org> Message-ID: Leonardo Santagada wrote: > Em 22/04/2007, ?s 21:24, Maurice Ling escreveu: > >> Thanks Leonardo > You're welcome > >> So yes, I'm kinda polling interests here... Any suggestions? > > If you make an R interpreter using pypy we would probably still need > RPy to use R inside python. What you could do is implement Numeric (I > don't know how it is called this days, maybe numpy or numarray) in > pypy, Numpy appears to be the official merger between Numeric and Numarray. In general you'd hope PyPy will eventually grow ways to reuse important bits of C-based Python infrastructure for the implementation of non-Python language. Or can it already do so through rctypes? It sounds a bit odd to use Numeric for the implementation of R that way, but it'd make sense to be able to do so, right? Naturally PyPy wouldn't be able to use its magical optimization abilities on those bits, though. Regards, Martijn From arigo at tunes.org Mon Apr 23 17:56:54 2007 From: arigo at tunes.org (Armin Rigo) Date: Mon, 23 Apr 2007 17:56:54 +0200 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462B41DC.4090802@acm.org> References: <462B41DC.4090802@acm.org> Message-ID: <20070423155654.GA20273@code0.codespeak.net> Hi Maurice, On Sun, Apr 22, 2007 at 09:07:08PM +1000, Maurice Ling wrote: > I've been reading up on pypy and is really interested in the idea of > implementing X language interpreters in pypy, where X can be any known > programming language. In general, the more interesting languages to try to implement with PyPy are dynamic languages. Of course it's possible, and maybe even nice, to write an interpreter for Pascal. It's just that there is a bias towards dynamic languages, both in what RPython supports and in what the translation toolchain can do with it. Well, you can always try to build a dynamically extensible Pascal environment with automatic memory management :-) Which reminds me to mention that a Smalltalk environment would be a nice project in PyPy. A bientot, Armin. From fijal at genesilico.pl Mon Apr 23 20:04:56 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 23 Apr 2007 20:04:56 +0200 Subject: [pypy-dev] scheme interpreter In-Reply-To: References: <46264E7C.1010006@genesilico.pl> <4628C474.4060403@genesilico.pl> Message-ID: <462CF548.9020902@genesilico.pl> Jakub Gustak wrote: >> We can try to organize some kind of mini-sprint in Poland if you like to >> introduce you. As far as I know you're living in Wroclaw, I'm passing >> through Wroclaw once in a while, so we can arrange one-two days long >> coding session if you find it suitable for you. > > Well that sounds fun! > > I (my association) can organize a place to work at my university with > network and some desks. We definitively can do this. > > And by the way, my association is organizing "The 4th Linux Session". > It is planned on 26th of May. It is, despite the name, generally about > open software, etc. I am planning to give an introduction talk about > PyPy. But maybe one of you would like to take over the talk, as long > as I am a newbie. > > Cheers, > Jakub Gustak > > :ms I don't think that actually giving PyPy talk to people who don't know python makes sense. Actually PyPy is not very good first python. Instead, a general python talk would be more productive (and way better understood). From tjreedy at udel.edu Mon Apr 23 21:13:36 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 23 Apr 2007 15:13:36 -0400 Subject: [pypy-dev] Who's developing language interpreters in PyPy References: <462B41DC.4090802@acm.org> <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> <462BFCC8.60100@acm.org> Message-ID: "Martijn Faassen" wrote in message news:f0hsqn$d4b$1 at sea.gmane.org... |Numpy appears to be the official merger between Numeric and Numarray. *is*, insofar as anything is 'official'. |It sounds a bit odd to use Numeric for the implementation of R that way, |but it'd make sense to be able to do so, right? 'R' is both a (statistics/data analisis) language and an interpreter system. (I have not used it but read some some time ago.) The latter, I presume, is implemented in some combination of C and Fortran, as are NumPy and SciPy. I would not be surprised if the R system used some of the same libraries (BLAS, LinPack, FFTPack, etc). So, if the array concepts are compatible, it make perfect sense to me to base an alternate implemention of R the language on NumPy and the R functions that are already in SciPy. The motivation would either be a) proof of concept of PyPy as a general platform for implementing dynamic languages or b) an implementation with value-added for users (free (if R is not yet), open-source (ditto), access to other Python facilities). | Naturally PyPy wouldn't be able to use its magical optimization abilities on those bits Many to most of 'those bits' have been heavily optimized already, which is why to use them. Terry Jan Reedy From simon at arrowtheory.com Mon Apr 23 21:40:11 2007 From: simon at arrowtheory.com (Simon Burton) Date: Mon, 23 Apr 2007 12:40:11 -0700 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: References: <462B41DC.4090802@acm.org> <9BC16641-1752-43D7-A0DB-68EB08CC4BA6@gmail.com> <462BFCC8.60100@acm.org> Message-ID: <20070423124011.a0c2caa2.simon@arrowtheory.com> On Mon, 23 Apr 2007 15:13:36 -0400 "Terry Reedy" wrote: > > | Naturally PyPy wouldn't be able to use its magical optimization abilities > on those bits > > Many to most of 'those bits' have been heavily optimized already, which is > why to use them. > > Terry Jan Reedy Yes, but how about this idea: that we would like to take vector expressions, such as the sum of three arrays, X+Y+Z, and instead of creating a temporary array to house X+Y (and then summing with Z), we sum the elements from all three arrays at once. This kind of calculation is very typical in numpy/R, where temporary arrays are created, transversed then destroyed alot, and the CPU cache overheats, and people become generally unhappy. Last year I had a look at teaching the rtyper to understand numpy expressions (see pypy.rpython.numpy), with the idea of heading in this more intelligent direction. This year i discovered the pypy JIT and had a brain orgasm; it would be very interesting to use (+develop) the JIT towards these cache friendly ideas also. It really makes no sense to reimplement R, i think, UNLESS you can interface with the present R libraries. The big strength of R is it's many many libraries for statistics etc. I don't think it's much of an interesting language in and of itself. Simon. From santagada at gmail.com Tue Apr 24 02:16:19 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Mon, 23 Apr 2007 21:16:19 -0300 Subject: [pypy-dev] New Javascript parser in the works Message-ID: I started development of the javascript parser, based on the pythongrammar.txt file on parsing test dir. The thing is still in its infancy, but I just wanted to say that I am working on it, and would love any help. It is living in users/santagada/newjsparser for now... will move to js when it is at least kind of working. About the parsing lib I have some questions (should be asking cfbolz but I don't seem to find him on irc lately): * ParsingError should print something like lineno: self.lineno+1 collum: self.collum+1 (I know there is a pretty error function, but still) * IGNORE and friends, how do I make then work? * I don't know why when it recognizes something (or I think it should) it just gives me list index out of bounds (I will check what is happening, but if someone know why it would be better). About the grammar: * based on python grammar, so automatic semicolon insertion is OFF. You have optional semicolons at the end of lines though * No regex literals (ahh someday maybe, i'm not really interested in them) * Lot's of work to be done still :) -- Leonardo Santagada santagada at gmail.com From mauriceling at gmail.com Tue Apr 24 02:47:32 2007 From: mauriceling at gmail.com (Maurice Ling) Date: Tue, 24 Apr 2007 10:47:32 +1000 Subject: [pypy-dev] Motivation for re-implementing R (GNU S) in PyPy (perhaps?) Message-ID: <462D53A4.9000708@acm.org> Well, R is free and open sourced. It is based on S and Splus, which the developers decided to close-source after a while (after achieving success). R is also known as GNU S for that matter. IMHO, R itself is a simple language and a relatively simple platform. It is a language that manipulates data but philosophically, it is not a statistical or mathematical language. The R core team seems to adhere to the view that R is a programming language where (by chance and intent) a lot of statistical tools are built on. Hence, most of the statistical libraries for R are written in R. I believe that the entire Bioconductor is written in R. Hence, the motivation for considering implementing or re-implementing R in PyPy is "natively" to bring in the strength of R (huge amounts of statistical libraries and data sets) into Python. I have to admit that my skills in this area (langauage interpreters/compilers) is rather limited to undergraduate level but I'm willing to learn more. So I'm currently reading codes on language interpreters for esoteric languages like BrainFuck simply because they are tiny but provides the relevant concepts. So, anyone like to support the idea of (re-)implementing R on PyPy? I'll need some "emotional" strength to go on this route. Also willing to hear other radical options... Another thing of interest to me is implementing modeling/simulation languages in PyPy as it will help in my future career route but my knowledge of even the simulation languages are rather limited. Please advice and comment. Cheers maurice From santagada at gmail.com Tue Apr 24 04:36:00 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Mon, 23 Apr 2007 23:36:00 -0300 Subject: [pypy-dev] Motivation for re-implementing R (GNU S) in PyPy (perhaps?) In-Reply-To: <462D53A4.9000708@acm.org> References: <462D53A4.9000708@acm.org> Message-ID: <2A1FF07E-73B3-48CA-AB9D-1BBE9B8CEDCF@gmail.com> Em 23/04/2007, ?s 21:47, Maurice Ling escreveu: > Well, R is free and open sourced. It is based on S and Splus, which > the > developers decided to close-source after a while (after achieving > success). R is also known as GNU S for that matter. > > IMHO, R itself is a simple language and a relatively simple > platform. It > is a language that manipulates data but philosophically, it is not a > statistical or mathematical language. The R core team seems to > adhere to > the view that R is a programming language where (by chance and > intent) a > lot of statistical tools are built on. Hence, most of the statistical > libraries for R are written in R. I believe that the entire > Bioconductor > is written in R. > > Hence, the motivation for considering implementing or re- > implementing R > in PyPy is "natively" to bring in the strength of R (huge amounts of > statistical libraries and data sets) into Python. So, if the language is open source, quite simple and the only advantage would be to have huge amounts of libraries... Why not just make a code conversion from R to Numpy + Python, a full featured language, used in a lot more places. Then you can get the libraries and also a bigger comunity. Just remember that making an interpreter of R using pypy will not bring anything to python, as they would be diferent interpreters that just happen to be inplemented on the same platform. It would keep the same distance as R as it is today (implemented in C I suppose) and Python (also made in C if you consider CPython). So I would probably say, do the Numpy work on pypy than make a translator R2Py so you can run your favorite R library on top of your optimized Numpy implementation. > > I have to admit that my skills in this area (langauage > interpreters/compilers) is rather limited to undergraduate level > but I'm > willing to learn more. So I'm currently reading codes on language > interpreters for esoteric languages like BrainFuck simply because they > are tiny but provides the relevant concepts. Mine to, but there is a lot of really brainy people on the project... and they really help (specially if you could go to some sprint) > So, anyone like to support the idea of (re-)implementing R on PyPy? > I'll > need some "emotional" strength to go on this route. Also willing to > hear > other radical options... > > Another thing of interest to me is implementing modeling/simulation > languages in PyPy as it will help in my future career route but my > knowledge of even the simulation languages are rather limited. Making Numpy work as we are saying (making it really optimized and cache friendly) is probably going to help your career even more. > Please advice and comment. > My two cents. -- Leonardo Santagada santagada at gmail.com From mauriceling at gmail.com Tue Apr 24 05:48:26 2007 From: mauriceling at gmail.com (Maurice Ling) Date: Tue, 24 Apr 2007 13:48:26 +1000 Subject: [pypy-dev] Motivation for re-implementing R (GNU S) in PyPy (perhaps?) In-Reply-To: <2A1FF07E-73B3-48CA-AB9D-1BBE9B8CEDCF@gmail.com> References: <462D53A4.9000708@acm.org> <2A1FF07E-73B3-48CA-AB9D-1BBE9B8CEDCF@gmail.com> Message-ID: <462D7E0A.2090209@acm.org> >> Well, R is free and open sourced. It is based on S and Splus, which the >> developers decided to close-source after a while (after achieving >> success). R is also known as GNU S for that matter. >> >> IMHO, R itself is a simple language and a relatively simple >> platform. It >> is a language that manipulates data but philosophically, it is not a >> statistical or mathematical language. The R core team seems to >> adhere to >> the view that R is a programming language where (by chance and >> intent) a >> lot of statistical tools are built on. Hence, most of the statistical >> libraries for R are written in R. I believe that the entire >> Bioconductor >> is written in R. >> >> Hence, the motivation for considering implementing or re- implementing R >> in PyPy is "natively" to bring in the strength of R (huge amounts of >> statistical libraries and data sets) into Python. > > > So, if the language is open source, quite simple and the only > advantage would be to have huge amounts of libraries... Why not just > make a code conversion from R to Numpy + Python, a full featured > language, used in a lot more places. Then you can get the libraries > and also a bigger comunity. This could be a nice idea - make R codes run on Numpy + Python. My line of thought is that since there is an implementation of Numpy (I do not know how complete it is) in PyPy already (pypy/rpython/numpy), implementing a means to get R codes to run in RPython will be just as equally good, since RPython are essentially complete Python programs. Kinda killing 2 birds with a stone, or so. > > Just remember that making an interpreter of R using pypy will not > bring anything to python, as they would be diferent interpreters that > just happen to be inplemented on the same platform. It would keep the > same distance as R as it is today (implemented in C I suppose) and > Python (also made in C if you consider CPython). So I would probably > say, do the Numpy work on pypy than make a translator R2Py so you can > run your favorite R library on top of your optimized Numpy > implementation. I think this line of argument can be made against every language interpreter implemented in PyPy, essentially everything can be interfaced at C. IMHO, what PyPy offers is the language-optimization-platform modularization. This may be loafy goal but sure worth the effort. I am not sure what making an interpreter of X (where X can be any language, such as javascript or prolog) using PyPy will really bring anything to Python than implementing X interpreter directly on Python itself (without using PyPy). Please enlighten me on this. Cheers maurice From rschmitt at medcom-online.de Tue Apr 24 08:52:30 2007 From: rschmitt at medcom-online.de (Robert Schmitt) Date: Tue, 24 Apr 2007 08:52:30 +0200 Subject: [pypy-dev] Who's developing language interpreters in PyPy Message-ID: <462DA92E.2010103@medcom-online.de> > Well, you can always try to build a dynamically extensible Pascal > environment with automatic memory management :-) Pascal? A nice university language for its time, but the type system makes practical use an absurd attempt (cf http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-pascal.html) > Which reminds me to mention that a Smalltalk environment would be a nice > project in PyPy. What about a C/C++ interpreter/compiler, there would be some real benefit if people could transpile C code to python. Plus, there's an existing C interpreter project out there, maybe there is a way to reuse some parts or at least some ideas of it. (This is probably too big a project for one person, but if there's any interest in this I'd be happy to join :-). From cfbolz at gmx.de Tue Apr 24 10:58:19 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 24 Apr 2007 10:58:19 +0200 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462DA92E.2010103@medcom-online.de> References: <462DA92E.2010103@medcom-online.de> Message-ID: <462DC6AB.8070400@gmx.de> Robert Schmitt wrote: > What about a C/C++ interpreter/compiler, there would be some real > benefit if people could transpile C code to python. To be honest, I don't see how a C-to-Python-compiler a) relates to PyPy and b) why it would be useful. What real benefit do you see there? Interfacing to C/C++ code is not that hard in CPython, and PyPy is getting there too. Such a compiler would also be quite hard, since C/C++ allow all sorts of crazy unsafe things, so you would end up doing something like described in the paper "Complete Translation of Unsafe Native Code to Safe Bytecode" by Brian Alliet and Adam Megacz. > Plus, there's an > existing C interpreter project out there, maybe there is a way to > reuse some parts or at least some ideas of it. You mean CINT? Quite crashy, in my experience. Which does not make it a less impressive (but very very crazy) thing :-) From cfbolz at gmx.de Tue Apr 24 10:58:38 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 24 Apr 2007 10:58:38 +0200 Subject: [pypy-dev] New Javascript parser in the works In-Reply-To: References: Message-ID: <462DC6BE.3050207@gmx.de> Hi Leonardo! Leonardo Santagada wrote: > I started development of the javascript parser, based on the > pythongrammar.txt file on parsing test dir. This is the point that does not really make sense to me already. You should base your grammar on the official (Mozilla) one, otherwise you will end up chasing and understanding strange corner cases. Also it makes updating the grammar much easier for future versions of the language. If you don't want to (or can't, for some reason) use the official grammar directly, you should use at least parts of it. > The thing is still in its > infancy, but I just wanted to say that I am working on it, and would > love any help. It is living in users/santagada/newjsparser for now... > will move to js when it is at least kind of working. I looked quickly at the directory, my comment is that you should really write tests. Otherwise you will get regressions when you change the grammar. As you know, PyPy is very strict about untested code, and an untested grammar is not really a good plan either. Also, the tests would have told me what you expect to work, in the current state it is completely worthless to me since I have no clue what should work and what not. > About the parsing lib I have some questions (should be asking cfbolz > but I don't seem to find him on irc lately): Sorry, I am enjoying my free time too much currently and don't want to be online consistently. Mail is fine for such a technical discussion anyway (and it has the additional benefit that I can answer you during this boring lecture I am sitting in now). > * ParsingError should print something like lineno: self.lineno+1 > collum: self.collum+1 (I know there is a pretty error function, but > still) There is no class called ParsingErro and ParseError (which exists) does not have a lineno attribute, so what exactly do you mean? If it is only a cosmetic change, just fix it yourself, I will look at it. Note that the line and column numbers of the parse errors are guesses only, there is no way to pinpoint the exact error location with PEGs. > * IGNORE and friends, how do I make then work? What friends? IGNORE itself is a bit documented, so read the docs (and the tests). The idea is that IGNORE is a regular expression of things that should be ignored in the input (probably comments and whitespace). > * I don't know why when it recognizes something (or I think it > should) it just gives me list index out of bounds (I will check what > is happening, but if someone know why it would be better). Check in a failing test (skipped or not, it's your directory anyway), otherwise I have no clue what you are talking about. > About the grammar: > * based on python grammar, so automatic semicolon insertion is OFF. > You have optional semicolons at the end of lines though > * No regex literals (ahh someday maybe, i'm not really interested in > them) Regex literals will only be possible after refactoring the parser generator, I fear. > * Lot's of work to be done still :) Yip. Cheers, Carl Friedrich From rschmitt at medcom-online.de Tue Apr 24 11:29:59 2007 From: rschmitt at medcom-online.de (Robert Schmitt) Date: Tue, 24 Apr 2007 11:29:59 +0200 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462DC6AB.8070400@gmx.de> References: <462DA92E.2010103@medcom-online.de> <462DC6AB.8070400@gmx.de> Message-ID: <462DCE17.1010005@medcom-online.de> Carl Friedrich Bolz schrieb: > To be honest, I don't see how a C-to-Python-compiler a) relates to PyPy > and b) why it would be useful. What real benefit do you see there? Such a module would not have to be part of pypy, but it could make quite good use of the machinery already in place. > Interfacing to C/C++ code is not that hard in CPython, and PyPy is > getting there too. Such a compiler would also be quite hard, since C/C++ > allow all sorts of crazy unsafe things, so you would end up doing > something like described in the paper "Complete Translation of Unsafe > Native Code to Safe Bytecode" by Brian Alliet and Adam Megacz. There certainly is a way to access python from C/C++ and vice versa, so that is not my concern. But going one step further would be really beneficial: Getting legacy C code to a platform where it can be used, test-infected, and refactored, that would be cool. On the other hand, I totally agree with you that it would be quite a crazy endeavor - then again, what's life without a challenge :-) Taking the approach of the paper would probably be easier than translating the source, but I don't see a benefit unless you use the symbolic intermediate data generated by the compiler so you can generate readable code in the end - or do I misunderstand the pypy architecture, can't you generate rpython output with it? From arigo at tunes.org Tue Apr 24 20:47:01 2007 From: arigo at tunes.org (arigo at tunes.org) Date: Tue, 24 Apr 2007 11:47:01 -0700 Subject: [pypy-dev] EuroPython 2007 - call for refereed papers Message-ID: <20070424184701.GA2267@bespin.org> Hi all, He're a reminder to submit a talk at EuroPython! Like each year, we have both the regular conference (see call at http://indico.cern.ch/conferenceCFA.py?confId=13919) and a somewhat separated Refereed Papers section. Here is the call for the latter. The deadline for both is the 18th of May. ======================================================================== EuroPython 2007 Vilnius, Lithuania 9-11 July Call for Refereed Papers http://www.europython.org/ ======================================================================== EuroPython is the only conference in the Python world that has a properly prestigious peer-reviewed forum for presenting technical and scientific papers. Such papers, with advanced and highly innovative contents, can equally well stem from academic research or industrial research. We think this is an important function for EuroPython, so we are even making some grants available to help people with travel costs. We will be happy to consider papers in subject areas including, but not necessarily limited to, the following: * Python language and implementations * Python modules (in the broadest sense) * Python extensions * Interoperation between Python and other languages / subsystems * Scientific applications of Python * Python in Education * Games * Agile Methodologies and Testing * Social Skills We are looking for Python-related scientific and technical papers of advanced, highly innovative content that present the results of original research (be it of the academic or "industrial research" kind), with proper attention to "state of the art" and previous relevant literature/results (whether such relevant previous literature is itself directly related to Python or not). We do not intend to let the specific subject area block a paper's acceptance, as long as the paper satisfies other requirements: innovative, Python-related, reflecting original research, with proper attention to previous literature. Abstracts ========= Please submit abstracts of no more than 200 words to the refereeing committee. You can send submissions no later than 18 May 2007. We shall inform you whether your paper has been selected and announce the conference schedule on the 25 May 2007. For all details regarding the submission of abstracts, please see the EuroPython website (http://www.europython.org). WARNING: Independently of their topic, all abstracts must be submitted *in the Refereed Papers track* in order to be considered by the refereeing committee! If your abstract is accepted, you must submit your corresponding paper before 29 June 2006. Last-minute changes will be accepted until the start of the conference. You should submit the paper as a PDF file, in A4 format, complete, "stand-alone", and readable on any standards-compliant PDF reader (basically, the paper must include all fonts and figures it uses, rather than using external pointers to them; by default, most PDF-preparation programs typically produce such valid "stand-alone" PDF documents). There are no strict typesetting rules. Refereeing ========== The refereeing committee, selected by Armin Rigo, will examine all abstracts and papers. The committee may consult external experts as it deems fit. Referees may suggest or require certain changes and editing in submissions, and make acceptance conditional on such changes being performed. We expect all papers to reflect the abstract as approved and reserve the right, at our discretion, to reject a paper, despite having accepted the corresponding abstract, if the paper does not substantially correspond to the approved abstract. Presentation ============ The paper must be presented at EuroPython by one or more of the authors. Presentation time will be between half an hour and an hour, including time for questions and answers, depending on each paper's details, and also on the total number of talks approved for presentation. Proceedings =========== We will publish the conference's proceedings in purely electronic form. By presenting a paper, authors agree to give the EuroPython conference non-exclusive rights to publish the paper in electronic forms (including, but not limited to, partial and total publication on web sites and/or such media as CDROM and DVD-ROM), and warrant that the papers are not infringing on the rights of any third parties. Authors retain all other intellectual property rights on their submitted abstracts and papers excepting only this non-exclusive license. Subsidised travel ================= We have funds available to subsidise travel costs for some presenters who would otherwise not be able to attend EuroPython. When submitting your abstract, please indicate if you would need such a subsidy as a precondition of being able to come and present your paper. (Yes, this possibility does exist even if you are coming from outside of Europe. Papers from people in New Zealand who can only come if their travel is subsidised, for example, would be just fine with us...). -+- Armin Rigo From simon at arrowtheory.com Wed Apr 25 00:45:20 2007 From: simon at arrowtheory.com (Simon Burton) Date: Tue, 24 Apr 2007 15:45:20 -0700 Subject: [pypy-dev] Motivation for re-implementing R (GNU S) in PyPy (perhaps?) In-Reply-To: <462D7E0A.2090209@acm.org> References: <462D53A4.9000708@acm.org> <2A1FF07E-73B3-48CA-AB9D-1BBE9B8CEDCF@gmail.com> <462D7E0A.2090209@acm.org> Message-ID: <20070424154520.32faf1ca.simon@arrowtheory.com> On Tue, 24 Apr 2007 13:48:26 +1000 Maurice Ling wrote: > > This could be a nice idea - make R codes run on Numpy + Python. My line > of thought is that since there is an implementation of Numpy (I do not > know how complete it is) in PyPy already (pypy/rpython/numpy), In terms of completeness, we barely scratched the surface. Simon. From simon at arrowtheory.com Wed Apr 25 00:50:29 2007 From: simon at arrowtheory.com (Simon Burton) Date: Tue, 24 Apr 2007 15:50:29 -0700 Subject: [pypy-dev] Who's developing language interpreters in PyPy In-Reply-To: <462DC6AB.8070400@gmx.de> References: <462DA92E.2010103@medcom-online.de> <462DC6AB.8070400@gmx.de> Message-ID: <20070424155029.e785a214.simon@arrowtheory.com> On Tue, 24 Apr 2007 10:58:19 +0200 Carl Friedrich Bolz wrote: > > Robert Schmitt wrote: > > What about a C/C++ interpreter/compiler, there would be some real > > benefit if people could transpile C code to python. > > To be honest, I don't see how a C-to-Python-compiler a) relates to PyPy > and b) why it would be useful. What real benefit do you see there? Being able to run optimisations that include external C libraries. This is what the llvm guys can do with the gcc front end, i believe. hmm, perhaps it then makes sense to build a llvm frontend :) Simon. From santagada at gmail.com Wed Apr 25 05:22:24 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Wed, 25 Apr 2007 00:22:24 -0300 Subject: [pypy-dev] New Javascript parser in the works In-Reply-To: <462DC6BE.3050207@gmx.de> References: <462DC6BE.3050207@gmx.de> Message-ID: <8F8CD746-5748-45C9-BCEA-A22776438E87@gmail.com> Em 24/04/2007, ?s 05:58, Carl Friedrich Bolz escreveu: > Hi Leonardo! > > Leonardo Santagada wrote: >> I started development of the javascript parser, based on the >> pythongrammar.txt file on parsing test dir. > > This is the point that does not really make sense to me already. You > should base your grammar on the official (Mozilla) one, otherwise you > will end up chasing and understanding strange corner cases. Also it > makes updating the grammar much easier for future versions of the > language. If you don't want to (or can't, for some reason) use the > official grammar directly, you should use at least parts of it. I've tried to start, converted the number literals, but somehow they are not working, can you try it and help me to understand how do I find and fix this kind of bugs (i'm a fast learner, antonio showed me how to find then when translating rpython code and now I can find and fix bugs miself). > >> The thing is still in its >> infancy, but I just wanted to say that I am working on it, and would >> love any help. It is living in users/santagada/newjsparser for now... >> will move to js when it is at least kind of working. > > I looked quickly at the directory, my comment is that you should > really > write tests. Otherwise you will get regressions when you change the > grammar. As you know, PyPy is very strict about untested code, and an > untested grammar is not really a good plan either. Also, the tests > would > have told me what you expect to work, in the current state it is > completely worthless to me since I have no clue what should work and > what not. > Done man, now I will be writing tons of tests, I just need to get the first ones to work. They are in test_parser.py >> About the parsing lib I have some questions (should be asking cfbolz >> but I don't seem to find him on irc lately): > > Sorry, I am enjoying my free time too much currently and don't want to > be online consistently. Mail is fine for such a technical discussion > anyway (and it has the additional benefit that I can answer you during > this boring lecture I am sitting in now). perfect. > >> * ParsingError should print something like lineno: self.lineno+1 >> collum: self.collum+1 (I know there is a pretty error function, but >> still) > > There is no class called ParsingErro and ParseError (which exists) > does > not have a lineno attribute, so what exactly do you mean? If it is > only > a cosmetic change, just fix it yourself, I will look at it. Note that > the line and column numbers of the parse errors are guesses only, > there > is no way to pinpoint the exact error location with PEGs. > It has a sourcepos and that has a lineno... but it is all working ok on test_parse.py >> * IGNORE and friends, how do I make then work? > > What friends? IGNORE itself is a bit documented, so read the docs (and > the tests). The idea is that IGNORE is a regular expression of things > that should be ignored in the input (probably comments and > whitespace). > Read the documentation, I think that there is not much point in separating pure regexes from the other actions (at least if I understand correctly in real PEGs there isn't such separations). But I am living with then, and man great docs! >> * I don't know why when it recognizes something (or I think it >> should) it just gives me list index out of bounds (I will check what >> is happening, but if someone know why it would be better). > > Check in a failing test (skipped or not, it's your directory anyway), > otherwise I have no clue what you are talking about. > There is some failing tests now >> About the grammar: >> * based on python grammar, so automatic semicolon insertion is OFF. >> You have optional semicolons at the end of lines though >> * No regex literals (ahh someday maybe, i'm not really interested in >> them) > > Regex literals will only be possible after refactoring the parser > generator, I fear. > I don't like then anyway so thats ok. >> * Lot's of work to be done still :) > > Yip. > > Cheers, > > Carl Friedrich > Thanks and thanks in advance, -- Leonardo Santagada santagada at gmail.com From cfbolz at gmx.de Fri Apr 27 21:36:25 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 27 Apr 2007 21:36:25 +0200 Subject: [pypy-dev] New Javascript parser in the works In-Reply-To: <8F8CD746-5748-45C9-BCEA-A22776438E87@gmail.com> References: <462DC6BE.3050207@gmx.de> <8F8CD746-5748-45C9-BCEA-A22776438E87@gmail.com> Message-ID: <463250B9.4080607@gmx.de> Hi Leonardo! Leonardo Santagada wrote: > Done man, now I will be writing tons of tests, I just need to get the > first ones to work. They are in test_parser.py I just looked at the current state of affairs, and while the grammar seems to be getting more complete, there is still only a couple of tests, and those that are there are failing. Ok, it's your time but I can't say I like this approach. Just looking at the grammar made me note the following problem: Something like the following is wrong: additiveexpression : multiplicativeexpression "+" additiveexpression | multiplicativeexpression "-" additiveexpression | multiplicativeexpression ; The problem is that something like "5 - 3 - 3" with this grammar will give you a parse tree that essentially looks like the following: additiveexpression /|\ / | \ 5 - additiveexpression /|\ / | \ 3 - 3 And evaluating this tree gives 5, instead of the correct -1. Unfortunately solving this is not trivial. In theory the grammar rule should look like this: additiveexpression : additiveexpression "+" multiplicativeexpression | additiveexpression "-" multiplicativeexpression | multiplicativeexpression ; which does not work, since then you have a left recursion, which is not supported. In theory there could be a nice grammar transformer that removes the left recursion for you (which is simple and always possible) together with a nice tree transformer that makes the tree look correctly (which is not so simple). Until then, you can use the following workaround: additiveexpression : multiplicativeexpression "+" >additiveexpression< | multiplicativeexpression "- >additiveexpression< | ; which will lead to a wrong tree originally, but the tranformer will tranform the tree into this: additiveexpression / | | | \ / | | | \ 5 - 3 - 3 which is not as nice, since additiveexpression has more children than only three but at least it's easy to find out what is correct. You have to make sure then that when you transform the tree into the nodes you use for interpretation that you do the right thing then. Oh, another small thing: would you mind not using tabs in the grammar? I know it is not a python file, but somehow the number of spaces per tab is different between your and my editor, so it makes it a bit annoying for me to look at. Do you have local changes? Otherwise I could do a tab-removing checkin. Cheers, Carl Friedrich From cfbolz at gmx.de Fri Apr 27 22:11:27 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 27 Apr 2007 22:11:27 +0200 Subject: [pypy-dev] New Javascript parser in the works In-Reply-To: <463250B9.4080607@gmx.de> References: <462DC6BE.3050207@gmx.de> <8F8CD746-5748-45C9-BCEA-A22776438E87@gmail.com> <463250B9.4080607@gmx.de> Message-ID: <463258EF.5030303@gmx.de> Carl Friedrich Bolz wrote: > Just looking at the grammar made me note the following problem: [snip] hm, now that I found this problem, which grammar are you using exactly? The one at http://www.mozilla.org/js/language/js20/formal/parser-grammar.html gives the rules for addition correctly: AdditiveExpression ==> MultiplicativeExpression | AdditiveExpression + MultiplicativeExpression | AdditiveExpression - MultiplicativeExpression or did you just rewrite it incorrectly? Cheers, Carl Friedrich From santagada at gmail.com Sat Apr 28 02:50:38 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Fri, 27 Apr 2007 21:50:38 -0300 Subject: [pypy-dev] Fwd: New Javascript parser in the works References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> Message-ID: Forgot to send to pypy-dev. And now I commited code that was supposed to do what I wanted with the tests in revision 42384. But the code is ugly, my visitor somehow don't visit everyone it should and I am to sleepy to code. Am I doing things the wrong way or doing what I wanted with the tests that hard? Iniciar mensagem reenviada: > De: Leonardo Santagada > Data: 27 de abril de 2007 19h24min15s GMT-03:00 > Para: Carl Friedrich Bolz > Assunto: Re: [pypy-dev] New Javascript parser in the works > > > Em 27/04/2007, ?s 17:11, Carl Friedrich Bolz escreveu: > >> Carl Friedrich Bolz wrote: >>> Just looking at the grammar made me note the following problem: >> [snip] >> >> hm, now that I found this problem, which grammar are you using >> exactly? The one at >> > the one in the standard, as you sugestd to me... it is at: > http://www.ecma-international.org/publications/standards/Ecma-262.htm > >> http://www.mozilla.org/js/language/js20/formal/parser-grammar.html >> >> gives the rules for addition correctly: >> >> AdditiveExpression ==> >> MultiplicativeExpression >> | AdditiveExpression + MultiplicativeExpression >> | AdditiveExpression - MultiplicativeExpression >> >> or did you just rewrite it incorrectly? >> > > I both rewritten it incorrectly and also there is a problem, if I > put MultiplicativeExpression first like on the standard and in the > mozilla one I get code like 5+4 interpreted as having one > multiplicative expression with 5 and somehow it doesn't consume all > the input and still thinks it is valid. > > The other problem was that I didn't know how to fix it, so I just > did what I could expecting that with some code people would help me > more (this one I got right :). The biggest problem with parsing is > that there is no one using it besides you... at least you help me a > lot so i'm not really complaning. > > About tests I'm having this problem, I want to create generator > tests like some that I have but I would like to do something like > having lots of lines of tests, maybe with comments and maybe > setting what would be the start simbol to try to match it. Also I > would like to be able compare the results doing tests like: > checking the number of a type of node on the tree (eg: 5+5 should > have 2 numeric literals). The perfect thing would be able to print > how the trace of the packratparser, seeing what rules it is > executing. But I really want to have a better testing suite, but > like just failing some test for a reason I do not know or passing a > test but doing things completely wrong is not sufficient for me > now... I will work to make this test tool. > > Now about semicolons, how should I deal with them? in the spec the > grammar doesn't deal with them and in the mozilla one I don't see > how they are doing it also. As we have set that as the parsing > module works today it is not possible to do automatic semicolon > insertion, can we do "forced semicolon presence" as seen on C and > Java? (some lightbulb just lightened up here, maybe I should look > for the grammar of any of those two languages) > > > >> Cheers, >> >> Carl Friedrich > > -- > Leonardo Santagada > santagada at gmail.com > > > -- Leonardo Santagada santagada at gmail.com From anto.cuni at gmail.com Sat Apr 28 14:02:36 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 28 Apr 2007 14:02:36 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> Message-ID: <463337DC.2080503@gmail.com> Hi Niko, hi Paul! Here are some remarks/suggestions about your discussion. I'm also CC-ing pypy-dev, so we can also catch someone else's suggestions, if any :-). > First, there are those things are absolutely necessary to do to get PyPy > to translate: > > 1. weak refs > 2. I don't know what else goes here --- try and see I guess Apart from weak refs, I think the other big feature missing is support for external functions (mostly I/O functions). Unfortunately this part is a bit of a mess: since in the old days pypy's only targets were low-level platforms the I/O model of RPython is modeled after the unix file descriptors. This means that at the moment high level backends need to emulate the fd interface and forward the real work to the native I/O functions: to see how gencli does, look at the ll_os class in translator/cli/src/ll_os.cs. I guess this would be the easiest way also for genjvm, and probably for now we should pick this solution. I know, this it's both ugly and hackish; the good news is that I and Carl did some work towards a better solution: at the moment all the I/O inside the standard interpreter is done using the (interp-level) rlib/streamio.py library, which in turns uses the low-level file descriptor interface; the long-term solution would be to provide an alternative implementation of streamio.py that uses .NET/Java streams and let the backends using that instead of the current one. Finally, let me add another task that I think it's very important: 3. make most of existing tests passing with genjvm Look at cli/test directory: you will find a lot of files that import tests from somewhere else (mostly from rpython/test). genjvm do the same, but a lot of tests are still missing; once you get all those tests passing you can be quite confident (but still not sure, of course) that pypy would translate. Some of the tests in cli/tests are cli-specific or very old and not conforming to the new test framework; here is a list of the tests you should port these tests to jvm: - test_range.py - test_constant.py - test_tuple.py - test_float.py - test_builtin.py - test_int.py - test_exception.py Moreover, there is test_runtest, which test a bit of the gencli test framework itself; if the genjvm test framework is similar to the gencli's one, it could make sense to port this also this one. Niko, what do you think? > New features: > > 1. allow Java code to be invoked (need to look at the CLI work here) > 2. JSR 223 I have to admit that I don't know very much about JSR-223: Paul, could you send me the specification, please? I don't feel like to register to sun's website :-). If I understand correctly the level of integration provided by JSR-223 is simpler/less powerful than the one offered by Jython, right? If this is the case, it could make sense to implement JSR-223 first (also because it's part of Paul's SoC proposal), then try to provide the same level of integration as Jython (or IronPython for the .NET side); for the latter task, I think that some code could be shared between gencli and genjvm. > Internal Changes That "Would Be Nice": > > 1. Estimate the maximum size of the stack, rather than giving some > arbitrary "high" number as we do know. this would also be useful for gencli :-) > 2. Deal with JVM size limits for very large methods and classes. (never > hit those yet but probably will) probably this falls into the "try to translate pypy-jvm and see" task :-). > 3. Find a better way to handle exceptions. One suggestion was not to > map rpython's "Object" to the class Object but rather to an interface. Indeed. Also useful for gencli. > 4. Use protected access modifiers rather than public. Pedronis seems to > think this would be important. I don't see how it could be so important at this point. Am I missing something? > 5. Speed and performance optimizations, similar to those being done for C# let me add another point: 6. once we get pypy-jvm, run Python's regression tests and try to pass as much of them as possible. I personally think that point 6 is more important than point 5 at the beginning. > Of these ideas, I am not sure which are best for a "first project". I > would be happy to handle weakrefs, since it seems like they may be quite > easy for me but time consuming for you, but if you wanted to look into > them, that's fine with me too. Adding support for weakrefs to gencli was a very easy task: just wrap/unwrap the objects into the System.WeakReference when requested. > Antonio, you said you tried to translate PyPy as a whole with the JVM > backend? It seems that is the best way to find the list of things that > need doing, but I haven't done it myself yet. Yes, I tried: after a bit of hacking on the interpreter code I could get rid of weakrefs, but the translations failed on a KeyError inside jvm/database.py, then I gave up. To sum up, I think that priority wise the most important thing to do is to port the remaining tests to genjvm and make them passing: weakrefs and external functions are subtasks of this; then try-fail-fix-try until we get a running pypy-jvm. ciao Anto From fijal at genesilico.pl Sat Apr 28 14:35:07 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sat, 28 Apr 2007 14:35:07 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <463337DC.2080503@gmail.com> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> Message-ID: <46333F7B.4020104@genesilico.pl> Also a note from my side: Would be cool to have config option to turn off weakrefs (and some functionallity provided by them, like subclasses). I trimmed (same as Antonio) weakref from the interpreter and shouldn't be hard and maybe will allow to translate whole pypy on js backend (well, not really sure, but let's see) Cheers, fijal From florian.schulze at gmx.net Sat Apr 28 14:47:19 2007 From: florian.schulze at gmx.net (Florian Schulze) Date: Sat, 28 Apr 2007 14:47:19 +0200 Subject: [pypy-dev] Fwd: New Javascript parser in the works References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> Message-ID: On Sat, 28 Apr 2007 02:50:38 +0200, Leonardo Santagada wrote: >> Now about semicolons, how should I deal with them? in the spec the >> grammar doesn't deal with them and in the mozilla one I don't see >> how they are doing it also. As we have set that as the parsing >> module works today it is not possible to do automatic semicolon >> insertion, can we do "forced semicolon presence" as seen on C and >> Java? (some lightbulb just lightened up here, maybe I should look >> for the grammar of any of those two languages) This is the biggest and hardest problem about js parsing. The spec does define how to handle it, I'm not sure now how the grammar reflects that though. Looking at C doesn't help, because there it always needs to be present and can't be replaced with newlines. The problem with a js parser is, that newlines aren't really whitespace, just like in python. But the rules are weird, because newlines are only sometimes relevant, not everytime. A js parser which doesn't handle this correctly is in my opinion just wrong. You couldn't parse any real world javascript with it. Regards, Florian Schulze From cfbolz at gmx.de Sat Apr 28 18:22:50 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 28 Apr 2007 18:22:50 +0200 Subject: [pypy-dev] Fwd: New Javascript parser in the works In-Reply-To: References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> Message-ID: <463374DA.6000007@gmx.de> Florian Schulze wrote: > On Sat, 28 Apr 2007 02:50:38 +0200, Leonardo Santagada > wrote: > > >>> Now about semicolons, how should I deal with them? in the spec the >>> grammar doesn't deal with them and in the mozilla one I don't see >>> how they are doing it also. As we have set that as the parsing >>> module works today it is not possible to do automatic semicolon >>> insertion, can we do "forced semicolon presence" as seen on C and >>> Java? (some lightbulb just lightened up here, maybe I should look >>> for the grammar of any of those two languages) > > This is the biggest and hardest problem about js parsing. The spec does > define how to handle it, I'm not sure now how the grammar reflects that > though. Looking at C doesn't help, because there it always needs to be > present and can't be replaced with newlines. The problem with a js parser > is, that newlines aren't really whitespace, just like in python. But the > rules are weird, because newlines are only sometimes relevant, not > everytime. A js parser which doesn't handle this correctly is in my > opinion just wrong. You couldn't parse any real world javascript with it. The part of the spec that describes the automatic semicolon insertion is completely silly, in my opinion. It goes something like this: When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true: ... This is completely crazy, because it effectively forces you to write a parser using a left-to-right parsing technique and also a parser that works by doing exactly one token lookahead. The second part is what makes packrat parsing fail, since it uses arbitrary many tokens lookahead, so you cannot really determine what an "offending token" is since you cannot distinguish it from normal backtracking. I don't see how you can fix that, really. Now you have basically two choices: you can change force all semicolons to be inserted, which makes most code out there not parse. The other one is more brainstormy-like, it does not work as I describe but maybe someone has an idea to get it to work: you could change the grammar to be very lenient with semicolons (at least for a packrat parser this might be easy) meaning that it will programs as valid that existing Javascript engines will reject. Something like this: a = b c = d would be valid. This opens its own set of problems such as: a = b ++ c Which would most likely be parsed to be equivalent to: a = b++; c; Whereas with the spec it is: a = b; ++c; No clue how to fix that, yet. Cheers, Carl Friedrich From cfbolz at gmx.de Sat Apr 28 18:41:58 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 28 Apr 2007 18:41:58 +0200 Subject: [pypy-dev] Fwd: New Javascript parser in the works In-Reply-To: References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> Message-ID: <46337956.6020409@gmx.de> Florian Schulze wrote: > On Sat, 28 Apr 2007 02:50:38 +0200, Leonardo Santagada > wrote: > > >>> Now about semicolons, how should I deal with them? in the spec the >>> grammar doesn't deal with them and in the mozilla one I don't see >>> how they are doing it also. As we have set that as the parsing >>> module works today it is not possible to do automatic semicolon >>> insertion, can we do "forced semicolon presence" as seen on C and >>> Java? (some lightbulb just lightened up here, maybe I should look >>> for the grammar of any of those two languages) > > This is the biggest and hardest problem about js parsing. The spec does > define how to handle it, I'm not sure now how the grammar reflects that > though. Looking at C doesn't help, because there it always needs to be > present and can't be replaced with newlines. The problem with a js parser > is, that newlines aren't really whitespace, just like in python. But the > rules are weird, because newlines are only sometimes relevant, not > everytime. A js parser which doesn't handle this correctly is in my > opinion just wrong. You couldn't parse any real world javascript with it. The part of the spec that describes the automatic semicolon insertion is completely silly, in my opinion. It goes like this: When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true: ... This is completely crazy, because it effectively forces you to write a parser using a left-to-right parsing technique with exactly one token lookahead, by hand (because a lot of parsing frameworks don't allow you to do the customization that is necessary). The lookahead part is what makes packrat parsing fail, since it uses arbitrary many tokens lookahead, so you cannot really determine what an "offending token" is since you cannot distinguish it from normal backtracking. I don't see how you can fix that, really. Now you have basically two choices: you can force the user to insert all semicolons, which makes most code out there not parse. The other one is more brainstormy-like, it does not work as I describe but maybe someone has an idea to get it to work: you could change the grammar to be very lenient with semicolons (at least for a packrat parser this might be easy) meaning that it will programs as valid that existing Javascript engines will reject. Something like this: a = b c = d would be valid. This opens its own set of problems such as: a = b ++ c Which would most likely be parsed to be equivalent to: a = b++; c; Whereas with the spec it is: a = b; ++c; No clue how to fix that, yet. Maybe you could do something similar to what Python does, inserting newline tokens into the token stream and removing those between matched pairs of parenthesis. Cheers, Carl Friedrich From lac at openend.se Sat Apr 28 18:59:53 2007 From: lac at openend.se (Laura Creighton) Date: Sat, 28 Apr 2007 18:59:53 +0200 Subject: [pypy-dev] Fwd: New Javascript parser in the works In-Reply-To: Message from Carl Friedrich Bolz of "Sat, 28 Apr 2007 18:22:50 +0200." <463374DA.6000007@gmx.de> References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> <463374DA.6000007@gmx.de> Message-ID: <200704281659.l3SGxrCt008735@theraft.openend.se> In a message of Sat, 28 Apr 2007 18:22:50 +0200, Carl Friedrich Bolz writes: >would be valid. This opens its own set of problems such as: > > a = b > ++ c > >Which would most likely be parsed to be equivalent to: > > a = b++; > c; > >Whereas with the spec it is: > > a = b; > ++c; > >No clue how to fix that, yet. > >Cheers, > >Carl Friedrich In the Canadian military for an analagous set of problems we did the following: First of all you do the laxness move -- i.e. you get rid of the semicolon restictions. Then you get a big a sample space of the problem you have as you are willing to deal with. In some way determine that it is 'typical' -- which is a research topic in itself, but if you are not in the field, then the rule is 'make a good guess, refine it later when you are wrong'. Then determine where it is better to stick in the semi based on how the language is actually used. So, should the spec differ from what you do, that is actually of no problem until you find that people really write code like the above and want the spec, not the way you parsed it. You would be surprised at how many of those problems go away because no human ever writes things like that. Should your problem space be dominated by machine-generated code, though, your personal ideas of 'how often will somebody write this' goes out the window. Laura, who thinks that the W3C validation project may be interested in what you are doing and have already got some problematic use cases to worry about. From santagada at gmail.com Sat Apr 28 16:08:46 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 28 Apr 2007 11:08:46 -0300 Subject: [pypy-dev] Fwd: New Javascript parser in the works In-Reply-To: References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> Message-ID: Em 28/04/2007, ?s 09:47, Florian Schulze escreveu: > > This is the biggest and hardest problem about js parsing. The spec > does > define how to handle it, I'm not sure now how the grammar reflects > that > though. Looking at C doesn't help, because there it always needs to be > present and can't be replaced with newlines. The problem with a js > parser > is, that newlines aren't really whitespace, just like in python. > But the > rules are weird, because newlines are only sometimes relevant, not > everytime. A js parser which doesn't handle this correctly is in my > opinion just wrong. You couldn't parse any real world javascript > with it internet exlporer doens't do ASI (automatic semicolon insertion for now own I will call it ASI) properly so for you account it is wrong... If I remember currently all modern javascript frameworks use ES (explicit semicolon) because of diferences in real world parsers. What we can do is provide a tool to put the ; on your legacy code, but that is something that people should be doing anyway so it is not a biggie for me. So I am going with ES for now... when cfbolz and I get some time together to work on making it work then we can try to be exactly to the spec. And the formal grammar doesn't reflect this at all, besides being wrong (there is an errata in the mozilla site that fixes it a bit) and have some parts missing, it completely ignores ASI and the present it as textual information (a very very informal specification). I'm going to focus on making a real test suite for my js parser... if it doesn't drive me crazy I will be back here. > . > > Regards, > Florian Schulze -- Leonardo Santagada santagada at gmail.com From cfbolz at gmx.de Sat Apr 28 19:25:43 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 28 Apr 2007 19:25:43 +0200 Subject: [pypy-dev] Fwd: New Javascript parser in the works In-Reply-To: <200704281659.l3SGxrCt008735@theraft.openend.se> References: <00AC2FE8-875D-419E-A36C-758B38895C28@gmail.com> <463374DA.6000007@gmx.de> <200704281659.l3SGxrCt008735@theraft.openend.se> Message-ID: <46338397.6080402@gmx.de> Laura Creighton wrote: > In a message of Sat, 28 Apr 2007 18:22:50 +0200, Carl Friedrich Bolz writes: >> would be valid. This opens its own set of problems such as: >> >> a = b >> ++ c >> >> Which would most likely be parsed to be equivalent to: >> >> a = b++; >> c; >> >> Whereas with the spec it is: >> >> a = b; >> ++c; >> >> No clue how to fix that, yet. >> >> Cheers, >> >> Carl Friedrich > > > In the Canadian military for an analagous set of problems we did the > following: > > First of all you do the laxness move -- i.e. you get rid of the > semicolon restictions. Then you get a big a sample space of the > problem you have as you are willing to deal with. In some way > determine that it is 'typical' -- which is a research topic in itself, > but if you are not in the field, then the rule is 'make a good guess, > refine it later when you are wrong'. Then determine where it is > better to stick in the semi based on how the language is actually > used. So, should the spec differ from what you do, that is actually > of no problem until you find that people really write code like the > above and want the spec, not the way you parsed it. > Very good points, all. Of course the real plan is to find a behavior that works in most cases and is easy to parse. Afterwards we make our interpreter very successful and people will be forced to comply with the behavior because they want to be compatible, thereby training the JavaScript programmers to write better code :-). > You would be surprised at how many of those problems go away because > no human ever writes things like that. Should your problem space > be dominated by machine-generated code, though, your personal > ideas of 'how often will somebody write this' goes out the window. I think that computer generated code is often more explicit since it has advantages and does not cost too much. Also, fixing a code-generator is easier than fixing handwritten code. Cheers, Carl Friedrich From cfbolz at gmx.de Sat Apr 28 19:56:11 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 28 Apr 2007 19:56:11 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <463337DC.2080503@gmail.com> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> Message-ID: <46338ABB.30808@gmx.de> Antonio Cuni wrote: > Hi Niko, hi Paul! > Here are some remarks/suggestions about your discussion. > I'm also CC-ing pypy-dev, so we can also catch someone else's > suggestions, if any :-). I have one :-). >> First, there are those things are absolutely necessary to do to get PyPy >> to translate: >> >> 1. weak refs >> 2. I don't know what else goes here --- try and see I guess > > Apart from weak refs, I think the other big feature missing is support > for external functions (mostly I/O functions). > Unfortunately this part is a bit of a mess: since in the old days pypy's > only targets were low-level platforms the I/O model of RPython is > modeled after the unix file descriptors. This means that at the moment > high level backends need to emulate the fd interface and forward the > real work to the native I/O functions: to see how gencli does, look at > the ll_os class in translator/cli/src/ll_os.cs. I guess this would be > the easiest way also for genjvm, and probably for now we should pick > this solution. > > I know, this it's both ugly and hackish; the good news is that I and > Carl did some work towards a better solution: at the moment all the I/O > inside the standard interpreter is done using the (interp-level) > rlib/streamio.py library, which in turns uses the low-level file > descriptor interface; the long-term solution would be to provide an > alternative implementation of streamio.py that uses .NET/Java streams > and let the backends using that instead of the current one. I think it is the time now to do away with the file descriptor simulation, it was useful at one point but is very silly now. Instead, a subclass of pypy.rlib.streamio.Stream should be created that only delegates to the Java/.NET Stream classes, probably making use of the facilities for buffering that the platforms offer. I think it is perfectly reasonable to not have os.open and friends on pypy.net as long as file works. If another placeof pypy still uses os.open I am strongly for fixing that. Cheers, Carl Friedrich From arigo at tunes.org Sat Apr 28 20:56:33 2007 From: arigo at tunes.org (Armin Rigo) Date: Sat, 28 Apr 2007 20:56:33 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <46338ABB.30808@gmx.de> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> Message-ID: <20070428185633.GA3734@code0.codespeak.net> Hi Carl, On Sat, Apr 28, 2007 at 07:56:11PM +0200, Carl Friedrich Bolz wrote: > If another placeof pypy still uses os.open I am strongly > for fixing that. There is the app-level os.open(), which of course uses the interp-level os.open(). It means that if a backend only supports streamio, we can't easily provide the low-level os functions at app-level. This is probably fine, though: I think that Jython doesn't have them at all, for example. (Also, I guess that someone in a reverse-hacking mood could rewrite the interp-level code implementing os.open() to use streamio if necessary...) A bientot, Armin. From cfbolz at gmx.de Sat Apr 28 21:02:55 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 28 Apr 2007 21:02:55 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <20070428185633.GA3734@code0.codespeak.net> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <20070428185633.GA3734@code0.codespeak.net> Message-ID: <46339A5F.4060408@gmx.de> Hi Armin! Armin Rigo wrote: > On Sat, Apr 28, 2007 at 07:56:11PM +0200, Carl Friedrich Bolz wrote: >> If another placeof pypy still uses os.open I am strongly >> for fixing that. > > There is the app-level os.open(), which of course uses the interp-level > os.open(). It means that if a backend only supports streamio, we can't > easily provide the low-level os functions at app-level. This is > probably fine, though: I think that Jython doesn't have them at all, for > example. (Also, I guess that someone in a reverse-hacking mood could > rewrite the interp-level code implementing os.open() to use streamio if > necessary...) That's more or less exactly what I meant by the following: "I think it is perfectly reasonable to not have os.open and friends on pypy.net as long as file works. If another placeof pypy still uses os.open I am strongly for fixing that." But it was probably confusing, because it mixed the applevel os.open (first occurrence) with the interplevel os.oppen (second occurrence). Thanks for clarifying. Cheers, Carl Friedrich From fijal at genesilico.pl Sat Apr 28 21:14:57 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sat, 28 Apr 2007 21:14:57 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <20070428185633.GA3734@code0.codespeak.net> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <20070428185633.GA3734@code0.codespeak.net> Message-ID: <46339D31.4060902@genesilico.pl> Armin Rigo wrote: > Hi Carl, > > On Sat, Apr 28, 2007 at 07:56:11PM +0200, Carl Friedrich Bolz wrote: > >> If another placeof pypy still uses os.open I am strongly >> for fixing that. >> > > There is the app-level os.open(), which of course uses the interp-level > os.open(). It means that if a backend only supports streamio, we can't > easily provide the low-level os functions at app-level. This is > probably fine, though: I think that Jython doesn't have them at all, for > example. (Also, I guess that someone in a reverse-hacking mood could > rewrite the interp-level code implementing os.open() to use streamio if > necessary... That includes os.dup and few others (I can imagine implementing os.dup using streamio, but that would be insane reverse-hacking mood). Probably one good step would be to make our tools (mostly py.test) work without applevel os.dup and friends (it uses it in few places, also for capturing, but that's quite shallow and capturing can be even tuned with options). From anto.cuni at gmail.com Sun Apr 29 10:58:18 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sun, 29 Apr 2007 10:58:18 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <46338ABB.30808@gmx.de> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> Message-ID: <46345E2A.2080103@gmail.com> Carl Friedrich Bolz wrote: > I think it is the time now to do away with the file descriptor > simulation, it was useful at one point but is very silly now. Instead, a > subclass of pypy.rlib.streamio.Stream should be created that only > delegates to the Java/.NET Stream classes, probably making use of the > facilities for buffering that the platforms offer. I think it is > perfectly reasonable to not have os.open and friends on pypy.net as long > as file works. If another placeof pypy still uses os.open I am strongly > for fixing that. I agree, and this is why I mentioned the problem :-). I think there are two ways to make it working: 1) write a dummy CliFile (or JvmFile) subclass of stream, then special-case that class in the backend to map directly to System.Io.FileStream (or the Java equivalent) 2) make CliFile or JvmFile real classes, using the interpret-level bindings to forward the methods; then, we should modify open_file_as_stream and construct_stream_tower to instantiate these classes instead of the standard ones. In both cases I also think it's not trivial to get all the combination of mode/options working, because .NET uses a slightly different set of options than posix to determine how to open a file (I don't know about Java). I think that solution (2) is easier to implement and more readable, but so far it's possible only for gencli because genjvm doens't provide interp-level bindings to java libraries. By contrast Solution (1) is not trivial to implement if the interfaces of our Stream class and the Java's one are very different. Maybe a better solution would be to map the dummy streamio.JvmFile to a class written in Java doing the necessary conversions and forwarding to the native stream class. About the app-level os.* functions; I also think that for now we could simply omit them, but in the long term we should write an alternative implementation based on streamio (IronPython does it in a similar way). ciao Anto From anto.cuni at gmail.com Sun Apr 29 11:00:05 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sun, 29 Apr 2007 11:00:05 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <46339D31.4060902@genesilico.pl> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <20070428185633.GA3734@code0.codespeak.net> <46339D31.4060902@genesilico.pl> Message-ID: <46345E95.7090004@gmail.com> Maciek Fijalkowski wrote: > Probably one good step would be to make our tools (mostly py.test) work > without applevel os.dup and friends (it uses it in few places, also for > capturing, but that's quite shallow and capturing can be even tuned with > options). +1 (and maybe add a new --noposix option that turns off all those features when running on a platform != posix) From cfbolz at gmx.de Sun Apr 29 12:34:15 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 29 Apr 2007 12:34:15 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <46345E2A.2080103@gmail.com> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <46345E2A.2080103@gmail.com> Message-ID: <463474A7.7050607@gmx.de> Hi Anto! Antonio Cuni wrote: > I agree, and this is why I mentioned the problem :-). > > I think there are two ways to make it working: > > 1) write a dummy CliFile (or JvmFile) subclass of stream, then > special-case that class in the backend to map directly to > System.Io.FileStream (or the Java equivalent) > > 2) make CliFile or JvmFile real classes, using the interpret-level > bindings to forward the methods; This is indeed the solution that I had in mind. Of course I forgot that there are no interpreter-level bindings for Java yet, how hard would it be to get them? We will need them anyway later. And writing them might still be less work than writing the file descriptor implementation. > then, we should modify open_file_as_stream and construct_stream_tower to > instantiate these classes instead of the standard ones. The result will be very cool because you can then use rlib.streamio and get good cross-platform behavior. > In both cases I also think it's not trivial to get all the combination > of mode/options working, because .NET uses a slightly different set of > options than posix to determine how to open a file (I don't know about > Java). I don't think it is so bad. If you don't want to map the Python semantics to the .NET ones, you can use the .NET stream only as the lowestone in the stream tower and leave buffering and line endings to the existing code. Or you can find an intermediate solution. > About the app-level os.* functions; I also think that for now we could > simply omit them, but in the long term we should write an alternative > implementation based on streamio (IronPython does it in a similar way). Yes, but this can probably even be done on applevel. Cheers, Carl Friedrich From fijal at genesilico.pl Sun Apr 29 12:02:38 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 29 Apr 2007 12:02:38 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <463474A7.7050607@gmx.de> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <46345E2A.2080103@gmail.com> <463474A7.7050607@gmx.de> Message-ID: <46346D3E.8010601@genesilico.pl> Carl Friedrich Bolz wrote: > Hi Anto! > > Antonio Cuni wrote: > > I agree, and this is why I mentioned the problem :-). > > > > I think there are two ways to make it working: > > > > 1) write a dummy CliFile (or JvmFile) subclass of stream, then > > special-case that class in the backend to map directly to > > System.Io.FileStream (or the Java equivalent) > > > > 2) make CliFile or JvmFile real classes, using the interpret-level > > bindings to forward the methods; > > This is indeed the solution that I had in mind. Of course I forgot that > there are no interpreter-level bindings for Java yet, how hard would it > be to get them? We will need them anyway later. And writing them might > still be less work than writing the file descriptor implementation. > Part of it is a SoC anyway, so I don't think we care in what order SoC is done. (and personally I think it makes sense to provide Java bindings first and than to care about the translation). From anto.cuni at gmail.com Mon Apr 30 10:34:37 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 30 Apr 2007 10:34:37 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <463474A7.7050607@gmx.de> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <46345E2A.2080103@gmail.com> <463474A7.7050607@gmx.de> Message-ID: <4635AA1D.2080704@gmail.com> Carl Friedrich Bolz wrote: > > 2) make CliFile or JvmFile real classes, using the interpret-level > > bindings to forward the methods; > > This is indeed the solution that I had in mind. Of course I forgot that > there are no interpreter-level bindings for Java yet, how hard would it > be to get them? We will need them anyway later. And writing them might > still be less work than writing the file descriptor implementation. The implementation of file descriptor by itself is quite easy, but I agree that in this case the correct solution is to develop java bindings for RPython, which will probably also be useful for next tasks such as JSR-223. Also, java bindings could share (as usual :-)) most of the rtyper code used by the .NET bindings. > > then, we should modify open_file_as_stream and construct_stream_tower to > > instantiate these classes instead of the standard ones. > > The result will be very cool because you can then use rlib.streamio and > get good cross-platform behavior. this would be a big bonus. Going further, how hard would it be to rtype the builtin "file" to use streamio? > I don't think it is so bad. If you don't want to map the Python > semantics to the .NET ones, you can use the .NET stream only as the > lowestone in the stream tower and leave buffering and line endings to > the existing code. Or you can find an intermediate solution. Yes, it makes sense. .NET streams are always buffered when reading, I don't know if/how another layer of buffering could affect performances. Moreover, I think there is no easy way to open a stream in "text" mode: on Windows if you open a text file with the low level stream interface you get "\r\n" at the end of lines, so it might be necessary to insert another layer that does the conversion (the same as I'm doing now in the C# implementation -- see the CRLFTextFile class in cli/srs/ll_os.cs). > > About the app-level os.* functions; I also think that for now we could > > simply omit them, but in the long term we should write an alternative > > implementation based on streamio (IronPython does it in a similar way). > > Yes, but this can probably even be done on applevel. sure, and it would be probably reusable both for cli and jvm! ciao Anto From anto.cuni at gmail.com Mon Apr 30 10:42:43 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 30 Apr 2007 10:42:43 +0200 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <46346D3E.8010601@genesilico.pl> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <46345E2A.2080103@gmail.com> <463474A7.7050607@gmx.de> <46346D3E.8010601@genesilico.pl> Message-ID: <4635AC03.9050107@gmail.com> Maciek Fijalkowski wrote: > Part of it is a SoC anyway, so I don't think we care in what order SoC > is done. (and personally I think it makes sense to provide Java bindings > first and than to care about the translation). Well, strictly speaking java bindings for rpython are not part of Paul's SoC proposal but indeed they are probably the most effective way to implement other features that he promised. Btw, I'm not sure it's a good idea to develop them as the first task in PyPy, because it's not straightforward if you have no experience with the rtyper. My suggestion is to start by porting tests to genjvm and fixing the discovered bugs, because it should be a more newcomer-friendly task; then java-bindings for rpython and I/O layer; finally finally translation of pypy-jvm. Paul, what do you think of this plan? ciao Anto From paul.degrandis at gmail.com Mon Apr 30 13:41:43 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Mon, 30 Apr 2007 07:41:43 -0400 Subject: [pypy-dev] PyPy JVM Backend In-Reply-To: <4635AC03.9050107@gmail.com> References: <0BB159E0-B748-40ED-8D08-B838FB7C4ECA@alum.mit.edu> <463337DC.2080503@gmail.com> <46338ABB.30808@gmx.de> <46345E2A.2080103@gmail.com> <463474A7.7050607@gmx.de> <46346D3E.8010601@genesilico.pl> <4635AC03.9050107@gmail.com> Message-ID: <9c0bb8a00704300441k151f9fe0t8806b8f152200e11@mail.gmail.com> Anto, I think this is a good strategy for me. It'll allow me to put something material to the information I gained from your thesis and gain knowledge that will help me in the long run with PyPy. The tasks for me will be: 1.) Port tests, fix uncovered bugs 2.) Java bindings 3.) I/O layer as discussed on this list 4.) pypy-jvm translation 5.) JSR 223 (The Scripting API) For more information on JSR 223, here's a little tutorial/article: http://www.onjava.com/pub/a/onjava/2006/04/26/mustang-meets-rhino-java-se-6-scripting.html And here are the languages with bindings for it now: https://scripting.dev.java.net/ Regards, Paul On 4/30/07, Antonio Cuni wrote: > > Maciek Fijalkowski wrote: > > > Part of it is a SoC anyway, so I don't think we care in what order SoC > > is done. (and personally I think it makes sense to provide Java bindings > > first and than to care about the translation). > > Well, strictly speaking java bindings for rpython are not part of Paul's > SoC proposal but indeed they are probably the most effective way to > implement other features that he promised. > > Btw, I'm not sure it's a good idea to develop them as the first task in > PyPy, because it's not straightforward if you have no experience with > the rtyper. > > My suggestion is to start by porting tests to genjvm and fixing the > discovered bugs, because it should be a more newcomer-friendly task; > then java-bindings for rpython and I/O layer; finally finally > translation of pypy-jvm. > > Paul, what do you think of this plan? > > ciao Anto > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.degrandis at gmail.com Mon Apr 30 15:45:54 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Mon, 30 Apr 2007 09:45:54 -0400 Subject: [pypy-dev] What about a Slate front-end? Message-ID: <9c0bb8a00704300645p463b04f6vec7a3ca226a3c4a4@mail.gmail.com> Hi all, Not too long ago there was a discussion about possible front-ends. I know someone here is part of the tunes project... so how about a slate front end? There has been recent talk on the slate mailing list about the deficiencies with the current VM and some weird setup and handling of the stack... perhaps pypy is a better setup for the language. Just a thought. Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: