* FromGitter
* Blacksmoke16 hopes it doesn't change again to `2020-06-10` tomorrow :P
renich has joined #crystal-lang
renich_ has joined #crystal-lang
renich has quit [Ping timeout: 260 seconds]
renich_ is now known as renich
renich_ has joined #crystal-lang
renich has quit [Ping timeout: 260 seconds]
renich_ is now known as renich
renich has quit [Quit: renich]
chachasmooth has quit [Ping timeout: 260 seconds]
chachasmooth has joined #crystal-lang
DTZUZU has joined #crystal-lang
_ht has joined #crystal-lang
mistergibson has joined #crystal-lang
<raz>
mmm libxml
<raz>
soon we'll need a bundler-audit for crystal
<raz>
shardler-audit
<FromGitter>
<naqvis> libxml isn't that part of stdlib
<raz>
i'm sure that will be fixed after the 6th CVE or so :P
<FromGitter>
<naqvis> :D
<FromGitter>
<naqvis> are there any breaking changes in latest version of libxml?
alexherbo2 has joined #crystal-lang
<raz>
no idea. i only remember it because nokogiri pops up in bundler-audit every now and then. but looking at the history it doesn't actually seem that bad (1 in 2020, 3 in 2019)
alexherbo2 has quit [Remote host closed the connection]
<FromGitter>
<naqvis> should be really good
<FromGitter>
<naqvis> i remember last time (due to some forum thread) there was a discussion on scanning the docker images of Crystal, there were many CVE
<FromGitter>
<naqvis> for that were all due to base images
<FromGitter>
<naqvis> alpine based images seems quite great wrt to CVE
<raz>
yea i think in the long term it would be nice to have CVE checks baked directly into the shards-utilit
<raz>
or perhaps integrate with the github/gitlab security checks
<raz>
but haven't thought about it much yet
<FromGitter>
<ImAHopelessDev_gitlab> @Blacksmoke16 i just read an entire github about the placement of an io named argument
deavmi has quit [Ping timeout: 260 seconds]
deavmi has joined #crystal-lang
<raz>
all of github? like back-to-back? :D
zorp_ has joined #crystal-lang
deavmi has quit [Ping timeout: 256 seconds]
deavmi has joined #crystal-lang
duane has joined #crystal-lang
<FromGitter>
<neutrinog> hey, I'm porting a constraint solving algorithm (for calculate GUI constraints) and I've been moving all of the operations into handy dandy methods like `def ==(...` so I can easily specify constraints like `x == y + 10`. Pretty straight forward and works great. However... I'm running into a problem when my constraint equation looks like this `(x + 10) == 20`. The compiler thinks it's a boolean. If however I
<FromGitter>
... have a constraint equation with a variable on either side everything works fine `x + 2 == y + 10`.
<FromGitter>
<neutrinog> I think my solution will be to change the float operator arguments to `Number` and then simply `to_f64` it in the constructor. Is there any reason why I shouldn't use `number.to_f64` blindly like that?
<FromGitter>
<neutrinog> I just like the option to not have to affix `f64` to all my numbers.
<FromGitter>
<Blacksmoke16> prob would be fine
<FromGitter>
<Blacksmoke16> assuming the numbers wont be big enough to lose precision?
<FromGitter>
<neutrinog> I think f64 will be as large as anyone will need.
<FromGitter>
<neutrinog> This is only for UI constraint calculations.
<FromGitter>
<Blacksmoke16> 👍
mistergibson has quit [Quit: Leaving]
<FromGitter>
<neutrinog> so now that I'm overriding all of the `==` methods I can't perform regular object comparison. Is there a way to do object comparison without using `==`?
<FromGitter>
<neutrinog> Externally, I want to use `==` because it's convenient for writing constraints. Internally (in the constraint algorithm) I want to be able to do regular object comparison (is that object this object).
<FromGitter>
<neutrinog> it would be ok if I had to write some black magic and use a custom `.equals` method for internal use.
<jhass>
mmh, I don't think we really have alias/alias_method
<jhass>
what kind of objects are you defining == for?
<jhass>
and what does regular object comparision actually mean for them?
<jhass>
(sorry, I dind't read up on all the above)
<jhass>
as you can see for Reference types, if you want that default implementation, you can just call same?
<jhass>
for struct it's a bit more complex
<jhass>
but maybe equality is domain specific for your objects anyhow?
<jhass>
so just define your own method for internal use
<FromGitter>
<neutrinog> externally yes, but internally the algorithm treats them as regular objects in a hash and needs to perform regular object comparison.
<FromGitter>
<neutrinog> `same?` should be exactly what I need.
<jhass>
mmh, yeah putting them in hash and overriding == seems dangerous
<FromGitter>
<neutrinog> Though I'm probably going to migrate everything to structs eventually.
<jhass>
maybe you should have a DSL object and an internal version?
<jhass>
the DSL version could be a simple struct wrapper around the internal one
<jhass>
and for storage you fetch the internal one from the wrapper
<FromGitter>
<neutrinog> That would probably be a bit safer to maintain.
<FromGitter>
<neutrinog> actually, the algorithm needs to keep track of these particular objects anyway so it can update the values. So I'll need to at least store them in an array and map the index to some key.
<FromGitter>
<neutrinog> using `same?` might actually be less ugly. And the worst that could happen is the compile will scream at me if I accidently use == internally.
<jhass>
still might make sense to decouple the state from the DSL? struct Expression; @state = ExpressionState.new; def ==(other); @state.restrict_equals(other.@state); end; end; Idk, probably the particular example doesn't quite capture what you're doing but it illustrates the concept of a wrapper that provides the pretty API but delegates any state changes to some internal object which you can
<jhass>
then fetch, store and reconstruct a DSL wrapper around as needed
<FromGitter>
<neutrinog> yeah that makes sense.
<FromGitter>
<neutrinog> initially all of the operators were decoupled as global methods (from the java source).
<FromGitter>
<Blacksmoke16> i.e. allow mutating a hash of data at compile time that could be later used to do whatever
<FromGitter>
<Blacksmoke16> if that's something that is actually wanted is still TBD, hence why that PR is in limbo ha
<FromGitter>
<naqvis> that's neat
<FromGitter>
<naqvis> i'm just thinking what if i misspell or don't add `compile` macro, will I get compile-time error?
<FromGitter>
<Blacksmoke16> related to the serialization stuff we been talking about, i think it could also be used as a way for users to define custom exclusion logic of their ivars
<FromGitter>
<naqvis> though i include `CompilerPass`, but don't provide `compile` macro, what would happen?
<FromGitter>
<naqvis> yeah, true. and Its really very neat
<FromGitter>
<Blacksmoke16> if its not handled by default, id deff add some custom validation to raise if its not right; like not a module and/or doesnt have that method
<FromGitter>
<naqvis> gotcha 👍
<FromGitter>
<Blacksmoke16> yup, be a better way to handle *most* custom annotation exclusion stuff
renich has joined #crystal-lang
renich has quit [Client Quit]
renich has joined #crystal-lang
renich has quit [Ping timeout: 256 seconds]
renich has joined #crystal-lang
<FromGitter>
<lbarasti> Hi folks, trying something new, premiering a live-coding session on building a DSL interpreter in Crystal now: https://www.youtube.com/watch?v=C8R5GYJ9KYo