<jhass>
I don't think so, it doesn't really make sense conceptually
<jhass>
a macro is a code transsformation step
<jhass>
it doesn't actually have a stack frame and thus return value
<FromGitter>
<didactic-drunk> Conceptually I want the macro to stop doing whatever it's doing. Similar to `return (nil)`
<FromGitter>
<Blacksmoke16> `if/else`
<FromGitter>
<didactic-drunk> Yes, but now It's one indentation level deeper/uglier.
<FromGitter>
<Blacksmoke16> welcome to macros :p
alexherbo2 has joined #crystal-lang
<jhass>
would you expect to be able to return early from a template?
<jhass>
macros essentially are templates
<FromGitter>
<didactic-drunk> Your talking about implementation details. I'm talking about form and function. It's named. It looks like a function. Yes.
<FromGitter>
<Blacksmoke16> user defined macros would help with this
<FromGitter>
<Blacksmoke16> as you could then put that logic outside of the template
<FromGitter>
<didactic-drunk> What if it wasn't implemented that way and was more like ruby, or even called ruby as a preprocessor step? Not allowing early return makes sense when looking from the bottom up, but not to me when looking from the top down of why can't I do it when I can do it elsewhere?
<FromGitter>
<jwoertink> Anyone know if there's any plan to make XML serializable like JSON and YAML?
<jhass>
XML is a lot more complex there, I don't see it happening in stdlib tbh
<jhass>
but there's nothing stdlib can do that a shard cannot
FromGitter has quit [Ping timeout: 260 seconds]
oprypin_ has joined #crystal-lang
oprypin has quit [Ping timeout: 260 seconds]
FromGitter has joined #crystal-lang
JuanMiguel has quit [Quit: This computer has gone to sleep]
<FromGitter>
<sam0x17> I've actually written some basic xml dsl's embedded in projects before, it's not hard if you have a limited domain you're doing it in
<FromGitter>
<sam0x17> depending on what you're doing you might also be able to just make use of ECR
<oprypin_>
i'd run it only if pkg-config is used for the first time
<Stephie>
yeah
<Stephie>
but its the compiler
<Stephie>
taking 200 more us doesnt matter
<oprypin_>
but on windows why would it look for pkg-config in all path directories
<oprypin_>
disk is slow and like the PATH on windows is huge usually
<Stephie>
cause its gonna use pkg-config *every* compile
<Stephie>
if you want to never use pkg-config on windows that one thing
<Stephie>
i'd like to know if it's ever been used there
<Stephie>
right
<Stephie>
there's precompiled pkg-config windows deps
<Stephie>
so, i'll say yeah people use it on windows
<oprypin_>
:o
<oprypin_>
the thing about find_executable is, should it find with & without .exe extension?
<oprypin_>
it probably should
<Stephie>
actually
<Stephie>
windows has an env var for path extensions....
<oprypin_>
wait it works right now. HOW
<Stephie>
PATHEXT
<Stephie>
wait what
<Stephie>
with .exe??
<oprypin_>
no it doesnt im studpid
<Stephie>
mood
<Stephie>
i'd like to know if cmd will search in path for stuff without ext
<Stephie>
we should copy it's behaviour
<oprypin_>
no it won't
<Stephie>
then, it shouldn't
<oprypin_>
anyway, find_executable won't blow up, you can just use it now. it's just wrong
<Stephie>
nice
<oprypin_>
it'd probably find "pkg_config" somewhere in PATH but not "pkg_config.exe"
JuanMiguel has joined #crystal-lang
JuanMiguel has quit [Quit: This computer has gone to sleep]
zorp_ has quit [Ping timeout: 264 seconds]
<oprypin_>
aha find_executable should, i think, match the behavior of what'd work with Process.run
<oprypin_>
and ... CreateProcess doesn't look at PATHEXT
<oprypin_>
and also it's really weird right now that find_executable is wrong even on posix, because it'll find any file that happens to match with PATH
<oprypin_>
going back to windows, expanding stuff like `.bat` is purely a thing shell does
<FromGitter>
<stellarpower> The markdown class in the standard library is a work in progress right?
<oprypin_>
the way that CreateProcess itself works is literally "if the path doesnt end with .exe, append .exe to it"
<oprypin_>
stellarpower, it's abandoned and hidden
<FromGitter>
<stellarpower> Ahh XD
<FromGitter>
<stellarpower> That would be why my compiler can;t find it
<FromGitter>
<stellarpower> I thought it was too old
<FromGitter>
<stellarpower> Perhaps it's too new
<FromGitter>
<stellarpower> Was there a particular reasn it was abandoned?
<oprypin_>
stellarpower, it's known to be incomplete and maintaining markdown as part of standard library is seen as undesirable
<FromGitter>
<stellarpower> Fair enough
<FromGitter>
<stellarpower> I think it would be useful but like regular expressions it's suffered hugely from too many standards
<FromGitter>
<stellarpower> and thought rather than making a PR if there was an ongoing disciussion about stdlib equivalent was gonna ask where I could share my thoughts
<FromGitter>
<stellarpower> Oh also quick question, is there anything equivalent to ruby's `methods` that lets us introspect what I can call on an object?
<FromGitter>
<Blacksmoke16> yes but its via macros
<straight-shoota>
"A pathname [...] that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname."
<straight-shoota>
So `a/` is to be treated as `a/.`, which normalizes to `a`
* straight-shoota
thinking
<straight-shoota>
But technically `.` refers to a directory, so there might actually be a semantic difference...
<oprypin_>
ah lol carcin has another layer of macros
<FromGitter>
<simonhf> hello! newbie question coming up :-)
<FromGitter>
<simonhf> I have a working crystal one liner: $ crystal eval --time --progress --error-trace 'h=Hash{"one" => 1, "two" => Hash{"foo" => 3}}; printf %[debug: >#{h}< >%s< >%s< >%s<\n], h["one"], h["two"], h["two"].as(Hash)["foo"];' debug: >{"one" => 1, "two" => {"foo" => 3}}< >1< >{"foo" => 3}< >3< β Execute: 00:00:00.011405934
<FromGitter>
<simonhf> Trying to figure out how to do nested hashes
<FromGitter>
<simonhf> In Perl I could do e.g. $h{two}{foo} which is much more compact...
<oprypin_>
well you did it fine so far
<FromGitter>
<simonhf> How can I get rid of the length ".as(Hash)" part?
<oprypin_>
crystal code usually isn't structured that way (and doesn't need to be for real world)
<FromGitter>
<Blacksmoke16> id prob avoid using hashes depending on the use case
<FromGitter>
<simonhf> If I have a nested hash several layers deep then lines will get very long :-)
<FromGitter>
<Blacksmoke16> prob better off with structs
<FromGitter>
<simonhf> @oprypin thanks! I write a lot of perl one-liners in my day to day work and am used to using nested hashes... how would you structure the hashes away?
<FromGitter>
<stellarpower> Sorry, another newbie question. Can we reference types in their "aliases"? Like β `Tree = Hash(Node, Union(Tree, Node))` for a recursive structure
<FromGitter>
<Blacksmoke16> i also wouldnt use recursive types :P
<FromGitter>
<stellarpower> what would be a better way of doing it?
<oprypin_>
simonhf, `record A, one : Int32, two : B; record B, foo : Int32; A.new(one: 1, two: B.new(foo: 3))`
<FromGitter>
<stellarpower> IN the scenario where I have an AST-style thing
<FromGitter>
<Blacksmoke16> recursive type using a struct
<FromGitter>
<stellarpower> I need to read up on structs
<oprypin_>
simonhf, then `p! h.one, h.two, h.two.foo`
<FromGitter>
<stellarpower> Think it throws my head a little using ruby-like syntax but C++-style thinking. All for the best but am meeting in the middle
<hightower4>
simonhf, right, as oprypin_ suggests, `record` would allow you to elegantly create structs. Another way could be using Tuples or NamedTuples. Yet another way could be using classes. Given those couple methods available, you'd decide on a case-by-case basis which one is best. Or for example, if your hashes always contain just 2 or 3 data types (like ints, strings, or further hashes), you could keep them in three separate hashes, so that each
<hightower4>
hash contains key/values of only one type, etc...
<FromGitter>
<simonhf> @oprypin thanks! trying to put your snippets into a one liner that works :-)
<FromGitter>
<simonhf> @oprypin the first part seems to define the structs, but no reference to h. the second part references h... which has me confused...
<oprypin_>
simonhf, oh sorry. `record A, one : Int32, two : B; record B, foo : Int32; h = A.new(one: 1, two: B.new(foo: 3)); p! h.one, h.two, h.two.foo`
<FromGitter>
<simonhf> @oprypin that works, thanks!
<FromGitter>
<simonhf> trying to wrap my head around this :-)
<FromGitter>
<j8r> @Blacksmoke16 Do you think it is ok to yield a namedtuple will all annotations keys (here for `Crystalizer::Field`)
<FromGitter>
<j8r> This allows to also set custom keys, I am not sure what to think
<FromGitter>
<j8r> On one side it allows to share annotations, but on the other hand a given key with a value may not be interpreted the same for different formats
<FromGitter>
<Blacksmoke16> idt that key is right, its not really annotations, more like named_argument users defined on the field annotation
<FromGitter>
<j8r> yes
<FromGitter>
<j8r> The format implementation will be more or less related to the library, at least official ones. I don't think there will be huge issues then
<FromGitter>
<j8r> Now, thinking of a standard `Any` type
<FromGitter>
<j8r> The main issue is how to get rid of the `@raw : T`
<FromGitter>
<j8r> An just serialize T
<FromGitter>
<Blacksmoke16> `any.raw.to_json`?
<FromGitter>
<j8r> Ha right, I am noob
<FromGitter>
<j8r> I can just set overloads in the formats which does this
<FromGitter>
<Blacksmoke16> prob yea
<FromGitter>
<j8r> Last thing, the `Type` alias in the Any
<FromGitter>
<j8r> I guess generics
<FromGitter>
<Blacksmoke16> hm?
<FromGitter>
<j8r> For example, in JSON `Hash(String, Any)` and in YAML `Hash(Any, Any)`
<FromGitter>
<Blacksmoke16> just `alias Any = JSON::Any | YAML::Any`?
<FromGitter>
<j8r> Just see there is `Set(Any)` in YAML... didn't know there are sets un yaml
<FromGitter>
<j8r> No, the principle here is to be generic - a single Any type for all possible formats
<FromGitter>
<Blacksmoke16> uses same logic as array, but does `Set.new arr`
<FromGitter>
<j8r> But why it is not in json?
<FromGitter>
<Blacksmoke16> :shrug: just wasnt implemented?
<FromGitter>
<j8r> better question: why it is here?
<FromGitter>
<Blacksmoke16> just was implemented? :P