profile
viewpoint
Nickolay Platonov canonic-epicure http://bryntum.com Russia http://joose.it

bryntum/chronograph 55

A reactive state management system with novel and unique properties

canonic-epicure/JooseX-CPS 7

Some syntax sugar for 'Continuation Passing Style' in Joose

canonic-epicure/JooseX-Attribute 6

Additional features for Joose attributes

bryntum/fiesta 4

Collaborative creation of test cases for Siesta

canonic-epicure/ExtX.Layout 4

Collection of layouts for ExtJS

canonic-epicure/joosex-bridge-ext 4

Bridge from Joose to Ext3

canonic-epicure/Dist-Zilla-Plugin-JSAN 3

JSAN plugin for Dist::Zilla

canonic-epicure/HTTP-Request-Provider 3

Cross-platform HTTP request implementation

canonic-epicure/JooseIt 3

Joose.it website, business card of Joose project

canonic-epicure/JooseX-Meta-Lazy 3

Role to make metaclass 'lazy'

push eventbryntum/chronograph

nickolay

commit sha 709307b141eb846ec8d802eb8985d2378f9c7ca1

optimized imports

view details

nickolay

commit sha 799548fd0a5efa5411fbf4d1c224ce070d7f985e

test name

view details

nickolay

commit sha 120be76a811f27d08c60a79d3ac656e00739686d

starting on the async computations

view details

push time in 3 days

issue commentbryntum/support

Chrono calculation ends up in infinite loop and hangs out the browser

Seems not a bug, just a race condition in test. Passes in this form:

    t.iit('Should undo removing', async t => {
        gantt = await t.getGanttAsync({
            tasks : [
                {
                    id        : 1,
                    startDate : '2017-01-16',
                    duration  : 1
                },
                {
                    id        : 2,
                    startDate : '2017-01-16',
                    duration  : 1,
                    expanded  : true,
                    children  : [
                        {
                            id        : 3,
                            startDate : '2017-01-16',
                            duration  : 1
                        }
                    ]
                }
            ],
            // it doesn't hang out with no dependencies
            __dependencies : [],
            dependencies : [
                {
                    id        : 10,
                    fromEvent : 1,
                    toEvent   : 3
                }
            ],
            resources : [],
            assignments : []
        });

        const
            { project }   = gantt,
            { taskStore } = project,
            task          = taskStore.getById(3),
            stm           = project.getStm();

        t.chain(
            { waitForPropagate : project },
            async() => {
                project.commitCrudStores();
                stm.enable();
                stm.startTransaction();

                taskStore.remove(task);
            },
            { waitForPropagate : project },
            async() => {
                stm.stopTransaction();

                stm.undo();
            },
            { waitForPropagate : project },
            async() => {
                t.notOk(taskStore.changes, 'No changes found');
            }
        );
    });

What was happening in previous was that, its not valid to use the trigger config for the waitForPropagate chain step. Siesta first starts to wait for the condition and then calls the trigger. So the waitForPropagate was completing even before the trigger was called.

However, the test passes for me, only if I modify the waitForPropagate to:

        waitForPropagate : async function(partOfProject, ...args) {
            partOfProject = partOfProject.project || partOfProject;

            const { replica } = partOfProject;

            return this.waitFor(() => replica && !(/*replica.dirty || */replica.hasPendingAutoCommit() || replica.isCommitting), ...args);
        },

Which seems to be more correct for me, but might affect the other tests. I'll create a PR with this new test and the change for waitForPropagate.

pmiklashevich

comment created time in 4 days

push eventbryntum/chronograph

nickolay

commit sha e6e0238fa80068e3f91d607c19ed9905b2e87aa8

progress on tests

view details

nickolay

commit sha c9b51d7f8c291432fee6932f41081a782b476bdd

progress on tests

view details

nickolay

commit sha ecfba9e94c70fac8e54c2a57fdd845144112a879

- some DRY between the various calculation paths - do not use `startCalculation` API for regular sync calculations

view details

push time in 11 days

push eventbryntum/chronograph

nickolay

commit sha 238df70f27a0db37ea4844cc3074be8cad9cc14d

handle the possibility of epoch change

view details

push time in 11 days

push eventbryntum/chronograph

nickolay

commit sha 4cbfc3a456439843d20ba7a16b0cacedca67026f

refactoring tests

view details

nickolay

commit sha 15c8d490dca0bb7aeeaa48f32e2a3dfb2bd67136

making tests common - testing both sync and gen calculations

view details

nickolay

commit sha c84fcdcf55590ea7ba26f6b744be51aa79359a0c

making tests common - testing both sync and gen calculations

view details

push time in 18 days

push eventbryntum/chronograph

nickolay

commit sha 13e4c6cd763b608b5b70a56a9339a159cd142fec

test for calculable box gen

view details

nickolay

commit sha fb1842d9a7b295e7509e5c4a085e83ec8e437f24

introducing calculable box gen

view details

push time in 18 days

push eventbryntum/chronograph

nickolay

commit sha 6e71d9c450c2719a830175f1202da4422fe72ea7

added old definition of `Mixin` type helper

view details

nickolay

commit sha 2bc4ca2763df25f5547d7c84d867fd5085595dea

generic argument `V` for value of `BoxImmutable`

view details

nickolay

commit sha fb16b0e20511c2fecb406ca856dd2002ae9cce4a

comment

view details

nickolay

commit sha 2c84555f4d3b485e8e5a929b3d9f72b635d3ba11

generic

view details

push time in 19 days

push eventbryntum/chronograph

nickolay

commit sha dc377b724938c0bb86c354b95c48865ac0d4ed26

new test

view details

nickolay

commit sha 4f14b49567d060253ff7d8669398bc51832c0bb1

comment

view details

nickolay

