jerrygreen

jerrygreen issue comment ecsyjs/ecsy

jerrygreen

jerrygreen NONE

createdAt 3 days ago

is ecsy dead?

jerrygreen

comment in 3 days ago

@dumblob I am, secretly^*, continue developing the thing, it changed a lot but the most important: I'm still not entirely happy with it to ship to the masses.

A lot changed since back then, for example I now use Svelte instead of React: still, it has react-ish look, very simple to design interfaces (unlike any gaming frameworks), but it has much more lean code than React (I have to admit it, even though I've spent many years developing with React). I also use Tauri to be able to ship the game for desktops (instead of Electron, so the total executable size is small). I made my own AssemblyScript loader, so I can load AssemblyScript directy from files without any other "glue"-code like WebAssembly.instantiateStreaming(...), just as lean as any other function I'd import from JS/TS, like this:

^{(Svelte code; you can see the imported code is WASM/AssemblyScript, you can say this by the shown types)}

What's also important, I try not to just build some game engine in vacuum, but I am also in the process of designing my own game (medieval-fantasy rpg-rts). I can barely say I've even started actual "game" code: only the engine code. Because apart from the engine, I'm spending time to many other things: making Design Doc (I rewrote it few times from scratch already), the sketches, designing UI, making PRs or filing issues to other related libraries, and I also spend a lot of inspirational time too: I am re-playing many games I've played early, which inspired me to make a game in the first place (because initially I'm more a software dev than game dev, and most of my professional work I spent on software other than games), and many other things like tinkering with UDP in web tech (it doesn't seem UDP is hugely used in web-based games, though it is technically possible... just unpleasant). So this engine I'm coming up, - still doesn't look to me to be ready for the masses. Particularly, I want this engine to better support client-server architectures, with dedicated servers, while as of now I mostly have spent time on client-side yet, and server-side is poorly supported and needs more thought.

Also I'm in doubt in overall if I should release this engine or any libs without an actual game. I would like the idea to be my own first customer of my own tool, and if I release the engine without a game, this fact will quickly become untrue and make me feel bad in many ways.

Last but not least, I am doing it all just by myself, no any hidden team behind, so the process takes real real long time, I don't even have a grasp on estimation of when any of it will be ready. Just doing it for fun in spare time. Not to expect any github project links anytime soon, unfortunately... And sorry for so much text, too.

^* I mean not entirely secret of course, but at least I don't advertise or talk about this a lot. But yes I am working on it.

Apr

16

1 month ago

started

jerrygreen started ellisonleao/magictools

started time in 1 month ago

Apr

5

1 month ago

jerrygreen issue comment AssemblyScript/assemblyscript

jerrygreen

jerrygreen NONE

SyntaxError: missing ) after argument list

Unfortunately 0.20.0 to 0.20.3 versions have this crucial error when I try to import assemblyscript/asc:

$ node --trace-warnings
Welcome to Node.js v14.15.2.
Type ".help" for more information.
> var asc = import('assemblyscript/asc')
undefined
> (node:8260) UnhandledPromiseRejectionWarning: SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
    at emitUnhandledRejectionWarning (internal/process/promises.js:168:15)
    at processPromiseRejections (internal/process/promises.js:247:11)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)
(node:8260) SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
(node:8260) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
    at emitDeprecationWarning (internal/process/promises.js:180:11)
    at processPromiseRejections (internal/process/promises.js:249:13)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)

And if I try to import directly the dist files as a workaround, from assemblyscript/dist/asc, then I'm stuck into another error, "Cannot find module", - similar to #2241.

P.S. While older versions aren't usable either, due to #2247, now I'm considering if I should wait for a fix of the current problem, or maybe use bash equivalent of asc from js through execSync/child_process, as a temporary workaround of this issue (which sounds ridiculous but I think it should work), or maybe I should use older versions with this older bug where I should provide all the "additional options"

jerrygreen

@BatiGencho i guess you should put "type": "module" into package.json, where this should be available by default.

