Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 12 10:08
    SuperOP535 closed #92
  • Jan 13 21:26
    rom1504 commented #95
  • Jan 13 18:12
    rom1504 opened #96
  • Jan 13 18:11
    rom1504 opened #95
  • Nov 29 2018 20:42

    rom1504 on master

    Change some functions to arrow … (compare)

  • Nov 29 2018 20:42
    rom1504 closed #94
  • Nov 29 2018 20:33
    SuperOP535 synchronize #94
  • Nov 29 2018 20:31
    SuperOP535 synchronize #94
  • Nov 29 2018 20:29
    SuperOP535 opened #94
  • Nov 29 2018 18:31
    SuperOP535 closed #93
  • Nov 29 2018 08:56
    SuperOP535 opened #93
  • Nov 25 2018 15:53

    rom1504 on master

    update chat badges (compare)

  • Nov 15 2018 13:29
    SuperOP535 opened #92
  • Nov 15 2018 13:23
    SuperOP535 commented #75
  • Nov 15 2018 11:18
    rom1504 commented #75
  • Nov 15 2018 10:18
    SuperOP535 commented #75
  • Nov 13 2018 01:17
    rom1504 commented #75
  • Nov 12 2018 23:19
    rom1504 closed #85
  • Nov 12 2018 23:19
    rom1504 commented #85
  • Nov 12 2018 23:19

    rom1504 on master

    Added LICENSE file (compare)

Hans Elias J.
@hansihe
Question, if you think protodef is so stupid in every single way, why don't you just design your own version/use something else? If you come up with something better I would definitely use it.
William Gaylord
@wgaylord
I have never said it was stupid.
I am just questioning the questionable stuff that does not make sense.
Hans Elias J.
@hansihe
It would help a lot if you could come up with alternative solutions instead of JUST criticizing. We are aware there is a lot of complexity in some places, but it's that way because we believe it to be necessary
Robin Lambertz
@roblabla
Of all the points you gave, only one was valid : the new version make the semantics of container in the JSON dirtier
And when you did come up with that point, you didn't try to help make it better. You just criticized.
Hans Elias J.
@hansihe
The easiest way to prove us wrong is to come up with something better
William Gaylord
@wgaylord
I did suggest improvements....
but you did not like them
Hans Elias J.
@hansihe
Tell us again
William Gaylord
@wgaylord
Instead of adding an extra thing called virtual_field just make an optional virtual tag in the args types... Just like containers.
Hans Elias J.
@hansihe
Unless I misunderstand you, that would completely break encapsulation
that opens a whole new can of worms
Robin Lambertz
@roblabla
This message was deleted
Hans Elias J.
@hansihe
To help us further understand, would you mind making your proposed changes to a forked version of the gist?
William Gaylord
@wgaylord
its doing exactly whats in the json in the pds
Hans Elias J.
@hansihe
That way we can be sure we don't misunderstand you
William Gaylord
@wgaylord
okay.
Hans Elias J.
@hansihe
chibill: Could you please make the change you propose to the gist first? I want to be sure we understand each other correctly.
William Gaylord
@wgaylord
Its just making the PDS show the same info as the JSON .
Robin Lambertz
@roblabla
@hansihe Any reason for the ; ? This is going to sound completely pedestrian, but I do find those rather ugly :P
William Gaylord
@wgaylord
https://gist.github.com/chibill/c9b0a97d45be09b43fc5d72ab210af24 also the thing in the json I only changed to make it match container's because the way it was just got rid of what was said.
Hans Elias J.
@hansihe
chibill: Okey, one of the reasons it is the way it is in the pds is because it's a lot easier to identify virtual fields when scanning quickly when it's at the beginning
The second reason is that I want items in a type to be mainly identified by their name. virtual_field and field behave so differently semantically that I thought it made a lot of sense to distinguish them
Robin Lambertz
@roblabla
@hansihe how do you "extend" virtual_field to add new prop types ? Because external types might want to extend this.
Hans Elias J.
@hansihe
unsure what you mean by that
oh
i see
well, that requires code generation
William Gaylord
@wgaylord
So why are containers that are virtual not virtual_containers?
Hans Elias J.
@hansihe
so it the compiler has to be aware of it
chibill: that mainly grew out of the way the IR in my compiler is structured. there is only one internal variant
we might want to change that
William Gaylord
@wgaylord
so virtual_fields are virtual and different then a field but a container can be virtual or not..
seems odd but okay.
Hans Elias J.
@hansihe
we might want to change that
I still have a couple of arguments defending it
if you want to hear them
William Gaylord
@wgaylord
that post was after mine.
Hans Elias J.
@hansihe
not on my side, but sure
Robin Lambertz
@roblabla

TBF, you could just do

{
  "types": {
     "virtual_container": ["container", {
       virtual: true,
       fields: "$0"
    }]
  }
}

Or something like that anyway ? I think.

At least in node I think that works sorta :P
(Dirty hack though)
Anyway, g2g to sleep.
Hans Elias J.
@hansihe
me too
talk to you later
Robin Lambertz
@roblabla
So, some thought about protodef in general. Currently, minecraft protocol.json doesn't handle framing, compression, encryption, etc...
This is kinda sad, and should be remedied.
Which brings me to two fun topics. Protocol types, and recursive serialization.
There are essentially two protocol types : stream and framed protocols. In a stream protocol, we don't know the end of a "thing" until we've attempted reading it. In a framed protocol, we know the size beforehand.