commit sha 4615141d4bca0254e1ae7a3b6098a1565620afa2

new test

view details

nickolay

commit sha 12f01339830f96715ef2edba5cebcf0858c9aaf4

test fix

view details

push time in 19 days

push eventbryntum/chronograph

nickolay

commit sha a2996ce13768b75bb11a7620bc9b86d76cf5ab25

measure with rejection enabled

view details

nickolay

commit sha 7105bfbf97d182074a6c407e3c42cc317deb7cf0

state

view details

nickolay

commit sha c3fba58b9efcb2e1167e0edcd6efef26ed407c50

garbage collection

view details

nickolay

commit sha 61bc29eb65c52e4476fbec1488e5f213e66aaf77

comment

view details

nickolay

commit sha 813e28302ba6462f5a0960a83fae768ed87797d0

fixed recursion into visited atoms

view details

push time in 20 days

push eventbryntum/chronograph

nickolay

commit sha 4d0264899541671b78d18dcfe601d33eb9b88d80

slight refactoring of iteration

view details

nickolay

commit sha fb5e17e00a22a5f8cc2c2d15dd65e4efd5af2a87

keepLastResult option

view details

nickolay

commit sha ff87fb167624eb1d3918dc95e53a526dacc897d0

set owner on the owner's side

view details

nickolay

commit sha b32088742f1e6588df668367468c1bcb0796fc57

moved `immutableForWrite` from Box to Atom

view details

nickolay

commit sha ccbcb894a614f1daf42e83a391a4b840851e7c25

keep last result tweak

view details

nickolay

commit sha a9f14acb6b33f53020ae9937a8f1516c46008e2a

`historyLimit : 0` should enable rejection feature and only store 1 transaction except the currently running one

view details

nickolay

commit sha 7bffe15adaa05888a0e2aad4daab61973d7d52dc

`keepLastResult` for memory snapshots

view details

nickolay

commit sha 95df0ff7dfd60ea1244dff758ec0a1872ebcca72

// need to keep the order of edges addition, otherwise // performance degrades

view details

nickolay

commit sha 6c498f3f8210ad3175097e66c925bcd8d10fd5f5

comments

view details

push time in 20 days

push eventbryntum/chronograph

nickolay

commit sha d4885816b3663287555492b7b362ffe8c785a5ff

need to mutate the `nextTransaction` at the end, after all mark/unmark operations has completed

view details

nickolay

commit sha 4f381e69a4780e9bc902049edce3cba6171cfdd8

additional test

view details

push time in 23 days

push eventbryntum/chronograph

nickolay

commit sha d94e0d1ee210873fdd872f2c8b9cbda3ce178792

commit in empty graph

view details

nickolay

commit sha 84e4940d09af1d401984279b81ed17191357d95c

tests

view details

nickolay

commit sha 7a62f25e991252d252a83c204e0a894097e6f960

support redo after undo-ing all transactions

view details

nickolay

commit sha d0254aa44d7268bd61920b8bf3c5c8d400eb75c9

correctly save atom state in the quark, to be able to preserve the staleness

view details

push time in 23 days

push eventbryntum/chronograph

nickolay

commit sha 747c61dfead0d166bcb20cfcd8539430c4c8cd26

option to enable profiling of the benchmark

view details

nickolay

commit sha b2995f21547e5ea17bb2f9d99f42253e7f98ec82

collect garbage as part of commit

view details

nickolay

commit sha e7cc8f1e096694f858ea937e209e21229459babe

access storage properties directly

view details

nickolay

commit sha f4fbe0ea6e99d6e77c1ad0f47bb3a9ff140a14cf

option for profiling

view details

nickolay

commit sha 5fb5515602a6403b51756a308ba37ea57a93060a

test for redo

view details

nickolay

commit sha 510c99fc4696f1a55b0bc7b07244665ed9f4f838

undo benchmark

view details

nickolay

commit sha 16c796e20ccb9c7b436e59ebf8dc5a4b3a17632a

commit benchmark

view details

push time in 24 days

push eventbryntum/chronograph

nickolay

commit sha 34ff7f78bc736d8f6089803f103688693f249003

add strict atoms to transaction

view details

nickolay

commit sha 4f374b3a8bbc6d3e1c8a504d96ea91387aeb9feb

comments

view details

nickolay

commit sha 4e8ba3dbc336bd8698b1cbe54b594e571ab90fed

names

view details

nickolay

commit sha 66c7f78eadeb836f86035affa4c0efa37cea8fa9

fixed garbage collection test

view details

push time in 25 days

push eventbryntum/chronograph

nickolay

commit sha abe6b576b0659bfe16a15c129e0079b3126f0554

progress on benchmarks

view details

nickolay

commit sha 00a14183d2de5a3fb060ab6583d011cd3ae512a2

reject after reject should do nothing

view details

push time in 25 days

push eventbryntum/chronograph

nickolay

commit sha 5b0f7eb10637da2e2431e144f813af4a3c3c7cc7

progress on benchmarks

view details

push time in 25 days

push eventbryntum/chronograph

nickolay

commit sha 172680747644f64a896da1a206e1563a52f451bd

progress on benchmarks

view details

nickolay

commit sha 8cc37097294ccf77faec779d93f2f7a278f79592

progress on benchmarks

view details

nickolay

commit sha 5a1d057a5cb086a01ac1d2e5093d35ccc83674ac

progress on benchmarks

view details

nickolay

commit sha a653265f27cf74f2ab19a4a76887134e223288e4

progress on benchmarks

view details

nickolay

commit sha a4d857c47dd28502f8da960a43878fbd2dca5d73

progress on benchmarks

view details

nickolay

commit sha cdd48aa0100dc9cb1186e7dec2f1612e8322d8a1

add strict atom to transaction on add