Also in my vite framework settings I had to pass this:

export default defineConfig({
  build: {
    target: 'esnext',
  }
})

Maybe you have some similar settings for your project environment.

jerrygreen issue comment ScoopInstaller/Scoop

jerrygreen

jerrygreen NONE

install previous versions

While you can install an app of a particular version using: scoop install <app>@<version> this will only work if you don't already have a newer version of the app installed.

It would be nice to be able to:

install an older version of the app, but maybe not update the current version (or prompt the user). This is useful for checking if a feature existed in an older version of an app, especially if you tend to use scoop cleanup a lot.
switch your current version of the app using syntax similar to the version install syntax: ie. scoop reset <app>@<version> instead of the syntax described here

I uninstalled idea-ultimate (was on most recent 2018.1.3), and was able to install an old version using scoop install <app>@<version>, but now I can't update it to the most recent, see:

scoop update idea-ultimate
idea-ultimate: 2017.1.6 (latest version)
Latest versions for all apps are installed! For more information try 'scoop status'

jerrygreen

Yeah, I eventually did scoop install [email protected], thanks.

Sorry for being unclear, because the mentioned problem "install previous versions", - is indeed resolved. It's another thing... Like for example when you make npm install [email protected] will try to install the latest under version 16. One might say "using shortcuts for installing previous versions".

jerrygreen

jerrygreen NONE

SyntaxError: missing ) after argument list

Unfortunately 0.20.0 to 0.20.3 versions have this crucial error when I try to import assemblyscript/asc:

$ node --trace-warnings
Welcome to Node.js v14.15.2.
Type ".help" for more information.
> var asc = import('assemblyscript/asc')
undefined
> (node:8260) UnhandledPromiseRejectionWarning: SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
    at emitUnhandledRejectionWarning (internal/process/promises.js:168:15)
    at processPromiseRejections (internal/process/promises.js:247:11)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)
(node:8260) SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
(node:8260) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
    at emitDeprecationWarning (internal/process/promises.js:180:11)
    at processPromiseRejections (internal/process/promises.js:249:13)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)

And if I try to import directly the dist files as a workaround, from assemblyscript/dist/asc, then I'm stuck into another error, "Cannot find module", - similar to #2241.

P.S. While older versions aren't usable either, due to #2247, now I'm considering if I should wait for a fix of the current problem, or maybe use bash equivalent of asc from js through execSync/child_process, as a temporary workaround of this issue (which sounds ridiculous but I think it should work), or maybe I should use older versions with this older bug where I should provide all the "additional options"

jerrygreen issue comment AssemblyScript/assemblyscript

jerrygreen

jerrygreen NONE

SyntaxError: missing ) after argument list

Unfortunately 0.20.0 to 0.20.3 versions have this crucial error when I try to import assemblyscript/asc:

$ node --trace-warnings
Welcome to Node.js v14.15.2.
Type ".help" for more information.
> var asc = import('assemblyscript/asc')
undefined
> (node:8260) UnhandledPromiseRejectionWarning: SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
    at emitUnhandledRejectionWarning (internal/process/promises.js:168:15)
    at processPromiseRejections (internal/process/promises.js:247:11)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)
(node:8260) SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
(node:8260) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
    at emitDeprecationWarning (internal/process/promises.js:180:11)
    at processPromiseRejections (internal/process/promises.js:249:13)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)

And if I try to import directly the dist files as a workaround, from assemblyscript/dist/asc, then I'm stuck into another error, "Cannot find module", - similar to #2241.

P.S. While older versions aren't usable either, due to #2247, now I'm considering if I should wait for a fix of the current problem, or maybe use bash equivalent of asc from js through execSync/child_process, as a temporary workaround of this issue (which sounds ridiculous but I think it should work), or maybe I should use older versions with this older bug where I should provide all the "additional options"

jerrygreen

Indeed, [email protected] works.

