[Issue #222] TypeError: Cannot read property 'context' of undefined

[Olemis Lang]

Hi !

I thought it would be easy to implement #222 , so I started working on
it minutes ago . What I did was to generate js code for _csv module ,
create _csv.py.js file under a new folder www/tests/pycache/ , which I
insert upfront in sys.path . As far as the import logic is concerned
everything is working as expected . Nevertheless the following error
is thrown when actually running module code .

{{{
"TypeError: Cannot read property 'context' of undefined
at $DefCtx.transform (http://localhost/brython/www/src/py2js.js:1845:22)
at $Node.transform (http://localhost/brython/www/src/py2js.js:291:32)
at $Node.transform (http://localhost/brython/www/src/py2js.js:284:44)
at Object.$B.py2js (http://localhost/brython/www/src/py2js.js:6820:10)
at Object.$B.$lambda (http://localhost/brython/www/src/py_utils.js:455:18)
at eval (eval at <anonymous>
(http://localhost/brython/www/src/py_import.js:227:14),
<anonymous>:428:77)
at eval (eval at <anonymous>
(http://localhost/brython/www/src/py_import.js:227:14),
<anonymous>:445:6)
at eval (eval at <anonymous>
(http://localhost/brython/www/src/py_import.js:227:14),
<anonymous>:1968:2)
at $B.run_py.run_py (http://localhost/brython/www/src/py_import.js:227:9)
at Object.importer_path.exec_module
(http://localhost/brython/www/src/py_import.js:414:56)"
}}}

The anonymous eval stack frames belong to _csv.py.js code . Relevant
LOC is printed below

{{{#!sh

$ cat www/tests/pycache/_csv.pyc.js | head -428 | tail -1
$locals["delimiter"]=getattr($B.builtins["property"],"__call__")($B.$lambda([["_csv_Dialect_76",$locals__csv_Dialect_76],
["_csv",$locals__csv]]," self"," self._delimiter"));
}}}

So it seems to me that I should do something else involving certain
context , isn't it ? What is it about exactly ?

p.s. Importing _csv module from either stdlib paths or www/Lib/ works
fine , so it does not seem to be an issue with generated js code .

[Olemis Lang]

I've been trying to figure this out for days but I have no clue yet .
Could anybody please provide any hints about how js contexts work ? Am
I missing something obvious in my reasoning below ?

--
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Pierre Quentel]

Olemis,

I have started working on this. We must test precompiling to see if it actually improves import time, although I'm not sure of the result.

In the latest commits I have added 2 files, tests/precompile.html and cgi-bin/precompile.py. It's still very experimental. The html page :
- loads the content of the module datetime.py
- translates it to javascript, exactly as in the online editor ; this is done by calling function py2js of module javascript (I had to fix it, maybe it's the bug that I fixed that caused the issue you report, but I'm not sure)
- sends the javascript code to the cgi script, which stores it on disk as /cgi-bin/saved.js

Then I copy saved.js to /libs/ and run /scripts/make_stdlib_static.py (I told you it was experimental ;-) to add saved.js to the list of scripts in /src/stdlib_paths.js

After that, I can import the module by "import saved" :

Brython 3.2.1 on Netscape 5.0 (Windows)
>>> import saved
>>> saved.datetime.now()
datetime.datetime(2015, 7, 6, 9, 28, 34, 226000)
>>>

At this stage it's hard to tell how much faster it is to load saved than datetime, because they import other scripts that should also be precompiled.

An obvious drawback of this approach is the size of the precompiled file : 74 kB becomes 330 kB minified (saved.js is actually bigger) ie between 4 and 5 times bigger.

Do you think you can build on these scripts to precompile all the files in stdlib ?

[Billy Earney]

experiments I have done, also show that compiled files are much larger.  One thing I tried was saving the compiled files to local storage.  I did this for all files, and that turned out to not be a good idea.  For some reason things didn't speed up.  (I tried this over a year ago, so I cannot remember exactly what didn't work right.)

I'm thinking that maybe a different approach would be to save compiled files to local storage when the compilation time is greater than a certain amount of time (maybe 100ms?)  A few modules such as re (I believe the sre* modules take a long time to compile).   The down side to this, is that we would have to check local storage during each import to see if a module exists there before looking in the regular places.  This might slow things down a bit for a regular import.

Just a thought...

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brython/b4a135d1-a52c-471b-a30e-a4c8328d3e15%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Billy Earney]

After sending this email it dawned on me, what the issue was.    Brython does not do a "pure" compile to js.  Many objects (I believe generators are one), saves some of the code to objects, and are executed later.  If you output the js output to a file, local storage, etc, and later call those, you will get undefined errors.  I believe your "TypeError: Cannot read property 'context' of undefined" error is one of those.

Because of this I had to abandon the work I did.  Also Pierre and I (and others) had done some work to speed up the transpiler, so one could argue that the speed up and extra complexity of the js output saved didn't add much to improve performance.

Billy

[Olemis Lang]

On 7/6/15, Pierre Quentel <pierre....@gmail.com> wrote:
> Le lundi 6 juillet 2015 04:25:27 UTC+2, Olemis Lang a écrit :
>>
>> I've been trying to figure this out for days but I have no clue yet .
>> Could anybody please provide any hints about how js contexts work ? Am
>> I missing something obvious in my reasoning below ?
>>

[...]

>
> Olemis,
>
> I have started working on this. We must test precompiling to see if it
> actually improves import time, although I'm not sure of the result.
>

Ok . I'll reread this thread later today and get something done .
Everything I've done (on this direction) is published in
olemis/t222_import_pyc branch in my fork [1]_ .

> In the latest commits I have added 2 files,

I'll take a look into this in a while .

[...]

>
> Then I copy saved.js to /libs/

JFTR I'd prefer to publish these precompiled files at a different path .

[...]

> (I
> told you it was experimental ;-)
>

[...]

understood

> After that, I can import the module by "import saved" :
>
> Brython 3.2.1 on Netscape 5.0 (Windows)
>>>> import saved
>>>> saved.datetime.now()
> datetime.datetime(2015, 7, 6, 9, 28, 34, 226000)
>>>>
>
> At this stage it's hard to tell how much faster it is to load saved than
> datetime, because they import other scripts that should also be
> precompiled.
>
> An obvious drawback of this approach is the size of the precompiled file :
> 74 kB becomes 330 kB minified (saved.js is actually bigger) ie between 4
> and 5 times bigger.
>

This is for devs to decide , and IMO it's just a matter of what's the
most important resource CPU vs disk space vs download time .

> Do you think you can build on these scripts to precompile all the files in
> stdlib ?
>

I'll tell you once I review this in more detail , but looks like a
good starting point .

[...]

.. [1] https://github.com/olemis/brython/tree/olemis/t222_import_pyc