Add display impl, rm outputManage, print and console.log default to browser console by marimeireles · Pull Request #749 · pyscript/pyscript

marimeireles · 2022-09-05T15:35:23Z

This is a WIP, still need to work in tests, but @antocuni wants to see the code, =)

Closes #635 #634 #230 #472 #280 #230 #712 #758 #76 #103

TODO: Create test cases for: #230 #472

antocuni · 2022-09-05T15:47:38Z

        )


+current_py_script_tag = None


UPPERCASE ;)
Or, even better: instead of using a global, you can store the value as an attribue of the function object itself:

def display(): ... display._default_target_id = None def set_default_display_target_id(id): display._default_target_id = id

oops
true about the uppercase
alright 👍 I did it like this cause you said global was the best solution? but you actually just mean we shouldn't use an object?
Also, I don't understand why it's a problem to use an object. I think it's possible to just pass it on the base.ts, on the same place where I call the set_current_display_target function. What do you think?

I did it like this cause you said global was the best solution? but you actually just mean we shouldn't use an object?

yes exactly. What I meant was "using global state is simpler than injecting a per-script object".
That said, you can set global state in two ways:

with a "real" global variable, as you did

as an attribute of the global display function

The difference is shallow, but usually in Python (2) is preferred because it makes it clear that the global is specific to this function

Also, I don't understand why it's a problem to use an object. I think it's possible to just pass it on the base.ts, on the same place where I call the set_current_display_target function. What do you think?

feel free to try and tell me how it goes :)

marimeireles · 2022-09-06T15:36:33Z

I'd like to propose a small refactor for this PR.
The way we output errors on the REPL is not ideal and the red banner by the footer of the page is not pretty, IMO.
I'd like to implement by default that all error messages show up underneath the REPL tag that errored with an UI that copies the error logs on the browser console. (Light red background with red colored letters in a red lined box)
What are folks opinions on this? @fpliger @antocuni

antocuni · 2022-09-07T09:19:41Z

I'd like to propose a small refactor for this PR. The way we output errors on the REPL is not ideal and the red banner by the footer of the page is not pretty, IMO. I'd like to implement by default that all error messages show up underneath the REPL tag that errored with an UI that copies the error logs on the browser console. (Light red background with red colored letters in a red lined box) What are folks opinions on this? @fpliger @antocuni

I don't have any strong opinion.
+0 to improve the style, although it looks OT with this PR.

marimeireles · 2022-09-14T17:58:48Z

+CURRENT_PY_SCRIPT_TAG = None
+
+
+def set_current_display_target(element):
+    global CURRENT_PY_SCRIPT_TAG
+    CURRENT_PY_SCRIPT_TAG = element
+
+
+def display(value, parent=None, append=True):
+    if parent is None:
+        global CURRENT_PY_SCRIPT_TAG
+        parent = CURRENT_PY_SCRIPT_TAG
+    Element(parent).write(value, append)


@antocuni I forgot how to declare a global in a class... could you please show me again? :)

"a global in a class" -- I don't know what it means :). But maybe you are referring to this pattern:

def set_current_display_target(element): get_current_display_target._obj = element def get_current_display_target(): return get_current_display_target._obj get_current_display_target._obj = None

I.e., instead of storing it in a global, you store it as an attribute of get_current_display_target.

marimeireles · 2022-09-14T18:00:44Z

tests are a WIP
I don't understand why the make fmt didn't catch this one line that the flake8 caught in the CI. Is this something we have it on the CI and not on the Makefile maybe? Or am I using the wrong thing.

marimeireles · 2022-09-14T18:02:32Z

+.hidden {
+    visibility: hidden;
+}


I don't think we need this, TODO for me, test it tomorrow.

marimeireles · 2022-09-14T18:09:08Z

Okay... Tests run 100% locally to me but not on the CI 😔