view details

nickolay

commit sha af7a2c17dcf3f6bc09c5e28066a9b517ff58365d

progress on benchmarks

view details

nickolay

commit sha 64f6413594c098f458377aec14515c311832ac02

clear for leveled queue

view details

nickolay

commit sha 297fd3bc56466c48cf2e6fa1a551b962244cfe8f

progress on benchmarks

view details

nickolay

commit sha 2e60b0bf417e54463a5bab6fe14e9e7e6af97493

failing test

view details

nickolay

commit sha 96ce4fa096ed6d813bd46bf4de20c69b86d7b7ef

name for iteration

view details

nickolay

commit sha 08b009340866a575da6bf3605ea02a29a1c3f3c0

clear stack on reject

view details

nickolay

commit sha 10c176bf1378ee3b724a0c5a989d387b99f51533

equality for value comparison

view details

nickolay

commit sha dc7a22c2d871aac37c2b6dcf5f493d332f06cdd3

start revisions from 0

view details

nickolay

commit sha 6a6705afa848ab6166446c941db6bc4142f22da1

correct atom state handling during rejection

view details

push time in 25 days

push eventbryntum/chronograph

nickolay

commit sha e2141b925e55421be576471d74296151ace9c228

progress on benchmarks

view details

nickolay

commit sha a2a557e01fc733076abbbae24c02cece4ce4cc18

random progress

view details

nickolay

commit sha 8096f3bc0ed6c48de6ef330a003203db9198eaba

cleanup

view details

nickolay

commit sha 5242eb156f4be2c5d76132a94c219b8870740fb5

comments

view details

nickolay

commit sha 4c27463330ac692a50b87fcc82048ab7489d0306

comments

view details

nickolay

commit sha 6325bc5eb360c4c9b781a00c8765efa304561202

'propagateStaleDeep' = propagatePossiblyStale + propagateStaleShallow

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha 0fffde653804db6f2b9f099e5bcd515be6fa965b

progress on benchmarks

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha b0d27fadc488e109acd6561bae8e89ba86a29e45

additional scripts

view details

nickolay

commit sha e01279354c1ddaf55808775f336545bc5b288c5d

garbage collection info + different delays

view details

nickolay

commit sha 422da9338bfa609634bbd851eea3f823de968e45

progress on benchmarks

view details

nickolay

commit sha ef904722fc079701ae70be9c24d5f12d9943266d

progress on benchmarks

view details

nickolay

commit sha e9740b6d3e9d525acd8b6093d03e643bc255f2a8

progress on benchmarks

view details

nickolay

commit sha 5d1030adb9e370afaec8519d504336254f393772

progress on benchmarks

view details

nickolay

commit sha 9ef82cbc21d76f00ce1f280140f9f32e94054de5

progress on benchmarks

view details

nickolay

commit sha 1089f64124a3a79fbc6efbd5f4ff775460b8305a

progress on benchmarks

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha c7243af76b3f53910d0d7fce87972c35b78ed074

comment

view details

nickolay

commit sha 12b2072a295f80bab83c04c87d919af810d24cc3

folder renamed

view details

nickolay

commit sha 001748a06463e1595a7dd57d32ceabbe9e3c4c75

moving code

view details

nickolay

commit sha 1a5a439c4545dde9745f2652526dcb20ffbab0cb

moving code

view details

nickolay

commit sha 68d868d1a30c64a7db8c6221efb57e0742997b65

await garbage collection

view details

nickolay

commit sha c8ab3652f87b449119dea97da860938b1a8ee6d2

progress on benchmarks unification

view details

nickolay

commit sha 1d86d83a709889e19e357cf908fd019025d33603

progress on benchmarks unification

view details

nickolay

commit sha b9258abca47995224d8c634d8a884e48495c947c

progress on benchmarks unification

view details

nickolay

commit sha b83a48913584359418802eb26eaf3c5cd999b492

performance fix - should not have cyclic imports

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha fd7a6376cd02d3707b5463f607f6178853d4d5fe

progress on garbage collection

view details

nickolay

commit sha 385b984b1aa3a77007d23d0b5b3c6aa33903cb13

- added "pseudo" freezing for `historyLimit === 0` case - reject tests improved

view details

nickolay

commit sha 35de98da03ad45a6021f8129931216ca49ad4496

- tests

view details

nickolay

commit sha 4efe86a9293c70966da1189e47b97a60f2fe2dea

array filling benchmark

view details

nickolay

commit sha d46af0e887057e9cfe84648c474574fa79266d53

progress on garbage collection

view details

nickolay

commit sha 9b44ccf4d61b2a743577821b5e44ea4602224038

progress on garbage collection

view details

nickolay

commit sha 3e8a3beea98186275d3f428fbf11a78a5ed165fc

tweaks

view details

nickolay

commit sha 9e803baa1f471616dd94cc96aeac5a430bc89899

tweaks

view details

nickolay

commit sha 0f58195b4b0e16c8aa963fd824ac1812b21902eb

todo test

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha 56b316031e05ffde26488a4b4bbe805567583cf9

benchmarking object as map

view details

nickolay

commit sha 1c6f04aa3d3f2a50196a563c09066e12162607ea

progress on garbage collection

view details

nickolay

commit sha a622d4cf9d8534a809d6b7e4c3efc58dc0bf0589

progress on garbage collection

view details

nickolay

commit sha b2f6eccd3635bbe147bdf7e362da94616b690090

progress on garbage collection

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha 80ff406c4c6936d8e3a545cfc47a2bd8bc6bba0b

docs

view details

push time in a month

issue commentmicrosoft/TypeScript

Recursive definitions in mixins

@orta This is because you haven't created an "abstract" mixin type - a type that represents instance of any class that has consumed a mixin. You only work with specific classes. Abstract "Scalable" would look like:

// supporting declarations for mixin pattern
export type AnyFunction<A = any>      = (...input: any[]) => A
export type AnyConstructor<A = any>   = new (...input: any[]) => A
export type Mixin<T extends AnyFunction> = InstanceType<ReturnType<T>>

function Logger<TBase extends Constructor>(Base: TBase) {
  return class Logger extends Base {
 };
}

type LoggerT = Mixin<typeof Logger>  // "abstract" mixin type 

Actually, I just checked and the originally submitted code seems to work starting from 3.8.2!! (The version picker in playground is awesome). It does not work in 3.7.5 and prior.

Hopefully this was an intentional improvement, properly covered with a test, not a random codebase fluctuation. Could you check may be?

canonic-epicure

comment created time in a month

push eventbryntum/chronograph

nickolay

commit sha b73c91ff816625e32fc4784e8a04f6ec70407f0f

- progress on undo/redo in branch

view details

nickolay

commit sha b5023743e5de9f0a0d9403c4de28022bd5b10515

optimized imports

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha 2bc635e0298a226c3d6a9e2c6670781acdae9794

- progress on undo/redo in branch

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha 3244ab8fc39de5264292bc0e0c217c9ce47090ee

comment

view details

nickolay

commit sha 193b100a10853587dd9357a4578b1d785fe92718

iteration and transaction moved to own files

view details

nickolay

commit sha 61de3339dbb2fee9497595dbdad764d904e6afc9

restructure folders

view details

nickolay

commit sha 82dfd8bab7d73546e9df5c396c98488ac8d62d47

optimized imports

view details

nickolay

commit sha feb9d249677dfe85b2c835f65348b94be4fdcd8e

test for strict atoms

view details

nickolay

commit sha 0d221906f840152d842952ad29517329aa93f858

- introduced atom identity - DRY cleanup in undo/redo - progress on garbage collection

view details

push time in a month

push eventbryntum/chronograph

nickolay

commit sha c7fb7269cca9a59347587ad71351e981da4d00c6

progress on branching

view details

nickolay

commit sha c273a858dfa1a4fbd46d83af3efde4e69b92756e

configurable compact settings

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 8bd8cac8a1faaed599d5782735f4d556a1e60f9a

cleanup

view details

nickolay

commit sha 9655018b5e178cde24ad350b4e8c65cbc628222d

has to be number

view details

nickolay

commit sha caf671c0e5e2c25915cbc2a081582283d542574a

ups, was reading from the same atom

view details

nickolay

commit sha 5389c6b6c0dcd6bfc6eb6b879ecce2ef6d720c94

progress on branching

view details

nickolay

commit sha 328cd6dec84c11e6031e01c99bbbc2cc480280ed

progress on branching

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 4f96908f20091abc6a5cd5693f400256c6c549bf

discord link

view details

nickolay

commit sha 6a5f3bbd372a8896d75212acab27f93ff07b4126

discord link

view details

nickolay

commit sha edcdf552ec282ff4df9f243be8be33df96cfa3d7

- Fixed a bug, that calculation function from the entity super-class could leak to the sub-class.

view details

nickolay

commit sha 3251e1ebfcac6ddb2b418cba37d86973b3e74f0c

docs

view details

nickolay

commit sha 0e8ba340b7a25e36b7182a2d330647ea4703571c

docs

view details

nickolay

commit sha c6bb0f0be52c96d9d3857d0b55a12ce26a5379c4

Merge remote-tracking branch 'origin/master' into chrono2

view details

nickolay

commit sha df7171081a1bcc42dfeb546acb29a08b78446838

renamed cytoscape example

view details

nickolay

commit sha 21f1fdc132a3352625be4cd683d8ecae5830663f

clear counter

view details

nickolay

commit sha 1cceb07e328e2bb6b4b3aa54dfb742d6d0c4b5cf

progress on branching

view details

nickolay

commit sha bd11c59b185fe6e277f1cb03a1f01e84d03036ed

progress on branching

view details

nickolay

commit sha ce435c7733c8573bea4f331fbae6dc43eff5086a

progress on branching

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 6b77953a43f91b356ddc0e5c686f42c4d1ea5898

discord link

view details

push time in 2 months

issue commentnonara/ts-patch

[Question] Any example of macros-like, source-modifying transformer?

Thank you! It seems this task is more complex than I thought initially. However, as you mentioned, it seems that it is doable. It is very tempting to implement it - the possibilities looks endless. I'll be making attempts from time to time. Hopefully one day I'll submit a PR with support for type : 'macros' transformers :)

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

Thank you! Will definitely save time for future new users!

canonic-epicure

comment created time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 0e8ba340b7a25e36b7182a2d330647ea4703571c

docs

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 3251e1ebfcac6ddb2b418cba37d86973b3e74f0c

docs

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 6a2a09b894e1468a828d800714e1f332f1131c64

comment

view details

nickolay

commit sha d1f340a290f66c222bbc5e95caec3b1609cd498e

benchmarks

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 7dee10ad8ccf8e6a73eba64222b309831e4d97fc

progress on `forEachOutgoing`

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 60b161ed7c1c2ef6d7f3598a2bde985f007b9584

ignore vscode files

view details

nickolay

commit sha 6635bf464c410da491406ad012d3fe7e49ecb7fd

progress on benchmarks

view details

nickolay

commit sha 9a95af4a5741153a243b855fa222a6190f3a8577

progress on benchmarks

view details

nickolay

commit sha d8a14ded165fd8fd1f191af8de868f3b19fe39f7

uniqable tweaks

view details

nickolay

commit sha dad01dcd4ec6bb35450ee5facf95629f5b4c1bae

progress on `forEachOutgoing`

view details

nickolay

commit sha e4088503c22f1c3ed9b76e79830701c3f00e7400

progress on `forEachOutgoing`

view details

nickolay

commit sha c7b0c8f4ca5b1bed8e62e92625c300880100d7c7

progress on `forEachOutgoing`

view details

nickolay

commit sha d43bee34aff211565b0d8b9f8333b200b583f24d

progress on `forEachOutgoing`

view details

push time in 2 months

issue commentnonara/ts-patch

[Question] Any example of macros-like, source-modifying transformer?

It would be technically possible to do by doing a regular transform and using ts-patch diagnostic altering functions to find and remove diagnostic errors regarding references to added properties.

@nonara That would work, however it would be just a workaround for this particular case. I'm aiming for a general solution that can introduce new symbols, including new types (want to implement transformer for mixins, may be for sum types etc).

for now ts compiler doesn’t allow pre transformation of the source code. it is heavily depends on source text. it is possible, but the way is very tricky - in fs reading stage you parse ts file, transform it, then compile again to ts source and then provide result text file to the compiler. but this way has caveats like you lose original positions and errors and sourcemaps will be broken. to avoid that you should to remap these lines manually by patching methods which work with positions

@cevek Is there any example available?

What if the new symbols will be all placed on the same line - that way the positions of other symbols in the file won't change?

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

Oh, yes, now the host config is filled, of course.

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

Oh, actually, there is an example of configuration similar to mine:

{
    "compilerOptions": {
        "plugins": [
            { "transform": "./transformers/my-transformer.ts", "type": "program" },
        ]
    }
}

But it is clearly incorrect.

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

So I was missing how the "program" transformers are specified.

Docs says:

type | Plugin entry point format (see: Type Signatures)

And in the "Type Signatures" the first line says:

program (default)

So I've happily configured my transformer as:

        "plugins": [
            { "transform": "../typescript-transformer-lazy-property/src/Transformer.ts", "type" : "program" }
        ],

Whereas, after examining docs more thoroughly, it needs to be:

        "plugins": [
            { "transform": "../typescript-transformer-lazy-property/src/Transformer.ts", transformProgram : true }
        ],

Perhaps its worth updating the docs (removing the "program" from the "type" list).

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

[Question] Any example of macros-like, source-modifying transformer?

It seems for purposes of macros expansion the "program" transformer is hooked too late - onto the "emit" method. By that time, there are already getGlobalDiagnostics and getSemanticDiagnostics called.

How is the "program" transformer different from the "before" and "after"? I'd expect the "program" transformer to completely override the usual TS pipeline.. But I'm biased of course and looking from the macros use case perspective. Probably "program" transformer solves some other use case.

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

Perhaps you meant this signature:

export default function (program : ts.Program, host? : ts.CompilerHost, options? : { ts : typeof ts }) {
...
}

This works correctly (still have to replace host with ts.createCompilerHost(program.getCompilerOptions())). But no added-file.js anywhere in the output again. Perhaps its because it is located in the transfomer's source tree?

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

[Question] Any example of macros-like, source-modifying transformer?

So, no examples of such transformer exists? Very surprising.

@cevek Why the AST -> string -> AST transformation cycle is needed? I might be missing something, but as suggested here, one can override the getSourceFile method of the CompilerHost instance. This method seems to return the already parsed SourceFile. One can just replace the original definition Nodes with expanded?

The source file positions can be kept unchanged for the all Nodes except the newly expanded ones? For the new nodes, one can set the file position to originate at the source node and to have length of 0 may be (to not affect the positions of other code).

Perhaps I'm missing something, as I'm not experienced with transformers yet, but can't believe nobody has already made a "macros" transformer.

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

The code you posted fails with Cannot destructure property 'ts' of 'undefined' as it is undefined

The original code still fails with the same error:

About the

The one area where you may run into problems is if the typescript instance you're importing differs from the one which called the transformer.

Does that mean that versions of TS need to match, or it needs to be exactly the same TS instance, currently its a different instance, yes.

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

This is what I've started from. Double checking the TS versions.

canonic-epicure

comment created time in 2 months

issue openeddsherret/ts-morph

[Question] Integration with `ts-patch`?

Hello,

Am I correct, that currently ts-morph assumes a custom compilation process?

Is it possible to integrate ts-morph with ts-patch or ttypescript? The goal is a seamless enhancement of the TS compiler with the macros expansion abilities.

created time in 2 months

issue openednonara/ts-patch

[Question] Any example of macros-like, source-modifying transformer?

Hello,

I'm trying to implement the following "macros-transformer".

I'd like to expand a definition like:

class SourceClass {
    @lazy
    lazyProperty    : Map<number, string>       = new Map()
}

to:

class TransformedClass {
    $lazyProperty   : Map<number, string>       = undefined

    get lazyProperty () : Map<number, string> {
        if (this.$lazyProperty !== undefined) return this.$lazyProperty

        return this.$lazyProperty = new Map()
    }

    set lazyProperty (value : Map<number, string>) {
        this.$lazyProperty = value
    }
}

And I want to make the $lazyProperty to be available for the rest of the program (to be able to check the lazy value presence).

For that I need the transformation to happen before the type-checking stage in compiler's pipeline. Is there any example of similar transformer? Is this something that can be done with the program transformer?

created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

I've tried with:

/** 
 * Add a file to Program
 */
import * as ts from 'typescript'
import * as path from 'path'

export const newFile = path.resolve(__dirname, 'added-file.ts')

export default function (program : ts.Program, host? : ts.CompilerHost) {
    return ts.createProgram(
        program.getRootFileNames().concat([newFile]),
        program.getCompilerOptions(),
        ts.createCompilerHost(program.getCompilerOptions()),
        program
    )
}

which worked without errors, but I don't see the extra file added-file.ts emitted anywhere (both with and without "outDir" compiler option).

Am I missing something?

canonic-epicure

comment created time in 2 months

issue commentnonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

seems to be the same:

nickolay@frontier:~/workspace/typescript/typescript-transformer-test$ npx ts-patch install
[+] ts-patch installed!
nickolay@frontier:~/workspace/typescript/typescript-transformer-test$ npx tsc
host.useCaseSensitiveFileNames is not a function
nickolay@frontier:~/workspace/typescript/typescript-transformer-test$ npx tsc --version
Version 3.9.5
nickolay@frontier:~/workspace/typescript/typescript-transformer-test$ 
canonic-epicure

comment created time in 2 months

issue openednonara/ts-patch

`program` transformer example from the documentation fails with `host.useCaseSensitiveFileNames is not a function`

Hi,

I'm trying to implement the program transformer and started from the example in the documentation:

/** 
 * Add a file to Program
 */
import * as ts from 'typescript';
import * as path from 'path';
 
export const newFile = path.resolve(__dirname, 'added-file.ts');
 
export default function (program: ts.Program, host?: ts.CompilerHost) {
  return ts.createProgram(
    /* rootNames */ program.getRootFileNames().concat([ newFile ]),
    program.getCompilerOptions(),
    host,
    /* oldProgram */ program
  );
}

Unfortunately, it fails "out of the box" with host.useCaseSensitiveFileNames is not a function error message.

It seems the transformer receives the empty host argument, but then later in the parseConfigHostFromCompilerHostLike there's an assumption it has the useCaseSensitiveFileNames property:

    /* @internal */
    function parseConfigHostFromCompilerHostLike(host, directoryStructureHost) {
        if (directoryStructureHost === void 0) { directoryStructureHost = host; }
        return {
            ........
            useCaseSensitiveFileNames: host.useCaseSensitiveFileNames(),
            .........
        };
    }

Am I missing something?

created time in 2 months

issue commentjustinfagnani/proposal-mixins

Should mixins be inheritance-based?

I think this point

It's a little unclear how multiple mixins ought to work

Is exactly the opposite with inheritance-based mixins (I'm strong proponent of those)

It is very clear, how multiple inheritance-based mixins combines together. And it is very unclear how they combine for copying-based mixins. Here's why:

Inheritance-based mixins, as follows from their name, just performs inheritance. This is a simple, intuitive concept, everybody understands very well. If you combine several mixins - thats just long inheritance chain, thats all. Again, the intuition, developed from the years of work with single-class inheritance answers all questions.

For copying-based mixins there's no such intuition to re-use. You need to write some specification that will define all edge cases:

  • What will happen if 2 or more mixins defines the method/property with the same name? Which one will "win"?
  • In what order the constructors of mixins are called?
  • If some method is defined in the mixins and in the class itself - what is the order of calls for super chain?
  • What will happen if in one mixin some property is private, but in another public? etc, etc
zenparsing

comment created time in 2 months

push eventbryntum/chronograph

nickolay

commit sha ec45683cf42d0518d183a3c0b1a102e43a2816c8

more compact

view details

nickolay

commit sha 2345a651e44ebe4b15d2670f93fcb5d7cd081ba1

intermediate array surprisingly improves performance (better memory locality?)

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha cc6d81c056b627a5e840fdb9db3fe0091a2da423

progress on tests

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha a290742ffd15d42218eb9f46c6cd3b15215990da

micro optimization

view details

nickolay

commit sha 2421d6be400b3ef8308268c791ce631fd301295f

test fix

view details

nickolay

commit sha 54146afc7b5dfb0944fa4270a13d372a4926980c

microoptimization was a bug

view details

nickolay

commit sha bc21e44e4fc0e948087e962aaa31755d4433c732

progress on test, performance regression

view details

nickolay

commit sha 9ba120badb36aa2b2b7a1d55720b1988ad39cfcd

box name, progress on test, performance regression

view details

nickolay

commit sha 76045fd540bfcd21e69e458a03fdc71437a0039f

progress on tests

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 14c83881d924c00a3d31b050c49035aad99b20a5

benchmark only chrono2

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 7a3cc7550d0a3840cb68408ebf423db82f3116bf

progress on undo/redo/reject

view details

nickolay

commit sha 2b3f0cdc1e96acb6febd9bb586e322f5e7cf12ca

uniqable tweak

view details

nickolay

commit sha ef905477605dcd389f894342ff797a3aaec3cfba

progress on undo/redo

view details

nickolay

commit sha 7c7631a1c1dc5c7d1284351c48f1bd76b4593abb

stale edges

view details

nickolay

commit sha b8a58a02b2ac42fec5c87c6af4d7c8af13db0b68

compilation errors

view details

push time in 2 months

issue openedbryntum/support

Expose ChronoGraph symbols in UMD bundles

Users start to customize the engine: https://www.bryntum.com/forum/viewtopic.php?f=51&t=14360&p=73531#p73531

and they will need access to various ChronoGraph symbols. So we need to expose those somewhere in the UMD bundles.

Probably will be best to expose a single object ChronoGraph with all those symbols.

Symbols needed:

ProposedOrPrevious, Reject, PreviousValueOf, ProposedValueOf, HasProposedValue from `src/chrono/Effect.js'

created time in 2 months

push eventbryntum/chronograph

nickolay

commit sha edcdf552ec282ff4df9f243be8be33df96cfa3d7

- Fixed a bug, that calculation function from the entity super-class could leak to the sub-class.

view details

push time in 2 months

issue closedmobxjs/mobx

Stale dependencies should not be used

Hello,

Found a case when a stale dependency is affecting a graph.

Use this sandbox to reproduce: https://codesandbox.io/s/cool-murdock-pu0tc?file=/src/index.js

What happens in the test:

  1. A small graph is established, in which one node is "dispatcher" - contains reference to another node.
const i1 = observable.box(0);
const i2 = observable.box(1);
const dispatcher = observable.box(i1);
  1. Computed value depends on dispatcher and the node it contains
let counter = 0;
const c1 = computed(function() {
  counter++;
  return dispatcher.get().get() + 1;
});
  1. First iteration, dispatcher contains reference to i1, we compute the value of c1 based on the value of i1
  2. We write i2 to dispatcher and re-compute c1, which now depends on i2 instead of i1. The dependency from i1 to c1 becomes stale.
dispatcher.set(i2);

is(counter, 0);

// during these reads the `c1` will acuire a dependency on `i2` and old dependency on `i1` will become "stale"
is(c1.get(), 2);

is(counter, 1);
  1. We write to i1 and this write is expected to not affect c1. In reality c1 becomes stale and recomputed.
// this write should not affect `c1` since it depends on `i2`
i1.set(10);

is(counter, 0);

is(c1.get(), 2);

is(counter, 0); // <---  THIS THROWS

closed time in 2 months

canonic-epicure

issue commentmobxjs/mobx

Stale dependencies should not be used

Thanks for the explanations, it seems to work with { keepAlive : true }. Closing it.

canonic-epicure

comment created time in 2 months

issue openedmobxjs/mobx

Stale dependencies should not be used

Hello,

Found a case when a stale dependency is affecting a graph.

Use this sandbox to reproduce: https://codesandbox.io/s/cool-murdock-pu0tc?file=/src/index.js

What happens in the test:

  1. A small graph is established, in which one node is "dispatcher" - contains reference to another node.
const i1 = observable.box(0);
const i2 = observable.box(1);
const dispatcher = observable.box(i1);
  1. Computed value depends on dispatcher and the node it contains
let counter = 0;
const c1 = computed(function() {
  counter++;
  return dispatcher.get().get() + 1;
});
  1. First iteration, dispatcher contains reference to i1, we compute the value of c1 based on the value of i1
  2. We write i2 to dispatcher and re-compute c1, which now depends on i2 instead of i1. The dependency from i1 to c1 becomes stale.
dispatcher.set(i2);

is(counter, 0);

// during these reads the `c1` will acuire a dependency on `i2` and old dependency on `i1` will become "stale"
is(c1.get(), 2);

is(counter, 1);
  1. We write to i1 and this write is expected to not affect c1. In reality c1 becomes stale and recomputed.
// this write should not affect `c1` since it depends on `i2`
i1.set(10);

is(counter, 0);

is(c1.get(), 2);

is(counter, 0); // <---  THIS THROWS

created time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 6a5f3bbd372a8896d75212acab27f93ff07b4126

discord link

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 9804f8da7a7fe14296437adc727b30c409f6f662

discord link

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 4f96908f20091abc6a5cd5693f400256c6c549bf

discord link

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 4ae426cad2d365d08ec0aeb46c0d192a533c0c9a

better names

view details

nickolay

commit sha 3e50b83d8dac28acd9227b45374b1fa9ea1a594f

progress on undo/redo

view details

nickolay

commit sha 044b36877ce8d3d91531abb8aa9cca1871c0f2cb

progress on undo/redo

view details

nickolay

commit sha 05bc31a65fb431ff2f9bef2ed3574ded4d019a8d

progress on undo/redo

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 2fa4a092f9f62c263d538fa939913626ae02689c

progress on undo/redo

view details

push time in 2 months

delete branch bryntum/chronograph

delete branch : chrono2-temp

delete time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 8b369ded1f14b08734e38b2d8cfc60fe5b9a271a

WTF

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha de2b4a76458e18c2cf207c008cd0abbe8f32145e

WTF

view details

nickolay

commit sha 8992195f506ef996662c74f300eb2772f120d084

WTF

view details

push time in 2 months

create barnchbryntum/chronograph

branch : chrono2-temp

created branch time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 8ffadb5dcd49f8d0358bdb0ab1a9a819df38f147

`immutable` property on a box should be a property

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 1fdb32034e2482752ce63f3696bd33568bd9000c

compilation errors

view details

nickolay

commit sha 3bc38a980ffe07315c4005d8d8ec8e1ebf0f9283

focus on deep changes

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha a3661a2549939c1962965664cdfb4b672c83741b

google analytics

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha f5942aa6d48f7f7aa444cb32db6065ed0e1ab973

added generic type argument to Box, CalculableBox

view details

nickolay

commit sha 5793d4afbbbb1ec7f139fd1938b01f440174dac8

progress on graph state threading

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 6bf341b477994c1479cd1d0d958d061146638238

record

view details

nickolay

commit sha 9d32123ae789ac84511ee54ce3e0a7104e09a2f8

benchmark

view details

nickolay

commit sha b343eacdfefd9bb4d05d422335eaf3306c983722

progress on graph structure

view details

push time in 2 months

issue commentmicrosoft/TypeScript

Suggestion: Improve type of `constructor` on the instance type of a class

This could be easily done with a macros. Then people would start using it right now, finding corner cases, making evaluation. At some point it would be clear if its good change for everyone or its someones, very specific requirement. In the 1st case this "macros" could be included in the TS core, in the 2nd - nobody cares and TS team does not have to care as well.

But TS team does not want to support macroses out of the box to allow language experiments in the user space. Instead they want to proceed through lengthy discussions, which lasts for years.

rbuckton

comment created time in 2 months

issue commentmicrosoft/TypeScript

Suggestion: Improve type of `constructor` on the instance type of a class

As always there are lengthy discussions about the simple, quality of life proposal:

for every class:

class SomeClass {
}

define the type of constructor property as typeof SomeClass

interface SomeClass {
    readonly constructor : typeof SomeClass
}

Can we have this simple improvement?

rbuckton

comment created time in 2 months

push eventcanonic-epicure/simplex-method-solver

nickolay

commit sha b5bc6b5e1fc615783dd6c0365fd4bc7ca21b8247

switched to using node.js

view details

push time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 2b7b52e1920587f713e142206c475f02aee9bad0

proposedValue progress

view details

nickolay

commit sha 7264dad1eeb30983204614dd8a331862c76e3936

todo

view details

nickolay

commit sha 2a832575bcb73f086556f0f766dffcd5ff081652

starting on graph

view details

push time in 2 months

push eventcanonic-epicure/simplex-method-solver

nickolay

commit sha 6bf65bb84ae5db7c7f73a7600e9c3ac5988127a1

ignore simplex Q values with 0 coefficient near the variable

view details

push time in 2 months

push eventcanonic-epicure/simplex-method-solver

nickolay

commit sha 26d00cbab3c5b9802f3e7cd5bccabdcf54cb4d5f

fix equation subtraction

view details

push time in 2 months

issue commentmicrosoft/TypeScript

TypeScript 4.0 Iteration Plan

@Jack-Works I don't understand your points. Perhaps you mean that macroses will extend parser and create new synatx?

For me, macros is just AST -> AST function, that runs prior typechecker somehow, therefor it can create new AST nodes that will be typechecked regularly. It does not create new syntax however - the input is regular AST, the output too. It does create new nodes in AST.

The discussion will be off-topic for this thread, perhaps to be continued on #compiler channel in discord?

DanielRosenwasser

comment created time in 2 months

push eventbryntum/chronograph

nickolay

commit sha a56830d9c50c9219a3a2be0f9c3dfa477087e3e1

progress on calculation

view details

nickolay

commit sha 7c90434fb4fc99a294a2d2adda629edd5522cc5e

progress on edges

view details

nickolay

commit sha 73b667e606224b7a66fdafd4f06acdfc90f106e7

Node

view details

nickolay

commit sha 963cb5f1aebebb9de6adc4d9287c1ce909cabbf7

Immutable

view details

nickolay

commit sha 819cd3095f0e2c5a937ed1c03b050af12e5f54b1

uniqable

view details

nickolay

commit sha b146b526dd0020e28c25a56066ea999b5eb58ea6

some progress

view details

nickolay

commit sha a7121b21305f2891f9c372c9604e2d2d341eaa55

some progress

view details

nickolay

commit sha d1f2fc073cc293851126fd88720e4109b0c43416

Quarks reduced to merely immutable storage, Atoms performs all logic

view details

push time in 2 months

issue commentmicrosoft/TypeScript

TypeScript 4.0 Iteration Plan

Ok, so 4.0.0 is just a next minor release, good to know.

Regarding the "macroses do not satisfy the TS goal" and "use ttypescript for transformers" (ts-patch works better btw) - this resembles the jedi move - "this is not the feature you need". No, macroses and transformers out of the box please. Its been requested years ago.

DanielRosenwasser

comment created time in 2 months

issue commentmicrosoft/TypeScript

TypeScript 4.0 Iteration Plan

Feels like TS is loosing momentum? Nullish coalescing and short-circuiting assignments for the next, major, 4.0.0 release? No big goals and ambition ideas anymore?

For the next major, I'd expect:

  • Higher kinded typing
  • Dependent typing? Type-level functions? (Ok, this one can be for 5.0.0)
  • Nominal typing
  • Macroses
  • Support for transformers in tsconfig.json
  • Compilation to WASM (of some language subset)
DanielRosenwasser

comment created time in 2 months

issue commentnonara/ts-patch

[Feature request] : Zero configuration

Ok, thanks for reply.

canonic-epicure

comment created time in 2 months

issue openednonara/ts-patch

[Feature request] : Zero configuration

Shouldn't the ts-patch just auto-patch the local TS on installation? If user add ts-patch as dependency, s/he clearly has an intention to patch the TS? This should be doable with npm hooks?

In the same way it can unpatch the TS upon un-installation (if there's a corresponding hook).

This will make ts-pacth zero-configuration utility.

created time in 2 months

created repositorycanonic-epicure/typescript-transformer-lazy-property

created time in 2 months

push eventbryntum/chronograph

nickolay

commit sha 4a6d08ab4ee0223d645b9b773ec0abb03ab8e97b

progress on Box

view details

nickolay

commit sha 31e0675c2d65ba17e89eeea61718e4c1071cc4eb

progress on Box & Record

view details

nickolay

commit sha edaa1942571cfc7a71a85e92dd89ce82c2bbd3f1

progress on Box & Record

view details

nickolay

commit sha c7ef203f0004a2c99067755d5e972bd402fd3563

progress on CalculableBox

view details

nickolay

commit sha f6d886895b1ca8b67f61217e14ee65b7994431d4

progress on CalculableBox

view details

push time in 2 months

push eventSamuraiJack/simplex-method-solver

nickolay

commit sha 913ff0a9c01523c6055a4523532338065af9acfd

do not minimize

view details

push time in 2 months

push eventSamuraiJack/simplex-method-solver

nickolay

commit sha ff796ed0805bcef6b6c7cd2e733a4883ddfc05f5

additional options

view details

nickolay

commit sha 112320a0866ca9089c142072298a5a42d49d0f13

additional options

view details

push time in 2 months

delete branch bryntum/chronograph

delete branch : better_mixins

delete time in 2 months

delete branch bryntum/chronograph

delete branch : calls-queue

delete time in 2 months

delete branch bryntum/chronograph

delete branch : cutoffs

delete time in 2 months

delete branch bryntum/chronograph

delete branch : cycle_dispatcher

delete time in 2 months

more