Just tried it with [email protected] and [email protected], and yes, with little hack with assemblyscript/dist/asc.js, it indeed works. Thanks.

jerrygreen issue comment ScoopInstaller/Scoop

jerrygreen

jerrygreen NONE

install previous versions

While you can install an app of a particular version using: scoop install <app>@<version> this will only work if you don't already have a newer version of the app installed.

It would be nice to be able to:

install an older version of the app, but maybe not update the current version (or prompt the user). This is useful for checking if a feature existed in an older version of an app, especially if you tend to use scoop cleanup a lot.
switch your current version of the app using syntax similar to the version install syntax: ie. scoop reset <app>@<version> instead of the syntax described here

I uninstalled idea-ultimate (was on most recent 2018.1.3), and was able to install an old version using scoop install <app>@<version>, but now I can't update it to the most recent, see:

scoop update idea-ultimate
idea-ultimate: 2017.1.6 (latest version)
Latest versions for all apps are installed! For more information try 'scoop status'

jerrygreen

Doesn't seem that this issue is resolved. I tried scoop install [email protected], but I'm getting error:

scoop install nodejs works but it installs the latest current version (17), at while I want lts version (16)

Apr

4

1 month ago

jerrygreen issue comment AssemblyScript/assemblyscript

jerrygreen

jerrygreen NONE

Cannot find module 'assemblyscript/asc' or its corresponding type declarations.

The website says it's possible to call asc programmatically in JavaScript, and can be imported as follows:

import asc from "assemblyscript/asc";

Source: Programmatic usage

However, trying to do so in TypeScript fails with the error message from the title. There is no @types/assemblyscript package either, at least not that yarn can find.

TypeScript seems to think the module is called assemblyscript/dist/asc, as I can import that with no such error.

jerrygreen

I have type: module in package json but this doesn't resolve the problem

jerrygreen issue comment AssemblyScript/assemblyscript

jerrygreen

jerrygreen NONE

Cannot find module 'assemblyscript/asc' or its corresponding type declarations.

The website says it's possible to call asc programmatically in JavaScript, and can be imported as follows:

import asc from "assemblyscript/asc";

Source: Programmatic usage

However, trying to do so in TypeScript fails with the error message from the title. There is no @types/assemblyscript package either, at least not that yarn can find.

TypeScript seems to think the module is called assemblyscript/dist/asc, as I can import that with no such error.

jerrygreen

Before trying Typescript just try to import it from js. I'm getting Cannot find module error with just pure js. At least I'm using v14.15.2, but you seem to stuck into the same error with v16-17, too, so I guess it's not the Node version.

jerrygreen

jerrygreen NONE

UnhandledPromiseRejectionWarning: SyntaxError: missing ) after argument list

Unfortunately 0.20.0 to 0.20.3 versions have this crucial error when I try to import assemblyscript/asc:

$ node --trace-warnings
Welcome to Node.js v14.15.2.
Type ".help" for more information.
> var asc = import('assemblyscript/asc')
undefined
> (node:8260) UnhandledPromiseRejectionWarning: SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
    at emitUnhandledRejectionWarning (internal/process/promises.js:168:15)
    at processPromiseRejections (internal/process/promises.js:247:11)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)
(node:8260) SyntaxError: missing ) after argument list
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)
(node:8260) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
    at emitDeprecationWarning (internal/process/promises.js:180:11)
    at processPromiseRejections (internal/process/promises.js:249:13)
    at processTicksAndRejections (internal/process/task_queues.js:94:32)

And if I try to import directly the dist files as a workaround, from assemblyscript/dist/asc, then I'm stuck into another error, "Cannot find module", - similar to #2241.

P.S. While older versions aren't usable either due to #2247, I'm considering if I should wait for a fix of the current problem, or maybe use bash equivalent of asc from js through execSync/child_process, as a temporary workaround of this issue.

jerrygreen

jerrygreen NONE

Programmatic use: "additional options" aren't additional

In the docs, Programmatic usage section, this code is mentioned:

  // Additional API options
  stdout?: ...,
  stderr?: ...,
  readFile?: ...,
  writeFile?: ...,
  listFiles?: ...,
  reportDiagnostic?: ...,
  transforms?: ...

When I try the simplest code like this:

asc.main(['myModule.ts'])

I'm getting errors then:

Error: 'options.stdout' must be specified

When I pass options.stdout, it raises error about stderr requirement, then readFile, etc.

Those options, though called "additional"... Aren't additional.

Due to the issue #2241, I'm not using the most recent version and instead I'm using [email protected], but this "additional" problem seems to be around for an eternity anyway, and I guess it is present in the recent versions, too.

Please make this programmatic usage to be what it's shown to be: make additional options truly additional. Thanks.

jerrygreen issue comment AssemblyScript/assemblyscript

jerrygreen

jerrygreen NONE

Programmatic use: "additional options" aren't additional

In the docs, Programmatic usage section, this code is mentioned:

  // Additional API options
  stdout?: ...,
  stderr?: ...,
  readFile?: ...,
  writeFile?: ...,
  listFiles?: ...,
  reportDiagnostic?: ...,
  transforms?: ...

When I try the simplest code like this:

asc.main(['myModule.ts'])

I'm getting errors then:

Error: 'options.stdout' must be specified

When I pass options.stdout, it raises error about stderr requirement, then readFile, etc.

Those options, though called "additional"... Aren't additional.

Due to the issue #2241, I'm not using the most recent version and instead I'm using [email protected], but this "additional" problem seems to be around for an eternity anyway, and I guess it is present in the recent versions, too.

Please make this programmatic usage to be what it's shown to be: make additional options truly additional. Thanks.

jerrygreen

Ok, then I'm closing this one.

jerrygreen

jerrygreen NONE

Programmatic use: "additional options" aren't additional

In the docs, Programmatic usage section, this code is mentioned:

  // Additional API options
  stdout?: ...,
  stderr?: ...,
  readFile?: ...,
  writeFile?: ...,
  listFiles?: ...,
  reportDiagnostic?: ...,
  transforms?: ...

When I try the simplest code like this:

asc.main(['myModule.ts'])

I'm getting errors then:

Error: 'options.stdout' must be specified

When I pass options.stdout, it raises error about stderr requirement, then readFile, etc.

Those options, though called "additional"... Aren't additional.

Due to the issue #2241, I'm not using the most recent version and instead I'm using [email protected], but this "additional" problem seems to be around for an eternity anyway, and I guess it is present in the recent versions, too.

Please make this programmatic usage to be what it's shown to be: make additional options truly additional. Thanks.

fork

jerrygreen forked rollup/rollup

jerrygreen/rollup

0

jerrygreen/rollup

0

⚡ Next-generation ES module bundler

jerrygreen Updated 2 months ago

fork time in 1 month ago

Apr

3

1 month ago

jerrygreen issue SchemaStore/schemastore

jerrygreen

jerrygreen NONE

Request-for-new-schema

AssemblyScript's asconfig.json

Description of the JSON schema.

AssemblyScript is TypeScript-like language that is compiled to WebAssembly (wasm).

Supporting information.

Documentation about its configuration (asconfig.json): https://www.assemblyscript.org/compiler.html#configuration-file

Are you making a PR for this?

No, someone else must create the PR.

started

jerrygreen started BowlerHatLLC/asconfigc

started time in 1 month ago

Mar

29

1 month ago

jerrygreen issue comment roxiness/routify

jerrygreen

jerrygreen NONE

remove unnecessary wrapper

Honestly initialize function doesn't seem to do anything, while templating code only creates additional wrapper (div), - which only makes the situation with html even worse. While JS has callback hell problem, HTML has div wrapper hell problem. Thus, the code removes unnecessary initialization code (prove me wrong), and removes the wrapper.

jerrygreen

I would say that an alternative would be good, especially since currently the handlers aren't removed when the div is unmounted.

So does that mean we should merge the change?

Btw, I just tested how it works with a few router components being used at the same time. They store their paths in location separately using ; separator, like this:

http://localhost:3000/menu;/menu

Honestly this current behavior is just weird, non-web, and simply above my understanding, and honestly I don't even want to understand that: it is some very edgy case (/menu;/menu urls? definitely an edgy case).

With this PR, it works still little similar but not entirely similar: it slightly breaks the current behavior.

If you want it to be non-breaking, please feel free to adapt it for your needs, for your picture of how this supposed to work, or close the PR: that's up to you. My only call: the wrapper div is not necessary, and shouldn't be applied (pls don't add to the div-hell problem). And thx for the lib anyway.

Summary about state-of-now of PR:

✅ Seems to be non-breaking change for simple routes: no page reload etc, works as smooth as before ✅ Seems to be non-breaking change for nested routes: no page reload etc, works as smooth as before ❌ Seems to break current behavior for multiple routers

Mar

26

1 month ago

jerrygreen issue comment roxiness/routify

jerrygreen

jerrygreen NONE

remove unnecessary wrapper

Honestly initialize function doesn't seem to do anything, while templating code only creates additional wrapper (div), - which only makes the situation with html even worse. While JS has callback hell problem, HTML has div wrapper hell problem. Thus, the code removes unnecessary initialization code (prove me wrong), and removes the wrapper.

jerrygreen

Honestly I’m little confused when you say «router» and especially «routers», because previously you meant «route» and «routes».

route(s) - a folder structure that translates into an accessible url(s) nested route(s) - a route structure that is more than one level deep in folders router - an element that user imports from routify library, and applies to his code, which brings him the NextJSy routes that we all like (that I’m trying to change here, so it no more requires a wrapper div)

And when you say «routers», - I don’t understand if you mistakenly call routes routers again, or if it’s another thing now. It seems you mean the router component itself now, rather than routes… But honestly I don’t know if it’s even possible to use more than one routER, and if possible, - why would anyone do that? Maybe I just don’t know about some ricky-tricky-edge-case, but honestly it sounds like nonsense. I might be wrong though, but please then explain.

jerrygreen issue comment roxiness/routify

jerrygreen

jerrygreen NONE

remove unnecessary wrapper

Honestly initialize function doesn't seem to do anything, while templating code only creates additional wrapper (div), - which only makes the situation with html even worse. While JS has callback hell problem, HTML has div wrapper hell problem. Thus, the code removes unnecessary initialization code (prove me wrong), and removes the wrapper.

jerrygreen

commit time in 1 month ago

You're right, I'm wrong: this code, indeed, needed for nested routes. By some reason this creates a full page reload when routes are nested.

Off-topic: that's a question why... Why it does not make full page reload for non-nested routes? But I don't urge you to answer that since it's not related to the point that the wrapper is not required.

I made a change that it now listens to the document, not some very parent body-like tag wrapper. Tried it on a few links, nested, non-nested: seems to work fine. Any other remarks?

push

jerrygreen push jerrygreen/routify

jerrygreen

remove unnecessary wrapper

Function initialize now listens to the document event, not element wrapper. One less div wrapper, hooray!

commit sha： 308214838da7c64e0c5f021e948cd1dd57ad9e1b

push time in 1 month ago

Mar

25

1 month ago

jerrygreen issue roxiness/routify

jerrygreen

jerrygreen NONE

bug

needs triage

`vite-plugin-svelte` raises a warning in console

Warning (Error?):

node_modules/@roxi/routify/lib/runtime/Instance/Node.svelte:16:8 will not be reactive if Component changes. Use <svelte:component this={Component}/> if you want this reactivity.

Versions:

"@roxi/routify": "3.0.0-next.83", "@sveltejs/vite-plugin-svelte": "1.0.0-next.40", "vite": "2.8.4", "svelte": "3.46.4",

pull request

jerrygreen pull request roxiness/routify

jerrygreen

jerrygreen NONE