Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 05 07:34
    Saiv46 commented #86
  • Sep 03 10:34
    rom1504 commented #86
  • Sep 03 10:33
    rom1504 commented #86
  • Sep 03 09:56
    Saiv46 commented #86
  • Sep 02 07:04
    Saiv46 edited #98
  • Sep 02 06:52
    rom1504 commented #98
  • Sep 02 06:49
    Saiv46 commented #98
  • Sep 02 06:48
    Saiv46 commented #98
  • Sep 01 11:18
    rom1504 commented #98
  • Sep 01 11:04
    Saiv46 edited #98
  • Sep 01 11:03
    Saiv46 opened #98
  • Aug 24 16:35
    rom1504 commented #97
  • Aug 24 16:33

    rom1504 on master

    Release 1.6.10 (compare)

  • Aug 24 16:31

    rom1504 on master

    add gitpod and fix gitmodules (compare)

  • Aug 24 16:29
    rom1504 closed #65
  • Aug 24 16:29
    rom1504 commented #65
  • Aug 24 16:28
    rom1504 closed #53
  • Aug 24 16:28
    rom1504 commented #53
  • Aug 24 16:28
    rom1504 closed #52
  • Aug 24 16:28
    rom1504 commented #52
Hans Elias J.
@hansihe
["u8", null] is perfectly valid
therefore "u8" is valid
it's that simple
William Gaylord
@wgaylord
So short hand is just putting null...
Hans Elias J.
@hansihe
exactly
William Gaylord
@wgaylord
Well now that someone actually says that...
Hans Elias J.
@hansihe
that's what I tried to say
the same rules applied to every type
For types that don't take an argument, you can either supply something like null, or use the shorthand
if just type_name is specified, type_arg just defaults to undefined
I did several times
you could do "type": ["u8", null]
(it can also be just type_name if type_arg is supposed to be undefined)
that's four times in total
five if we include the latest one
CertainLach
@CertainLach
Anyone want to try new logger for node.js?)
import NodeLoggerReceiver from '@meteor-it/logger-receiver-node-console';
import Logger from '@meteor-it/logger';

Logger.addReceiver(new NodeLoggerReceiver());

let a=new Logger('a');
let b=new Logger('b');
a.log(12);
a.log('%s, %s!','Hello','World');
    logger.ident('Starting gravity engine...');
    if (!DEV) {
        logger.ident('Generating keys with cool visualization because we can');
        let placeholder = ['%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10), '%s'.repeat(10)].join('\n');
        for (let keyId = 1; keyId <= 3; keyId++) {
            logger.ident(`${keyId}/3`);
            for (let i = 0; i <= 100; i++) {
                let data = [];
                for (let p = 0; p < 100; p++) {
                    if (key.addData(seedKey({entropy:-4}))) data.push(' / '.bgBlack);
                    else data.push(' \\ '.bgWhite.black);
                }
                logger.log(placeholder, ...data);
                await sleep(Math.random() * 180);
            }
            logger.deent();
        }
        logger.deent();
    }
    else {
        logger.warn('No key generation in dev mode!');
    }
    logger.deent();
    logger.ident('Loading Space IDE...');
    // logger.ident('Loading plugins...');
    // let pluginLoader=new PluginLoader('spaceidepl',__dirname+'/plugins');
    // try{
    //     let plugins=await pluginLoader.load();
    // }catch(e){
    //     fatal(e.message);
    // }
    // logger.deent();
    logger.log('Init() (Because plugin system is now disabled)');
Thats a cool encryption key generator :D, but main feature of them - visualisation with logger
And also my express.js alternative: https://www.npmjs.com/package/@meteor-it/xpress
Hans Elias J.
@hansihe
whole compilation units almost work now
that should be enough for now, we can deal with cross-file stuff later
compilation units includes namespaces and stuff
mhsjlw
@mhsjlw
so much hype
time frame for maybe being able to write backends ?
:)
Hans Elias J.
@hansihe
not yet
lol
after it successfully compiles a protocol.json is the timeframe
how long depends on how much I work on it I guess :)
mhsjlw
@mhsjlw
you're missing the varint serializer @hansihe ?
William Gaylord
@wgaylord
I wonder if it would be possible to make a python back end eventually for your nice little project.
mhsjlw
@mhsjlw
yeah, it'd be easy
nice little project
secretly over 9000 lines of code
lol
William Gaylord
@wgaylord
i said little not small. :P
Hans Elias J.
@hansihe
mhsjlw: I did not bother putting it in, should be easy to do though
Hans Elias J.
@hansihe
so the way I am doing it is that a single protodef file is a compilation unit
inside a compilation unit all types can refer to each other, even recursively
a compilation unit can also optionally have native types, they need to be defined for each language the spec file wants to support manually
when a spec file with native types wants to support a target, it needs to have a separate config file for that target. it contains things the compiler needs to know to link in those types, including what type of value it returns
(this is what enables the compiler to generate a match on certain values, like integers)
config file also contains additional info a specific language backend might need
Hans Elias J.
@hansihe
once I have all of this done and working, I am going to add the ability to import a spec file into another spec file
I imagine this is how the protodef "builtins" would be handled, just a spec with common types implemented natively in all languages we support
when importing spec files, they will be handled as a completely separate compilation unit. it will be handled the same way as native types inside the compiler, but the needed information is taken from the spec file instead of per-language config files like for native types
in the future we can add support for including spec files from git repos if we want, that should be relatively easy
Hans Elias J.
@hansihe
ok, namespace resolving is fully finished now