<FromGitter>
<watzon> Nah not quite what I'm looking for. I'd like to handle JSON deserialzation in a similar way to Crystal, where you define types, converters, etc for JSON keys.
<FromGitter>
<Blacksmoke16> use crystal? :p
<FromGitter>
<watzon> Unfortunately Ruby is without annotations, so it definitely wouldn't be as clean as with Crystal
<FromGitter>
<Blacksmoke16> why use ruby in the first place then?
<FromGitter>
<watzon> Trying to do a project that will actually seem relevant to potential employers
<FromGitter>
<watzon> Unfortunately Crystal doesn't do much for a resume
<FromGitter>
<Blacksmoke16> do they actually care what lang? i usually just see like `relevant experience with a OOP language`
<FromGitter>
<watzon> In my experience they do, at least when you're aiming for senior level positions
<FromGitter>
<Blacksmoke16> fair enough
<FromGitter>
<Blacksmoke16> not related to that pokemon project i take it then?
<FromGitter>
<watzon> Yeah no haha. That one's in Crystal.
<FromGitter>
<Blacksmoke16> Nice. How's the serializer working out?
<FromGitter>
<watzon> It's working great
<FromGitter>
<Blacksmoke16> Find any bugs or anything?
<FromGitter>
<watzon> Not yet. I haven't really worked on the project since the other day.
<FromGitter>
<Blacksmoke16> 👍 ah gotcha
<FromGitter>
<Blacksmoke16> So far so good then ha
<FromGitter>
<stellarpower> @watzon do you mean like a JSON schema?
<FromGitter>
<stellarpower> I used a package in python called that
<FromGitter>
<watzon> Kind of. Deserializing JSON objects would require some kind of schema.
<FromGitter>
<stellarpower> What I saw was you can import data to ruby and then validate a hash against a class-like structure as a schema. Thus it's agnostic of the data source(I was using yaml)
<FromGitter>
<stellarpower> Are you reading from a stream?
<FromGitter>
<watzon> Nah just from a HTTP response body
<FromGitter>
<watzon> The problem is I have a lot of nested objects
<FromGitter>
<watzon> And the JSON needs to deserialize ObjectA which contains ObjectB which contains ObjectC.
renich has quit [Ping timeout: 256 seconds]
<FromGitter>
<mattrberry> Is there a way to override the getter defined by the property macro?
<FromGitter>
<Blacksmoke16> Use setter and define the getter manually
<FromGitter>
<Blacksmoke16> Do something to the macro code to conditionally define a unique getter for the special case
<FromGitter>
<mattrberry> That was my first thought, and I have a working approach with ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ but I don't necessarily want to have to apply the bitshift on every single call to a register [https://gitter.im/crystal-lang/crystal?at=5ec891e1f0b8a2053aa9f401]
<FromGitter>
<Blacksmoke16> Hmm
<FromGitter>
<Blacksmoke16> How do you mean?
<FromGitter>
<mattrberry> Like it'd be nice to be able to do something like:
<FromGitter>
<Blacksmoke16> So why not just do that
<FromGitter>
<mattrberry> I didn't realize that was a valid syntax :shrug:
<FromGitter>
<mattrberry> Thanks!
rocx has quit [Ping timeout: 260 seconds]
<FromGitter>
<sam0x17> yeah on that note, so ok apparently you can have default values in macro parameters? what else can you do? I'm assuming you can't directly specify types or anything (other than raising if it's the wrong type)
<FromGitter>
<Afront> are there other "paper books" on Crystal aside from *Programming Crystal*?
alexherbo2 has joined #crystal-lang
<FromGitter>
<galvertez> i'm curious about the `@[AlwaysInline]` annotation. gitbook says it gives a "hint" to the compiler. is that to say that the compiler will default to attempting to inline methods, or does it mean more like "try to inline this, but if not, no biggie"
<FromGitter>
<galvertez> that is, will the compiler tend toward inlining things, or *not* inlining, except where told otherwise
DTZUZO_ has quit [Ping timeout: 240 seconds]
DTZUZO_ has joined #crystal-lang
DTZUZO_ has quit [Quit: WeeChat 2.6]
_ht has joined #crystal-lang
<raz>
i don't know what the annotation does but would say the docs are in conflict there
<raz>
ah, just read up, actually they are not
<raz>
but i think the wording could be improved, e.g. "Tells the compiler to always inline" (since the word "hint" is misleading)
<raz>
since it's called "AlwaysInline" assume that's what it does (otherwise it should be called "PreferInline")
<raz>
i assume*
<FromGitter>
<galvertez> so the compiler does not default to inlining where possible, yeah?
<FromGitter>
<galvertez> i am wondering if private defs could be safely inlined by default
<FromGitter>
<galvertez> i mean it's trivial to just type the annotation where i think it belongs, was just thinking about it
<raz>
pretty surely it defaults to inlining where reasonable (based on optimization heuristics). if it would inline everything that's _possible_ (which is nearly everything) it would be a rather inefficient ;)
<raz>
(lots of duplication, cache pressure etc.)
yxhuvud has quit [Remote host closed the connection]
<jhass>
yeah, don't use the annotation unless your profiled your code and then on the call that you assume to be a bottle neck, tried it and profiled again
<jhass>
Crystal by itself inlines any block receiving methods, the rest is left to LLVM
<jhass>
so the annotation just sets an attribute in the LLVM IR. Weirdly enough I cannot find proper docs for it, best I could find is https://clang.llvm.org/docs/AttributeReference.html but even there it's just referenced in the docs for other attributes
<oprypin>
namedtuples should be used when they *must* be used, this doesnt appear to be such a situation
<Andriamanitra>
can you explain what you mean by that? namedtuples are as good as tuples and tuples are like, super nice i think
rocx has joined #crystal-lang
<jhass>
oprypin has the habit of stating his opinion as a fact ;)
<oprypin>
asterite's opinion too. close enough to fact
<jhass>
asterite's opinion of things isn't the most stable thing :D
<raz>
well, i think many people (incl. myself) often want to use them in situations where their limitations don't make them a good fit.
<raz>
like the above method arg example is probably a common wall people bump into because that's just such a common thing in ruby, js and other languages
<raz>
i think it's mostly the syntax that misleads (they kinda look like hashes, but don't behave like them at all)
<raz>
having an extra `MyStruct.new` in there isn't terrible, but it does add a bit of awkwardness. also in other situations (like passing **kwargs around) it gets more complicated.
<raz>
(i don't have good improvement-suggestions for these things, they're just observations from what i bump into quite regularly :))
<oprypin>
raz, dont foget u can do MyStruct.new(**kwargs)
<oprypin>
like, add on overload that does just that and passes it to the normal one
<raz>
oprypin: i know and i have. i also convert them to hashes sometimes, merge them (NamedTuple.new(**self, **other)) or get into a divorcement argument with nested macros.
<raz>
there are just some situations you don't *want* to put a struct-jacket on them. like when you want to allow the user to pass an arbitrary **kwargs onwards to a method he wrote himself (but still inspect it along the way)
<raz>
it's complicated, programming is hard :(
<oprypin>
raz, yea those latter are the situations for namedtuple
<oprypin>
though not so sure about inspecting them
<raz>
well, one day i'll find a good, short example to put on carc.in. in practice i unfortunately always run into it when already 3 levels down the rabbit hole and difficult to extract a meaningful example that fits in a pastie
<raz>
like atm i'm extending the jennifer mapping()-macro with some more stuff. it kinda works (except when it gets nested, like in my above simplified example)
<FromGitter>
<j8r> Struct are also a lot more flexible
<FromGitter>
<j8r> Complex namedtuples have also verbose typing :/
<FromGitter>
<j8r> How overloads is done undertheground? Is it simples if/elsif in LLVM IR? I can just see by myself
<FromGitter>
<j8r> So much code on the `.ll`, I don't know where to look at
<FromGitter>
<naqvis> does there exists a crystal bindings shard for cross-platform webview (https://github.com/zserge/webview) library?
<FromGitter>
<naqvis> webview is much more cleaner and light-weight than .... (don't want to write electron) lol
<FromGitter>
<watzon> I started working on one, then realized that webview is written in C++. So a library would require first writing a C wrapper, then wrapping that wrapper with Crystal.
<FromGitter>
<naqvis> aahh
<FromGitter>
<naqvis> double work it is
<FromGitter>
<watzon> Yeah lol. If only they'd written it in C.
<FromGitter>
<watzon> Though webview is pretty small itself I believe. Someone could attempt to write something in pure Crystal.
<FromGitter>
<naqvis> but looking at the header file, seems API is in C
<FromGitter>
<naqvis> though its interface with GTK, Cocoa etc are done via classes
<oprypin>
yes it is the reason for what i was saying, but not for what you're seeing
<oprypin>
or at least not in the way that i've predicted
<oprypin>
could of course be due to the webview thing forking itself
<FromGitter>
<naqvis> no clue
<FromGitter>
<naqvis> but at least this copying to `/usr/local/lib` working, though not happy path , but at least will give me chance to proceed with writing binding
<FromGitter>
<naqvis> thanks again, so as you suggested `LD_LIBRARY_PATH=foo bash -c '......'` should work
<oprypin>
haha no :)
<oprypin>
sorry for confusion
<oprypin>
that example is purely for demonstrating that the variable penetrates only exactly one process. bash is being used only as an environment-variable-printer there
<oprypin>
other than that it can only make things worse
<oprypin>
one day some knowledgeable person will come and say "oh you should just use @rpath" or "oh you should just use @executable_path" but i have no idea. and not having access to a mac doesnt help xD
<oprypin>
could be the way that the dylib is build. i should try running otool on mine
<FromGitter>
<naqvis> interesting
<FromGitter>
<naqvis> might be the way dylib is build
<oprypin>
naqvis, i think you have another very interesting option. building the webviewbinding as an object file rather than a dynamic library, and then linking it directly into your application
<oprypin>
probably will work better
<FromGitter>
<naqvis> yeah, but that will require linking against `WebKit` framework at time of compiling crystal source code
<FromGitter>
<naqvis> os x box you have SIP enabled?
<oprypin>
indeed it differs in that it has everything starting with @rpath
<FromGitter>
<naqvis> CI VM i doubt will enable SIP
<oprypin>
naqvis, oh it does
<oprypin>
thats why i've been having all those complaints
<oprypin>
travis ci doesnt have it enabled though
<FromGitter>
<naqvis> osx Catalina?
<FromGitter>
<naqvis> yes it is
<FromGitter>
<naqvis> same version as mine
<FromGitter>
<naqvis> 1) 15.3
<FromGitter>
<naqvis> 1) 15.4*
<oprypin>
naqvis, so the difference is that my dyld has an @rpath and yours doesnt. but even in my case it barely works (e.g. cant do `LD_LIBRARY_PATH=foo crystal run` as that's 2 processes deep) so it's hardly a solution
<oprypin>
i didnt do this @rpath thing myself, it's CMake's default
<FromGitter>
<naqvis> then I guess simple solution would be to avoid generating custom dylib
<FromGitter>
<naqvis> just link against obj file and then have final version link against system libs :)
<oprypin>
yes
<FromGitter>
<naqvis> and why in `@[Link(ldflags:` relative paths doesn't work?
<FromGitter>
<naqvis> i mean for custom build objs or libs, stored in custom locations, why it require to provide the full path?
<FromGitter>
<naqvis> can't we just use relative paths?
<oprypin>
naqvis, i think the main problem is relative to *what*
<oprypin>
in crystal's case, relative to $cache/.crystal/mangled-main-name.cr/
<oprypin>
thats why you specify relative to current file, using __DIR__
<oprypin>
naqvis, the important part is, the full path to obj will not be permanently stored, the obj will just be absorbed entirely
<FromGitter>
<naqvis> agree, but my point was that compiler does know where the file reside and definitely path is relative to that, so compiler could have taken care of that no matter where it compiles that code
<FromGitter>
<naqvis> DIR is an option, but no the clean one imo
<FromGitter>
<naqvis> or might be that compiler think, ppl will be just linking against system libs, so there won't ever be use-case of custom build objects