console.info
    [pyscript/pyodide] Runtime config: {
      name: 'pyodide-default',
      lang: 'python',
      src: 'https://cdn.jsdelivr.net/pyodide/v0.21.2/full/pyodide.js'
    }

      at Object.out_fn [as info] (src/logger.ts:50:13)

  console.info
    [pyscript/pyodide] Loading pyodide

      at Object.out_fn [as info] (src/logger.ts:50:13)

make: *** [Makefile:93: test-ts] Error 1

Seems related to logger stuff from Antonio? But I rebased so ???
I'll check it tomorrow morning cause it's getting late for me.

fpliger

think this PR is very close to ready to approve. Only needs to fix tests.. or am I missing something @marimeireles ?

fpliger · 2022-09-15T13:57:25Z

+CURRENT_PY_SCRIPT_TAG = None
+
+
+def set_current_display_target(element):
+    global CURRENT_PY_SCRIPT_TAG
+    CURRENT_PY_SCRIPT_TAG = element
+
+
+def display(value, parent=None, append=True):
+    if parent is None:
+        global CURRENT_PY_SCRIPT_TAG
+        parent = CURRENT_PY_SCRIPT_TAG
+    Element(parent).write(value, append)
+
+


I think it's ok to start from here but think there are ways we can improve and isolate display "current target" to the scope of execution so that we don't end up with race conditions of different scopes overwriting on each other.

@philippjfr suggestion of ContextVar in #769 is really interesting.

Yeah!
I need @antocuni's input here on how to make it prettier.
I don't wanna use this kind of global 🙈

But I intend to give it a try on the ContextVar stuff for sure =)
I'm updating the issue ^

Nice! @antocuni , we have another opportunity to kindly disagree and trade beers! 😝

I think it's ok to start from here but think there are ways we can improve and isolate display "current target" to the scope of execution so that we don't end up with race conditions of different scopes overwriting on each other.

@fpliger
sorry, reading it only now. I think that what you are proposing is impossible.
The semantics of Python scopes clashes with the desired semantics of display() in which the implicit target depends on the caller.
The only way to implement it (see below*) is to use a global variable. Or at least, that's the conclusion which I came up with after thinking a lot about the issue.
ContextVar helps with the async case but not in general, because it's essentially a "coroutine-aware global variable" -- so long as you stay in the same coroutine you have the very same problems as global variables.

I think that we will regret this choice: it's not really compatible with python semantics and will cause subtle bugs and problems in the future, but I'm not willing to fight for it :).

"the only way to implement it": well, the only reasonable way. The unreasonable way would be to modify the AST and/or the bytecode to detect the usage of display() and do some deep magic.
But if we go down this route, I'll resign immediately 😂

@antocuni Apologies for butting in on this, and the following clarifying questions shouldn't delay this (quite good!) PR:

The semantics of Python scopes clashes with the desired semantics of display() in which the implicit target depends on the caller... ContextVar helps with the async case but not in general, because it's essentially a "coroutine-aware global variable" -- so long as you stay in the same coroutine you have the very same problems as global variables.

I did want to clarify - what are the situations where you're in the same coroutine but you have different callers (different implicit targets)? Doesn't a single coroutine inPyScript have a single caller and therefore a well-defined implicit target that can be tracked via a ContextVar?

What I think is probably best is for me to hush up for awhile, and have another spin at this once this PR is merged 😅. Probably I just have an outdated understanding of the desired semantics here.

I did want to clarify - what are the situations where you're in the same coroutine but you have different callers (different implicit targets)?

that's my point, we don't know 😅.
Using global state to pass around function arguments is a bad API design: it makes functions not re-entrant and in general leads to subtle bugs and behavior. Implicit global state is even worse.
My point is that this approach is inherently fragile and it's "wrong by default": if we can think of all possible corner cases we can put workarounds for them, but as soon as we forget about one we will see bugs.

A random examples of things which might happen:
currently we do set_display_target(X); ...; set_display_target(None), but if for any reason we end up calling this code recursively, the inner invocation would set the target to None and then the outer one would see it changing under its feet. AFAIK this is not something which can happen now but might happen in the future (maybe without even noticing). And also it would be easy to fix, you just need a stack of current targets instead of just a variable.
This might happen even sooner than we think: for example, what happens if you add a <py-script> tag to the DOM from python code? I don't know what is the desired semantics, but if by chance we decide that the python code needs to be executed immediately, then you are in the exact situation which I described above.

