02:10 coleman left 02:12 coleman joined 02:14 guifa joined 03:05 guifa left 08:00 samebchase left 10:11 [Coke] left 10:57 [Coke] joined 11:30 sena_kun joined 15:30 bartolin left
ugexe perl is putting TLS in core 16:22
lizmat interesting... from XS I assume, not written in pure perl 16:23
in that respect: I think we should make JSON support public as well (and update it so that :immutable can be used) 16:24
ugexe we could but that still would require some thinking about what to do about non-standard types. i.e. Version 16:36
which we have to think about because our current implementation works with Version but technically the way it does so is not round-trippable and thus potentially confusing for something exposed to general users
hence why languages often allow some type of TO-JSON() interface for objects (similar to providing your own raku method) 16:37
regardless, TLS is probably being put in the core for the package manager and less so to make having http servers require less dependencies 16:39
ab5tract lizmat: I support that. I guess as long as we are good with the current interface (from-json / to-json), attempts could be made later to provide VM-speficic fast path encoders/decoders
ugexe and even then further we probably then need to figure out rakus dual-life strategy 16:40
i mention all of this because the very last thing one would do to implement all of that is actually move the JSON module into the public space, it would not be anywhere near the first thing 16:41
ab5tract I'm a bit confused about your Version concern, for instance. Are you referencing marshalling of objects to and from JSON? Because that is somewhat separate from being able to import and export JSON datastructures 16:43
ugexe yes, the behavior and user expectations of to-json and from-json 16:44
ab5tract Then what does that have to do with Version or any other Raku type?
ugexe because 99% of users will not expect v12341234 to marshal to something
ab5tract JSON supports dictionaries, arrays, a few numerics, strings, booleans, and null
ugexe i may very well expect that to be a json parsing error
"v1234123" is ambiguous and would just be treated as a string i guess, but v1234123 is not the same 16:45
ab5tract it should be the same, because all the JSON encoder should do is call .Str on objects 16:46
ugexe that isnt how other languages do it
ab5tract (objects that haven't handled themselves)
ugexe Str and whatever the json representation are are usually provided by different methods
ab5tract Other languages mostly require you to have a complete type reference
in the form of a class or struct or what have you 16:47
ugexe and they will error if it encounters a type that 1) json does not know how to marshal and 2) does not have a custom marshaler provided by the user to declare how they want it done 16:48
in Go you have interface{} / any for instance
ab5tract or 3) provide a option to just stringify a field, or numify it, or whatever 16:49
lizmat is this about from-json? or also about to-json ?
ugexe mostly from-json 16:50
im not aware of any such option as 3 in Go
ab5tract for these languages, it's both. you are always marshalling out of and back into the same reference classes (which are the objects you are serializing in the first place)
ugexe: I expect it is covered by number 2 16:51
ugexe ok so what im saying is the user would need to provide such a custom marshaler
as users will have different expectations 16:52
ab5tract and I'm saying that it is more Raku-ish to allow both that as well as a toggleable default behavior
but neither of these things genuinely make sense to me inasmuch as there have been no complaints that I'm aware of about the JSON::Fast way of doing things 16:53
ugexe i guess fundamentally i just don't think that is good and leads to a php-like language of lots of weird gotchas and footguns you need to be aware of
ab5tract Well I would hate to see Raku become a language where you can't load a random JSON stream without defining 100% of the potential fields for 100% of the hash structures in that stream 16:54
ugexe there being no complaints in something that is yet to see widespread use does not mean it was designed in a way that widespread use would desire
ab5tract JSON::Fast is about as widespread as it gets for a Raku dependency 16:55
lizmat it is the #1 reverse dependency
ugexe the version serialization as it exists in JSON::Fast exists *only* because the core json parser does it and that *only* does it because we were passing raw version objects to CURI erroniously
lizmat rea > river 16:56
Top 3 distributions and number of dependees
Add 'verbose' to also see the actual dependees
JSON::Fast (405)
File::Directory::Tree (253)
MIME::Base64 (234)
ab5tract okay, so maybe there is some misunderstanding.. I think. marshalling a la JSON::Marshall / JSON::Unmarshall is out of scope for a core JSON
ugexe reverse dependencies are not indicative of the usage of something. lets be real: not a lot of people are using raku right now 16:57
so we lack a lot of the feedback and cases that come with widespread use
ab5tract if there is any marshalling behavior (ie reading JSON into an object of an acutal Raku class that is not a sane mapping of a JSON type) is out of scope 16:58
(imo)
so this Version situation is a non-feature that should not be part of an actual release 17:00
ugexe m: say Rakudo::Internals::JSON.to-json(q|{"foo":v112+}|)
ab5tract I think that widespread use amonst the community is obviously as good as it gets in gauaging the degree of developer acceptance 17:01
camelia "{\"foo\":v112+}"
ugexe oops that isn't right
m: say Rakudo::Internals::JSON.to-json({foo => v112+})
camelia {"foo":"112+"}
ab5tract didn't you say that this use was wrong to begin with?
lizmat m: put v112 17:02
camelia 112
lizmat m: put v112+
camelia 112+
lizmat so it's just stringifying
ugexe yes, and as ive mentioned i don't think that is sufficient
and why e.g. perl classes often provide TO-JSON type methods 17:03
lizmat well, what's stopping us from doing that as well?
ugexe which is a fine thing to do, but again that requires forethought and design decisions to take place
lizmat with sub Mu.TO-JSON(\x) { x.Str } 17:04
ugexe my original blurb was that moving the module to e.g. lib/ is the literal last thing to do
lizmat no... it should be in core setting *not* in lib
Geth rakudo/ugexe/deprecate-multi-file-operations: 1ea61d5a24 | ab5tract++ | 2 files
Simplify candidates by going with IO() only
ugexe hence the e.g. 17:05
but i disagree and would put it in lib/ 17:06
lizmat but we need it for module loading ? 17:07
ugexe yeah that is unfortunate 17:10
17:22 bartolin joined
lizmat re unmarshalling, is there a reason why we just shouldn't invoke.new on the class, and flattening the hash as named arguments ? 17:35
or related: create a Mu.from-hash method that would call self.new(:%_) by default 17:36
timo the reason is the json doesn't tell us what class to use 17:37
and json doesn't have a standardised way to specify that
lizmat giving a class the option to provide their own .from-hash method for unmarshalling
ab5tract I like the way the community libraries work
lizmat you mean raku.land/zef:raku-community-modul...:Unmarshal ? 17:38
ab5tract yeah
lizmat I was just looking at that also
timo when you have just ["v44", "v1.2"] where does it say it should use Version.new and not Str or IO::Path or HLL::Compiler or Stash or ...
lizmat actually to push a tweak in a mo
ab5tract and the related and also excellent raku.land/zef:vrurg/JSON::Class 17:39
timo alternatively, raku.land/zef:jonathanstowe/JSON::Class
ab5tract right
timo that's the one you get on debian for the name
ab5tract marshalling is cool, but what really sets Raku apart is that it is a flexible enough language to be able to do a lot JSON juggling *without* pre-declaraing the JSON structure 17:41
marshalling / un-marshalling is much more "traditional" in that it absolutely requires pre-determined schemas of the JSON data 17:42
it's a neat idea to work our a core solution for that stuff, but I think we might find greater success based on getting really fast parsing of arbitrary JSON into core more than we can with "hey look, you can spend the same amount of up-front time doing JSON parsing as you can in just about any other language" 17:45
tl;dr -- I do not agree that you need to solve marshalling of classes in order to ship useful improvements to core JSON handling and I also think that matching the behavior of "other" JSON serde options is a decent goal but ultimately an impossible one because the amount of incongruity between JSON parsers is legendary and every language has similar-but-unique approaches to JSON for the simple reason that it Just Makes Sense to do so 17:48
coleman wouldn't any strongly typed marshaling solution need to be built on a lower level parser that deals with map<str>object; 17:52
timo btw should we offer a mode for our json parsers where large integers get scrungled by first being put into a floating point number and then back? you know, how javascript does it? :P 17:53
Geth rakudo/ugexe/deprecate-multi-file-operations: 3ce0ee9684 | ab5tract++ | 2 files
Simplify candidates by going with IO() only
 17:54
