A reactive state management system with novel and unique properties
Some syntax sugar for 'Continuation Passing Style' in Joose
canonic-epicure/JooseX-Attribute 6
Additional features for Joose attributes
Collaborative creation of test cases for Siesta
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
Joose.it website, business card of Joose project
canonic-epicure/JooseX-Meta-Lazy 3
Role to make metaclass 'lazy'
push eventbryntum/chronograph
commit sha 709307b141eb846ec8d802eb8985d2378f9c7ca1
optimized imports
commit sha 799548fd0a5efa5411fbf4d1c224ce070d7f985e
test name
commit sha 120be76a811f27d08c60a79d3ac656e00739686d
starting on the async computations
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.
comment created time in 4 days
push eventbryntum/chronograph
commit sha e6e0238fa80068e3f91d607c19ed9905b2e87aa8
progress on tests
commit sha c9b51d7f8c291432fee6932f41081a782b476bdd
progress on tests
commit sha ecfba9e94c70fac8e54c2a57fdd845144112a879
- some DRY between the various calculation paths - do not use `startCalculation` API for regular sync calculations
push time in 11 days
push eventbryntum/chronograph
commit sha 238df70f27a0db37ea4844cc3074be8cad9cc14d
handle the possibility of epoch change
push time in 11 days
push eventbryntum/chronograph
commit sha 4cbfc3a456439843d20ba7a16b0cacedca67026f
refactoring tests
commit sha 15c8d490dca0bb7aeeaa48f32e2a3dfb2bd67136
making tests common - testing both sync and gen calculations
commit sha c84fcdcf55590ea7ba26f6b744be51aa79359a0c
making tests common - testing both sync and gen calculations
push time in 18 days
push eventbryntum/chronograph
commit sha 13e4c6cd763b608b5b70a56a9339a159cd142fec
test for calculable box gen
commit sha fb1842d9a7b295e7509e5c4a085e83ec8e437f24
introducing calculable box gen
push time in 18 days
push eventbryntum/chronograph
commit sha 6e71d9c450c2719a830175f1202da4422fe72ea7
added old definition of `Mixin` type helper
commit sha 2bc4ca2763df25f5547d7c84d867fd5085595dea
generic argument `V` for value of `BoxImmutable`
commit sha fb16b0e20511c2fecb406ca856dd2002ae9cce4a
comment
commit sha 2c84555f4d3b485e8e5a929b3d9f72b635d3ba11
generic
push time in 19 days
push eventbryntum/chronograph
commit sha dc377b724938c0bb86c354b95c48865ac0d4ed26
new test
commit sha 4f14b49567d060253ff7d8669398bc51832c0bb1
comment
commit sha 4615141d4bca0254e1ae7a3b6098a1565620afa2
new test
commit sha 12f01339830f96715ef2edba5cebcf0858c9aaf4
test fix
push time in 19 days
push eventbryntum/chronograph
commit sha a2996ce13768b75bb11a7620bc9b86d76cf5ab25
measure with rejection enabled
commit sha 7105bfbf97d182074a6c407e3c42cc317deb7cf0
state
commit sha c3fba58b9efcb2e1167e0edcd6efef26ed407c50
garbage collection
commit sha 61bc29eb65c52e4476fbec1488e5f213e66aaf77
comment
commit sha 813e28302ba6462f5a0960a83fae768ed87797d0
fixed recursion into visited atoms
push time in 20 days
push eventbryntum/chronograph
commit sha 4d0264899541671b78d18dcfe601d33eb9b88d80
slight refactoring of iteration
commit sha fb5e17e00a22a5f8cc2c2d15dd65e4efd5af2a87
keepLastResult option
commit sha ff87fb167624eb1d3918dc95e53a526dacc897d0
set owner on the owner's side
commit sha b32088742f1e6588df668367468c1bcb0796fc57
moved `immutableForWrite` from Box to Atom
commit sha ccbcb894a614f1daf42e83a391a4b840851e7c25
keep last result tweak
commit sha a9f14acb6b33f53020ae9937a8f1516c46008e2a
`historyLimit : 0` should enable rejection feature and only store 1 transaction except the currently running one
commit sha 7bffe15adaa05888a0e2aad4daab61973d7d52dc
`keepLastResult` for memory snapshots
commit sha 95df0ff7dfd60ea1244dff758ec0a1872ebcca72
// need to keep the order of edges addition, otherwise // performance degrades
commit sha 6c498f3f8210ad3175097e66c925bcd8d10fd5f5
comments
push time in 20 days
push eventbryntum/chronograph
commit sha d4885816b3663287555492b7b362ffe8c785a5ff
need to mutate the `nextTransaction` at the end, after all mark/unmark operations has completed
commit sha 4f381e69a4780e9bc902049edce3cba6171cfdd8
additional test
push time in 23 days
push eventbryntum/chronograph
commit sha d94e0d1ee210873fdd872f2c8b9cbda3ce178792
commit in empty graph
commit sha 84e4940d09af1d401984279b81ed17191357d95c
tests
commit sha 7a62f25e991252d252a83c204e0a894097e6f960
support redo after undo-ing all transactions
commit sha d0254aa44d7268bd61920b8bf3c5c8d400eb75c9
correctly save atom state in the quark, to be able to preserve the staleness
push time in 23 days
push eventbryntum/chronograph
commit sha 747c61dfead0d166bcb20cfcd8539430c4c8cd26
option to enable profiling of the benchmark
commit sha b2995f21547e5ea17bb2f9d99f42253e7f98ec82
collect garbage as part of commit
commit sha e7cc8f1e096694f858ea937e209e21229459babe
access storage properties directly
commit sha f4fbe0ea6e99d6e77c1ad0f47bb3a9ff140a14cf
option for profiling
commit sha 5fb5515602a6403b51756a308ba37ea57a93060a
test for redo
commit sha 510c99fc4696f1a55b0bc7b07244665ed9f4f838
undo benchmark
commit sha 16c796e20ccb9c7b436e59ebf8dc5a4b3a17632a
commit benchmark
push time in 24 days
push eventbryntum/chronograph
commit sha 34ff7f78bc736d8f6089803f103688693f249003
add strict atoms to transaction
commit sha 4f374b3a8bbc6d3e1c8a504d96ea91387aeb9feb
comments
commit sha 4e8ba3dbc336bd8698b1cbe54b594e571ab90fed
names
commit sha 66c7f78eadeb836f86035affa4c0efa37cea8fa9
fixed garbage collection test
push time in 25 days
push eventbryntum/chronograph
commit sha abe6b576b0659bfe16a15c129e0079b3126f0554
progress on benchmarks
commit sha 00a14183d2de5a3fb060ab6583d011cd3ae512a2
reject after reject should do nothing
push time in 25 days
push eventbryntum/chronograph
commit sha 5b0f7eb10637da2e2431e144f813af4a3c3c7cc7
progress on benchmarks
push time in 25 days
push eventbryntum/chronograph
commit sha 172680747644f64a896da1a206e1563a52f451bd
progress on benchmarks
commit sha 8cc37097294ccf77faec779d93f2f7a278f79592
progress on benchmarks
commit sha 5a1d057a5cb086a01ac1d2e5093d35ccc83674ac
progress on benchmarks
commit sha a653265f27cf74f2ab19a4a76887134e223288e4
progress on benchmarks
commit sha a4d857c47dd28502f8da960a43878fbd2dca5d73
progress on benchmarks
commit sha cdd48aa0100dc9cb1186e7dec2f1612e8322d8a1
add strict atom to transaction on add
commit sha af7a2c17dcf3f6bc09c5e28066a9b517ff58365d
progress on benchmarks
commit sha 64f6413594c098f458377aec14515c311832ac02
clear for leveled queue
commit sha 297fd3bc56466c48cf2e6fa1a551b962244cfe8f
progress on benchmarks
commit sha 2e60b0bf417e54463a5bab6fe14e9e7e6af97493
failing test
commit sha 96ce4fa096ed6d813bd46bf4de20c69b86d7b7ef
name for iteration
commit sha 08b009340866a575da6bf3605ea02a29a1c3f3c0
clear stack on reject
commit sha 10c176bf1378ee3b724a0c5a989d387b99f51533
equality for value comparison
commit sha dc7a22c2d871aac37c2b6dcf5f493d332f06cdd3
start revisions from 0
commit sha 6a6705afa848ab6166446c941db6bc4142f22da1
correct atom state handling during rejection
push time in 25 days
push eventbryntum/chronograph
commit sha e2141b925e55421be576471d74296151ace9c228
progress on benchmarks
commit sha a2a557e01fc733076abbbae24c02cece4ce4cc18
random progress
commit sha 8096f3bc0ed6c48de6ef330a003203db9198eaba
cleanup
commit sha 5242eb156f4be2c5d76132a94c219b8870740fb5
comments
commit sha 4c27463330ac692a50b87fcc82048ab7489d0306
comments
commit sha 6325bc5eb360c4c9b781a00c8765efa304561202
'propagateStaleDeep' = propagatePossiblyStale + propagateStaleShallow
push time in a month
push eventbryntum/chronograph
commit sha 0fffde653804db6f2b9f099e5bcd515be6fa965b
progress on benchmarks
push time in a month
push eventbryntum/chronograph
commit sha b0d27fadc488e109acd6561bae8e89ba86a29e45
additional scripts
commit sha e01279354c1ddaf55808775f336545bc5b288c5d
garbage collection info + different delays
commit sha 422da9338bfa609634bbd851eea3f823de968e45
progress on benchmarks
commit sha ef904722fc079701ae70be9c24d5f12d9943266d
progress on benchmarks
commit sha e9740b6d3e9d525acd8b6093d03e643bc255f2a8
progress on benchmarks
commit sha 5d1030adb9e370afaec8519d504336254f393772
progress on benchmarks
commit sha 9ef82cbc21d76f00ce1f280140f9f32e94054de5
progress on benchmarks
commit sha 1089f64124a3a79fbc6efbd5f4ff775460b8305a
progress on benchmarks
push time in a month
push eventbryntum/chronograph
commit sha c7243af76b3f53910d0d7fce87972c35b78ed074
comment
commit sha 12b2072a295f80bab83c04c87d919af810d24cc3
folder renamed
commit sha 001748a06463e1595a7dd57d32ceabbe9e3c4c75
moving code
commit sha 1a5a439c4545dde9745f2652526dcb20ffbab0cb
moving code
commit sha 68d868d1a30c64a7db8c6221efb57e0742997b65
await garbage collection
commit sha c8ab3652f87b449119dea97da860938b1a8ee6d2
progress on benchmarks unification
commit sha 1d86d83a709889e19e357cf908fd019025d33603
progress on benchmarks unification
commit sha b9258abca47995224d8c634d8a884e48495c947c
progress on benchmarks unification
commit sha b83a48913584359418802eb26eaf3c5cd999b492
performance fix - should not have cyclic imports
push time in a month
push eventbryntum/chronograph
commit sha fd7a6376cd02d3707b5463f607f6178853d4d5fe
progress on garbage collection
commit sha 385b984b1aa3a77007d23d0b5b3c6aa33903cb13
- added "pseudo" freezing for `historyLimit === 0` case - reject tests improved
commit sha 35de98da03ad45a6021f8129931216ca49ad4496
- tests
commit sha 4efe86a9293c70966da1189e47b97a60f2fe2dea
array filling benchmark
commit sha d46af0e887057e9cfe84648c474574fa79266d53
progress on garbage collection
commit sha 9b44ccf4d61b2a743577821b5e44ea4602224038
progress on garbage collection
commit sha 3e8a3beea98186275d3f428fbf11a78a5ed165fc
tweaks
commit sha 9e803baa1f471616dd94cc96aeac5a430bc89899
tweaks
commit sha 0f58195b4b0e16c8aa963fd824ac1812b21902eb
todo test
push time in a month
push eventbryntum/chronograph
commit sha 56b316031e05ffde26488a4b4bbe805567583cf9
benchmarking object as map
commit sha 1c6f04aa3d3f2a50196a563c09066e12162607ea
progress on garbage collection
commit sha a622d4cf9d8534a809d6b7e4c3efc58dc0bf0589
progress on garbage collection
commit sha b2f6eccd3635bbe147bdf7e362da94616b690090
progress on garbage collection
push time in a month
push eventbryntum/chronograph
commit sha 80ff406c4c6936d8e3a545cfc47a2bd8bc6bba0b
docs
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?
comment created time in a month
push eventbryntum/chronograph
commit sha b73c91ff816625e32fc4784e8a04f6ec70407f0f
- progress on undo/redo in branch
commit sha b5023743e5de9f0a0d9403c4de28022bd5b10515
optimized imports
push time in a month
push eventbryntum/chronograph
commit sha 2bc635e0298a226c3d6a9e2c6670781acdae9794
- progress on undo/redo in branch
push time in a month
push eventbryntum/chronograph
commit sha 3244ab8fc39de5264292bc0e0c217c9ce47090ee
comment
commit sha 193b100a10853587dd9357a4578b1d785fe92718
iteration and transaction moved to own files
commit sha 61de3339dbb2fee9497595dbdad764d904e6afc9
restructure folders
commit sha 82dfd8bab7d73546e9df5c396c98488ac8d62d47
optimized imports
commit sha feb9d249677dfe85b2c835f65348b94be4fdcd8e
test for strict atoms
commit sha 0d221906f840152d842952ad29517329aa93f858
- introduced atom identity - DRY cleanup in undo/redo - progress on garbage collection
push time in a month
push eventbryntum/chronograph
commit sha c7fb7269cca9a59347587ad71351e981da4d00c6
progress on branching
commit sha c273a858dfa1a4fbd46d83af3efde4e69b92756e
configurable compact settings
push time in 2 months
push eventbryntum/chronograph
commit sha 8bd8cac8a1faaed599d5782735f4d556a1e60f9a
cleanup
commit sha 9655018b5e178cde24ad350b4e8c65cbc628222d
has to be number
commit sha caf671c0e5e2c25915cbc2a081582283d542574a
ups, was reading from the same atom
commit sha 5389c6b6c0dcd6bfc6eb6b879ecce2ef6d720c94
progress on branching
commit sha 328cd6dec84c11e6031e01c99bbbc2cc480280ed
progress on branching
push time in 2 months
push eventbryntum/chronograph
commit sha 4f96908f20091abc6a5cd5693f400256c6c549bf
discord link
commit sha 6a5f3bbd372a8896d75212acab27f93ff07b4126
discord link
commit sha edcdf552ec282ff4df9f243be8be33df96cfa3d7
- Fixed a bug, that calculation function from the entity super-class could leak to the sub-class.
commit sha 3251e1ebfcac6ddb2b418cba37d86973b3e74f0c
docs
commit sha 0e8ba340b7a25e36b7182a2d330647ea4703571c
docs
commit sha c6bb0f0be52c96d9d3857d0b55a12ce26a5379c4
Merge remote-tracking branch 'origin/master' into chrono2
commit sha df7171081a1bcc42dfeb546acb29a08b78446838
renamed cytoscape example
commit sha 21f1fdc132a3352625be4cd683d8ecae5830663f
clear counter
commit sha 1cceb07e328e2bb6b4b3aa54dfb742d6d0c4b5cf
progress on branching
commit sha bd11c59b185fe6e277f1cb03a1f01e84d03036ed
progress on branching
commit sha ce435c7733c8573bea4f331fbae6dc43eff5086a
progress on branching
push time in 2 months
push eventbryntum/chronograph
commit sha 6b77953a43f91b356ddc0e5c686f42c4d1ea5898
discord link
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 :)
comment created time in 2 months
issue commentnonara/ts-patch
Thank you! Will definitely save time for future new users!
comment created time in 2 months
push eventbryntum/chronograph
commit sha 0e8ba340b7a25e36b7182a2d330647ea4703571c
docs
push time in 2 months
push eventbryntum/chronograph
commit sha 3251e1ebfcac6ddb2b418cba37d86973b3e74f0c
docs
push time in 2 months
push eventbryntum/chronograph
commit sha 6a2a09b894e1468a828d800714e1f332f1131c64
comment
commit sha d1f340a290f66c222bbc5e95caec3b1609cd498e
benchmarks
push time in 2 months
push eventbryntum/chronograph
commit sha 7dee10ad8ccf8e6a73eba64222b309831e4d97fc
progress on `forEachOutgoing`
push time in 2 months
push eventbryntum/chronograph
commit sha 60b161ed7c1c2ef6d7f3598a2bde985f007b9584
ignore vscode files
commit sha 6635bf464c410da491406ad012d3fe7e49ecb7fd
progress on benchmarks
commit sha 9a95af4a5741153a243b855fa222a6190f3a8577
progress on benchmarks
commit sha d8a14ded165fd8fd1f191af8de868f3b19fe39f7
uniqable tweaks
commit sha dad01dcd4ec6bb35450ee5facf95629f5b4c1bae
progress on `forEachOutgoing`
commit sha e4088503c22f1c3ed9b76e79830701c3f00e7400
progress on `forEachOutgoing`
commit sha c7b0c8f4ca5b1bed8e62e92625c300880100d7c7
progress on `forEachOutgoing`
commit sha d43bee34aff211565b0d8b9f8333b200b583f24d
progress on `forEachOutgoing`
push time in 2 months
issue commentnonara/ts-patch
@nonara Point is - docs are incorrect.
comment created 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?
comment created time in 2 months
issue commentnonara/ts-patch
Oh, yes, now the host config is filled, of course.
comment created time in 2 months
issue commentnonara/ts-patch
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.
comment created time in 2 months
issue commentnonara/ts-patch
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).
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.
comment created time in 2 months
issue commentnonara/ts-patch
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?
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.
comment created time in 2 months
issue commentnonara/ts-patch
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.
comment created time in 2 months
issue commentnonara/ts-patch
This is what I've started from. Double checking the TS versions.
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
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?
comment created time in 2 months
issue commentnonara/ts-patch
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$
comment created time in 2 months
issue commentnonara/ts-patch
The TS version was 3.8.3, trying with 3.9.5
comment created time in 2 months
issue openednonara/ts-patch
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
superchain? - What will happen if in one mixin some property is private, but in another public? etc, etc
comment created time in 2 months
push eventbryntum/chronograph
commit sha ec45683cf42d0518d183a3c0b1a102e43a2816c8
more compact
commit sha 2345a651e44ebe4b15d2670f93fcb5d7cd081ba1
intermediate array surprisingly improves performance (better memory locality?)
push time in 2 months
push eventbryntum/chronograph
commit sha cc6d81c056b627a5e840fdb9db3fe0091a2da423
progress on tests
push time in 2 months
push eventbryntum/chronograph
commit sha a290742ffd15d42218eb9f46c6cd3b15215990da
micro optimization
commit sha 2421d6be400b3ef8308268c791ce631fd301295f
test fix
commit sha 54146afc7b5dfb0944fa4270a13d372a4926980c
microoptimization was a bug
commit sha bc21e44e4fc0e948087e962aaa31755d4433c732
progress on test, performance regression
commit sha 9ba120badb36aa2b2b7a1d55720b1988ad39cfcd
box name, progress on test, performance regression
commit sha 76045fd540bfcd21e69e458a03fdc71437a0039f
progress on tests
push time in 2 months
push eventbryntum/chronograph
commit sha 14c83881d924c00a3d31b050c49035aad99b20a5
benchmark only chrono2
push time in 2 months
push eventbryntum/chronograph
commit sha 7a3cc7550d0a3840cb68408ebf423db82f3116bf
progress on undo/redo/reject
commit sha 2b3f0cdc1e96acb6febd9bb586e322f5e7cf12ca
uniqable tweak
commit sha ef905477605dcd389f894342ff797a3aaec3cfba
progress on undo/redo
commit sha 7c7631a1c1dc5c7d1284351c48f1bd76b4593abb
stale edges
commit sha b8a58a02b2ac42fec5c87c6af4d7c8af13db0b68
compilation errors
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
commit sha edcdf552ec282ff4df9f243be8be33df96cfa3d7
- Fixed a bug, that calculation function from the entity super-class could leak to the sub-class.
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:
- 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);
- Computed value depends on dispatcher and the node it contains
let counter = 0;
const c1 = computed(function() {
counter++;
return dispatcher.get().get() + 1;
});
- First iteration, dispatcher contains reference to
i1, we compute the value ofc1based on the value ofi1 - We write
i2to dispatcher and re-computec1, which now depends oni2instead ofi1. The dependency fromi1toc1becomes 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);
- We write to
i1and this write is expected to not affectc1. In realityc1becomes 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.
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:
- 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);
- Computed value depends on dispatcher and the node it contains
let counter = 0;
const c1 = computed(function() {
counter++;
return dispatcher.get().get() + 1;
});
- First iteration, dispatcher contains reference to
i1, we compute the value ofc1based on the value ofi1 - We write
i2to dispatcher and re-computec1, which now depends oni2instead ofi1. The dependency fromi1toc1becomes 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);
- We write to
i1and this write is expected to not affectc1. In realityc1becomes 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
commit sha 6a5f3bbd372a8896d75212acab27f93ff07b4126
discord link
push time in 2 months
push eventbryntum/chronograph
commit sha 9804f8da7a7fe14296437adc727b30c409f6f662
discord link
push time in 2 months
push eventbryntum/chronograph
commit sha 4f96908f20091abc6a5cd5693f400256c6c549bf
discord link
push time in 2 months
push eventbryntum/chronograph
commit sha 4ae426cad2d365d08ec0aeb46c0d192a533c0c9a
better names
commit sha 3e50b83d8dac28acd9227b45374b1fa9ea1a594f
progress on undo/redo
commit sha 044b36877ce8d3d91531abb8aa9cca1871c0f2cb
progress on undo/redo
commit sha 05bc31a65fb431ff2f9bef2ed3574ded4d019a8d
progress on undo/redo
push time in 2 months
push eventbryntum/chronograph
commit sha 2fa4a092f9f62c263d538fa939913626ae02689c
progress on undo/redo
push time in 2 months
push eventbryntum/chronograph
commit sha 8b369ded1f14b08734e38b2d8cfc60fe5b9a271a
WTF
push time in 2 months
push eventbryntum/chronograph
commit sha de2b4a76458e18c2cf207c008cd0abbe8f32145e
WTF
commit sha 8992195f506ef996662c74f300eb2772f120d084
WTF
push time in 2 months
push eventbryntum/chronograph
commit sha 8ffadb5dcd49f8d0358bdb0ab1a9a819df38f147
`immutable` property on a box should be a property
push time in 2 months
push eventbryntum/chronograph
commit sha 1fdb32034e2482752ce63f3696bd33568bd9000c
compilation errors
commit sha 3bc38a980ffe07315c4005d8d8ec8e1ebf0f9283
focus on deep changes
push time in 2 months
push eventbryntum/chronograph
commit sha a3661a2549939c1962965664cdfb4b672c83741b
google analytics
push time in 2 months
push eventbryntum/chronograph
commit sha f5942aa6d48f7f7aa444cb32db6065ed0e1ab973
added generic type argument to Box, CalculableBox
commit sha 5793d4afbbbb1ec7f139fd1938b01f440174dac8
progress on graph state threading
push time in 2 months
push eventbryntum/chronograph
commit sha 6bf341b477994c1479cd1d0d958d061146638238
record
commit sha 9d32123ae789ac84511ee54ce3e0a7104e09a2f8
benchmark
commit sha b343eacdfefd9bb4d05d422335eaf3306c983722
progress on graph structure
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.
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?
comment created time in 2 months
push eventcanonic-epicure/simplex-method-solver
commit sha b5bc6b5e1fc615783dd6c0365fd4bc7ca21b8247
switched to using node.js
push time in 2 months
push eventbryntum/chronograph
commit sha 2b7b52e1920587f713e142206c475f02aee9bad0
proposedValue progress
commit sha 7264dad1eeb30983204614dd8a331862c76e3936
todo
commit sha 2a832575bcb73f086556f0f766dffcd5ff081652
starting on graph
push time in 2 months
push eventcanonic-epicure/simplex-method-solver
commit sha 6bf65bb84ae5db7c7f73a7600e9c3ac5988127a1
ignore simplex Q values with 0 coefficient near the variable
push time in 2 months
push eventcanonic-epicure/simplex-method-solver
commit sha 26d00cbab3c5b9802f3e7cd5bccabdcf54cb4d5f
fix equation subtraction
push time in 2 months
issue commentmicrosoft/TypeScript
@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?
comment created time in 2 months
push eventbryntum/chronograph
commit sha a56830d9c50c9219a3a2be0f9c3dfa477087e3e1
progress on calculation
commit sha 7c90434fb4fc99a294a2d2adda629edd5522cc5e
progress on edges
commit sha 73b667e606224b7a66fdafd4f06acdfc90f106e7
Node
commit sha 963cb5f1aebebb9de6adc4d9287c1ce909cabbf7
Immutable
commit sha 819cd3095f0e2c5a937ed1c03b050af12e5f54b1
uniqable
commit sha b146b526dd0020e28c25a56066ea999b5eb58ea6
some progress
commit sha a7121b21305f2891f9c372c9604e2d2d341eaa55
some progress
commit sha d1f2fc073cc293851126fd88720e4109b0c43416
Quarks reduced to merely immutable storage, Atoms performs all logic
push time in 2 months
issue commentmicrosoft/TypeScript
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.
comment created time in 2 months
issue commentmicrosoft/TypeScript
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)
comment created time in 2 months
issue commentnonara/ts-patch
[Feature request] : Zero configuration
Ok, thanks for reply.
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
push eventbryntum/chronograph
commit sha 4a6d08ab4ee0223d645b9b773ec0abb03ab8e97b
progress on Box
commit sha 31e0675c2d65ba17e89eeea61718e4c1071cc4eb
progress on Box & Record
commit sha edaa1942571cfc7a71a85e92dd89ce82c2bbd3f1
progress on Box & Record
commit sha c7ef203f0004a2c99067755d5e972bd402fd3563
progress on CalculableBox
commit sha f6d886895b1ca8b67f61217e14ee65b7994431d4
progress on CalculableBox
push time in 2 months
push eventSamuraiJack/simplex-method-solver
commit sha 913ff0a9c01523c6055a4523532338065af9acfd
do not minimize
push time in 2 months
push eventSamuraiJack/simplex-method-solver
commit sha ff796ed0805bcef6b6c7cd2e733a4883ddfc05f5
additional options
commit sha 112320a0866ca9089c142072298a5a42d49d0f13
additional options
push time in 2 months