The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2015-05-27

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 disputin joined #mojo
00:07 pete left #mojo
00:14 marmez joined #mojo
00:15 punter joined #mojo
00:22 _dave_ out of curiosity, what's the use case for Mojo::ByteStream?
00:23 sri one-liners and template stuff
01:02 mattastrophe joined #mojo
01:29 berov1 joined #mojo
01:45 klapperl joined #mojo
01:58 inokenty-w joined #mojo
02:01 asarch joined #mojo
02:30 absolut_todd joined #mojo
02:48 noganex joined #mojo
02:55 kaare joined #mojo
03:11 basic6 joined #mojo
03:20 zivester joined #mojo
03:41 inokenty joined #mojo
04:16 mattastrophe1 joined #mojo
04:32 polettix joined #mojo
04:40 inokenty joined #mojo
05:04 howitdo joined #mojo
05:17 hshong joined #mojo
05:20 doby joined #mojo
05:44 dod joined #mojo
05:48 dod joined #mojo
05:52 batman I don't see how it's inconsistent. There's already TO_JSON logic, so what's the difference between adding some more?
05:53 batman Doing ->to_array() is fine on top level, but you might have a plain hash, with collections as values, and they might again contain bytestreams.
05:53 batman I think it would be convenient if that "just worked"
06:07 Eke joined #mojo
06:20 marcusr -1 from me, for the reasons sri mentioned.
06:28 polettix joined #mojo
06:43 xlat Hi, I am having trouble with a form parameter decoding, it's reproduce here: https://gist.github.com/xlat/216c510d1600d68b8bd4 ; have any idea what's wrong?
06:58 amon joined #mojo
07:01 hshong joined #mojo
07:13 Vandal31341 joined #mojo
07:17 berov joined #mojo
07:21 xlat joined #mojo
07:23 eseyman joined #mojo
07:26 inokenty joined #mojo
07:38 trone joined #mojo
07:44 dotandimet joined #mojo
08:04 Onigiri joined #mojo
08:36 batman marcusr: i don't understand how the reasons are related :(
08:37 batman is it because TO_JSON() is "overloading" in "JSON space"?
08:39 fhelmber_ joined #mojo
09:09 gatitskiy joined #mojo
09:10 gatitski_ joined #mojo
09:17 hshong joined #mojo
09:22 kendle joined #mojo
09:23 kendle mojo::dom find seems to always search from root of the tree, how to search only below current node
09:25 polettix joined #mojo
09:31 pink_mist d$ perl -Mojo -E 'say for map $_->find("b")->each, x("<b>foo</b><div><b>bar</b></div>")->find("div")->each'
09:31 pink_mist <b>bar</b>
09:31 pink_mist I don't see your results
09:33 kendle gimme a sec to translate to oneliner
09:39 kendle hmm, harder than I thought
09:50 kendle figures, typo
09:50 kendle thank you pink_mist
09:57 gatitskiy joined #mojo
10:22 salva joined #mojo
10:36 inokenty joined #mojo
10:36 schetchik joined #mojo
10:38 schetchik joined #mojo
11:01 gatitski_ joined #mojo
11:04 anufant joined #mojo
11:04 schetchik joined #mojo
11:08 anufant joined #mojo
11:14 neilhwatson joined #mojo
11:30 inokenty joined #mojo
11:39 schetchik joined #mojo
11:44 pink_mist hmm, wonder if there's a captcha plugin
11:44 * pink_mist goes to look
11:45 pink_mist oh there is!
11:47 pink_mist ah, both one that creates a security image on the server, and one that utilises reCAPTCHA, cool
12:03 mattastrophe joined #mojo
12:09 anufant joined #mojo
12:26 polettix joined #mojo
12:31 schetchik joined #mojo
12:33 fynjy joined #mojo
12:45 bwf joined #mojo
12:47 crab oh, hi lluad.
12:57 ajr_ joined #mojo
13:06 polettix joined #mojo
13:16 jberger xlat: would you consider this test comparable?
13:16 jberger http://pastie.org/10210102
13:17 jberger it makes much more sense to me
13:18 jberger and you can dump whatever you think is necessary, but I think my tests cover the cases
13:19 schetchik joined #mojo
13:20 zivester joined #mojo
13:22 Lee :Se
13:22 Lee oopsy
13:27 jberger xlat: also, what is wrong with "\x{e9}t\x{e9}" isn't that what you want?
13:29 jberger xlat: http://unicode-table.com/en/#00E9
13:33 xlat @jberger: oh, you are right... I was expecting to see "\xC3\xA9t\xC3\xA9"
13:34 gryphon joined #mojo
13:38 xlat @jberger: i'v got confused by urlencoding 'a=%C3%A9t%C3%A9'
13:47 xlat @jberger: so I should digg why my database return me something else after updating it...
13:49 jberger xlat: be sure your database is set to be in utf8 mode
13:49 jberger or else encode/decode on boundaries
13:49 jberger as usual
13:50 jberger (and on some dbs even en/de on boundaries won't be sufficient, you really want a mode setting)
13:51 anufant joined #mojo
13:52 mattastrophe joined #mojo
13:56 xlat @jberger: I will check that, but I think that sqlserver does not support native utf8 storage, but it seams that connection property characterset may help...
13:57 Grinnz xlat, usually how the data is stored doesn't matter, it's how the data is returned
13:59 xlat @Grinnz: sometimes it matter; I  have a case with sqlanywhere database using latin1 that does not support chars like "€", they are replaced by "?" in database...
14:02 Grinnz xlat, right, in that case you'd need to have it store in something that supports unicode
14:03 Ptolemarch joined #mojo
14:05 jberger "SQL Anywhere was known as Sybase SQL Anywhere prior to the acquisition of Sybase by SAP" the horror ... the ... horror
14:07 xlat @jberger: and did you know from where ms-sql from too?
14:07 jberger I just read that on wikipedia, so no
14:07 xlat http://en.wikipedia.org/wiki/Microsoft_SQL_Server#Genesis
14:08 jberger oh gods, its everywhere!
14:09 xlat and it sticks to your(my) fingers!
14:10 jberger https://www.youtube.com/watch?v=VKcAYMb5uk4
14:23 schetchik joined #mojo
14:23 anufant joined #mojo
14:29 schetchik joined #mojo
14:37 circ-user-l8Ec0 joined #mojo
14:45 zackiv31 joined #mojo
14:47 asarch joined #mojo
14:52 d4rkie joined #mojo
14:54 anufant joined #mojo
15:01 schetchik joined #mojo
15:05 Ptolemarch joined #mojo
15:14 * sri considers vetoing the TO_JSON thing now
15:15 sri i'm certain that what batman is proposing would be a huge mistake
15:18 jberger for the record I would vote against all to_string classes getting TO_JSON
15:18 jberger I just don't know where to draw the line
15:18 jberger {url => $c->url_for('something')} might be nice if that serialized
15:19 jberger but as you say, there are classes that shouldn't
15:20 Grinnz_ might be reasonable to draw the line at classes that have mutating to_strng
15:20 sri i think what you really want is for Cpanel::JSON::XS to learn how to stringify objects
15:20 jberger sri++
15:20 Grinnz_ that's not going to happen (especially with JSON::XS)
15:21 sri don't care about JSON::XS
15:21 Grinnz_ i could see Cpanel::JSON::XS adding that as an option though
15:21 Grinnz_ but not JSON::XS or JSON::PP
15:21 jberger certainly it could check if an object implements overloading stringification
15:21 howitdo joined #mojo
15:21 Grinnz_ no need to check
15:22 Grinnz_ $json->stringify_blessed(1)->encode($blah)
15:22 jberger you don't really want to accidentally get "SomeClass=0x132534" in your JSON accidentally do you?
15:22 Grinnz_ you don't accidentally put objects in JSON
15:22 Grinnz_ or you'd already "accidentally" get a null
15:23 jberger https://metacpan.org/pod/overload#overload::Method-obj-op
15:23 lluad Where this started was a mixture of Mojo::Pg::Results::hashes giving me a collection where I'd expect something array-llike, and Mojo::JSON being unable to serialize something array-like. Leading to exactly that in my JSON.
15:23 jberger if that returns a coderef, use it to serialize the object
15:24 jberger lluad: we certainly understand the problem
15:24 jberger the question is can we **consistently** do something about it
15:24 lluad I'm not sure we can.
15:25 jberger consistency is very important in Mojolicious
15:25 jberger its where a lot of our deprecations come from IMO
15:27 sri what's the best way to check if an object has stringify overloaded anyway?
15:28 Grinnz_ i think jberger linked something for that
15:28 * sri was just wondering if Mojo::JSON should turn an object that doesn't stringify into null too
15:29 Grinnz_ hmm, an interesting thought
15:29 Grinnz_ there's really no value in a non-overloaded object stringify
15:30 sri "$obj" eq overload::StrVal($obj) ? _encode_string($obj) : 'null'
15:30 sri that seems rather expensive
15:31 Grinnz_ you'd only need to check if the overload method exists, not the output of it
15:32 schetchik joined #mojo
15:32 sri can you do that without running into problems with bool overload?
15:32 sri as far as i understand it, bool overload acts as a backup for stringify overload
15:32 Grinnz_ defined overload::Method($obj, '""')
15:32 Grinnz_ oh?
15:33 sri yea, i think that wouldn't work
15:33 Grinnz_ but if it was using a backup wouldn't it stringify to that anyway?
15:33 Grinnz_ or maybe Method wouldn't return the backup
15:37 sri afraid i don't know enough about overload
15:38 sri google found this http://stackoverflow.com/questions/2602321/how-can-i-determine-if-an-object-or-reference-has-a-valid-string-coercion#comment2611840_2602356
15:39 jberger sigh
15:42 jberger then again, I might argue that we might only want the actual stringification overloading
15:42 jberger which is the opposite of what Sinan is saying there
15:42 anufant joined #mojo
15:42 jberger we dont care what "$obj" does
15:42 jberger at least not in boolean context etc
15:43 jberger we care about explicit stringification overloading
15:43 jberger I would say
15:43 Grinnz_ another fun thing: "" and concat overload can be different
15:43 Grinnz_ (if you're a really evil person)
15:44 sh4 joined #mojo
15:46 schetchik joined #mojo
15:46 sri ouch, Atom syntax highlighting got a lot worse recently
15:46 jberger Grinnz_: reminds me of https://metacpan.org/pod/Tie::Hash::Cannabinol
15:46 sri now it can't properly highlight Mojo::JSON anymore :S
15:47 Grinnz_ i forget what object came up recently that actually did this
15:47 Grinnz_ jberger: lol
15:47 jberger Grinnz_: PDL overloads .= to mean something completely different
15:47 Grinnz_ jberger: the reviews for that module are the best
15:48 jberger but that's because contact makes no sense to PDL objects, and you can't overload proper assignment
15:48 jberger so the (ab)use .= to assign
15:48 Grinnz_ heh
15:49 jberger hmmm, lots of typos, I must have had a contact high looking at that other module
15:50 Grinnz_ oh yeah, it was this: https://metacpan.org/source/MARKOV/Log-Report-1.05/lib/Log/Report/Message.pm#L24
15:51 Grinnz_ concatenation is overloaded because it's assumed to be accidental... lol
15:51 Grinnz_ direct from the docs: "(a dot where a comma should be used)"
15:52 Grinnz_ if you have a dot where a comma should be used i think you have a bigger problem
15:55 jberger back to business, I might code the logic as, if Mojo::JSON comes upon an object that does not implement TO_JSON, check for explicit overloading of the following (in this order):
15:55 jberger %{}, @{}, "", 0+
15:56 jberger I would especially not test booleaness (in my quick and not fully fleshed out opinion)
15:57 jberger because, true/false is not usually what you intend to be part of your object representation, just utilization
15:57 Grinnz_ unless it's a boolean object :P
15:57 jberger those already have explicit handling
15:57 Grinnz_ only the recognized ones
15:57 jberger remember, TO_JSON is checked first
15:58 Grinnz_ TO_JSON can't handle booleans, because there is no perl data structure that is "boolean" type
15:58 lluad If we're going down that path, should we also check for, e.g., to_array ?
15:58 jberger checking for @{} is essentially that
15:58 eseyman left #mojo
15:59 jberger Mojo::Collection is interesting because it doesn't actually implement an overloading for @{}
15:59 jberger because it is a blessed array refernces
15:59 Grinnz_ i thought it did?
15:59 jberger grrr, reference
15:59 Grinnz_ oh
16:01 jberger so in the discussion at hand, if we were to go forward making Mojo::JSON (and perhaps CPanel:: ) smarter, I would then propose adding TO_JSON to Mojo::Collection on its own
16:01 jberger (which is the current proposal, but without the changes to the json handler, and without TO_JSON on the stringy things, it is inconsistent)
16:01 * jberger 's head spins
16:13 anufant joined #mojo
16:17 gatitskiy joined #mojo
16:20 Repaster joined #mojo
16:28 inokenty joined #mojo
16:30 Repaster joined #mojo
16:42 ajr_ joined #mojo
16:44 schetchik joined #mojo
16:45 mattastrophe joined #mojo
16:45 schetchik joined #mojo
16:49 anufant joined #mojo
17:00 * batman updated the comment for #801
17:01 schetchik joined #mojo
17:08 anufant joined #mojo
17:15 Ptolemarch joined #mojo
17:17 fhelmber_ joined #mojo
17:30 trone joined #mojo
17:32 trone joined #mojo
17:32 berov joined #mojo
17:37 sri batman: i still don't understand your comment, it doesn't make Mojo::JSON consistent with Cpanel::JSON::XS
17:37 batman sri: Mojo::JSON stringyfies now, doesn't it..?
17:37 disputin joined #mojo
17:38 sri yes, and Cpanel::JSON::XS uses null
17:38 sri all you do is add an ugly workaround specifically for Cpanel::JSON::XS to a dozen Mojo::* classes
17:39 batman i can't argue with "ugly". i consider it a totally subjective statement :(
17:40 dod joined #mojo
17:41 sri well, then lets call it bad code
17:41 sri we have no use for those TO_JSON methods in core
17:42 Grinnz_ the Collection one would still serve a purpose
17:42 batman so you don't think this is convenient, being able to do encode_json({foo => c(1, 2, {bar => c(3,4)})}); ?
17:42 sri batman wants TO_JSON everywhere
17:43 batman sri: that suggestion was in response to "...since both would behave differently when passed to JSON encoders like Cpanel::JSON::XS"
17:43 sri and now that he brought it up, we have a new consistency problem actually
17:43 jberger batman has clairified "everywhere" to being places that have to_string and overload ""
17:43 sri we can't just ignore all the other classes with stringify overload
17:44 sri honestly, at this point i tend towards vetoing the whole thing, until there's a 100% clean proposal that has been well thought through
17:45 sri there's just too many consistency issues, even jberger's head started spinning
17:45 Grinnz_ well the first question is whether you want it to be consistent between Mojo::JSON and Cpanel::JSON::XS, that defines how to proceed
17:46 sri that would seem like a sensible start
17:46 Grinnz_ if not: the Collection change is the only one that matters
17:47 Grinnz_ if so: the string overloading has to be considered
17:49 sri https://github.com/kraih/mojo/pull/801#issuecomment-106010759
17:50 jberger sri / Grinnz_ : I think that is healthy
17:51 schetchik joined #mojo
17:51 disputin joined #mojo
17:53 * sri wonders how much code would break if we were more compatible with Cpanel::JSON::XS
17:55 Grinnz_ removing stringification of objects altogether would undoubtedly break things
17:56 sri if we decide to add TO_JSON methods everywhere, we would have to do that too i believe
17:56 gatitskiy joined #mojo
17:57 batman i like this: https://ssl.thorsen.pm/paste/26cfc40b2760
17:57 sri personally, i don't want more workarounds, i want the correct solution
17:57 batman can add that paste as a comment to #801 ?
17:58 sri batman: you're arguing for the wrong thing
17:58 * batman doesn't understand
17:58 sri that's the problem
17:59 sri i want a fundamental question answered, not examples for workarounds
18:00 sri what should happen if you pass a DateTime object to Cpanel::JSON::XS and Mojo::JSON?
18:02 mikegrb thank you mojo <3 https://gist.github.com/mikegrb/b36318a84301c1f19bdd
18:03 batman sri: so... do you mean that if the answer is "let's be consistent", then we need to remove the magical stringification in Mojo::JSON ...?
18:03 batman i really hope that doesn't happen :(
18:05 sri how do we justify not removing it?
18:05 sri (unless someone gets it added to Cpanel::JSON::XS)
18:07 batman is Cpanel::JSON::XS consistent with the way Mojo::JSON handle numbers?
18:07 gatitskiy joined #mojo
18:07 sri your proposal is to add 9 methods to mojolicious, just for Cpanel::JSON::XS, tests like the one for Mojo::Collection::TO_JSON wouldn't even work!
18:07 sri we couldn't have consistent tests for TO_JSON methods
18:07 inokenty joined #mojo
18:07 * batman shuts up.
18:08 batman i only end up convincing you the opposite of what i would like :(
18:08 sri my only interest here is correctness
18:09 sri this is not about opinions
18:10 batman then i can't vote, since i'm opinionated. count me out.
18:11 sri it is true though that i wouldn't have considered the wider overload problem if you hadn't brought it up
18:14 * sri has a feeling that we won't be reaching consensus on this anytime soon
18:14 sri perhaps a change in Cpanel::JSON::XS will resolve it at somepoint
18:15 mst I think in the case of objects that are expected to be JSONified providing a TO_JSON method -and- a stringify is more correct than only providing a stringify
18:16 sri how do you decide which objects are "supposed" to be JSONified?
18:16 schetchik joined #mojo
18:17 sri a Mojo::Date is supposed to be put into headers and cookies
18:18 batman sri: i use _a_lot_ of the mojo modules outside of web context, including Mojo::Date
18:18 sri that's not what they are optimized for though
18:18 sri so are they supposed to work with Cpanel::JSON::XS?
18:18 batman i would like that usage of Mojo::Date and Mojo::JSON outside of Mojolicious.pm was accounted for.
18:18 sri i don't think so
18:19 sri that seems like a huge can of worms
18:19 batman well. stop making awesome modules that i want to use everywhere then, hehe :)
18:19 sri loosely coupled components is one thing, but adding methods we don't actually need in core another
18:19 batman sri: your api is just too nice to avoid using :(
18:19 batman api/modules
18:20 sri i imagine consistency is one of the reasons you like those apis ;p
18:21 batman it's mostly because of dwim
18:22 sri DateTime for example does not ship with a TO_JSON method either
18:24 sri not actually that common on CPAN at all http://grep.cpan.me/?q=sub+TO_JSON
18:24 mst right, normally my DBIC objects have a TO_JSON method that does an explicit strftime on DateTime objects
18:25 sri Mango is a good exmple, it has a few data containers like dates and oids that have TO_JSON methods and are 100% supposed to be serialized
18:26 sri yea, i think we can say those Mojo::* classes are not supposed to be serialized
18:27 sri Mojo::URL might be the closest we have to something that is supposed to
18:27 sri in fact, Mojo::Date is a counter example
18:27 sri it stringifies to an HTTP date
18:28 sri but for JSON you'd want the RFC 3339 form
18:28 batman so if i want to serialize a Mojo::Collection, i need to manually convert it to an array-ref and then create a new exact same datastructure, put the collection into that structure and then call encode_json() ?
18:28 sri $collection->to_array
18:28 sri we have explicit conversion methods everywhere
18:29 ToApolytoXaos joined #mojo
18:29 sri evem $date->to_datetime for RFC 3339 actually
18:29 sri s/m/n/
18:30 mst I think I'd argue that a TO_JSON method on Mojo::Collection would be good as part of its quest to look as much like a normal array as possible
18:30 sri batman: have you actually looked at the original proposal?
18:30 sri https://github.com/kraih/mojo/pull/801#issue-81168773
18:30 sri all this has been originally about turning $results->hashes->to_array into $results->hashes
18:31 sri mst: Mojo::ByteStream wants to look like a string though ;p
18:31 Grinnz_ mst: array*ref* specifically, to avoid the overload-boolean type issues from before...
18:31 mst Grinnz_: yes, yes
18:32 mst you might recall that I was part of that conversation, since the Dancer-grade stupidity of the old implementation offended me
18:32 Grinnz_ sri: well Mojo::ByteStream would fit in the category of "supposed to be serialized", wouldn't it?
18:32 sri Grinnz_: don't think so actually
18:32 sri it's mostly used as a container in templates
18:32 Grinnz_ hm
18:33 batman sri: https://ssl.thorsen.pm/paste/24997781d84f
18:34 mst sri: thing is, some stringifies are useful to JSONification, some aren't
18:34 batman my comments are _only_ because i just just as much mojo code ouside of the web framework as outside.
18:34 Grinnz_ batman: i am not disagreeing, but how do you come to get a data structure with embedded collections?
18:34 mst I wonder if, really, the problem there is that render_to_string doesn't return a string
18:34 sri what Grinnz said
18:35 mst and having render_to_string and render_to_bytestream or something might be better
18:35 batman Grinnz_: ___outside_of_mojolicious_framework___
18:35 mst batman: that doesn't answer the question
18:35 sri mst: impossible, render_to_string would be useless, because of double escaping issues
18:36 sri Mojo::ByteStream specifically protects from XSS escaping
18:36 mst sri: ah, right
18:36 mst in which case the only consistent thing I can see is to add a TO_JSON method to it and make Mojo::JSON stop guessing when it sees a stringify overload
18:36 batman mst, Grinnz_: ok... so you want me to show an api i'm using at work where i return a hash with a neste collection object, just to prove it's actually possible...?
18:36 sri not that i think there's a problem at all
18:37 sri Mojo::ByteStream only came up because of consistency questions
18:37 sri not a problem
18:37 mst maybe somebody should write a plugin that monkeypatches a TO_JSON method into things
18:37 mst and then anybody using Cpanel::JSON::XS should load that
18:37 mst and everybody else can carry on without caring
18:37 Grinnz_ batman: it's possible of course... but i'm wondering why to use a collection in a nested object instead of just an arrayref
18:38 jberger me ponders a really evil monkey patch to Mojo::Base ;-)
18:38 * jberger runs
18:38 _dave_ just subclass it jberger
18:38 jberger _dave_: subclass Mojo::Base?!
18:38 Grinnz_ mst: Mojo::JSON::MaybeXS could monkey patch TO_JSON onto things :P
18:38 _dave_ sure
18:38 jberger btw, I was kidding
18:39 jberger it would (might) work
18:39 _dave_ I've done it :)
18:39 mst Grinnz_: use Mojo::JSON::MaybeXS::StopBatmanWhining;
18:39 batman Grinnz_: because i like to keep my objects around as long as possible
18:39 sri we're very far away from the original question again ;p
18:39 mudpit joined #mojo
18:39 mst welcome to IRC :P
18:39 sri which was how consistent Mojo::JSON should be with Cpanel::JSON::XS
18:39 sri especially regarding null values for objects without TO_JSON
18:40 sri if we were to decide we do the same, everything would be clear
18:40 mst I thought it threw an exception if there wasn't a TO_JSON method
18:40 sri it stringifies no matter what
18:40 jberger Mojo::JSON stringifies, CPanel:: dies unless a flag is on
18:41 sri oh, i meant Mojo::JSON
18:42 sri null unless TO_JSON would be an easy way for consistency
18:42 Grinnz_ JSON::XS et al have an option to either die or encode to null if an object can't be converted or if conversion is disabled
18:42 Grinnz_ this option is enabled for Mojo::JSON::MaybeXS so stuff doesn't die
18:43 Grinnz_ enabled = null, rather
18:43 Grinnz_ where "conversion" is TO_JSON
18:43 sri guess throwing an exception would be fine too
18:44 sri doesn't really matter for us, but we would need to make a change to the stringify behavior
18:44 mst I would, personally, be quite happy with 'die unless TO_JSON'
18:45 mst I somehow suspect that would result in much screaming though
18:45 _dave_ Gulp. Learn something new every day...so there's a chance that Mojo::JSON will not encode something I throw at it?
18:45 jberger _dave_: there is that chance during any serialization
18:45 _dave_ not with JSON::XS as far as I can tell
18:45 jberger any format to any other non-1-to-1
18:45 _dave_ I don't put blessed hashes in a conversion to be sure, but...
18:46 Grinnz_ _dave_: JSON::XS will die if that option is not enabled and you pass it an object
18:46 Grinnz_ it will also die if another option is not enabled and you pass it a filehandle or coderef
18:46 pink_mist _dave_: I dare you to find any JSON thing that serialises a filehandle; what would it even serialise that to?
18:46 Grinnz_ pink_mist: well Mojo::JSON serializes it :P
18:46 _dave_ hah...serialize a file handle to it's contents :)
18:46 pink_mist it does? :P
18:46 Grinnz_ to GLOB(...)
18:46 _dave_ probably a bad idea but
18:46 pink_mist well ... that's not really serialising, that's just stringifying
18:46 Grinnz_ indeed
18:47 Grinnz_ _dave_: in most cases that would be an atrocious idea...
18:47 _dave_ agreed
18:47 _dave_ still, I'm wondering why I've never run into this edge case
18:47 pink_mist _dave_: what if the filehandle is STDIN?
18:47 _dave_ I've encoded a lot of json
18:47 pink_mist or STDOUT?
18:47 purl somebody said STDOUT was sub { } ? the sub { } => an ordinary POE handler
18:47 _dave_ pink_mist: touche
18:50 jberger so this line of discussion brings me back to favoring TO_JSON and then explicitly overloaded operations
18:50 jberger stringify an object if it explicitly overloads stringification
18:51 jberger that brings some sanity, but it doesn't bring consistency with Cpanel:: unless they add it too
18:51 pink_mist how can you tell? can you expect what overloads an object supports?
18:51 pink_mist *inspect
18:51 jberger pink_mist: yes
18:51 pink_mist oh, that's cool
18:51 * pink_mist goes to read overload.pm in more detail
18:51 Grinnz_ _dave_: when you use an encoder that expects to deal with just hashrefs, arrayrefs, boolean objects, and scalars, it's pretty easy to avoid getting any unexpected type of ref in there
18:53 Grinnz_ _dave_: in the context of mojolicious, you have a lot more opportunities to say "make this stuff JSON", and it just does it in the background... i think this might be where you run into this case more
18:54 _dave_ I'm pretty conservative in what I send, so no surprise there. I try to learn from what I do vs what others who are clearly very good at this stuff do.
18:55 _dave_ If you are trying to have code that "just serializes"...along side what I perceive as the Mojolicious philosophy of "it just works"...I think "die" is a bad idea unless there's really an issue.
18:56 schetchik joined #mojo
18:56 _dave_ I don't pretend to understand the politics and practices of framework development, though. Big caveat. :)
18:57 gatitskiy joined #mojo
18:57 anufant joined #mojo
18:58 Grinnz_ well, decode_json already dies when it encounters invalid json, making encode_json die isn't too much of a leap, there is already j() which avoids dying...
18:58 _dave_ I so hate die
18:58 _dave_ grr
18:58 _dave_ :)
18:59 _dave_ My fingers type "local $SIG{__DIE__}" faster than "rm -rf *"
19:01 _dave_ Grinnz_ are you speaking of Mojo::JSON?
19:01 Grinnz_ yes
19:02 Grinnz_ why use local $SIG{__DIE__} instead of eval? thats just asking for trouble
19:02 _dave_ hm, how does j() tell whether to encode or decode?
19:02 Grinnz_ it guesses :)
19:02 _dave_ :/
19:02 Grinnz_ (scalar is decoded, ref is encoded)
19:02 _dave_ ah :D
19:02 _dave_ well nowdays I use Try::Tiny
19:03 _dave_ but you needed the local $SIG... along WITH the danged eval sometimes
19:03 Grinnz_ that sounds like a mess
19:03 mst if you needed that, your code was broken
19:03 _dave_ read Try::Tiny docs heh
19:03 Grinnz_ i have read them quite a bit... there's nothing that would require that
19:03 mst _dave_: I helped the author write it.
19:03 mst if you needed that, your code was broken
19:03 _dave_ explain please? :)
19:04 mst there's no reason to fuck with sigdie
19:04 mst except for things like stack tracers
19:04 _dave_ I had a couple cases where eval { Some::Cpan::Module::method() } would still die
19:04 Grinnz_ _dave_: then something was running not in that eval
19:05 mst no, you didn't
19:05 Grinnz_ _dave_: there is no way for a die to "escape" an eval without fuckery
19:05 _dave_ hey, I didn't write Some::Cpan::Module
19:05 mst you had a different bug and for some reason did something insane rather than debugging it
19:05 _dave_ you sound quite sure there, what am I missing?
19:05 mst I don't know what you did wrong
19:05 howitdo joined #mojo
19:05 mst if you ever encounter a situation like that again, I'll be happy to figure out what
19:06 Grinnz_ the specific name of the module and method could help too :P
19:06 mst but unless you intentionally installed a broken sigdie that called exit() or something similarly terrible
19:06 mst what you describe is simply not possible
19:06 Grinnz_ _dave_: this is just how die and eval are designed to work, so if it doesn't, then something is doing fuckery
19:07 _dave_ define "fuckery"? :D
19:07 Grinnz_ messing with $SIG{__DIE__}, for one...
19:08 _dave_ I set this all the time in daemon code. Why? Because some module I'm using will die instead of somehow throwing an error.
19:08 _dave_ It's defensive
19:08 mst die() *is* throwing an error
19:08 _dave_ yes and then it exits
19:08 mst if you don't catch it, yes
19:08 mst which is what eval {} is for
19:09 mst Try::Tiny is just an eval wrapper that avoids the most common mistakes
19:09 _dave_ ok, was there ever a time when eval{} would still die? say, perl 5.8? 5.6?
19:09 mst no
19:09 _dave_ you -sure- about that?
19:09 mst yes.
19:09 mst I don't know what you did, but it wasn't what you think it was.
19:09 Grinnz_ if you're runnign an event loop, and the event loop doesn't catch errors, wrap the event loop start in an eval
19:09 _dave_ ok, well... ;) not much I can say then.
19:10 Grinnz_ though they should all catch errors other than POE, which will catch errors if you set up sig_DIE
19:10 _dave_ I have seen eval {} die inside the braces
19:10 mst you haven't.
19:10 purl Nosir.  Not a scrap.  I was deliberately wasting your time.
19:10 mst you have misdiagnosed the problem
19:10 mst if you ever see the problem again
19:10 mst I will happily help you to diagnose it correctlky
19:10 _dave_ heh
19:10 vmbrasseur joined #mojo
19:11 ajr_ joined #mojo
19:12 pink_mist eval { gmtime("NaN") } #actually, it /is/ possible, if you trigger a bug in perl (this particular one has been fixed in very recent releases though, and didn't occur until sometime after 5.12) ... but $SIG{__DIE__} wouldn't help you here.
19:12 mst oh, yeah, you can crash perl entirely
19:12 Grinnz_ that's not dying :P
19:12 mst I can segfault perl all sorts of interesting ways
19:12 mst but SIGDIE is irrelevant to that
19:12 Onigiri But can you segfault sed?
19:13 mst basically, adding a SIGDIE in daemon code is not defensive, it's just silly
19:13 _dave_ being clearer: I've seen the perl process exit even inside an eval {}
19:13 mst well, yes, if you call exit()
19:13 _dave_ when I added SIGDIE the exiting stopped
19:13 mst but a SIGDIE won't help you
19:13 _dave_ I would never call exit in SIGDIE because I'm trying to have the thing not exit
19:13 mst my suspicion is that something -else- installed a SIGDIE
19:13 mst and what you did was uninstalled it by overwriting it with yours
19:13 pink_mist POSIX::_exit();
19:14 _dave_ that could very well be
19:14 _dave_ my defensiveness comes from many perl devs putting "die" in their cpan modules and "die" exiting the program
19:14 jberger eval { require Acme::Boom; Acme::Boom->import }
19:14 mst but the answer in that case would be to find out what installed the broken one and stop it
19:14 mst um, die() in cpan modules is completely correct
19:14 _dave_ if "die" did not exit, I wouldn't have a problem with it :D
19:15 mst die() does not exit the program when called within eval.
19:15 mst you explicitly did something to make it exit
19:15 jberger _dave_: what should an unhandled exception do?
19:15 mst and the answer is to figure out what and not do that.
19:15 _dave_ or someone else did
19:15 mst well, no, it's your code.
19:15 _dave_ I've seen SIGDIE in CPAN code
19:15 _dave_ I need to go find examples though...for this crowd lol
19:16 mst are you being intentionally obtuse?
19:16 mst loading a module that overrides sigdie is you explicitly doing something
19:16 _dave_ no I'm not being obtuse...you are being more precise with language than I am
19:17 _dave_ Yes, I explicitly loaded someone's CPAN code with SIGDIE. I did not intend to load any module that exits without giving me the option of stopping that exit.
19:17 mst and I still think something more complicated is likely going on
19:18 _dave_ I don't want my modules to exit. I want to handle all "unhandled" exceptions the best way I can.
19:18 mst because I have never seen a SIGDIE in the wild that does that
19:18 mst hence my offer to help you diagnose what happened
19:18 mst because you clearly don't actually know what happened, and I'd like to find out
19:19 _dave_ I don't remember the exact details. I have too much code out there over too many years and, much like you, have developed defensive practices because of issues I found. :)
19:19 mst sprinkling local sigdie around is not defensive, it's cargo cult
19:20 _dave_ My curiosity is what issues you have found which produces your ideas about SIGDIE.
19:20 mst I've no idea what you'
19:20 mst I've no idea what you're talking about
19:20 mst I merely pointed out that there are very few reasons why one would want to set it, and the usual one is stack tracing
19:20 jberger _dave_: sorry, but I expect most of us side with mst on this one
19:20 mst there are no 'issues' involved
19:21 Grinnz_ _dave_: the defensive practice is to wrap code in an eval when you don't want it to die, and then figure out what's actually hapenning if it still dies
19:21 mst it's just it's almost always the wrong thing to do
19:21 _dave_ jberger: I'm not fighting either :D
19:21 jberger ok
19:21 jberger then I would say that generally we encourage you to use it less, and when eval does the wrong thing, come ask
19:21 mst _dave_: I'd be reacting the same way to somebody calling 'no strict;' defensive programming against typos :)
19:22 _dave_ lol mst
19:23 _dave_ I don't see that the analogy is the same though
19:23 mst I know you don't
19:23 mst that's rather the problem
19:24 jberger avoiding the problem isn't fixing the problem
19:24 _dave_ If I experience ducks flying upside down, and you come and tell me that's impossible...what more useful communication can happen? :D
19:25 mst I didn't say it was impossible, I said it was abnormal and that therefore you should figure out what you've done to your perl VM and not do it again
19:25 jberger in that case (as now) then I would say "keep you camera handy and when it happens take lots of pictures"
19:25 mst I'm not telling you that you didn't experience what you experienced, I'm telling you that your reasoning from that point was faulty
19:25 _dave_ then you can claim I photoshopped them :)
19:26 jberger you probably did, and we would like to see how
19:26 _dave_ Ok, let's address the faulty reasoning claim. I'm open to seeing this if you can explain how it was faulty.
19:26 mst fundamentally you're saying "the ducks were flying upside down", and I'm saying "I think you somehow managed to stand on your head without noticing"
19:26 jberger ok, this is going nowhere, lets move on please
19:26 mst no, let's not. I've explained this at some length already.
19:26 mst you can continue to roll to disbelieve if you like
19:27 _dave_ I don't mind. I'm not mad, or annoyed, or anything else emotional :D
19:27 mst but in that case I'd invite you to go read the source first
19:27 jberger ok, then I step out, I'm not emotional, I just don't have the time for an endless conversation about this
19:27 jberger enjoy
19:27 _dave_ thanks for participating :)
19:27 jberger o/
19:28 _dave_ Mst, your claim (supported by the source code) is that "die does not exit inside an eval" correct?
19:29 jberger eval { die }; say "hello"
19:29 jberger should always say hello
19:29 _dave_ that case is verifiable yes
19:29 Grinnz_ _dave_: die does not exit the script when caught by an eval
19:29 mst _dave_: yes, and if you're seeing what appears to be that, then either something is explicitly exit()ing or equivalent, or your observations are incomplete in some way.
19:30 Grinnz_ there are reasons why it wouldn't get caught by the eval, but those are not normal reasons
19:30 * jberger has a guess
19:30 purl know is a silly bot
19:30 Grinnz_ there are also reasons the code you think is running inside the eval is actually runnign after the eval
19:30 jberger eval { use Acme::Boom }
19:30 jberger runtime vs compile time
19:30 Grinnz_ or before
19:31 mst or the eval is returning an object whose destructor is exploding
19:31 _dave_ mst!
19:31 _dave_ yes
19:31 jberger acutally that is a bad example, since Acme::Boom is a segfault
19:31 Grinnz_ oh god DESTROY
19:31 _dave_ there was an issue with DESTROY
19:32 mst right, so what happened was the object was returned from the eval
19:32 mst and then it was destructed outside of the eval
19:32 _dave_ yer kidding right?
19:32 Grinnz_ to avoid that, return something else from the eval
19:32 _dave_ eval { my $thing = Foo->new(); }
19:33 _dave_ Foo::DESTROY happens outside of the eval?
19:33 Grinnz_ eval { my $thing = Foo->new(); 1 } # now it doesn't
19:33 mst yes, because the last statement in a block is its return value, so you're returning $thing from the eval
19:33 marmez left #mojo
19:33 _dave_ oh ghod
19:34 jberger perl -E 'package Something { use Mojo::Base -base; DESTROY { die } }; eval { my $s = Something->new }; say "lives"'
19:34 jberger lives with a warning
19:34 mst yes, because as of 5.14 or so the behaviour of DESTROY was changed so that exceptions got converted into warnings so they didn't escape
19:35 jberger a ha
19:35 Grinnz_ don't let them free!
19:35 mst also, that eval is in void context; it might require a non-void context eval
19:35 * _dave_ facepalms
19:35 purl facepalms are certainly another important measure
19:35 mst but remember that if the eval is the last statement in a subroutine
19:35 jberger purl: mongolian cluster fuck
19:35 purl i heard mongolian cluster fuck was easier to type
19:35 mst it'll get its context from the caller
19:35 Grinnz_ nope, same in scalar context
19:35 jberger purl: be mst
19:35 purl WE ARE NOT FUCKING GUESSING
19:35 Grinnz_ lol
19:35 jberger \o/
19:35 mst yes, on a recent perl it'll be the same no matter what
19:35 sri lol
19:36 _dave_ I think you just found a 10 year old bug which I coded around
19:36 Grinnz_ _dave_: :)
19:36 jberger mst is pretty good
19:37 jberger purl: be sri
19:37 * purl writes impressive but unmaintainable code
19:37 jberger :o
19:38 pink_mist eval { {; my $thing = Foo->new } }; #would this work? I don't even know
19:38 _dave_ wouldn't the return value just propagate out?
19:38 jberger contexts propogate
19:38 Grinnz_ yea
19:39 Grinnz_ you don't return a "block"
19:39 _dave_ jberger: took me a few interchanges before I recognized mst as the "explicit" kind of geek ... sorry if this convo disturbed you
19:39 Grinnz_ _dave_: there's a lot of "explicitness" here, just ask sri a vague question and see what happens :P
19:39 _dave_ yes I've already seen he is like that ;)
19:39 _dave_ I move my explicitness based on the audience when I can
19:40 _dave_ some people absolutely hate exactness
19:40 mst when attempting to debug weird shit, exactness is quite important
19:40 _dave_ true
19:40 * sri kicks purl
19:40 purl What? What?  Did i miss a cue?
19:40 Grinnz_ or when attempting to tell a computer what to do, in general
19:40 _dave_ remember that most human interchange is fuzzy :D
19:40 _dave_ even when we think we are being exact
19:42 mst hrm, no, even going as far back as 5.8, I'm not seeing exceptions escape ... oh, hang on, it's actually ... hrm. there's something involving an error being replaced by destroy during stack unwind
19:42 Grinnz_ lol
19:42 mst the other possibility, of course, is that $@ ended up set when you didn't expect it to be
19:42 _dave_ local $SIG{__DIE__} = undef;  is also common for me
19:43 sri so, is anyone going to try and get stringify overload support into Cpanel::JSON::XS?
19:44 sri i kinda like the idea of "stringify or null"
19:44 _dave_ local $SIG{__DIE__} = undef; eval { $thing->new() } ... everywhere in my 10 year old code
19:44 sri in that case we could add "stringify or null" to Mojo::JSON, and accept the Mojo::Collection patch, and then not add any more TO_JSON methods
19:45 mst eh, just install a UNIVERSAL::TO_JSON that does that, then you don't need to patch Cpanel::JSON::XS
19:46 Grinnz_ the idea is to be compatible with Cpanel::JSON::XS itself in design i think :P
19:46 sri UNIVERSAL always feels too empty anyway
19:46 * mst hides sub UNIVERSAL::DESTROY { exit(255) } in _dave_'s code
19:47 Grinnz_ hahaha
19:47 _dave_ ow lol
19:47 mst so, yeah, destructors can overwrite $@ on older perls but that's about it
19:48 mst but I'm still claiming that you having somehow ended up upside down without noticing is more likely than the ducks having conquered gravity
19:48 sri sub UNIVERSAL::DESTROY { exit(255) if int rand 2 }
19:48 mst sri: that's the AWS version, right?
19:48 sri indeed
19:48 * sri is a big supporter of clown computing
19:49 _dave_ mst: ok, claim away :) We need a definitive orthogonal basis to resolve that one.
19:50 _dave_ mst: maybe I've been right side up most of my life
19:50 ajr_ I'll bite; what's "clown computing"?
19:50 mst ajr_: http://trout.me.uk/mongodb.jpg on EC2
19:50 Grinnz_ cloud computing, with face paint and fake noses
19:50 mst _dave_: yeah, without a repro case I'm fucked if I know
19:51 mst there's a bugfix in Catalyst::Plugin::StackTrace somewhere that didn't have an attached test case
19:51 _dave_ you got me looking through my older code now (instead of working on my mojo app)
19:51 mst the commit message was something along the lines of "I'm sorry about this, but my smallest repro case is a 1.7Gb VM image"
19:51 Grinnz_ _dave_: refactor everything!!
19:52 _dave_ I can't...some of this code has been running for 15 years with no issues. I won't touch it lol.
19:52 Grinnz_ :)
19:52 xlat @jberger: I found what's was wrong with my encoding matter, and just got a 'RTFM' : http://search.cpan.org/~sgoeldner/DBD-ADO-2.95/lib/DBD/ADO.pm#Character_set ^^
19:53 jberger _dave_: btw, no I'm fine
19:53 _dave_ jberger: :)
19:53 jberger I just really shouldn't be watching this window this much :-)
19:53 _dave_ well it's good for me, I can always stand to learn more
19:54 * jberger hands xlat a drink, (s)he's going to need it
19:55 sri we should add a nose to the mojolicious cloud http://image.spreadshirtmedia.net/image-server/v1/compositions/112604608/views/1,width=235,height=235,appearanceId=2/Clown-Computing.jpg
19:55 pink_mist sounds like a fun april 1st thing
19:55 pink_mist too bad it's may
19:55 jberger sri++
19:58 Grinnz_ sri: rofl
20:01 * jberger picks Grinnz_ up off the floor, its undignified
20:01 * jberger sets tianon on fire, because it has been a while
20:02 * tianon burrrrns ????
20:02 jberger nice
20:07 sri soooo
20:07 sri what should happen when you do this? perl -Mojo -E 'say j([Mojo::Base->new])'
20:08 lluad Anything that doesn't have the word "HASH" in it and doesn't segfault would work for me.
20:08 lluad die() out of preference.
20:10 sri my preference would be [null] i guess
20:11 mst I think for a CLI one-liner [null] is definitely good
20:11 lluad That'd be reasonable, I guess, if j() can't die. Though I'm not sure that's any better than ["Mojo::Base=HASH(foo)"], and might be worse in terms of not noticing errors.
20:11 mst I'm not 100% sure I think the same thing for application code
20:11 sri die() doesn't feel right
20:12 sri tracking down where stuff went wrong with a deep nested structure is easier if you see the result
20:12 sri and i like the idea of being able to handle all perl data types gracefully
20:12 lluad Yes - and at least you're more likely to notice something went wrong.
20:12 sri after all, we do so for inf and nan already
20:12 mst maybe '<refused to serialize Mojo::Base object>'
20:13 mst of course, that isn't consistent with anything else
20:13 mst but it'd be great for debugging
20:13 * sri nods
20:13 jberger mst: that isn't much better than the stringifyed memory address
20:13 sri lol
20:13 sri actually an argument for the stringified memory address
20:13 lluad That's not bad (though semantically not much better than Mojo::Base=HASH...)
20:13 sri oh my
20:13 jberger echo
20:14 mst honestly, I'd rather get the plain stringification than null
20:14 * jberger had really hoped that purl had an "echo" factoid
20:15 sri well, that was easy, plain stringify is clearly the winner
20:18 sri guess ideally would be the same functionality in Cpanel::JSON::XS
20:21 sri ok, i think accepting #801 as is would be reasonable, we will keep doing stringification, and hope that Cpanel::JSON::XS will support it in the future too, but we will not add workarounds for it to core
20:21 mst I would love to see JSON::PP and Cpanel::JSON::XS at least provide an option to stringify objects by default
20:21 sri the debugging argument convinced me i guess
20:22 sri we are familiar with "Mojo::Base=HASH(0x7f8522004638)" and can debug it very easily
20:22 mst right
20:22 mst whereas "where the fsck did that undef come from" is harder
20:22 sri yea
20:23 jberger ok, I can convince myself to vote on Mojo::Collection::TO_JSON without any other classes
20:25 jberger voted
20:27 good_news_everyon joined #mojo
20:27 good_news_everyon [mojo] kraih pushed 5 new commits to master: http://git.io/vk3UQ
20:27 good_news_everyon mojo/master 5ab59e9 Steve Atkins: add Mojo::Collection::TO_JSON to support serializing with Mojo::JSON
20:27 good_news_everyon mojo/master 58cabcd Steve Atkins: add documentation for Mojo::Collection::TO_JSON
20:27 good_news_everyon mojo/master 8d2168d Steve Atkins: reorder methods; document TO_JSON solely as an alias for to_array
20:27 good_news_everyon left #mojo
20:33 good_news_everyon joined #mojo
20:33 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/vk3Ig
20:33 good_news_everyon mojo/master 4ea1fa4 Sebastian Riedel: release preparations
20:33 good_news_everyon left #mojo
20:41 hernan604 joined #mojo
20:49 jzawodn joined #mojo
20:59 Onigiri Is there a db backed session store? I'd rather not utilize the cookie itself to store stuff.
21:03 pink_mist https://metacpan.org/pod/Mojolicious::Plugin::Session
21:04 Onigiri pink_mist: found that one, "First commit, we're not ready to release yet though, need DBI backend…" being the latest commit doesn't seem ... safe
21:04 pink_mist oh, that does indeed look ominous
21:07 mattastrophe joined #mojo
21:08 pink_mist uhm, I'm not sure how you see that being the latest commit though
21:08 pink_mist that's clearly the /first/ commit
21:09 Onigiri https://github.com/benvanstaveren/Mojolicious-Plugin-Session
21:09 pink_mist uh what
21:10 Onigiri So first & only commit
21:10 pink_mist https://github.com/vti/mojox-session this is the repository for that module...
21:10 pink_mist not whatever you think you found
21:11 pink_mist you clearly didn't go to the link I gave you
21:11 Onigiri I did though, but I already had that repo up from my google search.
21:11 pink_mist don't use google for perl stuff
21:12 pink_mist it's useless
21:12 pink_mist and in this case, misleading and wrong.
21:12 Onigiri indeed
21:16 Grinnz_ heh
21:17 fhelmber_ joined #mojo
21:22 polettix joined #mojo
21:31 vmbrasseur joined #mojo
21:58 Grinnz_ added an issue to Cpanel::JSON::XS, to see what reini thinks, https://github.com/rurban/Cpanel-JSON-XS/issues/37
22:02 sri Grinnz++
22:08 inokenty joined #mojo
22:26 genio joined #mojo
22:41 zackiv31 joined #mojo
23:15 inokenty joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary