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
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.
Now, it is possible to encapsulate one type of protocol inside of another. For instance, TCP is a stream protocol, but it encapsulates the minecraft protocol, which (after 1.7) is framed.