straight-shoota has quit [Ping timeout: 260 seconds]
_whitelogger has joined #crystal-lang
deavmi has quit [Read error: No route to host]
deavmi has joined #crystal-lang
<FromGitter>
<naqvis> Yeah, agree, this should be the right behavior
rcvalle has quit [Ping timeout: 240 seconds]
rocx has quit [Ping timeout: 260 seconds]
<FromGitter>
<Blacksmoke16> Think i should alias `.to_json` and `.from_json` to my implementation? I leaning towards no
<FromGitter>
<naqvis> yeah
<FromGitter>
<Blacksmoke16> now comes the fun part of how to wire this up to athena, while keeping it optional
<FromGitter>
<Blacksmoke16> well no, im getting ahead of my self. first write a bunch of tests and document all this :laugh:
<FromGitter>
<naqvis> I believe you are right on the topic
<FromGitter>
<naqvis> I also had this thought/question of optional dependency, but don't think shards is able to pull deps optionally on conditions specified
<FromGitter>
<Blacksmoke16> nope
<FromGitter>
<Blacksmoke16> sec
<FromGitter>
<naqvis> as it only differentiate between dev and non-dev deps
<FromGitter>
<Blacksmoke16> can do option 3, but is kinda hacky. I decided upon option 2
rcvalle has joined #crystal-lang
<FromGitter>
<naqvis> yeah, but how would you deal with `dependencies` section in shards.yml ?
<FromGitter>
<naqvis> should user add? or not add the entries for particular shard?
<FromGitter>
<naqvis> i mean requiring is different then shard pulling the lib
<FromGitter>
<Blacksmoke16> right, if they want to use it, they would have to add the shard
<FromGitter>
<Blacksmoke16> and require the corresponding ext file
<FromGitter>
<Blacksmoke16> plan atm would be to define the serializer as a service for the DI shard. Then the stuff that needs it, define it as an optional service so that if defined it'll be injected, otherwise itll be `nil`. Then i could use the serializer if its not nil and the type is my interface, otherwise falling back on `.to_json`
<FromGitter>
<naqvis> i was talking about something like rust cargo 'features`
<FromGitter>
<naqvis> they are very neat
<FromGitter>
<Blacksmoke16> yea, or really having a more official way to check if a shard is installed
<FromGitter>
<naqvis> yeah, i like your approach of overriding the default or falling back when user doesn't asks so
<FromGitter>
<Blacksmoke16> DI ftw 😉
<FromGitter>
<naqvis> but you are writing a more generic (de)serializer, how would user opt for (in/out)put format?
<FromGitter>
<naqvis> or am i mistaken on your plan you to support json,yaml etc?
<FromGitter>
<Blacksmoke16> the serializer would support JSON/YAML, however not sure I really need to allow them to customize the io format? who would make an api in yaml?
<FromGitter>
<naqvis> true, but how would this shard guess if usage is for json or yml?
<FromGitter>
<naqvis> i mean, this is more kind of a general package
<FromGitter>
<naqvis> where anyone willing to use general api irrespective of format can utilize it
<FromGitter>
<Blacksmoke16> sorry to be clear, im talking about having the serializer shard as an optional dependency within athena
<FromGitter>
<naqvis> and when needed, can invoke (de)serialize method and done
<FromGitter>
<Blacksmoke16> (my web framework)
<FromGitter>
<naqvis> yeah, I understand, but you will be using the ASR::Serializer in Athena and there its definitely will be dealing with json as in/out
<FromGitter>
<naqvis> but how would you configure ASR::Serializer in Athena to use json?
<FromGitter>
<naqvis> that was my question
<FromGitter>
<Blacksmoke16> ah, something like
<FromGitter>
<Blacksmoke16> ``````
<FromGitter>
<Blacksmoke16> ``````
<FromGitter>
<Blacksmoke16> guess you cant do code blocks in here?
<FromGitter>
<Blacksmoke16> just hardcode it realy
<FromGitter>
<naqvis> yeah, make sense then
<FromGitter>
<Blacksmoke16> the user could also define something on their own if they need more complex logic, this is just a sane default
<FromGitter>
<naqvis> looks very clean
<FromGitter>
<Blacksmoke16> thanks :) i try haha
<FromGitter>
<naqvis> 👍
<FromGitter>
<naqvis> another quick question on ASR::Serializer, behind the scences its wired to stdlib implementation of json/yaml, right?
<FromGitter>
<naqvis> believe you have done your own abstractions over stdlib ones?
<FromGitter>
<naqvis> what if new format is added or dev using via 3rd party shard?
<FromGitter>
<naqvis> is there a mechanism to have ASR::Serializer use different format?
<FromGitter>
<Blacksmoke16> yea, uses `JSON::Any` and `YAML::Any` under the hood, but adds another abstraction on top of them to provide a common interface
<FromGitter>
<Blacksmoke16> format is an argument when calling `#deserialize` or `#serializer`
<FromGitter>
<Blacksmoke16> so deff would be possible to have that be variable
<FromGitter>
<Blacksmoke16> however you cant reopen an enum, so it would have to be added to core first
<FromGitter>
<Blacksmoke16> as i was saying before a more robust solution would be to something within the shard itself versus relying upon json/yaml any and implement a proper interface/abstraction, but for now its prob fine
<FromGitter>
<Blacksmoke16> only other format i could see supporting that is common would be xml
<FromGitter>
<naqvis> yeah, but there are other binary formats like 'messagepack` etc
<FromGitter>
<Blacksmoke16> true
<FromGitter>
<Blacksmoke16> this is where optional shards would come in handy too
<FromGitter>
<naqvis> i would say having more general approach is better, thus giving dev options to go with any they need
<FromGitter>
<naqvis> by just implementing some interface and bingo they are done
<FromGitter>
<naqvis> true
<FromGitter>
<Blacksmoke16> require my shard, and require another shard that defines the parsing logic for it
<FromGitter>
<Blacksmoke16> required if you want to use type X
<FromGitter>
<naqvis> like in go, dev can just implement `Mashaler` interface with one method and they are ready for serialization, sames goes for UnMarshaler interface
<FromGitter>
<naqvis> yeah, agree that would be very clean interface
<FromGitter>
<Blacksmoke16> to be clear thats possible
<FromGitter>
<naqvis> json is always default, but one can ask for different format via URI
<FromGitter>
<Blacksmoke16> yup
<FromGitter>
<jwaldrip> Lets see how long it takes anyone to notice...
<FromGitter>
<naqvis> agree, if its already handling that way, then why not go with `NamedTuple` to specify the format?
<FromGitter>
<Blacksmoke16> :thinking: how would that be better than an enum?
<FromGitter>
<naqvis> that will save re-opening the struct to add new format (if there is any)?
<FromGitter>
<Blacksmoke16> kinda relying on the enum to return the correct visitor
<FromGitter>
<Blacksmoke16> sorry, when i was talking about re-opening the enum, i was saying that you cant
<FromGitter>
<Blacksmoke16> so to support a new format, they would have to open a PR to add that format to the `Format` enum, and provide visitors for it
<FromGitter>
<codenoid> `503 Service Temporarily Unavailable`
<FromGitter>
<Blacksmoke16> could use a string or whatever, but :shrug:
<FromGitter>
<naqvis> how about get rid of Format enum?
<FromGitter>
<naqvis> and pass the visitor as the param for method call?
<FromGitter>
<jwaldrip> Should not be
<FromGitter>
<Blacksmoke16> could work, but would be a strange API for the user
<FromGitter>
<Blacksmoke16> "whats a visitor?"
<FromGitter>
<naqvis> like `serialize(fmt : SerializationVisitorInterface).....`
<FromGitter>
<naqvis> defaults to JSON impl
<FromGitter>
<naqvis> this way, one needn't to provide the format
<FromGitter>
<Blacksmoke16> i used to use a module that included a specific interface
<FromGitter>
<naqvis> as shard will in-turn call respective impl methods when performing the (de)serialization
<FromGitter>
<Blacksmoke16> like `serializer.serialize obj, JSON`
<FromGitter>
<naqvis> yeah
<FromGitter>
<Blacksmoke16> that would allow using custom formats more freely, but if i recall there was some problem with it so switched to enum
<FromGitter>
<naqvis> default is JSON
<FromGitter>
<naqvis> aah
<FromGitter>
<naqvis> i've used modules extensively in shards i've built
<FromGitter>
<naqvis> and didn't encounter any issue
<FromGitter>
<naqvis> but i'm sure you must have hit by something
<FromGitter>
<naqvis> which I haven't
<FromGitter>
<naqvis> just sharing my thoughts and not necessarily you have to agree with all of them :)
<FromGitter>
<Blacksmoke16> all good. enum works quite well. I'm just skeptical that there are enough custom formats out there to have a need to make things less strict
<FromGitter>
<Blacksmoke16> in which case someone opening a PR adding a new format with some sort of implementation would be fine
<FromGitter>
<Blacksmoke16> messagepack already has an `Any` type, so might have to try a test implementation of it as a trial run
<FromGitter>
<naqvis> agree
<FromGitter>
<watzon> Oooh nice update
<FromGitter>
<Blacksmoke16> ill deff give that a shot once i get things more finalized
<FromGitter>
<naqvis> but my take was from different perspective, suppose i'm using this in my application, where need is to have another format other than what this shard offers (same messagepack)
<FromGitter>
<Blacksmoke16> actually, let me throw it in right now and see what happens
<FromGitter>
<naqvis> i can use this shard for implementation of JSON/YAML and extend visitor for other format
<FromGitter>
<Blacksmoke16> thats the idea, but that extension would require making a PR to the shard to scaffold some stuff
<FromGitter>
<naqvis> in this case, now I would have to change the code of this shard, to update enum
<FromGitter>
<Blacksmoke16> ill have to think on that, maybe ill try the module again
<FromGitter>
<naqvis> but shouldn't code be following the open-close principle?
<FromGitter>
<naqvis> i mean your awsome shard is already open where it does allow extension for new formats via visitor implementation
<FromGitter>
<naqvis> but tbh i'm reluctant in changing shard code-base for any new extension i've added
<FromGitter>
<Blacksmoke16> just that the enum doesnt play well with it :/
<FromGitter>
<naqvis> as this will require external shard updated code need to be shipped with my code for it to work on another machine
<FromGitter>
<Blacksmoke16> maybe just string constants would be ok
<FromGitter>
<naqvis> say CI
<FromGitter>
<naqvis> yeah, its just that enum stuff is not clicking with me
<FromGitter>
<Blacksmoke16> type safety :shrug:
<FromGitter>
<Blacksmoke16> prevents `:josn`
<FromGitter>
<Blacksmoke16> i do agree thats a big drawback, ill have to think on it more
<FromGitter>
<naqvis> :thubmsup:
<FromGitter>
<naqvis> i mean enum is good when we have fixed set of options, but your module is more general, so it shouldn't be restricted by enum
<FromGitter>
<Blacksmoke16> i guess i was viewing it as something fairly fixed
<FromGitter>
<Blacksmoke16> doesnt exactly work correctly atm, but would be something like that
<FromGitter>
<naqvis> thanks, and this proves how easy your shard is to get extended for new formats. I used msgpack just as an example, but i love the way you have put-up api for extension
<FromGitter>
<naqvis> and that could be any proprietary or non-custom format
<FromGitter>
<Blacksmoke16> ahh wasnt serializing the keys
<FromGitter>
<Blacksmoke16> apparently thats all it takes
<FromGitter>
<Blacksmoke16> anyway, off to bed for real now
<FromGitter>
<naqvis> wow, that's very neat and simplify things to much greater extent
<FromGitter>
<watzon> @jwaldrip it would be nice if dependents were listed somewhere. I see a count, but I don't see a list.
<FromGitter>
<jwaldrip> On my list to do ;-)
<FromGitter>
<jwaldrip> I have the data, just need to write the query
<FromGitter>
<watzon> 2 other things. How often are shards updated? And where does the email come from?
<FromGitter>
<watzon> Mine seems to be wrong haha, so I need to know where to update it
<FromGitter>
<watzon> Ahh nvm, it's from `shard.yml`
<FromGitter>
<watzon> Having a button to force an update could be nice
<FromGitter>
<jwaldrip> The indexer runs once per hour and will continue until the github rate limit is exceeded.
<FromGitter>
<watzon> Hmm nice
<FromGitter>
<watzon> Only other thing I can think of right now @jwaldrip, is that it could be nice to have some badges. For instance, dependencies and dependents badges that can be added to a README
<FromGitter>
<jwaldrip> There are a series of strategies. ⏎ 1) repo search for language=Crystal ⏎ 2) code search of file=shard.yml ⏎ 3) known GitHub api ids will try and update without using search ⏎ 4) unknown github api ids will search by url and update accordingly. [https://gitter.im/crystal-lang/crystal?at=5eafa8ad7a24ff01b0fda2b3]
<FromGitter>
<watzon> Nice redesign though. I like it.
<FromGitter>
<jwaldrip> Badges would be a fun addition. I'll add that to the list.
<FromGitter>
<jwaldrip> One thing to note that makes the redesign different than other indexes. Only projects with valid shard files will be indexed.
<FromGitter>
<watzon> It's one thing we're really missing for Crystal. I can think of a few that would be nice. Crystal version, dependents, and dependencies are the main ones.
<FromGitter>
<watzon> > One thing to note that makes the redesign different than other indexes. Only projects with valid shard files will be indexed. ⏎ ⏎ This is nice
<FromGitter>
<jwaldrip> Also, there is a blacklist maintained as a yml in the root of the repo. This will prevent those projects from showing on the front page.
<FromGitter>
<jwaldrip> Things like invidious have a valid shard file but don't provide themself to be useful to the community.
<FromGitter>
<jwaldrip> I still store those projects and I have thought of doing a separate projects area of the app, but I don't much see it's usefulness.
<FromGitter>
<jwaldrip> The purpose of the site is to empower creators
<FromGitter>
<jwaldrip> Generating docs is on my short list... just have to avoid all the system access you can do in macros.
<FromGitter>
<jwaldrip> If you don't mind opening issues for the things you would like to see, I can work on them.
<FromGitter>
<jwaldrip> Also, feel free to contribute. It was fun to build, but this was for the community and would love to see it be maintained by the community.
<FromGitter>
<watzon> Oh you're planning on actually generating docs for shards and having something like a central documentation repository? Like docs.rs?
<FromGitter>
<jwaldrip> Correct
<FromGitter>
<watzon> That would be awesome
<FromGitter>
<jwaldrip> Correct
<FromGitter>
<watzon> Any kind of API available or planned?
<FromGitter>
<jwaldrip> Gitter for iPhone... sorry about that
<FromGitter>
<jwaldrip> Would love to do that as well.
<FromGitter>
<watzon> It would be fun to build a telegram bot on the back of that API
<FromGitter>
<jwaldrip> I'm also going to be building a cli that provides some additional functionality and will allow things like `facet search kemal` or `facet add Kemal`
<FromGitter>
<jwaldrip> And clearly I have already thought of a name for the Cli ;-)
<FromGitter>
<watzon> Haha that would be awesome too
<FromGitter>
<jwaldrip> Facet : I.e. the side of a crystal
<FromGitter>
<watzon> I take it that `facet add` would add a dependency to `shard.yml`
<FromGitter>
<jwaldrip> Correct
<FromGitter>
<watzon> Which is something I've been hoping `shards` would integrate for a long ass time
<FromGitter>
<jwaldrip> Parse the yml, modify it, and write it
<FromGitter>
<watzon> That's awesome
<FromGitter>
<jwaldrip> I also want to add `facet install kemal`
<FromGitter>
<watzon> Well definitely let me know if there are any specific things you need help with, I'd be more than happy to contribute
<FromGitter>
<jwaldrip> Which would download, compile, and place the binary in your path.
<FromGitter>
<watzon> YES!
<FromGitter>
<watzon> Another thing that's been wanted by many for `shards` itself
<FromGitter>
<jwaldrip> The repo is open. PRs accepted anytime. It seems like the demand for api/cli is top of mind ;-)
<FromGitter>
<watzon> But... here we are
<FromGitter>
<jwaldrip> If you can't change the thing, build a new one ;-)
<FromGitter>
<watzon> Well I'll definitely take a look at the code base tomorrow and see what it would take to get an API going
<FromGitter>
<watzon> I see you're not using a framework?
<FromGitter>
<watzon> Oh wait, is `orion` a framework?
<FromGitter>
<jwaldrip> Orion for the web pieces
<FromGitter>
<watzon> Ok haha
<FromGitter>
<watzon> Never used it
<FromGitter>
<jwaldrip> I wrote it. Check the docs out. I think it's pretty comprehensive
<FromGitter>
<Blacksmoke16> by default string would use `ASR::Format.parse`
<sorcus>
Blacksmoke16: :-)
Xeago has quit [Ping timeout: 264 seconds]
<FromGitter>
<naqvis> So you mean, other than implementing the (de)serialize visitors, one also need to override these methods for new format?
<FromGitter>
<Blacksmoke16> yes
<FromGitter>
<naqvis> just use msgpack example, suppose its implemented by user of this shard, then what else steps he/she need to perform to have it enabled?
<FromGitter>
<Blacksmoke16> my thought is that if its like an "official" format, it'll be in the enum. Otherwise this gives the ability to extend it for private/custom formats not common enough to support in the main shard
<FromGitter>
<naqvis> then it definitely make sense
<FromGitter>
<Blacksmoke16> create the two visitors, and redefine these two methods to allow resolving the format to their visitor
<FromGitter>
<naqvis> my understanding was that, this allows common formats like json/yaml, but one can extend it for project specific use, without making any modification to the shard code-base
<FromGitter>
<Blacksmoke16> correct
<FromGitter>
<Blacksmoke16> and still provides the type saftey of the enum for common formats
<FromGitter>
<naqvis> as long as user of this shard are allowed to extend, I think it will be good
<FromGitter>
<chosenhood> Someone knows how to create a tuple like this using a macro? ⏎ P.S. (Yes, I have to use macros. It's a simple representation of my actual code) ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5eb010f27975db7ebfe2cacf]
<FromGitter>
<naqvis> personally I would have gone with asking the user to provide the concrete class as a param, which would do the (de)serialize
<FromGitter>
<tenebrousedge> `{{ NAMES.splat }}`
<FromGitter>
<naqvis> but I understand, there are always different ways to do same things
<FromGitter>
<tenebrousedge> or you can do it like you did
<jhass>
chosenhood: if outside a macro definition, you'll need a {% begin %} before the { and an {% end %} after the } to enter/exit the macro context
<FromGitter>
<naqvis> in that way, if tomorrow there is new XYZ format, one can simply invoke the methods by just passing the concrete class meeting the ASR::Serializer contract
<FromGitter>
<tenebrousedge> dang, gitter has threads now?
<FromGitter>
<naqvis> hurray, isn't it great 😆
<FromGitter>
<tenebrousedge> I guess we don't need slack now
<FromGitter>
<naqvis> with you 👍
<FromGitter>
<Blacksmoke16> ah, just not a fan of that. exposes too much to someone who just wants to serialize something, like `serialize obj, :json`
<FromGitter>
<naqvis> agree
<FromGitter>
<Blacksmoke16> plus if a new format is officially added they could just swap `:json` for `:xml` or whatever
<FromGitter>
<naqvis> true, but my thoughts were more on projects/dev which will use it for project specific use and they might have some proprietary or custom formats, which aren't going to be made public
v2px__ has quit [Ping timeout: 260 seconds]
<FromGitter>
<naqvis> i mean kind of stdlib like functionality, it offers general formats, but also allows custom extensions
<FromGitter>
<naqvis> but you already clarified that, one can still extend it for proj specific use, so I believe we are on same page now
<FromGitter>
<Blacksmoke16> in which case just redefining those two methods would be it. then there is a common API, and thats fairly simple
<FromGitter>
<naqvis> yeah, true
<FromGitter>
<Blacksmoke16> > i mean kind of stdlib like functionality, it offers general formats, but also allows custom extensions ⏎ ⏎ in what regard?
<FromGitter>
<jwaldrip> They dont work well on the iOS app :-/
<FromGitter>
<naqvis> like `Digest`, there are stdlib provided impls, but one can also add their own when needed
<FromGitter>
<naqvis> i mean, allows extension
<FromGitter>
<naqvis> and your shard is already doing that
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<Blacksmoke16> ill prob go with this for now and see how it plays out
<FromGitter>
<naqvis> and your shard is doing great work of unifying the (de)serialize API, thus hiding the actual format details
<FromGitter>
<chosenhood> thanks m8 totally 4got about begin and end
<FromGitter>
<naqvis> with you
<FromGitter>
<Blacksmoke16> mhm, the other big benefit is consolidating the macros
<FromGitter>
<Blacksmoke16> annotations*
<FromGitter>
<Blacksmoke16> `@[ASR::Skip]` would affect all formats
<FromGitter>
<Blacksmoke16> versus `JSON::Field(ignore: true)` ...
<FromGitter>
<naqvis> true and the best and cleanest thing is , one just need to know `ASR::Serialize` and full stop
<FromGitter>
<naqvis> don't need to know format specific (De)Serialize interfaces and calling format specific methods
<FromGitter>
<naqvis> tbh very clean and very friend for dev who dont' want to go into nitty-gritty details
<FromGitter>
<naqvis> at the same time open for dev who want to extend it for new formats
<FromGitter>
<naqvis> excellent job 👍
<FromGitter>
<Blacksmoke16> thanks :) I can't take all the credit tho
<FromGitter>
<Blacksmoke16> i asked maintainer about it. apparently there is a branch for 0.34.0 support that'll be released soonish
<FromGitter>
<Uzay-G> alright. And then I should just need to run `shards install` right? It doesnt seem to update the lib. Sorry but I am very much a beginner with crystal but I'm excited
<FromGitter>
<Blacksmoke16> i think its a bug with shards, i tested on master and it works. for now just rm -rf lib and shard.lock and run `shards install`
<FromGitter>
<Blacksmoke16> ran into this when using `branch: xx`
<FromGitter>
<Uzay-G> oh ok thx
<FromGitter>
<Uzay-G> that fixed that problem :). Now I have many others probably related to just fetching the last commit :0
<FromGitter>
<Blacksmoke16> hehe gl
<FromGitter>
<Uzay-G> yeah
<FromGitter>
<Uzay-G> I might just do not use the wrapper
<FromGitter>
<Blacksmoke16> :/
<FromGitter>
<Uzay-G> alright I fixed it :)
<FromGitter>
<Blacksmoke16> that was quick
<FromGitter>
<Uzay-G> I found the `cr-0.34` branch and just used that one
<FromGitter>
<Blacksmoke16> cool
lanodan has quit [Ping timeout: 256 seconds]
lanodan has joined #crystal-lang
<FromGitter>
<kingsleyh> evening: how do I convert this javascript to crystal: `1 + 0x80000000 == 2147483649`
<FromGitter>
<watzon> @kingsleyh basically you need something like this https://carc.in/#/r/90bp
<FromGitter>
<watzon> Of course the code will depend on the endianness you want
<FromGitter>
<watzon> @gla
<jhass>
possibly not even needing the .pos
<FromGitter>
<watzon> @Blacksmoke16 seems about right to me. Would `find_by` args try to find with all the args though? Or just ones that are private keys?
<jhass>
given the stuff you write before
<FromGitter>
<watzon> Yeah probably not
<FromGitter>
<Blacksmoke16> it would AND together all them
<FromGitter>
<kingsleyh> @watzon hmm it's not putting stuff in the right order so maybe I do need pos
<FromGitter>
<kingsleyh> oh no its ok - I used write_bytes for a single byte and it expanded it more than I though
<FromGitter>
<kingsleyh> I should have used write_byte singular for that one
<FromGitter>
<watzon> I just realized, I don't think you have enough space. The data you're trying to put on the end takes up 8 bytes, but after your `copy_from` operation you only have 5 bytes left over as far as I can tell
<FromGitter>
<watzon> Ahh ok haha, well if you got it working that's great
<FromGitter>
<kingsleyh> well I don't have it working yet lol
<jhass>
that's the downside of IO::Memory, it'll silently regrow to make space
<FromGitter>
<watzon> @Blacksmoke16 so in the ideal situation I feel like it should just be upserting based on the pk. Using `find_by` will attempt to find a record using all the args, right? So unless a record matches exactly it is only ever going to attempt to create a new record.
<FromGitter>
<Blacksmoke16> ah true
<FromGitter>
<watzon> And if it does match exactly that kinda defeats the purpose of updating
<FromGitter>
<Blacksmoke16> i think there is a method to get the pk value
<FromGitter>
<watzon> If there is that would be awesome
<FromGitter>
<Blacksmoke16> could make it where the first arg is the pk to lookup, then you can drop that into a `find`
<FromGitter>
<watzon> For now I guess I'll just check if the record exists and handle the logic myself
<FromGitter>
<watzon> > could make it where the first arg is the pk to lookup, then you can drop that into a `find` ⏎ ⏎ That would work as welll
<FromGitter>
<Blacksmoke16> same logic but replace `find_by` with `find`
<FromGitter>
<Blacksmoke16> then assume rest of args are the things to update/create with
<FromGitter>
<Blacksmoke16> would also require all required args to be included in that tho
<FromGitter>
<kingsleyh> @watzon the `1_i64 + 0x80000000` is not working - the js result is: `002b4be7f19ee27bbf30c667b642d5f4aa69fd169872f8fc3059c08ebae2eb19e780000001` but I'm getting `002b4be7f19ee27bbf30c667b642d5f4aa69fd169872f8fc3059c08ebae2eb19e70100008000000000`
<FromGitter>
<watzon> Oh so you're just trying to add `80000001` to the end?
<FromGitter>
<kingsleyh> the first number changes: e.g. 1 can be any number then you add it to the 0x80000000. and put it on the end of the array
<FromGitter>
<Uzay-G> but I just get connection refused
<FromGitter>
<Blacksmoke16> anything in the db logs?
<FromGitter>
<Blacksmoke16> make sure pw, username, etc is correct
<FromGitter>
<Uzay-G> maybe i need to specify port?
<FromGitter>
<Blacksmoke16> maybe? id imagine it would be using the default tho
<FromGitter>
<Uzay-G> i have a user postgres with db onyx
<FromGitter>
<Uzay-G> so I am trying: `Clear::SQL.init("postgres://postgres@localhost/onyx", connection_pool_size: 5)`
<FromGitter>
<Uzay-G> weird: `You are connected to database "onyx" as user "postgres" via socket in "/var/run/postgresql" at port "5432".`
Stephie has quit [Quit: Fuck this shit, I'm out!]
Vexatos has quit [Quit: ZNC Quit]
Stephie has joined #crystal-lang
<FromGitter>
<z64> has there been any discussion about backtraces with `Log.err(exception: ex)`? ⏎ they're often invaluable in helping with user reported errors of our app and at the moment I just end up adding `Log.error { ex.inspect_with_backtrace }` after every `Log.err` call
<FromGitter>
<Blacksmoke16> wouldnt that be better suited to the formatter?
<FromGitter>
<Blacksmoke16> or backend
<FromGitter>
<Blacksmoke16> as you have it within the entry
<FromGitter>
<Blacksmoke16> @Uzay-G are you doing anything other than trying to connect? could be failing on some query?
Vexatos has joined #crystal-lang
<FromGitter>
<z64> that is what i am asking. will I have to customize the formatted or has there been any movement about supporting that in the stock backends? i haven't been following the discussion, been too scattered between prs/issues to keep track of lately
<FromGitter>
<Uzay-G> idts @Blacksmoke16 because it says the connection is refused