spacepaste

Paste details

reply | raw | toggle line wrapping

  1.  
  2. Wednesday, November 15th, 2017
  4. Load more backlog…
  5. 2:45 PM <ronan> cfbolz: yeah, I'm hesitating between returns and return_, hence returns_
  6. 2:45 PM <fijal> ronan: so 'space' is something pypy-specific magical?
  7. 2:45 PM <ronan> yes
  8. 2:45 PM <fijal> I kinda want to have "you know rpython, you understand how types work"
  9. 2:46 PM <fijal> so no pypy-specific magic
  10. 2:46 PM <cfbolz> fijal: both things are quite magic
  11. 2:47 PM <fijal> cfbolz: yes, sure, one is less pypy-specific
  12. 2:47 PM <ronan> well, 'space' would just be a one-liner definition somewhere
  13. 2:47 PM <fijal> not deep in rpython?
  14. 2:47 PM <fijal> ;-)
  15. 2:47 PM <fijal> ronan: we've tried this in @enforceargs, why we don't use it more?
  16. 2:47 PM <ronan> no, somewhere in pypy
  17. 2:47 PM <fijal> cfbolz: question to you too
  18. 2:48 PM <antocuni> FWIW, I just managed to hit a "XXX should not happen" assert
  19. 2:48 PM <antocuni> http://paste.openstack.org/show/626376/
  20. 2:48 PM <fijal> SomeInstance(can_be_None=False, classdef=py._path.local.LocalPath)
  21. 2:48 PM <fijal> sounds fishy ;-)
  22. 2:49 PM <ronan> fijal: I guess it's because @enforceargs doesn't work very well
  23. 2:49 PM <antocuni> yes, I put an udir inside some rpython code
  24. 2:49 PM <fijal> why?
  25. 2:52 PM <ronan> fijal: it's basically more like an annotation-time assert than a type declaration, and you can't give useful types like List(int)
  26. 2:55 PM <fijal> I *really* dislike from something import List; List(int, resizable=False)
  27. 2:55 PM <fijal> also for anything non-trivial you either end up with import hell and circular imports
  28. 2:56 PM <fijal> and if we allow both W_Root and 'W_Root' that's a complete mess
  29. 2:59 PM <ronan> fijal: we can easily add cute aliases like [int] and {str: (float, int, str)}
  30. 2:59 PM <fijal> that all sounds like a nightmare to me
  31. 3:00 PM <fijal> Dict<int, float> looks a lot better
  32. 3:03 PM <fijal> anyway
  33. 3:03 PM <fijal> let's do an example
  34. 3:04 PM <fijal> def __init__(self, space, name, bases_w, dict_w,
  35. 3:04 PM <fijal> overridetypedef=None, force_new_layout=False,
  36. 3:04 PM <fijal> is_heaptype=True):
  37. 3:04 PM <fijal> in typeobject.W_TypeObject.__init__
  38. 3:06 PM <fijal> @rpython("space, bytes, list[W_Root], dict[bytes, W_Root], TypeDef, bool, bool->")
  39. 3:06 PM <fijal> @rpython("space, bytes, list[W_Root], dict[bytes, W_Root], TypeDef, bool, bool->", namespace="pypy")
  40. 3:06 PM <fijal> if we care
  41. 3:06 PM <fijal> @rpython("space", str, [W_Root], {str: W_Root}, TypeDef, bool, bool) looks very similar
  42. 3:07 PM <fijal> but no, because it's all of a sudden List(W_Root, resizable=False) or something
  43. 3:07 PM <fijal> and "str(non-null)" or what?
  44. 3:07 PM <fijal> I don't like how something like a nullable and non-nullable are dissimilar by a large degree
  45. 3:08 PM <ronan> the latter is a feature for me
  46. 3:08 PM <ronan> how do you define str(non-null) in your version, though?
  47. 3:09 PM <ronan> or a non-resizable list?
  48. 3:09 PM <fijal> str?
  49. 3:09 PM <fijal> array(foo)
  50. 3:10 PM <ronan> I mean a no_nul str
  51. 3:10 PM <fijal> str?
  52. 3:10 PM <fijal> with "?"
  53. 3:10 PM <cfbolz> no, wait
  54. 3:10 PM <fijal> ah, no nul
  55. 3:10 PM <fijal> maybe str[something-here]
  56. 3:11 PM <fijal> then <> is for templates [] is for parameters
  57. 3:12 PM <cfbolz> I must say the more syntax you invent the more I believe ronan ;-)
  58. 3:13 PM <ronan> indeed, we need something quite complex to define all the types we use, and I'd rather use Python for that than a half-baked DSL
  59. 3:14 PM <antocuni> here is where my typedef idea comes handy; "typedef str[no_nul=True] str_no_nul"
  60. 3:15 PM <fijal> I must say I'm not a huge fan of DSL either, but noone has provided a reasonable answer to circular imports
  61. 3:21 PM <fijal> any thoughts?
  62. 3:21 PM <fijal> ronan: ?
  63. 3:23 PM <ronan> fijal: my answer is still strings
  64. 3:24 PM <cfbolz> sorry, afk
  65. 3:24 PM <cfbolz> imo we should make this more concrete by looking at a real recursive import problem in interpreter/ or so
  66. 3:25 PM <ronan> if you get one in the signature, you do the lookup at annotation time in the module globals
  67. 3:26 PM <fijal> ronan: no
  68. 3:26 PM <fijal> which module?
  69. 3:26 PM <fijal> you might not have it ever in the module globals
  70. 3:27 PM <ronan> but how would it work in that case in your version?
  71. 3:28 PM <cfbolz> he wants a new namespace where all the types live
  72. 3:30 PM <ronan> but then you need to make sure that everything is defined before using it
  73. 3:31 PM <ronan> it's like a circular import problem, except different
  74. 3:32 PM <cfbolz> well, you do what you suggested, do the lookup only at annotation time
  75. 3:32 PM <cfbolz> but yes
  76. 3:33 PM <antocuni> I think we are looking at this problem somewhat from the wrong perspective
  77. 3:33 PM <antocuni> if the goal is to make RPython a "saner" a more usable language, we should approach it first from the user point of view
  78. 3:34 PM <fijal> IMO having "you write W_Root or 'W_Root' depending on the phase of the moon, but both work" is a bit user unfriendlt
  79. 3:34 PM → camara joined (~john@c-76-24-16-204.hsd1.ct.comcast.net)
  80. 3:34 PM <antocuni> i.e., to find a way which is ideally: 1) easy to read; 2) easy to write; 3) consistent; 4) easy to implement
  81. 3:35 PM <camara> str+ for the no nul case
  82. 3:35 PM <fijal> camara: what do you find more readable/writable?
  83. 3:35 PM <camara> taking inspiration from regular expressions
  84. 3:35 PM <fijal> IMO ronans strategy fails the 3)
  85. 3:35 PM <antocuni> also the 2, IMHO
  86. 3:36 PM <fijal> mitsuhiko: ping?
  87. 3:37 PM <antocuni> about no_nul: I would say that str and str(no_nul=True) should just be two different types (even if they end up being implemented by the same annotation with a different flag)
  88. 3:37 PM <antocuni> so, for example: "str" and "str0"
  89. 3:39 PM <ronan> I think fijal's solution fails 1, 3 and 4
  90. 3:39 PM <fijal> what's inconsistent?
  91. 3:39 PM <ronan> 1 and 4 because of the DSL aspect
  92. 3:39 PM <ronan> 3 is a general property of RPython
  93. 3:40 PM <antocuni> ronan: why is it hard to read, assuming that we design a good DSL?
  94. 3:40 PM <antocuni> also, note that your proposal is ALSO a DSL, just baked by python's parser instead of our own
  95. 3:41 PM <ronan> antocuni: because it's a new language
  96. 3:41 PM <antocuni> I didn't include "easy to learn" :-P
  97. 3:42 PM <antocuni> I'm serious: I think it's fine to trade a bit of learning curve (in the form of having to learn a DSL) in exchange for 1 and 2
  98. 3:42 PM <ronan> antocuni: and yes, I'm also propsing a DSL, but one that's easier to implement and learn
  99. 3:42 PM ⇐ slacky__ quit (~slacky@89-162-9-101.fiber.signal.no) Read error: Connection reset by peer
  100. 3:43 PM <antocuni> yes, and which is harder to read and write
  101. 3:45 PM <antocuni> ronan: e.g., take the example of test_optimizeopt
  102. 3:45 PM <antocuni> we used to write things like: oplist=[ResOperation('add', v0, Const(1)), ...]
  103. 3:45 PM <fijal> antocuni: no, we didn't write them ;-)
  104. 3:45 PM <antocuni> then we decided to switch to a DSL
  105. 3:46 PM <cfbolz> actually, that DSL shows most of ronan's points
  106. 3:46 PM <antocuni> fijal: I'm quite sure that we did at some point, but well
  107. 3:46 PM <antocuni> cfbolz: does it?
  108. 3:46 PM <cfbolz> yes
  109. 3:46 PM <ronan> antocuni: that's a different case
  110. 3:46 PM <cfbolz> eg it's completely bizarre to have to figure out where descrs come from
  111. 3:46 PM <fijal> antocuni: well, my point was more "we did not write enough of them"
  112. 3:46 PM <fijal> cfbolz: yes, we could have done a better job
  113. 3:46 PM <antocuni> ah yes
  114. 3:47 PM <ronan> that DSL allows switching from a declarative representation to an imperative one
  115. 3:47 PM <antocuni> ronan: I find it very similar to your proposal
  116. 3:48 PM <fijal> ronan: I think I'll implement a prototype and can we take discussion from there?
  117. 3:48 PM <fijal> more likely, I'll start with a way of fixing annotations so they don't change any more
  118. 3:49 PM <fijal> ronan: can we have a 3.5 recap on #pypy-sync though?
  119. 3:49 PM <ronan> my issue with the typing DSL is that I'm fairly sure that some things will be impossible to write
  120. 3:49 PM <cfbolz> note that we have several such mechanisms around already, and they are all not used much (rlib.signature, enforceargs, etc)
  121. 3:50 PM <ronan> fijal: as I said at first, syntax is a distraction, we need to make things work first
  122. 3:50 PM <fijal> yeah
  123. 3:50 PM <fijal> fair
  124. 3:50 PM <fijal> I'll show you my changes, hopefully later today
  125. 3:51 PM <camara> Why not use a similar syntax as type hints and get rid of the decorator. That way the typing is near the argument names. Maybe even change def to rdef to distingish rpython defs and aid the parser.
  126. 3:51 PM → adamholmberg joined (~adamholmb@2600:1014:b113:44e8:78d6:3be9:7f13:5e08)
  127. 3:52 PM <fijal> camara: because we don't preprocess rpython
  128. 3:53 PM <antocuni> we could modify our pypy27 to accept type annotations, and use those :)
  129. 3:54 PM <antocuni> then, we write a module which hijacks the parser to support them also on cpython 2.7
  130. 3:55 PM <antocuni> and we call it "python28", so that people can do "pip install python28" :)
  131. 3:55 PM <arigato> # -*- coding: python-with-hack -*-
  132. 3:55 PM <ronan> antocuni: yuck! I'd rather port rpython to Python 3
  133. 3:55 PM <camara> why would preprossing be necessary. You just change the language.
  134. 3:55 PM <antocuni> arigato: this looks like an excellent idea!
  135. 3:55 PM <fijal> camara: because our language starts from bytecode-level
  136. 3:55 PM <fijal> so once it's imported
  137. 3:55 PM <fijal> arigato: do you want to have opinions?
  138. 3:56 PM <arigato> not really
  139. 3:56 PM <arigato> I am honestly of the opinion that RPython is a bit hopeless for end users
  140. 3:56 PM <fijal> there is a chance of that :)
  141. 3:56 PM <fijal> but I meant more for "more interpreter authors"
  142. 3:57 PM ⇐ yuyichao quit (~yuyichao@c-24-63-250-128.hsd1.ma.comcast.net) Ping timeout: 248 seconds
  143. 3:57 PM <Rotonen> ronan: the zope/plone stack is actually going for rpython to python3 porting, be welcome to help there
  144. 3:57 PM <fijal> Rotonen: it's a different rpython right?
  145. 3:57 PM <arigato> yes, unrelated
  146. 3:57 PM <Rotonen> fijal: that's where my superficial understanding falls apart
  147. 3:57 PM <Rotonen> kk
  148. 3:58 PM <Rotonen> http://rpython.readthedocs.io/en/latest/faq.html#does-rpython-have-anything-to-do-with-zope-s-restricted-python <- actually straight in the faq as well :-)
  149. 4:05 PM → adamholm_ joined (~adamholmb@72.46.58.151)
  150. 4:07 PM <kenaan_> antocuni fix-vmprof-stacklet-switch 3e4e9ff62be1 /rpython/rlib/: make sure that vmprof don't sample the stack in the middle of stacklet switching, else it rea...
  151. 4:07 PM <kenaan_> antocuni fix-vmprof-stacklet-switch 1b1bdd6c7f39 /rpython/rlib/test/test_rstacklet.py: fix typo
  152. 4:07 PM <kenaan_> antocuni fix-vmprof-stacklet-switch 52a6650ba479 /pypy/module/_continuation/test/test_translated.py: add a test which is failing (i.e., segfaulting) on default, and that it seems to be fixed on ...
  153. 4:07 PM <kenaan_> antocuni fix-vmprof-stacklet-switch 46ee55287ed4 /: remove the space param from rvmprof.{start,stop}_sampling: it is not used and also it does no...
  154. 4:07 PM <kenaan_> antocuni fix-vmprof-stacklet-switch 2c8aa32187c0 /: close merged branch
  155. 4:07 PM <kenaan_> antocuni default 927cc69f4d52 /: merge the fix-vmprof-stacklet-switch: make sure that vmprof does not segfault in presence of continuation.switch...
  156. 4:08 PM → yuyichao joined ⇐ adamholmberg quit
  157. 4:14 PM <camara> fijal, for a crazy idea. I'm sure a hack could be done to import a module called rpython or rdef which does nothing under pypy and under CPython it preprocesses the module converting type annotations to a decorator. That way the user could use the cleaner type annotation format.
  158. 4:14 PM <fijal> I'm not sure if I want such hacks ;-)
  159. 4:15 PM ⇐ infinite quit (~infinite@45.32.84.160) Ping timeout: 260 seconds
  160. 4:15 PM <camara> Well the hack would only be under CPython.
  161. 4:17 PM <kenaan_> rlamy py3.5 dfff7758834e /pypy/module/posix/: Merged in thisch/pypy/py3.5 (pull request #584) Change return type of os.times to posix.times_result
  162. 4:17 PM <kenaan_> thisch py3.5 852c26ea2a1c /pypy/module/posix/: Change return type of os.times to posix.times_result The return type was changed in CPython3.3. Related: #2375
  163. 4:17 PM <kenaan_> thisch py3.5 898194d1902c /pypy/module/posix/test/test_posix2.py: Improve test for posix.times() Test that posix.times() returns a times_result object.
  164. 4:21 PM → infinite joined (~infinite@45.32.84.160)
  165. 4:43 PM <antocuni> arigato: when you feel like, please have a look at my continulet-no-frame-loop branch. It seems to work and the tests pass, but since the logic is subtle, I'd like some opinions/reviews about it
  166. 4:43 PM <arigato> ok
  167. 4:44 PM <antocuni> thanks
  168. 4:45 PM <antocuni> basically, the general idea is to remember also the topframe of the continulet, and to set the bottomframe.f_back to None when it's not running
  169. 5:01 PM ⇐ camara quit (~john@c-76-24-16-204.hsd1.ct.comcast.net) Remote host closed the connection
  170. 5:24 PM <kenaan_> rlamy py3.5 12f1fb4860ac /lib-python/3/test/test_inspect.py: Fix test to work on PyPy
  171. 5:43 PM <fijal> that was a long day
  172. 5:44 PM <kenaan_> fijal unicode-utf8 1d6d78e72d50 /: general progress towards moving more of the infrastructure from runicode towards unicodehelper, which helps us...
  173. 5:52 PM → zmt00, marky1991 and tbodt joined • adamholm_ → adamholmberg
  174. 6:13 PM <cfbolz> antocuni: would you unbreak test_whatsnew please?
  175. 6:23 PM <antocuni> cfbolz: sure
  176. 6:24 PM ⇐ ceridwen quit (~NoOne@unaffiliated/ceridwen) Quit: Ex-Chat
  177. 6:24 PM <antocuni> we should have an hg hook which reminds you
  178. 6:24 PM → ceridwen joined ⇐ marky1991 quit
  179. 6:27 PM <kenaan_> antocuni default 95e0fdd7cd86 /pypy/doc/whatsnew-head.rst: fix test_whatsnew
  180. 6:28 PM <fijal> it's called buildbot
  181. 6:28 PM ⇐ oberstet quit (~oberstet@p5B37F03E.dip0.t-ipconnect.de) Ping timeout: 240 seconds
  182. 6:29 PM <antocuni> yes, it takes only 24hours
  183. 6:30 PM ↔ drolando nipped out
  184. 6:37 PM <fijal> indeed
  185. 6:38 PM <antocuni> well nowadays it might be that pypy-only non-translated tests take a reasonable amount of time
  186. 6:39 PM <antocuni> like, we might be able to run them on travis or similar
  187. 6:41 PM <fijal> we can run test_whatsnew on travis :)
  188. 6:41 PM <antocuni> LOL
  189. 6:41 PM → marky1991 joined (~marky1991@unaffiliated/marky1991)
  190. 6:42 PM <fijal> or some interesting subset
  191. 6:42 PM <fijal> like interpreter/ and objspace/
  192. 6:42 PM <fijal> I'm not joking
  193. 6:43 PM <antocuni> I just launched a "time py.test pypy/" on bencher4
  194. 6:43 PM <antocuni> let's see how much it takes
  195. 6:44 PM <fijal> does it not crash?
  196. 6:45 PM <antocuni> we will see
  197. 6:45 PM <fijal> during collection
  198. 6:46 PM → Arfrever joined (~Arfrever@apache/committer/Arfrever)
  199. 6:46 PM <antocuni> no, it doesn't crash but I see tons of skipped tests
  200. 6:46 PM <ronan> antocuni: it takes 36 mins, 6 secs on py3.5
  201. 6:46 PM <antocuni> and if I try to run these tests directly, they just pass
  202. 6:46 PM <antocuni> weird
  203. 6:46 PM <ronan> see http://buildbot.pypy.org/builders/own-linux-x86-64/builds/6369 ;)
  204. 6:46 PM → oberstet joined (~oberstet@p5B37F03E.dip0.t-ipconnect.de)
  205. 6:47 PM <antocuni> ronan: cool, especially because if we run them on travis we can e.g. parallelize them
  206. 6:47 PM <antocuni> so it might be that a build takes a total wall clock time of ~10minutes or so
  207. 6:48 PM ⇐ raynold quit (uid201163@gateway/web/irccloud.com/x-ksexfkocndfpelxx) Quit: Connection closed for inactivity
  208. 6:49 PM <ronan> antocuni: we can't run them on travis, though, because bitbucket
  209. 6:49 PM <antocuni> yes sure
  210. 6:49 PM <antocuni> it might be worth moving to github just for this, possibly
  211. 6:50 PM ⇐ lritter_ quit (~lritter@x4db44acd.dyn.telefonica.de) Ping timeout: 268 seconds
  212. 6:50 PM <antocuni> also, bitbucket has pipelines nowdays, although they are not as feature complete as travis, AFAIK
  213. 6:50 PM → asmeurer joined ⇐ drolando quit ↔ tbodt and jamesaxl nipped out
  214. 7:02 PM <fijal> we can export stuff automatically to GH and then run travis from there
  215. 7:02 PM <fijal> I think
  216. 7:03 PM <fijal> without real migrate, just have a mirror
  217. 7:04 PM ⇐ jamesaxl quit (~James_Axl@109.172.62.242) Read error: Connection reset by peer
  218. 7:05 PM <fijal> antocuni: we can run interpreter/ objspace/ and module/xyz that was touched at least
  219. 7:08 PM ⇐ adamholmberg and asmeurer quit
  220. 7:16 PM <antocuni> yes, sounds like a good idea
  221. 7:16 PM → drolando joined (~drolando@8.18.218.175)
  222. 7:16 PM <antocuni> and a good summer of code project
  223. 7:17 PM <fijal> infrastructure makes terrible SoC projects IMO
  224. 7:19 PM → jamesaxl joined (~James_Axl@109.172.62.242)
  225. 7:21 PM <mitsuhiko> fijal: pong
  226. 7:21 PM <fijal> mitsuhiko: feel like reading bit of history about the rpython annotations and such?
  227. 7:21 PM <mitsuhiko> send me :)
  228. 7:22 PM <fijal> logs from here
  229.  
Powered by spacepaste. Paste removal.