Re: persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)
Not sure this pertains to the ECMAScript spec in any way. You may have better luck with WICG, because they are who deal with those specs - those are specific to the web, while JS is used in places where those might not even make sense (like IoT sensors). - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Wed, Sep 4, 2019 at 12:40 PM kai zhu wrote: > > at work, we have browser-app that load-and-persist ~100MB (500k rows) > csv-files into wasm-sqlite3 [1], (ingestion-time is ~15s for 100MB csv). we > wish to go bigger, but chrome's indexeddb has a hard-limit of 125MB per > key-value object (on windows). > > i don't have anything actionable. just want people aware of datapoint, and > think about javascript-language-design to improve UX-handling with > sqlite3-persistence. > > fyi, ignoring persistence, chrome can handle wasm-sqlite3 datasets as large > as 300MB (1.5 million rows) in memory, before crashing (on 8gb windows10 > machine). > > [1] sql.js wasm-sqlite3 > https://github.com/kripken/sql.js > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)
at work, we have browser-app that load-and-persist ~100MB (500k rows) csv-files into wasm-sqlite3 [1], (ingestion-time is ~15s for 100MB csv). we wish to go bigger, but chrome's indexeddb has a hard-limit of 125MB per key-value object (on windows). i don't have anything actionable. just want people aware of datapoint, and think about javascript-language-design to improve UX-handling with sqlite3-persistence. fyi, ignoring persistence, chrome can handle wasm-sqlite3 datasets as large as 300MB (1.5 million rows) in memory, before crashing (on 8gb windows10 machine). [1] sql.js wasm-sqlite3 https://github.com/kripken/sql.js ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Moving forward with function decorators
Class member decorators are there:
https://github.com/tc39/proposal-decorators
Object method decorators: of course they do make sense but honesty I don't
know do they need to be also included as a part of "function decorators
proposal"? They look and behave very similar to class members. In other
words their decorators also need to accept [target, property, descriptor]
and return the descriptor.
ср, 4 сент. 2019 г. в 14:04, Michael Luder-Rosefield :
> I don't see any mention of class/object shorthand methods; would these be
> trivial, do you think?
>
> ```
> class FooClass {
> @dec1 @dec2
> bar () { }
> }
>
> const fooObj = {
> @dec1 @dec2
> bar () { }
> }
> ```
> --
> Dammit babies, you've got to be kind.
>
>
> On Wed, 4 Sep 2019 at 11:49, Андрей Губанов
> wrote:
>
>> Here I described my thoughts about this topic
>> https://github.com/finom/function-decorators-proposal. The main idea of
>> moving forward with function decorators is to make them behave like there
>> were defined and wrapped by another function, not more, and get rid of any
>> hoisting when they're used.
>>
>> Function expression and arrow functions
>>
>> const foo = @decorator1 @decorator2 function bar() { return "Hello" }
>> // Will become:
>> const foo = decorate([decorator1, decorator2], function bar() { return
>> "Hello" });
>>
>> And
>>
>> const foo = @decorator1 @decorator2 () => "Hello"
>> // Will become:
>> const foo = decorate([decorator1, decorator2], () => "Hello");
>>
>>
>> Function
>> declarations
>>
>> And this is the most important. I propose to make a decorated function
>> declaration behave as let definition.
>>
>> @decorator1 @decorator2 function foo() { return "Hello" }
>> // Will become:
>> let foo = decorate([decorator1, decorator2], function foo() { return "Hello"
>> }); // no hoisting!
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Moving forward with function decorators
I don't see any mention of class/object shorthand methods; would these be
trivial, do you think?
```
class FooClass {
@dec1 @dec2
bar () { }
}
const fooObj = {
@dec1 @dec2
bar () { }
}
```
--
Dammit babies, you've got to be kind.
On Wed, 4 Sep 2019 at 11:49, Андрей Губанов
wrote:
> Here I described my thoughts about this topic
> https://github.com/finom/function-decorators-proposal. The main idea of
> moving forward with function decorators is to make them behave like there
> were defined and wrapped by another function, not more, and get rid of any
> hoisting when they're used.
>
> Function expression and arrow functions
>
> const foo = @decorator1 @decorator2 function bar() { return "Hello" }
> // Will become:
> const foo = decorate([decorator1, decorator2], function bar() { return
> "Hello" });
>
> And
>
> const foo = @decorator1 @decorator2 () => "Hello"
> // Will become:
> const foo = decorate([decorator1, decorator2], () => "Hello");
>
>
> Function
> declarations
>
> And this is the most important. I propose to make a decorated function
> declaration behave as let definition.
>
> @decorator1 @decorator2 function foo() { return "Hello" }
> // Will become:
> let foo = decorate([decorator1, decorator2], function foo() { return "Hello"
> }); // no hoisting!
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Fwd: Moving forward with function decorators
Here I described my thoughts about this topic
https://github.com/finom/function-decorators-proposal. The main idea of
moving forward with function decorators is to make them behave like there
were defined and wrapped by another function, not more, and get rid of any
hoisting when they're used.
Function expression and arrow functions
const foo = @decorator1 @decorator2 function bar() { return "Hello" }
// Will become:
const foo = decorate([decorator1, decorator2], function bar() { return
"Hello" });
And
const foo = @decorator1 @decorator2 () => "Hello"
// Will become:
const foo = decorate([decorator1, decorator2], () => "Hello");
Function
declarations
And this is the most important. I propose to make a decorated function
declaration behave as let definition.
@decorator1 @decorator2 function foo() { return "Hello" }
// Will become:
let foo = decorate([decorator1, decorator2], function foo() { return
"Hello" }); // no hoisting!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
