<kevinsjoberg>
If I want to to loop over indexes starting from 1 in Crystal what would I do? I can do it using a regular loop but usually the each/each_with_index methods are preferred due to performance.
<kevinsjoberg>
I basically want to do, "loop from 1 to n-1". Would (1..a.size).times do |i| do?
<kevinsjoberg>
s/times/each/
<kevinsjoberg>
Yeah, this worrked: "1...sorted_list.size).each".
<FromGitter>
<naqvis> π
<FromGitter>
<naqvis> `1.upto(a.size) do |i| .....`
<FromGitter>
<manveru> is anyone monitoring the crystal keybase account? wrote to it about a security issue last week but got no response...
alexherbo2 has joined #crystal-lang
<raz>
manveru: security issue in crystal (security bug) or related to keybase?
<FromGitter>
<manveru> raz: in crystal
<jhass>
I think that key is just used and published there for distribution signing
<FromGitter>
<manveru> guess that didn't mean keybase chat though :)
<raz>
+1 jhass. that was actually my next question (does crystal have a formal process for such reports, and is it keybase)
<jhass>
I'll bring this up internally
<raz>
perhaps a simple email contact address (that goes to asterite et al) could work, for reports that should not be sent publcally
<FromGitter>
<manveru> it's actually an issue with shards, but that has even less contact options
<jhass>
how severe do you judge this? Given shards design I kinda doubt it's unexpected RCE or something, so you might just open an issue for now
<raz>
well, suppose RCE would be trivial with post-install hooks etc.
<raz>
but i don't see how any pkg manager could prevent that
<raz>
RCE is part of their job kinda ;)
<FromGitter>
<manveru> yeah, it's not super severe, mostly command injection for things like `shards lock`
<jhass>
hence I used "unexpected RCE" :)
<raz>
:D
<raz>
well played, sir
<FromGitter>
<manveru> :)
<jhass>
because yes, some RCE is part of its features
<FromGitter>
<manveru> indeed
<raz>
i guess a real bug would be if shards could be tricked into fetching/installing unexpected things (hi npm! o/ )
<yxhuvud>
or if stuff is written outside of the relevant directory
<FromGitter>
<manveru> i guess that might be possible, haven't done much more than a tiny PoC
<FromGitter>
<manveru> i'll make an issue
<raz>
yxhuvud: well, post-install scripts run as the current user. also it installs code that you presumably compile shortly after (which can again exec arbitrary commands)
<raz>
you kinda have to trust your deps by definition, there's not much shards could do to change that
<FromGitter>
<manveru> i compile my shards within nix sandboxes, not directly via `shards install`, so i like some separation of concerns
<raz>
ah... hmm
<raz>
ok perhaps shards could have a --dont-run-hooks option
<raz>
but that would likely break a bunch of shards
<jhass>
waj has been doing a lot of work on shards recently, I'm not sure if that's done or what all his plans are
<jhass>
I can imagine the latter issue not being completely out of scope there, so might be worth to do a ping on the issue before you invest too much time
<FromGitter>
<manveru> hm, i noticed that with shards master the versions now contain the commit
<jhass>
ah, see :D
<FromGitter>
<manveru> looks like `version: 0.1.0+git.commit.e61b200edb735d5676e11cbe56e8353c8b2ced0b` now
<FromGitter>
<manveru> so i guess that's done already :)
<FromGitter>
<manveru> would be nicer in a separate field, but well, not that hard to parse
<jhass>
mmh, I wonder if that was a side effect of the molinillo port already?
<jhass>
but then shards' own lockfile does not do it yet
<FromGitter>
<manveru> it probably just didn't need any update yet
<FromGitter>
<manveru> :)
<FromGitter>
<manveru> would be even nicer if it included the ref the rev is reachable from as well
<jhass>
mmh, actually wer we sure it's always included now?
<jhass>
taking a second look at the code I'm not so sure
sorcus has quit [Quit: WeeChat 2.8]
lunarkitty has quit [Ping timeout: 260 seconds]
sorcus has joined #crystal-lang
lunarkitty has joined #crystal-lang
<FromGitter>
<RomainFranceschini> Hi all, just wondering if someone already tried to compile crystal code as a shared library to embed in an app written in another language
<FromGitter>
<RomainFranceschini> I have a PoC with swift calling crystal code. I know Crystal is not meant to be used that way but I'm just curious
<jhass>
except for calling crystal's main function maybe
<jhass>
but yeah, I see no practical uses
<jhass>
the runtime is too invasive
<jhass>
especially including bdwgc
<yxhuvud>
Especially not with Swift. They are at *very* similar levels on the abstraction level chain.
deavmi has quit [Read error: No route to host]
deavmi has joined #crystal-lang
zorp_ has quit [Ping timeout: 272 seconds]
sz0 has quit [Ping timeout: 260 seconds]
sz0 has joined #crystal-lang
<FromGitter>
<RomainFranceschini> Thanks, yes it was just fun to do that I donβt intend to go further
<FromGitter>
<RomainFranceschini> Although having a shared crystal code base and use it across platforms would be nice
<FromGitter>
<RomainFranceschini> To define GUIs I mean
<jhass>
with platforms you mean techstacks?
rocx has joined #crystal-lang
<FromGitter>
<RomainFranceschini> Yes
<raz>
bringing crystal onto iOS would be cool tho. actually the only non-linux platform i'd personally be interested in
<raz>
esp. with apple glasses round the corner
<raz>
glasses + crystal, it even sounds right! :p
<FromGitter>
<naqvis> raz you need to evaluate Swift lol
<raz>
well, i've heard good things about it. but i'm not really keen on learning another language at this point
<raz>
plus there's so much synergy if you could write crystal both on client+server
<FromGitter>
<naqvis> hybrid apps?
<raz>
but yea... i'm just dreaming. prob rather unrealistic. ;)
<FromGitter>
<naqvis> everything starts with a vision and dream
<raz>
yes, but even if you don't go hybrid, just having the full codebase in the same language is great
<raz>
(that's the drive behind all those JS server-side frameworks after all. except... they started on the wrongest possible side of the fence)
<FromGitter>
<naqvis> true, but they still made their position in the competition and become defacto
<FromGitter>
<naqvis> almost everywhere you can find support from each and every mainstream vendor
<FromGitter>
<naqvis> i would blame this to JS only lol
allisio has joined #crystal-lang
<allisio>
Is it possible to multiple-assign to the result of a macro call without resorting to an Array in the macro?
<jhass>
you can return a tuple
<jhass>
or anything responding to #[](Int) really
<jhass>
multi assign is just syntax sugar rewriting a, b = c to _tmp = c; a = _tmp[0]; b = _tmp[1]
<allisio>
Right, sorry; I meant without having to "wrap" the body at all, since that's resulting in an inconvenient union type that doesn't manifest with plain-old multi-assign.
<allisio>
But I see that the absolute minimal case of something like `1, 2` isn't a valid macro body, so I suspect I'm barking up the wrong tree.
<jhass>
yeah I don't really see the issue with putting a { at the start of your macro and } at the end of it
<jhass>
you want it to evaluate to multiple values anyways, but why force the user to always call it in a multiassign
<allisio>
It's mostly that I want this particular bit of my DSL to look a certain way, but I'm realizing it's major yak-shaving.
<FromGitter>
<Blacksmoke16> Got an example?
<FromGitter>
<Daniel-Worrall> `ENV["CRYSTAL_WORKERS"]?.try &.to_i || 4` just used this little snippet to handle how many workers to initialise dynamically at runtime
<FromGitter>
<Blacksmoke16> Isn't that what's built in already?
<FromGitter>
<Daniel-Worrall> by workers, I mean for my script
<FromGitter>
<Daniel-Worrall> An Array of Runtimes and an Array of Mutexes to synchronise to them
<FromGitter>
<Blacksmoke16> Ahh gotcha
<FromGitter>
<Daniel-Worrall> Yeah, it's concurrent-safe but not parralel safe so I'm wrapping it
<jhass>
well our stance is to avoid shared state between fibers
<FromGitter>
<ArtLinkov> Hi, I'm trying to edit the ameba config to higher cyclometric complexity, I changed `shards.yml` to this: β β ```ameba: β github: crystal-ameba/ameba β version: ~> 0.12.1 β MaxComplexity: 30``` β β But it doesn't seem to work, any suggestions? (other than `ameba --except Metrics/CyclomaticComplexity` everytime I run ameba) [https://gitter.im/c
<FromGitter>
<j8r> won't be hard to do, still need to work on this
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<Blacksmoke16> does it work?
<FromGitter>
<Blacksmoke16> `unless ann && ann[:ignore]` does that mean the annotation is required?
<FromGitter>
<Blacksmoke16> i know `String` has quite a few ivars internally that messed up some stuff i tired to do a while ago
<FromGitter>
<Blacksmoke16> since it would try to set all of those as well
<FromGitter>
<j8r> annotation is not required
<FromGitter>
<j8r> `unless ann && ann[:ignore]` means `if !(ann && ann[:ignore])`, so if there is an annotation with a ignore
<FromGitter>
<j8r> I have taken this from stdlib :)
<FromGitter>
<didactic-drunk> Can I use a `macro` to add types to an array of types? β I have callbacks from a c function I'm trying to send through a channel without defining the method args 3-4 times. β Simplified example: β β ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ecbde0dff7a920a720e40c3]
<FromGitter>
<Blacksmoke16> ah right
<FromGitter>
<Blacksmoke16> @didactic-drunk something like that would prob work yea
<FromGitter>
<Blacksmoke16> might need to use standard `{% for x in y %}` syntax tho
<FromGitter>
<didactic-drunk> How do I make `MSGS` work taking arbitrary types?
<FromGitter>
<didactic-drunk> I don't need `MSGS` at runtime. Is there a compiler storage definition? @@@msgs?
<FromGitter>
<Blacksmoke16> how do you mean? its all at compile time so there arent really any types
<FromGitter>
<j8r> For [de]serializing anything, to "any" format
<FromGitter>
<j8r> Quick, don't know. I have the idea since a long time, I have resumed the works since several weeks
<FromGitter>
<j8r> I think it would be great to work together on this one @Blacksmoke16 :)
<FromGitter>
<Blacksmoke16> id say its more of a wrapper around stdlib stuff. any new formats would require moneky patching to add the pull parser methods, in addition to actually implementing a pull parser no?
<FromGitter>
<j8r> No
tdc has quit [Ping timeout: 264 seconds]
<FromGitter>
<Blacksmoke16> is pretty slick tho, nice approach
<FromGitter>
<Blacksmoke16> no?
<FromGitter>
<j8r> I just called the `to_json` and `new` of the stdlib to avoid reimplementing everything
<FromGitter>
<j8r> I can perfectly copy-paste on it, just lazy :)
<FromGitter>
<Blacksmoke16> yea thats fair. I just mean like what if you wanted to implement message pack?
<FromGitter>
<Blacksmoke16> wouldnt that be a non trivial thing?
<FromGitter>
<j8r> In addition of YAML and JSON?
<FromGitter>
<Blacksmoke16> yea
<FromGitter>
<j8r> That's not hard
<FromGitter>
<j8r> look at for example `json.cr` and the `json` directory
<FromGitter>
<j8r> a new module lie `MessagePack` will call `Crystalizer.each_var` for serialization, and do whatever it needs to convert an object to messagepack
<FromGitter>
<Blacksmoke16> but doesnt that assume the format already has some form of pull parser logic?
<FromGitter>
<j8r> not really
<FromGitter>
<j8r> You mean
<FromGitter>
<j8r> Iterating over ivars is not always possible?
<FromGitter>
<j8r> for me it is logical for formating each to a given format
<FromGitter>
<watzon> @j8r what are your thoughts on adding to crystalizer the ability to do what I thought `key` and `root` already did in `JSON::Serializable`?
<straight-shoota>
serde uses an internal data model for mapping between serialization format types and language types: https://serde.rs/data-model.html#types
<straight-shoota>
For a self-describing format, the deserializer can be used with `deserialize_any`, so the format implementation looks at the data and figures out the data type
<straight-shoota>
For non-self-describing formats, the deserializer must be told the data type to expect. And the implementation decides which format type corresponds to the serde type it's been told
<FromGitter>
<j8r> thanks to have clarified that
<FromGitter>
<j8r> In my case, I think it could be just an overload
<FromGitter>
<j8r> (there is already a way to iterate over ivars)
<FromGitter>
<j8r> ho, that's already possible - nothing to do lol
<FromGitter>
<j8r> Anyway, I did know serde and it looks great. I struggle to fully comprehend Rust code :/
<FromGitter>
<j8r> @watzon looking at the issue
<FromGitter>
<j8r> I think also `root` is confusing compared to `key`
<FromGitter>
<j8r> It would be cleared to have something like `key: "some.path"` - Even if it is not possible
<FromGitter>
<j8r> because of key which can have dots, which would need to be escaped etc
<FromGitter>
<watzon> Yeah, you could also use some other kind of separator, but it would be nice
<FromGitter>
<watzon> `key` could also be a `String | Array(String)`, and if it's an array it would use each item as a key.
<FromGitter>
<watzon> That's more or less what @Blacksmoke16 did I believe
<FromGitter>
<Blacksmoke16> i just a did a tuple and pass that to `.dig`
<FromGitter>
<watzon> That makes sense. Pretty simple.
<FromGitter>
<Blacksmoke16> its going to be harder in his case since the data isnt fully parsed yet
<FromGitter>
<watzon> Mmmm
lanodan has quit [Ping timeout: 260 seconds]
lanodan has joined #crystal-lang
<FromGitter>
<watzon> Ok there has to be an error in `HTTP::Client` or the `OpenSSL` binding itself somewhere. I was noticing issues myself, and now I've received an issue report in Tourmaline about it https://github.com/protoncr/tourmaline/issues/25
<FromGitter>
<watzon> Seems to be in OpenSSL itself based on the trace