coleman I like this API, fwiw github.com/tidwall/gjson?tab=readm...esult-type
Geth rakudo/ugexe/deprecate-multi-file-operations: a5a4ac2545 | ab5tract++ | 2 files
Simplify candidates by going with IO() only
 17:59
ugexe ab5tract: to me that is arguing top-down vs bottom-up, which is going to be a matter of opinion for most people. personally i generally lean towards top-down design when a clear vision of the end product/system can be achieved, although in practice im usually blending both top down and bottom up 18:02
ab5tract I can dig that, but only when it doesn't preclude implementing the bottom portions that actually don't require any of that top-level design to be in place. see coleman++'s point 18:03
the other side of this is that top-down design can be slow to begin with, and when it's combined with mostly/only async text chat, it can get demotivating or suffer from constant re-treading as conversations re-occur but with a slightly altered roster of participants 18:06
that's not an actual mark against it as a design philosophy, but rather a reflection on the obstacles we are facing when reaching for it
ugexe a bottom-up approach might be something like "Let’s just parse JSON into a hash right now" and only later try to figure out how it needs to do versioning, validation, or error-handling consistently across the system. which can lead to rewrites or major refactors once you realize your bottom-up implementation doesn’t fit the eventual top-level needs. maybe that is fine, but often that can 18:07
result in having some core logic that has to maintain bug compatibility
ab5tract The best a VM can do is put it into the right 6model type though, right? 18:08
The rest is up the HLL
timo the VM can also invoke code that it's been passed, so there's kind of a lot it could do 18:10
ab5tract Getting an API perfect in the first go-round. Has it ever happened? 18:15
ugexe perfect is the enemy of good enough. what we want to avoid is obviously bad apis like unlink(*@paths) etc
lizmat fwiw, I think there's a lot of experience to build on
ab5tract To distill my point a bit, top-down design can be really powerful. In order for us to pull it off -- my feeling is that -- we would need to change our way of working a bit. Maybe setting up a committee dedicated to evolving that design that meets regularly-ish and chips away at it? I don't know the specifics, only that without some sort of formal effort to grind the design into existence, it will likely to serve more as a deterrent to trying 18:18
anything at all than as a finish line we are working towards.
s/it will likely to/I fear that it will/ 18:20
ugexe yes that would be good. i also admit that with our current number of developers it can often be hard to get feedback. however, just creating a design outline before implementing something even without feedback is a giant step in the right direction as it shows thoughts/considerations were given to things rather than what might be described as prototyping 18:25
ab5tract fair point 18:27
timo one thing i can think of is we don't want to make it impossible to get at things that are under the same hash key in a json dictionary 18:30
some low-level parser bits are implemented as a stream of events. "dictionary opened", "dictionary key 'foo'", "True value", "dictionary closed", "end of document" 18:32
just thought i'd mention it as one possible piece for an implementation near the bottom end of the design 18:33
for handling especially big documents it might be desirable to not create any "object hierarchy" bits for things we might not ever access, so a hypothetical parser could record offsets into the source at strategic points so a lazy deserializer could pick parsing back up 18:34
but that doesn't have to be part of the "initial offering", it could go in a module instead for example 18:35
19:08 finanalyst left 22:07 finanalyst joined 22:52 sena_kun left
Geth rakudo/ugexe/deprecate-multi-file-operations: bad6872834 | (Nick Logan)++ | src/core.c/io_operators.rakumod
Remove calls to .IO on IO::Path objects
 23:28
ugexe So github.com/rakudo/rakudo/pull/5485 is green, but when i run the spectest it fails. i do not think we are running spectests in the CI anymore 23:53
Geth roast/ugexe/use-existing-utils: cbb5c3fbcc | (Nick Logan)++ | S32-io/child-secure.t
Use existing util functions
 23:56
roast: ugexe++ created pull request #867:
Use existing util functions		 23:59

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!