Another example is event handlers: when thinking about the issue I realized that event handlers were a problem, but god only knows how many other problematic situations there are that we couldn't think of.

marimeireles · 2022-09-16T15:16:14Z

+            <string>await runtime.run(`set_current_display_target(element="${this.id}")`);
+            <string>await runtime.run(source);


@antocuni this is where we fetch the id.

why do you need the <string> prefix?
(Genuine question, there might be a good typescript reason which I don't know)

The <string> casts the return type to a string in TS.

Pyodide returns any from calls to runPython and runPythonAsync but the result does have a well-defined typed result being a union of boolean | string | number | Proxy... oh my!

type PyodideResult = boolean| string | number | Proxy | undefined const result0:Promise<PyodideResult> = await pyodide.runPython(code ); const result0:Promise<PyodideResult> = await pyodide.runPythonAsync(code );

I see no issues with this syntax as the TS Strict work should improve this in time.

antocuni

good job 💪
Although it definitely misses tests 🍻

antocuni · 2022-09-16T15:50:00Z

            out_element.appendChild(script_element)
-        else:
+        elif hasattr(out_element, "innerHTML"):
            out_element.innerHTML = html


this look like a code smell. Why do we need to check whether out_element has "innerHTML"?

I'm not sure if we need this anymore. I think it's the result of some previous behavior that I can't reproduce anymore.
But, why is it a code smell?
It's not better to be more specific about what we want?

(I think that the code is outdate, but answering just for the sake of conversation)

I think it's the result of some previous behavior that I can't reproduce anymore.

if you can kill a line of code without causing any fail to test, it either means that the line of code is useless (and so it should be removed) or tests are missing (and so they should be added).

But, why is it a code smell?

out_element is supposed to be an instance of Element and as such it always have the innerHTML property. If it doesn't it means that we are passing something of the wrong type, but then this is the wrong place where to fix the problem: it should be fixed earlier and avoiding passing an out_element which is not actually an element.

antocuni · 2022-09-16T15:50:21Z

-
-
 pyscript = PyScript()
-output_manager = OutputManager()


hoorray for killing a lot of code 🎉

antocuni · 2022-09-16T15:51:23Z

+            <string>await runtime.run(`set_current_display_target(element="${this.id}")`);
+            <string>await runtime.run(source);


why do you need the <string> prefix?
(Genuine question, there might be a good typescript reason which I don't know)

antocuni

Very good job @marimeireles 🎉.
I read and reviewed your commits one by one, in true TDD spirit and you did a very good job at following it 😍.
I left many comments, but don't be alarmed: most of them are just style/suggestions/nitpicks that can be ignored, but I hope that you can find them useful.
A couple of comments are real issues that needs to be addressed though. But as I said, in general I'm very happy with the overall shape of this PR

antocuni · 2022-10-13T15:32:01Z

-            <string>await runtime.run(`set_current_display_target(element="${this.id}")`);
+            <string>await runtime.run(`set_current_display_target(target_id="${this.id}")`);
            <string>await runtime.run(source);
+            <string>await runtime.run(`set_current_display_target(target_id=None)`);


[fix] if runtime.run(source) raises an exception, the current_display_target is never set back to None.
There should be a try/finally (and a test!)

Note: I'm reviewing commits one by one, so it could be that this is already fixed by next commits. Feel free to ignore in that case

Thanks! I completely forgot about it.
This is what you mean:

try { <string>await runtime.run(`set_current_display_target(target_id="${this.id}")`); <string>await runtime.run(source); } finally { <string>await runtime.run(`set_current_display_target(target_id=None)`); }

correct?

yes. And ideally, with a test ;)
The test is a bit hard to write, but I I guess that with the current code the following test would fail:

execute a <py-script> which raises an exception

call display() from an event handler: in theory it should fail (because you cannot call display() without explicit target form event handlers), but with the current code it will pass because the current_target was set in (1) and never reset to None.

So the test should check that (2) fails.

antocuni · 2022-10-13T15:36:15Z

-        # XXX fixme
-        assert "1 1" == inner_text
+        text = self.page.text_content("body")
+        assert "hello" in text


I'm confused. If I understand correctly, in this test we want to check that hello in displayed in a very specifiy place (second-pyscript-tag), so you should be more precised and get the text_content() of it, instead of the text_content of the whole body.

antocuni · 2022-10-13T15:37:09Z

+                def display_hello():
+                    # this fails because we don't have any implicit target
+                    # from event handlers
+                    display('hello', target='my-button')


same as above, the comment is wrong

antocuni · 2022-10-13T15:46:39Z

+    def test_image_display(self):
+        self.pyscript_run(
+            """
+                <py-env>- matplotlib</py-env>


you will notice it as soon as you rebase, but <py-env> is gone. You should use <py-config>

antocuni · 2022-10-13T15:51:16Z

+        console_text = self.console.all.lines
+        assert 'print from python' in console_text
+        assert 'print from js' in console_text
+        assert 'error from js' in console_text


[nitpick] note that with self.console you can do much more precise asserts if you want. E.g. you could say:

assert self.console.log.lines[-2] == 'print from python' assert self.console.log.lines[-1] == 'print from js' assert self.console.error.lines == ['error from js']

antocuni · 2022-10-13T15:56:50Z

+        )
+        console_text = self.console.all.lines
+        assert console_text.index('1print') == (console_text.index('2print') - 1)
+        assert console_text.index('1console') == (console_text.index('2console') - 1)


[style] the name of the variable is wrong: I would expect console_text to be a string (like console.text), but here it's a list.

Also, you can be much more concrete in your test: here you are basically introducing some semi-complex logic to check that the code when to consecutive but different lines, but you can probably do something much simpler:

lines = self.console.log.lines assert lines[-4] == '1print' assert lines[-3] == '2print' assert lines[-2] == '1console' assert lines[-1] == '2console'

Generally speaking, it is better to have tests which contains very straightforward logic: they are easier to read, there is less probability that the test itself is buggy, and it's much easier to understand what's wrong in case of failure.

But again this is a nitpick and the test is already very good 💪 , so feel free to ignore this comment if you want

antocuni · 2022-10-13T15:57:53Z

+        console_text = self.console.all.lines
+        assert 'print from python' in console_text
+        assert 'print from js' in console_text
+        assert 'error from js' in console_text


ah cool, I think this fixes my previous comment. Good job! 💪

antocuni · 2022-10-13T15:58:36Z

+                    import asyncio
+                    for i in range(2):
+                        display('A')
+                        await asyncio.sleep(0.1)


why 0.1? The standard python way to say "please switch to another coroutine" is await asyncio.sleep(0)

… to terminal

marimeireles · 2022-10-14T15:21:31Z

The REPL test that's failing really doesn't make sense... I think they're just haunted. It runs on my machine.

…f stops failing on CI

marimeireles · 2022-10-14T16:02:12Z

Ok, so this beauty is finally green, but I had to add a weird fix.
I need people who understands py-config here... So maybe @madhur-tandon, @antocuni?
I had the following problem:

This test would work fine on the CI:

    def test_runtime_config(self, tar_location):
        unzip(
            location=tar_location,
            extract_to=self.tmpdir,
        )

        self.pyscript_run(
            """
            <py-config type="json">
                {
                    "runtimes": [{
                        "src": "/pyodide/pyodide.js",
                        "name": "pyodide-0.20.0",
                        "lang": "python"
                    }]
                }
            </py-config>

            <py-script>
                import sys, js
                pyodide_version = sys.modules["pyodide"].__version__
                js.console.log("version", pyodide_version)
                display(pyodide_version)
            </py-script>
        """,
        )

        assert self.console.log.lines == [self.PY_COMPLETE, "version 0.20.0"]
        version = self.page.locator("py-script").inner_text()
        assert version == "0.20.0"

This one wouldn't:

    def test_runtime_config(self, tar_location):
        unzip(
            location=tar_location,
            extract_to=self.tmpdir,
        )

        self.pyscript_run(
            snippet="""
            <py-script>
                import sys, js
                pyodide_version = sys.modules["pyodide"].__version__
                js.console.log("version", pyodide_version)
                display(pyodide_version)
            </py-script>
        """,
            extra_head="""
            <py-config>
                runtimes:
                - src: "/pyodide/pyodide.js"
                  name: pyodide-0.20.0
                  lang: python
            </py-config>
        """,
        )

        assert self.console.log.lines == [self.PY_COMPLETE, "version 0.20.0"]
        version = self.page.locator("py-script").inner_text()
        assert version == "0.20.0"

Playing spot the difference, I've realized one file had pyconfig as YAML the other one as JSON, so I changed that on my last commit (2cfe470) and it worked. But I wonder:
a) why is this failing right here, right now? Seems so unrelated to what I'm doing
b) why isn't the YAML config working on this scenario?

Help here would be appreciated cause I don't understand what's happening.

madhur-tandon · 2022-10-14T16:04:08Z

@marimeireles That's because YAML is no longer supported. Only TOML and JSON are.

marimeireles · 2022-10-14T16:20:48Z

So it's fine to keep it as it is?

tedpatrick · 2022-10-14T16:42:45Z

If we are seeing YAML in the tests, it implies that the branch history is not current in the PR or commits are missing. We are close but merging this holds risk if the branch history is missing commits.

…

On Fri, Oct 14, 2022 at 11:20 AM Mariana Meireles ***@***.***> wrote: So it's fine to keep it as it is? — Reply to this email directly, view it on GitHub <#749 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISG7AHV6TVEK7GVD6IDQN3WDGB6XANCNFSM6AAAAAAQFDJ6LA> . You are receiving this because you commented.Message ID: ***@***.***>

madhur-tandon · 2022-10-14T16:47:24Z

So it's fine to keep it as it is?

No no, it means that you have old history, the repo doesn't have YAML anywhere now. So you should ideally rebase on top of main and force push.

antocuni · 2022-10-15T10:22:41Z

@@ -0,0 +1,71 @@
+import os


the presence of this file is wrong and it's probably a merge artifact.
It was renamed into test_py_config.py by PR 806, see here:
https://github.com/pyscript/pyscript/pull/806/files#diff-be855b518404836a1b9ed7ccecb56a8055aa1b0a11f3c73743cf44ac18a633bb

You can safely remove it.

antocuni · 2022-10-15T10:24:42Z

If we are seeing YAML in the tests, it implies that the branch history is not current in the PR or commits are missing. We are close but merging this holds risk if the branch history is missing commits.

Mystery solved, it is caused by a merge artifact, because test_py_runtime_config.py was renamed into test_py_config.py, see this comment:
#749 (comment)

…_py_config.py on the main branch

antocuni · 2022-10-17T09:05:46Z

@marimeireles today I merged #850 which caused another conflict in this branch, so I took the freedom to fix it in e1b1045, hope you don't mind.
I also killed test_py_runtime_config.py in 0a563b2.

I think we are very close to merge it! :)

marimeireles · 2022-10-17T13:03:20Z

@antocuni got it! 🎉
Thank you! :)
okaaaay I just need one more change.
And then we can merge it.
Pushing it soon.

marimeireles · 2022-10-17T13:15:02Z

Ready to merge when the check is green ✅

tedpatrick

Awesome work @marimeireles 🚢

antocuni

LGTM, good job @marimeireles 🎉🎉🎉

antocuni · 2022-10-17T13:47:22Z

@marimeireles please please please do not use the default commit message that it's suggested when you do "squash and merge": it's completely useless since it's just the concatenation of individual commits.
What I usually do is to write a summary of what the PR does, so that it will be easy to read it when we do git log from the terminal. Often it's a copy&paste&adapt of the first message of my PRs.
See e.g. the commits beb3aa1 and 11a517b as examples

marimeireles · 2022-10-17T14:28:52Z

Docs follow soon.

…rowser console (pyscript#749) * Add display impl, remove outputManage, print and console.log defaults to terminal * Fixing tests * Lint * Erase unecessary code, add cuter CSS formating for errors, fix problems around REPL output * Add fix to repl2 and lint * lint * Allow for list of display, fix elif to else * Add better global option * test work * xfails * (antocuni, mariana): let's try to start again with TDD methodology: write the minimum test and code for a simple display() * (antocuni, mariana): this test works out of the box * WIP: this test is broken, mariana is going to fix it * add a failing test * Add ability to deal with targets * Add append arg and append tests * Add multiple values to display * Small adjustments to tests. I noticed I wasn;t running all at some point * add display test * Add console tests * Add async tests * Fix repl tests * Fixing merging issues * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Address antocuni's review * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Fixing more tests * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * linting * Improve repl tests * Change my test so codespell is hapy with it * Test: change test_runtime_config to use json instead of toml to see if stops failing on CI * kill this file: it is a merge artifact since it was renamed into test_py_config.py on the main branch * Change test execution order and add async tests to async test file Co-authored-by: Antonio Cuni <anto.cuni@gmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

Major highlights: 1. Merge&simplify base.ts and pyrepl.ts; kill base.ts 2. improve and extente the py-repl integration tests 3. Reorder the code in pyrepl.ts. This part of the PR doesn't change much of the concrete logic: it's just a sequence of renaming variables, moving code around, group code into functions, killing code which is no longer needed. But the end result is much better and nicer to read, IMHO. Minor highlights: 1. py-repl now uses the new logic in pyexec.ts to run the code 2. after PR Add display impl, rm outputManage, print and console.log default to browser console #749 py-repl no longer displayed the result of the last evaluated expression (e.g. if you typed 42 and run it, it displayed nothing). This PR re-introduces this behavior, which is what you would expect by a REPL. 3. improve the pytest --dev option: now it implies --no-fake-server so that sourcemaps works automatically 4. improve the names of the CSS classes to be more consistent 5. kill pyrepl.test.ts: the old tests didn't check anything useful, this style of unit test doesn't really add much value if you have good integration tests (which now we have) and trying to revive them was not worth the hassle

…rowser console (pyscript#749) * Add display impl, remove outputManage, print and console.log defaults to terminal * Fixing tests * Lint * Erase unecessary code, add cuter CSS formating for errors, fix problems around REPL output * Add fix to repl2 and lint * lint * Allow for list of display, fix elif to else * Add better global option * test work * xfails * (antocuni, mariana): let's try to start again with TDD methodology: write the minimum test and code for a simple display() * (antocuni, mariana): this test works out of the box * WIP: this test is broken, mariana is going to fix it * add a failing test * Add ability to deal with targets * Add append arg and append tests * Add multiple values to display * Small adjustments to tests. I noticed I wasn;t running all at some point * add display test * Add console tests * Add async tests * Fix repl tests * Fixing merging issues * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Address antocuni's review * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Fixing more tests * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * linting * Improve repl tests * Change my test so codespell is hapy with it * Test: change test_runtime_config to use json instead of toml to see if stops failing on CI * kill this file: it is a merge artifact since it was renamed into test_py_config.py on the main branch * Change test execution order and add async tests to async test file Co-authored-by: Antonio Cuni <anto.cuni@gmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

marimeireles marked this pull request as draft September 5, 2022 15:36

antocuni reviewed Sep 5, 2022

View reviewed changes

marimeireles force-pushed the marimeireles/output branch 2 times, most recently from 4647165 to 31ce5bc Compare September 5, 2022 17:08

marimeireles mentioned this pull request Sep 6, 2022

Printing in the same line isn't working #472

Closed

3 tasks

marimeireles mentioned this pull request Sep 8, 2022

Print losing output context #230

Closed

JeffersGlass mentioned this pull request Sep 9, 2022

Docs: How To Pass Objects between JavaScript and PyScript #753

Merged

This was referenced Sep 12, 2022

py-script should only render to the page through the display function #646

Closed

Why do you force the output and errors to be visible after you evaluate an expression? #758

Closed

This was referenced Sep 14, 2022

Behavior of display() targets #768

Closed

Behavior of display() targets #769

Closed

marimeireles force-pushed the marimeireles/output branch from 834a909 to f3efe8e Compare September 14, 2022 17:57

marimeireles commented Sep 14, 2022

View reviewed changes

marimeireles marked this pull request as ready for review September 14, 2022 17:59

marimeireles commented Sep 14, 2022

View reviewed changes

fpliger reviewed Sep 15, 2022

View reviewed changes

marimeireles commented Sep 16, 2022

View reviewed changes

marimeireles force-pushed the marimeireles/output branch from a1480a6 to 6d321c8 Compare September 16, 2022 15:45

antocuni reviewed Sep 16, 2022

View reviewed changes

marimeireles mentioned this pull request Sep 28, 2022

Make pyscript.write replace content instead of append #76

Closed

antocuni mentioned this pull request Sep 29, 2022

Logging seems overly verbose in 2022.09.1.RC2 #799

Closed

3 tasks

JeffersGlass mentioned this pull request Sep 29, 2022

Plotly support #226

Closed

antocuni reviewed Oct 13, 2022

View reviewed changes

marimeireles added 3 commits October 13, 2022 22:21

Add display impl, remove outputManage, print and console.log defaults…

1db86f9

… to terminal

Fixing tests

6381b4c

Lint

9d02557

Change my test so codespell is hapy with it

8d97dce

Test: change test_runtime_config to use json instead of toml to see i…

2cfe470

…f stops failing on CI

antocuni reviewed Oct 15, 2022

View reviewed changes

antocuni added 2 commits October 17, 2022 11:00

Merge remote-tracking branch 'origin/main' into marimeireles/output

e1b1045

kill this file: it is a merge artifact since it was renamed into test…

0a563b2

…_py_config.py on the main branch

Change test execution order and add async tests to async test file

9babeb4

tedpatrick approved these changes Oct 17, 2022

View reviewed changes

antocuni approved these changes Oct 17, 2022

View reviewed changes

marimeireles merged commit 1587273 into pyscript:main Oct 17, 2022

marimeireles mentioned this pull request Oct 17, 2022

No Python output if console.log() is called after Python code #712

Closed

3 tasks

This was referenced Oct 22, 2022

display() sends the output to the wrong tag #878

Closed

Simplify pyrepl.ts and kill base.ts #884

Merged

antocuni mentioned this pull request Nov 1, 2022

PyodideRuntime.run should not await #879

Closed

jasonwashburn mentioned this pull request Nov 22, 2022

Getting Started example uses deprecated pyscript.write() method. #973

Closed

3 tasks

		<string>await runtime.run(`set_current_display_target(element="${this.id}")`);
		<string>await runtime.run(source);

		)


		current_py_script_tag = None

Conversation

marimeireles commented Sep 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marimeireles Sep 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marimeireles commented Sep 6, 2022

Uh oh!

antocuni commented Sep 7, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marimeireles commented Sep 14, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marimeireles commented Sep 14, 2022

Uh oh!

fpliger left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fpliger Sep 15, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JeffersGlass Oct 13, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tedpatrick Oct 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

antocuni left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

antocuni left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

marimeireles commented Sep 5, 2022 •

edited

Loading

marimeireles Sep 5, 2022 •

edited

Loading

fpliger Sep 15, 2022 •

edited

Loading

JeffersGlass Oct 13, 2022 •

edited

Loading

tedpatrick Oct 14, 2022 •

edited

Loading

marimeireles commented Oct 14, 2022 •

edited

Loading

antocuni commented Oct 17, 2022 •

edited

Loading