Hacker News new | past | comments | ask | show | jobs | submit | vanni's comments login




Thanks 4 this


Some food for thought (found during a quick evaluation of Svelte for future projects)

Contributors

https://github.com/sveltejs/svelte/graphs/contributors

See main three graphs.

Roadmap

https://github.com/sveltejs/svelte/issues/622

> (last comment - Jun 28, 2020) This isn't really an up to date of view on where we are and where we would like to go. We have some tentative plans to improve how we communicate the 'roadmap' in the future. We'll update when we know more.

https://github.com/sveltejs/svelte/issues/3704

> Honestly the roadmap for the near future is the same as it's been since Svelte suddenly got much more popular without a corresponding increase in maintainer resources: fixing bugs. Developing exciting new features is going to take a back seat to dealing with the huge backlog of issues for the time being.

From original Svelte author:

https://twitter.com/Rich_Harris/status/1341076126475710465

> [...] if you do this on a github repo i'm involved with because you're dissatisfied with the help that was given freely and patiently by other contributors, i will make a mental note of who you are so i can ensure you never get my help, ever

https://twitter.com/Rich_Harris/status/1341167074018795526

> [...] believe it or not I don't spend my time waiting around to be summoned by people expecting me to do free work for them


So, how did your evaluation go? I mean the real evaluation, experience of coding, building an app, deploying it?


So are you saying that you're concerned by the lack of a detailed vision for Svelte, or that you're concerned with the behavior of the primary maintainer of Svelte?


My main concerns as a "technology buyer" are (from what I found online with a rapid search): lack of funding, currently only two main committers (the original author not among them), project apparently in bugfixing-only mode, and the original author online attitude.


From an outsiders perspective, that's fair enough. However, Rich's time and focus as well as a number of other maintainers is currently on Svelte-Kit, which gets a commit around every 6 minutes at its peak, and at least every hour otherwise. Rich is ridiculously active.

Your comments are fair, but misguided.


I've seen some of the GitHub issues that Rich is referring to in those tweets. They're almost always cases where someone is asking for some feature or change in Svelte and the core contributors disagree that it fits with the design and vision of the project.

Then the OP tags Rich in the hopes that he will swoop in and and override the decision. It's almost always more of a tantrum than a real request for help.

As far as project progress, most of the recent work has been on SvelteKit, but I've been using Svelte for about a year now and it has steadily gained features during that time. It's definitely not in bugfix-only mode.


Funding is about $30,000 a year: https://opencollective.com/svelte#category-BUDGET


Ah, I see. That wasn't explicitly stated in your original comment, so I was just wanted to clarify.

I think these are valid concerns about Svelte's future. However, you should give it a try and see if you like it regardless. Its got some neat ideas.


Probably dynamic contrast ratio by graphic driver and/or monitor that is tricked/triggered by unusual dithered patterns during scrolling.


Right. Sabine Hossenfelder about it: https://www.youtube.com/watch?v=ZYM6HMLgIKA&t=395s



"pretty unintuitive" is an understatement...

  In [1]: import dis
  
  In [2]: def a():
     ...:     return (1 in [1,2,3] is True)
  
  In [3]: def b():
      ..:     return ((1 in [1,2,3]) is True)
  
  In [4]: a()
  Out[4]: False
  
  In [5]: b()
  Out[5]: True
  
  In [6]: dis.dis(a)
    2           0 LOAD_CONST               1 (1)
                2 LOAD_CONST               1 (1)
                4 LOAD_CONST               2 (2)
                6 LOAD_CONST               3 (3)
                8 BUILD_LIST               3
               10 DUP_TOP
               12 ROT_THREE
               14 COMPARE_OP               6 (in)
               16 JUMP_IF_FALSE_OR_POP    24
               18 LOAD_CONST               4 (True)
               20 COMPARE_OP               8 (is)
               22 RETURN_VALUE
          >>   24 ROT_TWO
               26 POP_TOP
               28 RETURN_VALUE
  
  In [7]: dis.dis(b)
    2           0 LOAD_CONST               1 (1)
                2 LOAD_CONST               5 ((1, 2, 3))
                4 COMPARE_OP               6 (in)
                6 LOAD_CONST               4 (True)
                8 COMPARE_OP               8 (is)
               10 RETURN_VALUE
Why?!


The disassembly in parent comment is made with CPython 3.6.9, but nothing substantial changes on CPython 3.8.x/3.9.x or PyPy.

Maybe it is related to grammar, and not to compiler...

AST dump in CPython 3.6.9 (manually formatted):

  In [1]: import ast
  
  In [2]: print(ast.dump(ast.parse("""\
     ...: def a():
     ...:     return (1 in [1,2,3] is True)""")))
  
  Module(
      body=[
          FunctionDef(
              name='a',
              args=arguments(args=[], vararg=None, kwonlyargs=[], kw_defaults=[], kwarg=None, defaults=[]),
              body=[
                  Return(
                      value=Compare(
                          left=Num(n=1),
                          ops=[In(), Is()],
                          comparators=[
                              List(elts=[Num(n=1), Num(n=2), Num(n=3)], ctx=Load()),
                              NameConstant(value=True)
                          ]
                      )
                  )
              ],
              decorator_list=[],
              returns=None
          )
      ]
  )
  
  In [3]: print(ast.dump(ast.parse("""\
     ...: def b():
     ...:     return ((1 in [1,2,3]) is True)""")))
  
  Module(
      body=[
          FunctionDef(
              name='b',
              args=arguments(args=[], vararg=None, kwonlyargs=[], kw_defaults=[], kwarg=None, defaults=[]),
              body=[
                  Return(
                      value=Compare(
                          left=Compare(
                              left=Num(n=1),
                              ops=[In()],
                              comparators=[List(elts=[Num(n=1), Num(n=2), Num(n=3)], ctx=Load())]
                          ),
                          ops=[Is()],
                          comparators=[NameConstant(value=True)]
                      )
                  )
              ],
              decorator_list=[],
              returns=None
          )
      ]
  )


OK, mystery solved. In Python:

  1 in [1,2,3] is True
is evaluated as

  (1 in [1, 2, 3]) and ([1, 2, 3] is True)
similarly to

  1 < 2 < 3
:facepalm:


I don't see anything surprising. "is" has higher prevalenz than "in" and that's it. Or am I misreading something?


It's not a matter of operator precedence for two reasons:

1) "in" and "is" have same precedence, and group left to right (see https://docs.python.org/3/reference/expressions.html#operato...)

2) you'll have runtime error:

  In [1]: def c():
     ...:     return (1 in ([1,2,3] is True))
  
  In [2]: c()
  ...  
  TypeError: argument of type 'bool' is not iterable
It seems related to CPython bytecode compiler implementation, the two functions are parsed in a different way, parentheses make the compiler go on a different path... but I'd like to understand why, without diving into CPython source code :) Anyone?


If this was the reason you'd get a TypeError, since there's no `bool.__contains__`.


Somewhat relevant:

https://intuiti.it/

A tool for Creativity born in the Polytechnic University of Milan. A synthesis of Design, Tarot and Gestalt Psychology.


From the "Integration with Other Frameworks" section of the article [1]:

> DearPyGui can actually be used in conjuction with other GUI frameworks. For example, with tkinter:

> This just requires replacing start_dearpygui with setup_dearpygui, render_dearpygui_frame, and cleanup_dearpygui in order to expose the event loop.

[1] https://itnext.io/python-guis-with-dearpygui-137f4a3360f2#2a...


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: